## digitalmars.D.learn - Comparison issue

- James Miller (34/34) Mar 19 2012 Hey, I'm trying to do some vector based code, and my unittests started
- bearophile (4/8) Mar 19 2012 Maybe I'd like to deprecate and then statically forbid the use of == amo...
- James Miller (4/12) Mar 19 2012 I wouldn't mind if it was just type weirdness, but its not. It appears t...
- Jesse Phillips (11/21) Mar 19 2012 I feel I should expand on bearophile's statement here. Checking
- H. S. Teoh (19/28) Mar 19 2012 Using == to compare floating point values is wrong. Due to the nature of
- Don Clugston (19/43) Mar 20 2012 No, no, no. That's nonsense.
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (5/7) Mar 20 2012 With the note that the integer type has better precision at higher

Hey, I'm trying to do some vector based code, and my unittests started to fail on testing normalize. I'm using the standard algorithm, but the assert is always return false. I did some investigation, and can show that this program causes failure: import std.math : sqrt; import std.stdio : writeln; T size(T)(T[] t){ T val = 0; for(size_t i = 0; i < t.length; i++) { val += t[i]*t[i]; } return sqrt(val); } void normalize(T)(ref T[] t) { auto s = size(t); foreach(ref v; t) { v /= s; } } void main() { float[] vector = [1,2,3,4]; normalize(vector); auto v1 = size!float(vector); writeln(v1 == 1); //false writeln(v1 == 1.0); //false writeln(v1 == 1.0f); //false writeln(v1+1 == 2.0f); //true } I used typeid and can show that the type of `v1` is `float`, as you'd expect. And the last one passes fine, as does doing `(v1+1)-1 == 1`. I'm not sure what could be causing this. I believe it may be a bug, but I would like to see if I'm just wrong instead. -- James Miller

Mar 19 2012

James Miller:writeln(v1 == 1); //false writeln(v1 == 1.0); //false writeln(v1 == 1.0f); //false writeln(v1+1 == 2.0f); //trueMaybe I'd like to deprecate and then statically forbid the use of == among floating point values, and replace it with a library-defined function. Bye, bearophile

Mar 19 2012

On Mar 20, 2012 1:50 AM, "bearophile" <bearophileHUGS lycos.com> wrote:James Miller:among floating point values, and replace it with a library-defined function.writeln(v1 == 1); //false writeln(v1 == 1.0); //false writeln(v1 == 1.0f); //false writeln(v1+1 == 2.0f); //trueMaybe I'd like to deprecate and then statically forbid the use of ==Bye, bearophileI wouldn't mind if it was just type weirdness, but its not. It appears that 1 does not equal 1.

Mar 19 2012

On Monday, 19 March 2012 at 12:50:02 UTC, bearophile wrote:James Miller:I feel I should expand on bearophile's statement here. Checking for equality in a float is usually wrong. After performing operations on a float the accuracy if the number changes. So performing any operations could result in your result being off by a fraction I.e. v1 could be (I'm not being acurate here as to what it, print it out and see) 1.0000000000000000000001 0.9999999999999999999987 I think there is a std.math function called frequal or something.writeln(v1 == 1); //false writeln(v1 == 1.0); //false writeln(v1 == 1.0f); //false writeln(v1+1 == 2.0f); //trueMaybe I'd like to deprecate and then statically forbid the use of == among floating point values, and replace it with a library-defined function. Bye, bearophile

Mar 19 2012

On Mon, Mar 19, 2012 at 08:50:02AM -0400, bearophile wrote:James Miller:Using == to compare floating point values is wrong. Due to the nature of floating point computation, there's always a possibility of roundoff error. Therefore, the correct way to compare floats is: immutable real epsilon = 1.0e-12; // adjustable accuracy here if (abs(y-x) < epsilon) { // approximately equal } else { // not equal }Maybe I'd like to deprecate and then statically forbid the use of == among floating point values, and replace it with a library-defined function.[...] I agree. Using == for any floating point values is pretty much never right. Either we should change the definition of == for floats to use abs(y-x)<epsilon for some given epsilon value, or we should prohibit it altogether, and force people to always write abs(y-x)<epsilon. T -- Never step over a puddle, always step around it. Chances are that whatever made it is still dripping.

Mar 19 2012

On 19/03/12 15:45, H. S. Teoh wrote:On Mon, Mar 19, 2012 at 08:50:02AM -0400, bearophile wrote:No, no, no. That's nonsense. For starters, note that ANY integer expression which is exact, is also exact in floating point. Another important case is that if (f == 0) is nearly always correct.James Miller:Maybe I'd like to deprecate and then statically forbid the use of == among floating point values, and replace it with a library-defined function.[...] I agree. Using == for any floating point values is pretty much never right. Either we should change the definition of == for floats to use abs(y-x)<epsilon for some given epsilon value, or we should prohibit it altogether, and force people to always write abs(y-x)<epsilon.Using == to compare floating point values is wrong. Due to the nature of floating point computation, there's always a possibility of roundoff error. Therefore, the correct way to compare floats is: immutable real epsilon = 1.0e-12; // adjustable accuracy here if (abs(y-x)< epsilon) { // approximately equal } else { // not equal }And this is wrong, if y and x are both small, or both large. Your epsilon value is arbitrary. Absolute tolerance works for few functions like sin(), but not in general. See std.math.feqrel for a method which gives tolerance in terms of roundoff error, which is nearly always what you want. To summarize: For scientific/mathematical programming: * Usually you want relative tolerance * Sometimes you want exact equality. * Occasionally you want absolute tolerance But it depends on your application. For graphics programming you probably want absolute tolerance in most cases.

Mar 20 2012

On 03/20/2012 02:08 AM, Don Clugston wrote:For starters, note that ANY integer expression which is exact, is also exact in floating point.With the note that the integer type has better precision at higher values. For example, there are many 32-bit values that uint can, but float cannot represent. Ali

Mar 20 2012