[Ecls-list] BIG change

[Juan Jose Garcia-Ripoll]

I have just committed a huge patch that adds support for NaNs and
infinities. I gave priority to this because it interferes with the FPE
trapping and there are later changes to be done to signals in general.
Let me first list the changes and then explain some problems.

 - Added a new section in external.h for defining compatibility macros
   for functions that changed name.

 - make_longfloat() is renamed ecl_make_longfloat().

 - A new configuration flag --with-ieee-fp adds support for NaN's, infinities
   and signed zeros, disabling certain floating point exceptions by default.
   In addition, when this is set, functions like LOG or ATAN will not
   signal errors when their arguments are not valid, but rather return NaN's
   (LOG 0) => -infinity, (ATAN 0.0 0.0) => NaN

 - A new command line option --trap-fpe / --no-trap-fpe tells whether ECL
   should ignore floating point exceptions and produce NaNs and infinities
   or either use the condition system to produce the associated errors.

 - Two new functions, EXT:FLOAT-NAN-P and EXT:FLOAT-INFINITY-P.

 - Eight new constants for the eight possible infinities
   EXT:{SHORT,SINGLE,DOUBLE,LONG}-FLOAT-{POSITIVE,NEGATIVE}-INFINITY

 - SI:TRAP-FPE always returns an integer denoting the new active / inactive
   floating point traps. In particular, (SI:TRAP-FPE 'LAST T) returns the
   currently active traps. This value can be passed to SI:TRAP-FPE as first
   argument again. This is useful for performing a computation without traps
	(let* (( (si::trap-fpe 'last nil)))
	  (prog1 (/ 0.0 0.0) (si::trap-fpe bits t)))

The patch is done in a way that NaNs and infinities are always there
-- they can be generated, they can be printed --. The only difference
that the configuration flag --with-ieee-fp makes is that it tells ECL
to let these no-numbers and infinities get to the user. If you use
--without-ieee-fp ECL will trap at run time the NaNs and infinities
and generate errors when they are created.

That is at least the theory. Funny enough, intercepting floating point
errors is much more difficult than letting NaNs and infinities be
produced. In other words, ECL will work best when doing full IEEE
computations and ignoring those errors.

The reason is that this interception may or may not happen due to C.
If ECL has inlined your calculations unboxing the floating point
numbers, it will produce no checks for the generation of invalid
operations or infinities. It is only when these values are boxed, that
it will detect them and probably generate an error.

Trapping floating point exceptions is not portable and it is not
always supported by the operating system. For instance, Mac OS X
libraries are compiled with traps disabled, and when you try to set
them on, they are many times disabled by functions such as printf, or
numerical functions.

Indeed, this seems to be what ISO C99 mandates: the only portable
thing is to check the exception flags of the floating point
environment after a computation. Since that is very costly, I decided
to try to switch on traps (Linux / Windows) and intercept NaNs and
infinities at the only reasonable and lest costly place: when they are
boxed.

Right here I may have lost most of you. So let me summarize the most important:

1* You pass --with-ieee-fp or nothing at all at configuration time.
ECL will produce NaNs and infinities. (/ 1 0) will raise a
division-by-zero error, while (/ 1.0 0) will produce an infinity.

2* You pass --without-ieee-fp at configuration time. ECL will
intercept NaNs and infinities, generating
floating-point-invalid-operation or division-by-zero errors at run
time.

3* You build with --with-ieee-fp but launch ECL using --trap-fpe. ECL
will behave as in 2)

4* You build with --without-ieee-fp but launch ECL using
--no-trap-fpe. ECL will behave as in 1)

Please comment. The patch has been uploaded today.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com