I agree that the Linux VM wasn't compiled with an MS compiler.  The problem
I referred to is that the MS compiler runtime gives different results for
debug vs. release builds, but I think that's a secondary issue.  Consider
the implementation of Float>>raisedTo:.  It ends up taking the natural
logarithm of the target object, which in the case which is producing
problems is 0.0.  log(0.0) *should* (I think) give back a NaN of some
variety, probably an negative infinity.  The problem is (apparently) that
some compilers/runtimes are doing so and some aren't, or are combining "two
wrongs" and making a "right".  (By this I mean that some compilers/runtimes
are producing negative infinity when the log of 0.0 is taken, then are
taking the exponential of negative infinity and producing zero.  I'm not
sure what's right here (should the results of exp(-infinity) be 0.0 or a
NaN?), but it's certainly not being handled consistently).

Bob Jarvis
The Timken Company

> -----Original Message-----
> From:	Richard L. Peskin [SMTP:rlpcon at vermontel.net]
> Sent:	Thursday, February 18, 1999 12:27 PM
> To:	squeak at cs.uiuc.edu
> Subject:	RE: That Linux Squeak 2.3 float error again
> 
> At 2:24 PM -0500 2/18/99, Jarvis, Robert P. wrote:
> >This situation arises because the implementation of Float>>raisedTo: uses
> >logarithms to calculate the result.  On the Windows platform it turns out
> >that the Microsoft C++ runtime lib gives back some unusual results for
> >exp(log(0.0))
> 
> I doubt if the Linux Squeak uses MS C++. Does this imply that the problem
> is in the Pentium fp?
> --dick
> 
> 
> =================================
> R. L. Peskin,  Rutgers Univ. ; <peskin at caip.rutgers.edu>;
> <http://www.caip.rutgers.edu/~peskin>
> VT Phone (802) 824-4558  NJ Phone (732) 445-4208
> "The corporate culture is concerned less with Occam's razor than his
> aftershave lotion."