John Cowan wrote: > Arthur Smyles scripsit: > >> That is precisely why [NaN] is not a real number. There is no one to one >> correspondence to a line in the case of a NaN > > *Every* inexact number represents a segment of the real number line > (or a region of the complex plane, if you prefer), finite in the case > of the rationals, infinite in the case of +inf and -inf and +nan.
Your concept of inexact numbers is incorrect. An inexact number with respect to the standard, has to do with whether a computer can represent the number perfectly or not. So the ratio 1/3 would be exact, but (div 1 3) would be inexact. It's irrelevant as far as what type of number a NaN is. Second, +inf and -inf are not ranges they are points. They lay on both ends of the real numbers, they follow most of the properties of real numbers, and it is established in mathematics. NaN follows none of those properties. Further, there is no concept of it for any description of reals that I have read. If there is a mathematical basis for it to be a real, please enlighten me. > > Floating-point arithmetic is not real arithmetic; it's not even > associative. > >> The question is: what should (nan? nan.0+1i) return. First, NaN is >> created by an indeterminate form. Second, NaN is contagious since any >> mathematical operation that recieves it, must return it. Therefore it >> should return #t. > > Currently nan? is only defined on real numbers, and ditto finite? > and infinite? I wouldn't be opposed to extending those to complex > numbers. nan? should return true if it's argument is a NaN, false otherwise. > >> And finally simplifying the complex number constructor to return a NaN >> if either the real or imaginary parts are NaN. > > That's where the sticky bit is. Instead of compnum addition involving > adding real parts and imaginary parts, there now have to be complicated > and annoying NaN checks. No. Anytime you do any mathematical operation with a NaN, the result must be a NaN, according to IEEE. So it has to be checked anyway. Besides, you would never create a complex number for nan.0+1i, you would convert it to nan.0 instead. The whole point of NaN is *not to have to > check* until the inner loop finishes: only then do you find out whether > your results are rubbish. > My proposed changes don't affect that. Arthur _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
