Re: [racket-dev] Weird bug in Typed Racket predicate for Float 0.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/09/11 18:26, Luke Vilnis wrote: 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! With last week's code I get: eq? 0.0 #f eqv? 0.0 #t Float? #t Float-Or-Integer? #f but with this morning's git version: eq? 0.0 #f eqv? 0.0 #t Float? #t Float-Or-Integer? #t on amd64 Gentoo GNU/Linux, HTH, Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5tsYEACgkQp/VmCx0OL2w/JwCgnWt5bRIor3nwtiX+XoHhI3W8 gPMAn3VAaQTC/E+9+gbcSXwvATDyfHMA =JGKC -END PGP SIGNATURE- _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Weird bug in Typed Racket predicate for Float 0.0
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.eduwrote: 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
[racket-dev] Weird bug in Typed Racket predicate for Float 0.0
Hi all, I think I've found a bug in Typed Racket's predicates, but investigating it raised a lot of questions, so I was hoping someone wouldn't mind explaining what's going on here. A couple weeks ago I wrote a TR program using version 5.1 (like a bonehead, my shortcut to DrRacket was running it out of the wrong directory so I wasn't using the version that I thought I was.) When I recently converted it to 5.1.3, I started noticing intermittent pattern matching failures. I managed to isolate it to the following standalone: #lang typed/racket (define-type Float-Or-Integer (U Float Integer)) (define-predicate Float-Or-Integer? Float-Or-Integer) (define-predicate Float? Float) (define (weird-predicate-behavior) (: integer-float (Integer - Float)) (define (integer-float int) (exact-inexact int)) (define x (integer-float 0)) (printf eq? 0.0 ~A ~% (eq? 0.0 x)) (printf eqv? 0.0 ~A ~% (eqv? 0.0 x)) (printf Float? ~A ~% (Float? x)) (printf Float-Or-Integer? ~A (Float-Or-Integer? x))) Running this produces: eq? 0.0 #f eqv? 0.0 #t Float? #t Float-Or-Integer? #f 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). Thanks, Luke 0001-Fixed-a-bug-where-predicates-would-sometimes-fail-to.patch Description: Binary data _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
