Re: [Scheme-reports] Numeric towers

[Ray Dillinger <bear@x>]

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