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

Re: Exactness

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.

bear <bear@xxxxxxxxx> writes:

>> Suppose we have two flonums tagged as exact. You divide them, and the
>> result is not a finite binary fraction, so the implementation can't
>> use the same representation for the result. What should it do?
>> a) Represent it in a flonum tagged as inexact.
>> b) Represent it as an exact ratio of two integers.
> c) consult settings or dynamic variables to see what the program
>    or user wants it to do.
> d) give an exact result if the representation width needed for
>    it is allowed, otherwise give an inexact result with the
>    maximum representation width allowed by the current settings.
> e) store a promise rather than an explicit numeric representation,
>    allowing the user to decide later how much precision they want
>    and propagating demands for precision into the branches of the
>    promise as necessary.
> f) ... something else you haven't thought of.
> g) ... something else *I* haven't thought of.

In other words a portable program can't predict what will happen and
can't state its requirements. This is bad.

I know what to expect from IEEE floats. I know for example that
calculations in a certain range of integers are exact. Or that numbers
have the same relative precision but different absolute precision, for
a wide range of magnitudes. Or that certain primitive operations take
constant time, and a number uses a fixed amount of memory - it doesn't
keep growing precision. I should be able to know more in Scheme - for
example that by default a flonum overflow will not be fatal but will
yield +inf.0, which will compare as greater than any other number
except itself and +nan.0.

I know what to expect from ratios.

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!

>> And that's good, it's not orthogonal. If it was, using different
>> representations for numbers of the same value and the same precision
>> would be redundant. R5RS even specifies that such numbers would be
>> indistinguishable (even more: the precision is not compared but the
>> exactness only, which is wrong if there are several possible amounts
>> of inexact precision, and SRFI-77 fixes that).
> Yes.  They *should* be indistinguishable.

What if they have different precisions? Imagine a Scheme
implementation with two flonum formats, where (= 3s0 3L0) is #t
but (= (/ 3s0) (/ 3L0)) is #f; this behavior should't be surprising.
What should be (eqv? 3s0 3L0)?

>> I presume then that since (factorial 100) preserves all 158 digits,
>> you want (factorial 100.0) to produce a result with 158 digits but
>> tagged as inexact, right?
> If there is a presumption in effect that inexact numbers in source
> whose precision isn't given explicitly are known to 158 digits or more,
> then yes, I'd want the result to 158 digits.  If the presumption is
> that inexact numbers in source whose precision isn't given explicitly
> are known to just 20 digits, then I'd want the first 20 digits and
> the magnitude.

If the number was read as 100.0, how many digits are accurate? The
person who entered the data into a file didn't specify the precision;
usually you can't assume that only these 4 digits are accurate.

You propose that the programmer can't be sure what will happen.

if it was obtained by (exact->inexact 100), then all digits are
accurate. You propose that the programmer should not be able to apply
exact->inexact to inputs to ensure that the result will be obtained
numerically while keeping time and space of individual operations

> Remember that R5RS' full numeric syntax, which virtually nobody takes
> full advantage of, allows explicitly *telling* the system how much
> precision a number has.

It's not enough. How many digits will #i1/3 store? You propose that
the programmer can't know whether there is a fixed number of digits
at all.

If somebody implements fancy numeric types with dynamically settable
precision or with lazily computed digits, I want to use them
explicitly - I don't want them to take over the syntax that virtually
all other languages use for IEEE floating point. I want the precision
and efficiency of computation to be predictable.

>> Are there any implementations where it is?
> MITScheme, for one.  There are probably a few others.

Huh? Judging from the sources it doesn't do anyhting like this. For
example exact->inexact converts everything to flonums or a complex
of flonums.

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