At Sun, 3 Oct 2010 10:01:31 -0400, Sam Tobin-Hochstadt wrote: > On Sun, Oct 3, 2010 at 7:43 AM, Matthew Flatt <mfl...@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'. _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev