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

Re: arithmetic issues

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.



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