Hmm, curiouser and curiouser. Using the latest nightly build from <a href="http://pre.racket-lang.org/installers/">http://pre.racket-lang.org/installers/</a>, I get #f #t #t #f both on my home machine and work machine, which run Windows 7 64-bit. Now I'm really curious as to what's going on here! <div class="gmail_quote">On Fri, Sep 9, 2011 at 12:08 PM, Vincent St-Amour <<a href="mailto:stamourv@ccs.neu.edu">stamourv@ccs.neu.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> At Thu, 8 Sep 2011 20:43:02 -0400, <div class="im">Luke Vilnis wrote: > Running this produces: > > eq? 0.0 #f > eqv? 0.0 #t > Float? #t > Float-Or-Integer? #f </div>With the latest from git on Debian 32 bit, I get `#t' for all four. What environment are you using? <div class="im"> > 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). </div>The patch looks fine. I'll apply it. Thanks! Vincent </blockquote></div>