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].

Interesting!

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 ⊥

_________________________
 Racket Developers list:
 http://lists.racket-lang.org/dev

Reply via email to