Andy Wingo <wi...@pobox.com> writes:
> I think &min/0 should be replaced by (&min/f64). Probably also you need
> a good +nan.0 story here; does this do the right thing? e.g.
>
> (let ((a +nan.0))
> (if (< a 100.0)
> (< a 200.0)
> (> a 50.0)))
>
> Does this fold to #t? I think for +nan.0 it should not,
Right, any numerical comparison involving a NaN must return false.
> but AFAIU with
> your patch it does fold. (Guile has some optimizer problems related to
> flonums, I think; this patch doesn't have to fix them all, but it
> shouldn't make them worse, or if it does, we need a nice story.)
>
>> +(define-simple-type-checker (f64-< &f64 &f64))
>> +(define-f64-comparison-inferrer (f64-< < >=))
>
> Likewise we need an understanding that the inverse of < is in fact >=.
> Maybe it is indeed :)
No, it is not, because of NaNs. What we can say is that (< x y) is
equivalent to (> y x) and (<= x y) is equivalent to (>= y x).
Also, inexact numerical operations are not associative. There's a lot
more that could be said about this topic, but in general please be aware
that the usual mathematical intuitions are a poor guide, and it is easy
for a naive compiler to destroy the properties of carefully written
numerical codes.
Thanks,
Mark
