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
exceeded.

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
assumptions.

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.

			Bear

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
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports