Challenge #1: How Small Things Have Big Impact

I’ve decided to bring up a new category: Challenges. I’ll be giving some puzzles or trick questions, and let you people solve it. The ‘right’ (if available at all…) answer will be told when somebody has quessed it.

Okay, here’s the first challenge:

How is it possible that 70.49 did not equal 70.49?
We encountered this problem. We had the following clause:

IF ($a == $b)
print “This is TRUE”
ELSE
print $a + “does not equal” + $b
ENDIF

The output was: 70.49 does not equal 70.49.

How was this possible? How is it possible that 70.49 does not equal 70.49? How was it possible to give us FALSE condition?

I assure you, in this case small things have a big impact. Feel free to participate: comment to this post and tell me what your answer would be?

P.S. Tim (Indiepath) – you are not allowed to participate. ;)

17 thoughts on “Challenge #1: How Small Things Have Big Impact

  1. Not quite the same, but they once had a bug on Ultima Online where the programmers accidentally redefined TRUE = 0. You wouldn’t believe the stuff that breaks.

  2. I realize I’m late for not reading feeds over the weekend, but…

    When i first saw this (though now i see above that it was a printing error more than a comparison error) I immediately thought of having it pounded into me from a young age never to compare foating point numbers directly in C.. so I’d always do:

    #define EPSILON 0.0000001 // adjust for accuracy

    if( fabs( a – b )

  3. As we always say: 1 + 1 = 3 for large values of 1. :)

    I went for the string/float solution. I’d reason that 70.492 would be printed as such. But not in php I understand? Odd…

  4. It was actually just a debug issue, the debugger was always rounding up! The data types were both doubles.

  5. I’ve noticed that even with identical types, sometimes the process of getting to the desired values can result in a minor discrepancy. For example (in C/C++) if both values were floats, but the incremental process to get the values is different, the data in memory can still be different. One can be 70.49 and the other might wind up 70.899999999999. I was always taught that when using floating point variables in comparisons to avoid direct equates at all cost. Always make it a range, or a = comparison.

  6. Using the “==” operator does not always compare the value of two objects, but whether or not the two objects are the same peice of data. This could very well be the case in the example given.

  7. I got similar error when did BSP subdivision :)

  8. I’ve had this problem once before, but luckily Visual Studio has an ASP.NET debugger ;)

  9. I know I’m not allowed BUT, it was PHP. When you debug it seems to round everything to 2 decimal places!!!

  10. @KGodwin: no no no, I won’t. You gotta think harder ;)
    (or read the solution from other posts ;)

    @Ben: yeh, I noticed your post after sending mine :)

  11. Just a suggestion…let us know what language it is in. =) I’m clearly out of the running since I’m checking it now but just a thought.

  12. Yes I saw your post with the answer only after having submited my comment.

    The subject is very interesting and can be very tricky. For example :
    $a = 70.49
    $b = 70.40
    $b += 0.09
    may lead to the problem if the type is some kind of float (of course in this case the difference would not be in the 3rd decimal, but in the “last” one).

  13. Ben: that could be the right answer, but wasn’t in this case (see previous reply)

  14. What’s the language ? If it’s a scripting language, maybe initialization was something :
    $a = 70.49
    $b = “70.49”
    So $a != $b since $a is a float and $b is a string, and the concatenation doesn’t show the difference.

  15. Well, that didn’t take long to solve. You are correct. Sometimes these kind of small issues can give you a big headache – especially when you *think* you have done everything correctly. It was the decimal places, one was actually 70.49 and the other was 70.492 or something.

  16. One’s a double and the other’s a float?

  17. I’d guess that printing was only outputting two decimal places, but the variables had three or more decimal places and they didn’t match exactly (like 70.491 vs 70.492).