[racket-dev] flonum vs. inexact-real

Vincent and I briefly discussed tools for 'numeric debugging' 
in my office. Hooking it up with CS is the right way to go. It 
should have occurred to us. 


On Oct 3, 2010, at 10:49 AM, Robby Findler wrote:

> Would it make sense for typed scheme to hook up with check syntax to
> show the type of subexpressions (say when mousing over parens or
> something)? I'm not sure if that's too late in general, but it seems
> like we're getting the point where we want to give programmers
> interactive feedback, at least about numbers.
> 
> Robby
> 
> On Sun, Oct 3, 2010 at 9:42 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
>> 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'.
>> 
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev
>> 
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev