Formal comment #143 (enhancement) Request for reconsideration of formal comment #11 Reported by: Aubrey Jaffer Version: 5.92 http://www.r6rs.org/formal-comments/comment-11.txt > | Formal comment #11 (defect) > | > | NaN is not a real number > | Reported by: Aubrey Jaffer > | > | Component: arithmetic > | Version: 5.91 .... > RESPONSE: > > In the draft R6RS, a NaN is regarded as a real (but not rational) > number. To make NaNs non-real, as formal comment #11 proposes, > would break the primary closure property It need not break closure. Flonums represent members of the union of real numbers and NaNs?. > that allows the operations of (r6rs arithmetic flonum) to be > implemented efficiently, often as a single machine instruction. Okay -- I shouldn't have extended this to fl operations. So the text: > | On page 100, the lines > | (fl= +nan.0 fl) ==> #f > | (fl< +nan.0 fl) ==> #f > | should be removed. should be retracted from #11. Then fl<, fl>, fl<=, fl>=, etc. would accept +nan.0 as an argument, while the generic operations <, >, <=, >=, etc. would not. Thus fl operations would retain efficient implementation. > Formal comment #11 would also degrade the performance of generic > arithmetic on flonums in compilers that use flow analysis to improve > the efficiency of generic arithmetic. Generic arithmetic (+, -, *, /) performance is not degraded by comparison operators rejecting NaNs?, but by the possibility of receiving non-real numbers, as can be returned by irrational functions. The fl versions of irrational functions can always return flonums (including NaNs?). > To forbid comparisons between a NaN and a flonum, as Formal comment > #11 proposes, would be incompatible with other programming > languages' interpretations of IEEE-754 and with hardware, making it > more difficult for Scheme to interoperate with other languages or to > make effective use of standard hardware. This same reasoning also argues against having complex non-real numbers. Supporting more numeric types necessarily creates interface issues with lesser languages. Use of the fl function-set can guarantee interoperability. > In particular, the IEEE-754 standard requires equality tests that > involve a NaN to come out false. If the central proposal of Formal > comment #11 were accepted, then implementations of Scheme could not > implement inexact real arithmetic that is compatible with IEEE-754 > or IEEE-754R. Formal comment #11 says nothing about (= +nan.0 +nan.0) ! The fl versions of comparison operators can be IEEE-754 compatible without burdening generic comparison operators with behavior which extends poorly to complex number systems. RESPONSE: The R5.92RS draft speaks of NaNs because the usual representations of inexact real numbers are based on the IEEE standards for binary floating point arithmetic. Those standards approximate real arithmetic, using NaNs as error results when a rational approximation or infinity would be misleading. The R6RS could define its own notion of a complex-NaN that is not considered to be real, but values such as +nan.0+nan.0i and +nan.0+45i serve that purpose already. The proposal claims that performance would not suffer, but we are not persuaded. In current practice, the representations of real numbers are usually disjoint from those of non-real complex numbers, and the generic arithmetic dispatch exploits this fact. If NaNs were regarded as non-real but represented like reals, then generic operations that require real arguments would be slowed by the need to detect and to reject NaNs. If NaNs were regarded as non-real and represented as non-real, then every result of a flonum operation would have to be examined to see whether it is a NaN, and converted to non-real representation if it is. Treating the NaN result of a flonum computation as a complex but not real number would reduce effectiveness of flow analysis, which would also make generic arithmetic slower. Currently, the flonum operations always return a real. Under the proposal, flonum operations would be capable of returning non-reals (the NaNs), which would destroy the primary closure property that flow analysis exploits when optimizing mixed flonum and generic arithmetic. For all of these reasons, the editors believe it is better to treat NaN as a real but not rational number.