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
