Paolo Bonzini a écrit :
>> What I have personally no clue about is whether anyone ever uses
>> float-valued NaNs for anything useful.
> 
> It allows delaying error checking to after the end of the computation.
> Some errors that do not affect the result would be silently ignored;
> most errors would result in a NaN.  Of course Smalltalk floats are so
> slow that this might not even make a difference (unless you use FFI to
> interface with external libraries).
> 
> With floating-point, I decided that the best course of action is "assume
> the IEEE-754 people are always right" (and that means W. Kahan mostly).
> 
> Paolo
> 
> 

This is a wise decision for most current situations.

What is unwise is to not fully support IEEE 754 Exception handling.

Default IEE754 rules are not mathematically well founded
They are just pragmatic hacks for solving nicely and efficiently some 
common problems.

If we have have different requirements we should be able to trap FPU 
exception and provide our own exception handling. And this should occur 
from within the image if we pretend Smalltalk is a general purpose language.

What I would like is better IEEE 754 integration and portability.
1) portable way to declare and handle extended double (long double in C)
2) portable way to get/set FPU sticky error flags
3) portable way to activate and catch FPU exceptions
4) portable way to select rounding mode

Alas, that's one point where IEEE 754 success was incomplete...
When reading ieee man pages, it seems there are as many interfaces as OS 
versions...
I don't even know which hardware supports or not these traps...
I even wonder if such features were mandatory...
That should not stop us: as suggested, Smalltalk is already sufficiently 
slow to afford a sticky flag test at each Float primitive in case no 
hardware trap is available.

With a portable C library, we could afford a few more primitives and 
decide at image level how to handle these Exceptions (either a 
primitiveFail or a quiet NaN in case of INVALID operation for example).

I understand this is not a Smalltalk priority; ST is not known as a 
flying Float cruncher...
However, ST markets should better not be restricted by the kernel...

Nicolas


PS: sure, I know gst is among best behaved (with STX) having extended 
double...