"Hamish \(DP\) Harvey" <dh4180 at bristol.ac.uk> wrote:
>> So, Attached are two fileIns. The first (PFImprv1.st) contains the updated
>> Interpreter>>primitiveLogN which fails if the result is NaN and a new
>> method Interpreter>>primitiveFloatRaisedTo which is defined in terms of
>> the C math library pow() function. This primitive fails if the receiver or
>> argument are not floats, or if the result is NaN.
>> 
>> The second contains replacement Number>>raisedTo: and Float>>raisedTo:
>> methods which make use of the new primitive and allow raisedTo: to be used
>> on -ve receivers.
>> 
>> There are some comments at the top of PFImprv1.st.
>> 
>> 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?

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.

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:
look forward or look backward.  My own bent is forward, but I've had to
watch where I was coming from (in order to see what was about to bite
me) enough times that I'm very receptive to both sides of the argument.

Would it be possible in the case of operations that generate a NaN to
throw an exception or signal primitive failure as appropriate, but
somehow stash the NaN in the execution context so an exception handler
can get it?  A platform that implements the full IEEE standard can put a
lot of information in a NaN that can be used to recover intermediate
results from numeric failures; a handler could use that information if
it were available.
-----------------------------------------------------------------------------
"Designers are pretty bright people, however.  They can come up with a
plausible-sounding example for almost anything." - Donald Norman
-----------------------------------------------------------------------------
Bruce Cohen,                               |  email: cohenb at gemstone.com
GemStone Systems, Inc.                     |  phone: (503)533-3602
20575 NW Von Neumann Drive                 |  fax:   (503)629-8556
Beaverton, OR USA 97006                    |  web:   http://www.gemstone.com