This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.
| From: Bradley Lucier <lucier@xxxxxxxxxxxxxxx> | Date: Wed, 18 May 2005 22:39:14 +0200 | | 1. I believe that every numerical value should have an external | representation. Is not-a-number numerical? SRFI-70 specifies notation for the two unique real infinities. It also specs a single (optional) notation for 0/0, but is not as emphatic about its uniqueness. Reading and writing 0/0 is not very useful, because it is an error waiting to happen. | There are many different NaNs (the only requirement is that the | biased exponent field should be a maximum and the mantissa field be | nonzero), so it should be possible to specify or determine this | information about a NaN from its external representation. The previous implementation of SCM was transparent to IEEE floats. This lead to strange numbers like 0/0+3i which have no sensible mathematical interpretation. That period of experimentation over, SRFI-70 reins in infinities to just three, two of which are very compatible with standard analytical use. That the mathematical limit can be implemented as a procedure is evidence of the power of this paradigm. Just because more codes are available in IEEE-754 format does not mean that using them will have more fidelity with mathematics. | 2. If Scheme really wants to get serious about floating-point | arithmetic, one should be able to specify the precision of | floating- point operations. "One-precision-fits-all" doesn't cut | it for serious code. For i686 platforms "gcc -O3" compiles floating point calculations to use 80-bit float representation. Reducing the precision of scalar operands nets no speed increase from floating-point hardware. But reducing the size of arrayed floating point numbers does increase speed because of their smaller cache footprints. The homogeneous arrays of SRFI-63 provide such size reductions. Serious floating point calculations should use the vectorized floating-point units many CPUs offer. This could be accomplished by extending Scheme's arithmetic procedures to operate on the homogeneous arrays of SRFI-63. Because the overhead would be amortized over many scalar calculations, type dispatch could be done at runtime, incurring a negligible speed penalty.