On Tue, 3 Feb 1998, Bruce Cohen wrote:

> 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,
Accepted.

....snip...

> On the other hand, of course, there's no way of knowing how much code
> would break if it saw NaN's coming back.  Well, that's the tradeoff:
It sees NaNs coming back from primitiveLogN at the moment - being made
to understand them can only be an improvement. Tim's fixes presumeablly
do that - at least so printOn: can deal with NaN.

....snip...

That aside, the other problem, in the definition of raisedTo: (in terms
of ln, however that should deal with -ve receivers) was the inspiration
for the modifications. Incidentally, I forgot to mention that I put
primitiveFloatRaisedTo in at primitive 39 in my fileins, which is
probably naughty, or something, but it does the job for me. Has no
smalltalk user ever need to do powers of -ve numbers before ;-) ?

Cheers,
Hamish