False Assertion Failed

Hi,

    I found a strange result in a test: the assertion fails and de comparand
objects are the same.
    It is a result from making some calculus and both results returns the
same float value.


    7.0805

    Inspecting the comparands individually, the number is the same. They
even has th same hash number.

    What could be wrong?

Sebastián

Sebastián,

>    What could be wrong?

Assuming you are using something like

    self assert: [a = b]

it sounds like the "usual" problem with comparing Float values.

Try changing the assertion to

    self assert: [a equals: b]

and see if that solves the problem.

Having equal #hash values might well be possible as the implementation of
Float>>hash does some "fiddling" with the fraction part (that I don't really
follow) that could possibly cause the tiny differences in values to be lost.
NB There is nothing to stop two different objects having the same hash
value.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ian,

    yes, that seems to solve the problem.

    Another srange behavior I've found in the SUnit Browser was that using
#= for floats, bring aleatory results, sometimes it passes and sometimes it
don't, and when the assertion fails, the debug command can't open the
debugger. The command is ignored (but not always).

    thanks,

Sebastián
PD: It could seem to be one, but is not a joke :)

"Ian Bartholomew" <[hidden email]> escribió en el mensaje
news:[hidden email]... really
> follow) that could possibly cause the tiny differences in values to be
lost.

Sebastián,

> Ian,
>
>     yes, that seems to solve the problem.
>
>     Another srange behavior I've found in the SUnit Browser was that using
> #= for floats, bring aleatory results, sometimes it passes and sometimes it
> don't,

That makes sense, independent of the SUnit browser.  Read about "machine
numbers".  Ian's suggestion of #equals: will often work.  Depending on
what you are doing (e.e. something with large roundoff errors, Monte
Carlo methods, etc.), you might need to set a wider tolerance, which is
fancy way of saying that you might need to test no a range of numbers
rather than use #= or #equals:.


 > and when the assertion fails, the debug command can't open the
> debugger. The command is ignored (but not always).

I see that kind of thing too.  The SUnit Browser is a great tool, but it
exhibits some random behavior.  The other problem I see is that
selecting a test case does not always show the tests (the list will be
empty).  Selecting another test and returning always seems to fix it.

I vaguely recall reading that these things were fixed, but I continue to
see them.  Caveat: much of my use of the SUnit Browser is via my
filtered browser goodie, which creates test cases on the fly.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]