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 08:14 UTC

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

>> I don't know what to expect from inexact real numbers. Do they behave
>> like floats, or like ratios with inexactness bit? It does matter!
>
> So we need a way to query those questions.

Querying is too late: when program needs a particular characteristic,
it doesn't help it that it could detect that the implementation
doesn't meet its expectations.

> Scheme doesn't have "flonums" and that's a good and rational design
> choice.

I disagree. There are programs which require flonums or something
which behave similarly. All Scheme implementations I know and all
other general-purpose languages I know provide flonums.

Consider the example at the end of R5RS run on a typical Scheme
implementation with floats and ratios, augmented with displaying all
elements of the lazy list it produces. It runs fine. But when we
replace the two inexact numbers in the initial state with exact ones
of the same values, fractions become bigger and bigger, even though
the growing precision it accumulates is useless: the algorithm is
inexact to begin with!

Consider its format of output, when we use "display" for individual
elements. It's fair to assume that it uses the same format as
number->string, whose specification has a special clause which forces
it to use the decimal notation whenever possible - this is good, and
even not enough control the programmer has over the representation.
But if the implementation interpreted .01 as something other than a
flonum, perhaps as 1/100 with inexactness bit, the decimal format of
the output would be incorrect (it wouldn't round-trip) and the
implementation would have to use some other format. It's definitely
not what the programmer expected, he will consider any other format as
wrong and the implementation as broken. Expectations that this program
uses the decimal format is technically speaking unportable, although
it's true everywhere in practice. This is bad.

> So if you want an implementation of + that is guaranteed not to use
> more memory in the result than in the operands, we can have that.
> No problem.  Such a function should also have optional arguments that
> specify what happens if the result doesn't fit in the space needed.

I want portable flonums.

If I don't get it from Scheme, I have plenty of other languages to
choose from.

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