Andrew Reilly scripsit: > I can't, at the moment, think of *any* situation where a fixnum overflow > that results in an inexact result would be appropriate, except perhaps > for toy problems like fact. It certainly isn't the right answer for > any example of linear iteration, counting, array index calculation, > or cryptography.
If your inexacts are IEEE double floats, as they are on almost all Schemes, then arithmetic operations on inexact integers, provided they derive from an exact source, will be quite correct up to +/- 2^53-1. That's a hefty sort of range for linear iteration or counting, and it's way too big for array or even file indexing. As for cryptography, when you need bignums, you need them, there is no arguing that. People hear about all the problems with floating-point fractions and cumulative error, and they are often seduced into overpessimism about floating point, thinking that floating-point integers have the same issues. They don't, as long as you stay within the significance range noted above. Someone proposed in an earlier thread the notion of flonum-only Schemes, and I shot it down because of the lack of distinction between exact and inexact numbers. But if there were just one extra bit available, which was propagated through arithmetic expressions by ORing, we'd have a pretty nice fixnum/flonum Scheme whose fixnums are internally flonums. -- And it was said that ever after, if any John Cowan man looked in that Stone, unless he had a [email protected] great strength of will to turn it to other http://ccil.org/~cowan purpose, he saw only two aged hands withering in flame. --"The Pyre of Denethor" _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
