On Mon, Sep 15, 2003 at 05:55:03PM -0400, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:
that it is a matter of precision, you have to decide how to deal with the issue.
(float)123456789;
(13) Result: 123456792.000000
I remember that there was an exception (on mainframes) on such conversion (when precision is lost). Some compilers even warn on such casts (and I agree with that).
Two values are equal if they are equal once converted to floats.
If at least one is float - yes. They are equal if they are equal once converted to floats.
Two values are equal if they are equal once converted to ints.
The range (numerical) is huge for floats, but extremely limited for ints, so this makes no sense.
A float and an integer are never equal.
This will break the basics of arithmetics :)
A float and an integer are never equal, except 0==0.0.
This will solve one particular problem (which was the reason of this thread), but also it will make a lot of things inconsistent.
A float and an integer are equal if they are equal within the precision bounds of the float (six decimals for single precision floats).
(** the winner :) **) This would be the best solution (with exception throwed when conversion will break the precision bounds, except when explicitly requested). Adding an implicit (light) check for 0.0 case, and avoiding check when conversion is explicit, it wouldn't affect the performance.
A float and an integer are equal if they are equal within the precision bounds of a predefined value (e.g. six decimals so that Pike programs executes the same on regardless of float implementation).
This will lead to inconsistency again. One may need better precision (me :), so it would be nice to have a configuration parameter (pragma?) to rule this.
Regards, /Al