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        cowan@ccil.org
Do what you will / this Life's a Fiction
And is made up of / Contradiction.  --William Blake

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports