At Thu, 8 Sep 2011 20:43:02 -0400, Luke Vilnis wrote: > Running this produces: > > eq? 0.0 #f > eqv? 0.0 #t > Float? #t > Float-Or-Integer? #f
With the latest from git on Debian 32 bit, I get `#t' for all four. What environment are you using? > The part of TR that generates the compound contracts for unions containing > Float types is using eq? instead of eqv? for the 0.0 and -0.0 case (which > started in version 5.1.1), which explains why the predicate fails. Somehow, > in the repro above, a 0.0 is being produced that doesn't eq? with the > literal 0.0. I tried doing this with, say, (eq? 0.0 (- (+ 3.0 1.0) > 4.0)) or (eq? > (exact->inexact 0) 0.0), but those both evaluate to #t, so either the > compiler is doing some very clever constant folding here, or eq? is supposed > to do value equality for floats. I'm assuming the former, but especially for > the exact->inexact case that seems pretty darn clever. Anyhow, I was hoping > someone could confirm my suspicion that this bug was so hard to reproduce > because of crazy compiler magic (also, assuming this is right and it's > simply an eq? vs. eqv? issue, I've sent along a patch). The patch looks fine. I'll apply it. Thanks! Vincent _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
