[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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
__("< Marcin Kowalczyk