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
___
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users
