[racket-dev] flonum vs. inexact-real

At Sun, 3 Oct 2010 08:42:47 -0600,
Matthew Flatt wrote:
> Reader syntax is the main way to get inexacts of different precision,
> though probably we should add a operators to convert numbers to a
> specific precision.

Sounds good.

> With generic arithmetic:
> 
>  * When mixing variants of inexact reals, lesser precision would be
>    promoted to higher precision. For example, adding a 32-bit float
>    with a 64-bit float would produce a 64-bit float. [This seems
>    clear.]
> 
>  * When an inexact result must be produced even though all arguments
>    are exact, the result would be represented by the maximum number of
>    bits available. [This also seems clear to me.]
> 
>  * When exacts are mixed with inexacts, the exacts could be converted
>    to inexacts using the highest precision used by inexacts in the
>    immediate operation. [I think this is the right choice. If you add
>    exact 0 or 1 to a 32-bit float, probably you want a 32-bit float
>    back.]

Sounds good too.

>    Alternatively, exacts could be always converted to the highest
>    precision available, which means that the result will use the
>    highest precision available. [If you add 7/22 to a 32-bit float, did
>    you want more precision in the result? Maybe, but more likely you're
>    confused about which kind of numbers you're dealing with.]

Assuming the default flonums are the ones with the most precision, you
would have to explicitly specify that you're using a 32-bit float in
this case. I think having a 32-bit float as a result would make sense.

> Whether operations involving a flonum and something else produces a
> flonum mostly depends on whether "flonum" is defined to be the highest
> precision available:
> 
>    If "flonum" always means the highest precision available, then when
>    generic operators produce inexact reals, they would always produce
>    flonums except when all inexact-real arguments have lesser
>    precision. This is true with either choice of coercion rules for
>    exacts to inexacts. [I think this is the right choice.]

I agree.

>    If "flonum" is not always the highest precision available, then you
>    can expect a flonum result from a generic operation when you provide
>    it only flonum arguments. Whether you get a flonum when combining it
>    with an exact depends on the choice of coercion rule for exacts to
>    inexacts. [This seems workable, but my best guess is that there's
>    little pay-off for the extra complexity.]

This seems overly complicated. I think that sacrificing precision as
the default would be both confusing and inconsistent with the rest of
the design of the numeric tower (fixnums overflow into bignums instead
of just wrapping around, division gives exact rationals, etc.).

> 
> These rules --- with my preferences where there are choices ---
> correspond to what is currently almost implemented in Racket with
> `--enable-float'.

In this case, the work to integrate that in Typed Racket should be
fairly easy.

Vincent