My comments Marcin 'Qrczak' Kowalczyk (19 Oct 2005 18:37 UTC)
Re: My comments Bradd W. Szonye (19 Oct 2005 19:17 UTC)
Re: My comments Thomas Bushnell BSG (19 Oct 2005 19:44 UTC)
Re: My comments Bradd W. Szonye (19 Oct 2005 19:55 UTC)
Re: My comments Thomas Bushnell BSG (19 Oct 2005 20:11 UTC)
Re: My comments John.Cowan (19 Oct 2005 20:10 UTC)
Re: My comments Thomas Bushnell BSG (19 Oct 2005 20:13 UTC)
Re: My comments Bradd W. Szonye (19 Oct 2005 20:25 UTC)
Re: My comments Marcin 'Qrczak' Kowalczyk (19 Oct 2005 20:23 UTC)
Re: My comments Bradd W. Szonye (19 Oct 2005 20:36 UTC)
Re: My comments Marcin 'Qrczak' Kowalczyk (19 Oct 2005 21:36 UTC)
Re: My comments Bradd W. Szonye (19 Oct 2005 21:42 UTC)
Re: My comments Bradd W. Szonye (19 Oct 2005 22:08 UTC)
Exactness (was Re: My comments) bear (20 Oct 2005 01:50 UTC)
Re: Exactness Thomas Bushnell BSG (20 Oct 2005 03:45 UTC)
Re: Exactness Marcin 'Qrczak' Kowalczyk (20 Oct 2005 09:13 UTC)
Re: Exactness Bradd W. Szonye (20 Oct 2005 20:15 UTC)
Re: Exactness bear (20 Oct 2005 22:09 UTC)
Re: Exactness Marcin 'Qrczak' Kowalczyk (21 Oct 2005 02:08 UTC)
Re: Exactness Thomas Bushnell BSG (21 Oct 2005 03:05 UTC)
Re: Exactness Marcin 'Qrczak' Kowalczyk (21 Oct 2005 08:15 UTC)
Re: Exactness Thomas Bushnell BSG (21 Oct 2005 18:38 UTC)
Re: Exactness Marcin 'Qrczak' Kowalczyk (21 Oct 2005 20:12 UTC)
Re: Exactness Thomas Bushnell BSG (21 Oct 2005 20:29 UTC)
Re: Exactness Marcin 'Qrczak' Kowalczyk (21 Oct 2005 20:38 UTC)
Re: Exactness Thomas Bushnell BSG (21 Oct 2005 20:44 UTC)
Re: Exactness Marcin 'Qrczak' Kowalczyk (21 Oct 2005 21:20 UTC)
Re: Exactness Thomas Bushnell BSG (21 Oct 2005 21:44 UTC)
Re: Exactness Marcin 'Qrczak' Kowalczyk (21 Oct 2005 22:18 UTC)
Re: Exactness Thomas Bushnell BSG (21 Oct 2005 22:48 UTC)
Re: Exactness Marcin 'Qrczak' Kowalczyk (22 Oct 2005 00:34 UTC)
Re: Exactness Thomas Bushnell BSG (22 Oct 2005 01:02 UTC)
Re: Exactness Per Bothner (22 Oct 2005 00:59 UTC)

Re: Exactness Marcin 'Qrczak' Kowalczyk 21 Oct 2005 21:20 UTC

Thomas Bushnell BSG <xxxxxx@becket.net> writes:

>> Why not the other way around: that the default behavior is known,
>> and implementations may provide other fancy choices which must be
>> turned on explicitly?
>
> Nope.  We should maintain consistency over time in the meanings of the
> functions.  It is not a decent idea to have the next RnRS standard
> specify addition in a way which is fundamentally incompatible with its
> predecessors.

It's compatible with existing practice.

> What you are describing as "fancy choices" are, in fact, the way
> Scheme has always behaved.

Any existing implementation uses any other representation by default
than fixnums/bignums, ratnums, flonums, and pairs of real numbers
which represent complex numbers?

(The difference between fixnums and bignums should not be exposed
except perhaps by some weird functions used as an efficiency hack.
Other representations are important though.)

Besides the fact that they don't all support the whole set, other
differences are minor. They differ in the behavior on overflow,
in the textual syntax of special values, in exactness of components
of complex numbers, in the ability to compute some mostly-inexact
functions for certain arguments exactly, and in the correctness
in maintaining every bit of precision by certain operations (like
converting a ratnum to a flonum, or converting a flonum to a string).
These are differences which could be reduced by a future standard.

CLISP supports variable-precision floats under the name of long
floats, apart from fixed-size IEEE and non-IEEE floats. This is fine
by me: sometimes very useful, not imposed on the user by default, and
doesn't have to be provided by every implementation because it's too
painful to implement. Well, from the user's point of view it would be
great if it was standarized and provided by every implementation, but
this choice is not realistic for now.

I'm pretty sure that there exist some Lisp or Scheme packages which
implement numbers with lazy streams of digits, decimal fractions and
arithmetic in Z/n. It's fine, as long as they don't take over the
common defaults.

--
   __("<         Marcin Kowalczyk
   \__/       xxxxxx@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/