[Chicken-users] Cleaning up floating-point-specific operators

[Will M Farr]

Hello all,

Due to the discussion of floating-point performance on this list  
initiated by Carlos Pita, I've been writing some toy benchmarks which  
use the fp+, fp-, etc operators.  The situation with these operators  
is a *mess*:

1. The binary arithmetic operators fp+, fp-, fp*, fp/ check their  
arguments for flonum-ness even in unsafe mode.
2. The binary operators fp<=, fp>=, etc, do not check their arguments  
for flonum-ness even in safe mode.
3. fp/ throws an error on division by zero instead of returning nan  
(when (fp/ 0.0 0.0)) or +/- inf (when (fp/ x 0.0)).

#1 directly contradicts the manual (which states that these operators  
do not check their arguments ever); #2 is very unsafe (though in  
keeping with the warning in the manual); #3 is an exceedingly bad  
idea in numerical algorithms---these often depend on getting infinite  
results for some calculations---and will shock the expectations of  
anyone who comes to Chicken from a numerical analysis background  
(i.e. me).

The attached patches to runtime.c and library.scm should fix these  
issues.  Here is what they do:

1. Add a (flonum? x) predicate to the library.
2. Implement the following type-checking rules for all fpXXX operators:
	a. In safe mode, check that arguments are flonums and throw an error  
if not
        b. In unsafe mode, check no arguments
3. Modify fp/ to return +/- inf (or nan if (fp/ 0.0 0.0)) when  
dividing by zero.  Trust me---if you're using floating point code,  
this is what you want.  In fact, many numerical codes depend on this  
behavior.

I feel like #1 and #3 should be uncontroversial (if you're suspicious  
of #3, I would recommend consulting the nearest person who writes  
numerical codes for a living).  #2 reflects my preference, but two  
consistent alternate behaviors could be:

2'. fpXXX operators do not ever check their arguments for flonum- 
ness.  (This is the current claim of the manual.)
2''. fxXXX operators always check their arguments for flonum-ness.

I would argue against 2' with two points: 1) it's annoying to  
accidentally crash the interpreter when testing code with (fp+ 1 1.0)  
in it and 2) the fpXXX operators are around for efficiency reasons,  
and people who want speed out of Chicken will probably be compiling  
in unsafe mode anyway.  I would argue against 2'' because it makes  
the fpXXX operators only barely faster than the standard arithmetic  
operators even when the user has explicitly asked to live dangerously  
by declaring (unsafe).

However, if the consensus opinion is for 2' or 2'' I would be happy  
to modify the patches to account for this in the interests of  
sensible behavior.  Assuming these patches are acceptable to felix  
(and whomever else who needs to approve), I am also happy to modify  
the manual to reflect the changes.

Thanks,
Will

library.patch
Description: Binary data

runtime.patch
Description: Binary data