Hmm, curiouser and curiouser. Using the latest nightly build from http://pre.racket-lang.org/installers/, 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!
On Fri, Sep 9, 2011 at 12:08 PM, Vincent St-Amour <stamo...@ccs.neu.edu>wrote: > 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