Simple counting with number 0.07 ?

Robert,

This problem has come up countless times on these forums, and on the internet in general - for any programming language that uses IEEE floating point representation (so C, Pascal, Python, SKILL, etc, etc). For example:

• Round-off error (Wikipedia)
• Why you should never compare two floating point numbers with equals (==) in SKILL?
• Numerical dynamic range (precision) in SKILL (this one was written by me)

Andrew

Hello Bertas,

this is due to the machine epsilon and the representation of each number in the computer. In this case, your 7.0 is not exactly that much, but there is some rounding accuracy related to the number of bits used to represent the number. You can confirm that by printing more significant digits for both of your examples:

Hence you can see where this 8.881784e-16 comes from. It's considered a good practice to avoid the equal operator (==) when comparing expressions on both sides, since such unpredicted results might result in spending some time debugging something that looks weird at first sight. I would say that the more stable and general way to approach number comparisons is:

num1 = a + b - ... - p

num2 = m - n + ... +q

epsilon = 1e-6 ;(or whatever accuracy works for you, usually related to the design grid when drawing somethng)

if(abs(num1-num2) < epsilon then ...

Also, you will notice that if you put the expression evaluation outside the if operator your code will behave more optimal in terms of speed.

Hope this explains the situation.

Regards,

Petar

Well, Andrew has already replied while I was typing the above, so sorry for the duplication.

Thank you guys for the explanation. I got the point. It's clear to me now. 

One more thing, SKILL now has the nearlyEqual function:

x=(0.07/(2*0.005))
7.0
x == 7.0  ;; BAD IDEA, AS NOTED ABOVE
=> nil
nearlyEqual(x 7)
=> t