Hacker News Reader

Comment by muyuu | Hacker News Reader

Yep grouping can lead to better real accuracy. But then you lose exact IEEE compatibility (get slightly different results that will fail a comparison).

View on HN

Thanks, I now see more clearly why this is important for comparisons :)

Speaking of comparisons... -Wfloat-equal will warn whenever you attempt to compare floats or doubles for equality.

Rule number one of floats: don't use == on them.

Pure cargo-culting. There are circumstances in which it’s perfectly appropriate to compare floating-point data for equality. There are also circumstances in which a comparison with some tolerance is more appropriate. Understand what situation you’re in, and understand the tools that you’re using.

Comparing floats for equality is equivalent to comparing them with tolerance that you don't control. I don't see a good reason to risk like that.

Comparing floats for equality is equivalent to a comparison with zero tolerance, not an uncontrolled tolerance.

Consider storing a timestamp as a number of seconds since the epoch. We might use == to check if the timestamp has changed.

Read the wikipedia entry on IEEE754-1985 (it has better diagrams than the main 754 entry): http://en.wikipedia.org/wiki/IEEE_754-1985#Representation_of...

Knowing is better than fearing.

No, it's not equivalent to that at all. Why would you think such a thing?

Oh, there must be a Common Lisp predicate that addresses this. prettymuchequalsp?

More seriously, I remember APL\360 SETFUZZ from long before many of you whippersnappers were born, which told the system to disregard so-many bits in an 'equals' evaluation.

FP implementations are generally evil, and errors cascade in irritating fashion. 50% of a numerical analysis class I took once was dedicated to error estimation. Stick to rationals if you can - it'll save your hairline.

Comparing floats is sometimes useful. For example, if you are testing that you have copied a data structure correctly.

Reply on news.ycombinator.com