[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.

*To*: schlie@xxxxxxxxxxx, will@xxxxxxxxxxx*Subject*: Re: arithmetic issues*From*: William D Clinger <will@xxxxxxxxxxx>*Date*: Thu, 19 Jan 2006 00:58:47 -0500*Cc*: srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx

Paul Schlie wrote: > Thereby hypothetically to keep things real simple, it may even be > considered reasonable to bound fixnums by a sign-less Inf (i.e. NaN); > effectively enabling basic balanced fixnums to be defined as: > > NaN -(2^(P-1)-1) 0 +(2^(P-1)-1) NaN > > [where NaN is effectively = -2^(P-1), i.e. the pattern 10...] > > Thereby any overflow may be relatively easily detected, and trapped > to return NaN, which in turn closes all subsequent operations to > corresponding return NaN. This would work, but modular arithmetic is more useful when implementing bignums. If you don't believe me, try it. > Where then precision required beyond (for the sake of argument P=16) > and more efficient modulo and/or greater precision fixnum data types > may be enabled through either virtual or literal libraries, as would > be the support for extended exact and inexact data types and their > correspondingly overloaded operators? Huh? > Where further for the sake of argument, as I personally dislike the > proposed use of typed functions (i.e. fl+ etc.); I'd much prefer that > simple default semantics be defined for mixed data type operations. > For example something along the line of "operations will be performed > in the declared order at the precision of the most precise operand"; Egner et al advocated this. One problem with this proposal is that exactness becomes contagious. If a calculation was intended to use inexact arithmetic of bounded precision, any exact value that slips into the calculation inadvertently will result in exact rational arithmetic with increasingly large denominators; it will be very slow, and is likely to consume all available memory if the computation is nontrivial. Furthermore that proposal is completely at odds with Scheme's history, in which inexactness has been contagious, and with the coercion rules of nearly every other programming language. The solution adopted in SRFI-77 is to provide type-specific operations, so programmers can easily express what kinds of numbers they intend their computations to use, and mistakes will be detected and reported (in safe mode). Will

**Follow-Ups**:**Re: arithmetic issues***From:*Paul Schlie

- Prev by Date:
**Re: arithmetic issues** - Next by Date:
**Re: arithmetic issues** - Previous by thread:
**Re: arithmetic issues** - Next by thread:
**Re: arithmetic issues** - Index(es):