[racket-dev] flonum vs. inexact-real
At Sun, 3 Oct 2010 10:01:31 -0400, Sam Tobin-Hochstadt wrote:
> On Sun, Oct 3, 2010 at 7:43 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> >
> > Sam and Vincent: Any thoughts on how easy or difficult the change would
> > be for Typed Racket (and its optimizer)?
>
> What would the precise hierarchy be? In other words, what would be
> the predicate for each type? Would there be automatic coercions?
The `flonum?' predicate would be the only new predicate for now. The
`inexact-integer?' predicate would imply `flonum?', but not vice-versa.
The flonum operators (with names that start `fl' or `unsafe-fl') would
require and produce flonums, only.
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.
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.]
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.]
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.]
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.]
These rules --- with my preferences where there are choices ---
correspond to what is currently almost implemented in Racket with
`--enable-float'.