Float comparation error

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Float comparation error

Esteban A. Maringolo-3
Hi,

        I'm comparing two floats, and they compare to false, when the shouldn't.

The "printable" representation of each, is: 1.125e-002, which if I
compare in a workspace returns true: "1.125e-002 = 1.125e-002"

But the return of some computations answer to false, maybe for the float
comparation.

anObject someComputation = otherObject someValue "false"

someComputation
        ^1.5e-002 * 7.5e-002 / 0.1

someValue
        ^1.125e-002


What could be happening?
I don't belive it is caused because it is a very small number.


Best regards,

--
Esteban.


Reply | Threaded
Open this post in threaded view
|

Re: Float comparation error

Schwab,Wilhelm K
Esteban,

>     I'm comparing two floats, and they compare to false, when the
> shouldn't.

[snip]

> What could be happening?

Float comparisons are tricky.  Try #equals:.

Have a good one,

Bill


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


Reply | Threaded
Open this post in threaded view
|

Re: Float comparation error

Ian Bartholomew-19
In reply to this post by Esteban A. Maringolo-3
Esteban,

> What could be happening?
> I don't belive it is caused because it is a very small number.

It's because most Float values are approximations, albeit very close
approximations, so comparing two computed (i.e. not literal) values may not
always answer the expected result.  Note that this is not a problem that
affects Dolphin but happens in every programming language that uses Floats.
Ask yourself how the result of 1.0 / 3.0 can be stored _exactly_.

The easiest way round it is probably to avoid using #= when comparing
Floats, use #equals: instead.  This just compares the significant part of
each Float value so the slight differences are ignored.

(1.5e-002 * 7.5e-002 / 0.1) = 1.125e-002  ===> false
(1.5e-002 * 7.5e-002 / 0.1) equals: 1.125e-002 ===> true

This has been mentioned quite a lot before so a search of the archive will
probably produce more detailed replies.

--
Ian

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


Reply | Threaded
Open this post in threaded view
|

Re: Float comparation error

Christoph J. Bachinger
In reply to this post by Esteban A. Maringolo-3
Hi Esteban,

comparing of floats in the form of  "1.125e-002 = 1.125e-002" is not the
usual way because of rounding errors in the last bits of the floating
point representation.

The established way is normaly to define an accuracy value mainly called
eps like the following method

eps

        ^0.000001 "As your application needs"

and then testing on equality by doing it like

fooMethod: expectedValue
        floatValue := self anyCalculationMethod.

        (expectedValue - floatValue) abs < self eps
                ifTrue: [] :)
                ifFalse: [] :(

Hopefully this meets your point.

best regards
cjb


Reply | Threaded
Open this post in threaded view
|

Re: Float comparation error

Esteban A. Maringolo-3
In reply to this post by Ian Bartholomew-19
Ian Bartholomew escribió:
> Esteban,
>>What could be happening?
>>I don't belive it is caused because it is a very small number.

 > Note that this is not a problem that
> affects Dolphin but happens in every programming language that uses Floats.

It happens in other programming languages, I know. :-/

> Ask yourself how the result of 1.0 / 3.0 can be stored _exactly_.

:-o

> The easiest way round it is probably to avoid using #= when comparing
> Floats, use #equals: instead.  This just compares the significant part of
> each Float value so the slight differences are ignored.

> (1.5e-002 * 7.5e-002 / 0.1) = 1.125e-002  ===> false
> (1.5e-002 * 7.5e-002 / 0.1) equals: 1.125e-002 ===> true

Yes... I found it just before starting to do my own implementation.
I solved it using #equals:, which is ~10 times slower than the
primitive in Float>>=, but it doesn't seem to affect the overall
performance.

> This has been mentioned quite a lot before so a search of the archive will
> probably produce more detailed replies.

Yes, I know... But I was lazy to search in the DSDN or in the group
archives (google groups). :-)

Regards,

--
Esteban.