bear <xxxxxx@sonic.net> 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
constant.

> 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
   \__/       xxxxxx@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/