[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'.