Alaric Snell-Pym scripsit: > To me that sounds like a definition of "fixnums overflow into flonums", > which is something slightly different. A system might have fixnums that > raise a condition rather than overflowing, without having a bignum system.
I agree that that's possible in principle, but in practice no system I know of uses it: they either nonconformantly wrap (producing incorrect fixnum results), or overflow to flonums, or overflow to bignums. Conditions are raised only when the bignums get too big, which can also be a matter of the format rather than the total storage. > I'd argue that overflow-to-flonum is questionable (it produces incorrect > results rather than no results, and lets you check for incorrectness > with exact?, but I foresee lots of code not thinking to check for exact? > and silently failing); it strikes me as useful to allow developers to > have mental rules like "exact + exact = exact". I agree, modulo physical devices can't represent arbitrarily large integers. But in order for "exact + exact = exact" to be as true as it can be, we need bignums. > I think that people who don't mind exacts overflowing to inexacts > are probably people who wanted inexacts in the first place and just > happened to get an exact when they typed "10". That, or they want fairly predictable performance (on modern CPUs, fixnums and flonums have about the same performance). > bignums are an implementation issue; minimal ranges are a user issue, > and what happens when those ranges are exceeded (errors or overflows to > inexacts) :-) What we are voting on is not bignums, but unbounded (modulo physical constraints) exact integers. -- John Cowan http://www.ccil.org/~cowan [email protected] Do what you will / this Life's a Fiction And is made up of / Contradiction. --William Blake _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
