>"Hamish \(DP\) Harvey" <dh4180 at bristol.ac.uk> wrote:
>>>  Any comments would be of interest. Is there any reason not to do this?
>>>  Does it reduce portability? Is there another way to define raisedTo: such
>>>  and ln such that they either work or throw and error, rather then
>>>  surreptitiously returning garbage?

Bruce Cohen replied:
>Well, from the narrow point of view of making the existing design work,
>this is reasonable.  But I would argue that NaN is not garbage, but a
>portable way to show numeric errors, since its part of the IEEE Floating
>Point standard, which ought to be available on all platforms.  I know,
>it's not available (or properly implemented) everywhere, but it seems to
>me that if we're trying interested in making it easier to use Squeak for
>a wide range of applications, including those that do heavy-duty numeric
>computation, that we ought to upgrade the design to meet the standard,
>which wasn't complete when Smalltalk-80 was designed.

I ran into the problems that Hamish did as well, awhile back.  It turns
out that not only NaN's, but Inf's and denormalized numbers have problems
in Squeak, as well.  My solution was to extend Squeak to handle these
special values, so that any of these values returned from a primitive
would be propagated and handled correctly within Squeak.  I don't think
that these fixes affect systems that don't implement IEEE-754 (any out
there, now?)

See enclosed change-set for details.



      -- tim


Attachment converted: Cog:Float Fixes.cs (TEXT/R*ch) (0000B47C)