[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Numeric towers
On Thu, 2011-01-06 at 15:32 -0800, Vincent Manis wrote:
> My apologies about having taken so long to respond to John Cowan's
> request for comments on the numeric tower taxonomy
> at http://trac.sacrideo.us/wg/wiki/NumericTower. I do have some
> comments on this taxonomy, and I hope they can still be considered by
> WG1 members.
For what it's worth, I consider it worthwhile to have a limited range
of exact ratios, where the results of (/) on exact arguments are exact
if both numerator and denominator are within a bounded integer range
and inexact otherwise. This provides "opportunistic" preservation of
exactness where you could not ordinarily specify it due to the
possibility of representation explosion.
Type theorists objecting that they need to be able to statically
determine the type of an operation without referent to the values
of the arguments will object to the exact/inexact conversion implicit
in bounded ratios. But it is certainly no worse than the number/error
conversion implicit in unbounded ratios when representation space is
It is also important to programs to know whether exact and inexact
numbers are interconvertible without changing numeric value. IE,
whether the system supports the same precision in inexact numbers
as exact numbers. This is sometimes a desirable property, but if
it is true it is also a sticky trap for code that makes contrary
Both of these issues are about managing the exponential increse in
the size of numeric representation and time required for numeric
operations under common operations in the presence of bignums.
PS. If we were starting from Tabula-Rasa, which we are not, I would
prefer bignums, including bignum ratios, to be a separate
numeric type with a syntax distinguished from regular numbers.
The difference being that the results of exact operations on
regular exact numbers or mixed numbers including at least
one regular exact number would convert to regular inexact
numbers on overflow, whereas the results of exact operations
on bignums would be to return either exact bignums or an
out-of-memory error. It is my contention that programs should
not risk the out-of-memory errors and speed penalties
associated with large-precision bignums unless very
specifically asking for them with a distinguished numeric
syntax that means nothing else.
Scheme-reports mailing list