On 18 February 2013 17:16, Ludovic Courtès <l...@gnu.org> wrote: > Daniel Hartwig <mand...@gmail.com> skribis: > >> scheme@(guile-user)> (define x 1/2) >> scheme@(guile-user)> (eq? x 2/4) >> $7 = #f >> scheme@(guile-user)> ,optimize (eq? x 2/4) >> $8 = (eq? x 1/2) >> scheme@(guile-user)> (define y 2/4) >> scheme@(guile-user)> (eq? x y) >> $9 = #f >> scheme@(guile-user)> ,optimize (define y 2/4) >> $10 = (define y 1/2) > > Quoth R5RS: > > `Eq?''s behavior on numbers and characters is > implementation-dependent, but it will always return either true or > false, and will return true only when `eqv?' would also return > true. `Eq?' may also behave differently from `eqv?' on empty > vectors and empty strings. > > What we may get wrong is that it looks as if it doesn’t always return > either true or false, because the behavior depends on whether one of the > operands is a literal.
I took that to mean only that eq? always returns a boolean, rather than requiring it to return the same boolean given the same numeric arguments. It would be fine to simplify some rationals and not others, as this action does not affect the outcome of eqv?. > However, it’s fundamentally wrong to rely on eq? to compare numbers. So > the test case you mention seems buggy, to start with. > > WDYT? > > Ludo’. Right, the test cases involving eq-ness of numbers are broken, should be removed. Patch to follow.
