[racket-dev] What are single flonums good for?

From: Neil Toronto (neil.toronto at gmail.com)
Date: Wed Sep 12 13:19:35 EDT 2012

On 09/12/2012 10:24 AM, Vincent St-Amour wrote:
> I agree that having to handle single floats when reasoning about numbers
> complicates things, and it annoys me too. But I still think it's less
> problematic than what I describe above [compilation could change the behavior
 > of a program].


I think the least problematic solution would be to separate them from 
the rest of the numeric tower, and give them their own set of 
single-flonum-only functions: sf+, sfabs, etc. They could even operate 
on single-precision complex numbers.

Hindsight, etc., though.

>> (: foo (case-> (Single-Flonum -> Single-Flonum)
>>                  (Flonum -> Flonum)
>>                  (Real -> Real)))
>> (define (foo x)
>>     (cond [(double-flonum? x)  (flfoo x)]
>>           [(single-flonum? x)  (real->single-flonum
>>                                 (flfoo (real->double-flonum x)))]
>>           [else  (flfoo (real->double-flonum x))]))
> This function already converts rationals to doubles, and it seems
> `flfoo' produces doubles too. You could drop the second clause, always
> produce doubles, change the type to `(Real -> Flonum)' and leave the
> conversion to single to the client. Since the math library always
> operates on doubles internally anyway, this would also eliminate
> unnecessary conversions to singles between stages of a pipeline.

It's not just slower. The unnecessary conversions lose precision because 
of double rounding. I hadn't thought of that yet, so thanks.

>> Why do we have these things?
> I don't know why they were added originally (as an option). In my limited
> experience, I don't think I've seen non-test code that uses them.

This gets at the design decision I'm facing now. Would anybody care if 
the math library just treated them like other non-double-flonum reals, 
and made no effort to preserve single-flonum-ness? I'm leaning toward 
doing that now.

Neil ⊥

Posted on the dev mailing list.