4 ms·

Can someone give an example of a time you would actually want to compare floats for equality? Every time I've come across it there's always been a better way.

jbay808 4y ago
Perhaps when you are unit testing a math function on a known input, for a specific platform, and there is a specific value that you are expecting it to return; anything else is an error.
VBprogrammer 4y ago
I think the most common case, though it's wrong in a multitude of ways, is when you accidentally end up with a float representing a money amount. Things which are genuinely representable as a float value testing for equality is very rarely useful.
enriquto 4y ago
> Can someone give an example of a time you would actually want to compare floats for equality? When they are integers. By construction, floats provide exact arithmetic for small ints. It makes sense to compare those for equality. Also, when defining a ``sign'' function, you may want to treat the equality case separately, to avoid introducing biases when the input data is quantized.
- cm2187 4y ago
  Also should a negative zero be strictly equal to zero?
  - enriquto 4y ago
    They have to be different if you want to have positive and negative infinity.
    - cm2187 4y ago
      yes, but if you want to check that a-b = 0.0, you want 0+ to be equal to 0-.
  - kps 4y ago
    In IEEE754, yes.
jrootabega 4y ago
As I understand the principles in the article: - The representable values are so dense near zero that there will be less practical difference between strict equality and approximate equality. Strict equality would be theoretically significant if you found it, but not really necessary to check for. You'll see mostly false negatives. - The representable values are so sparse far away from zero that strict equality isn't really valuable theoretically or practically. You'll see mostly false positives. So perhaps there is a region (the location and size of it depending on what you're modelling), where strict equality is just likely enough that you need to check for it, AND that the ULP at that point is meaningful for your application. But philosophically, in that situation, are you really comparing them for equality, or does your epsilon just happen to be zero? Would it be better to interpret your question as: are there situations where you want to check for strict equality no matter what either of the values are?
philh 4y ago
SQL queries sometimes put floats in GROUP BY. E.g. if you have a many-to-one relationship you might do a query like SELECT foo_id, foo.some_float, SUM(bar.some_thing) FROM foo JOIN bar USING (foo_id) GROUP BY foo_id, foo.some_float I feel kinda dirty whenever I do this. Though, I would guess the optimizer (at least in postgres) is smart enough to ensure no float equality checks actually happen under-the-hood. They could be necessary, if the schema was different than I'm imagining; but maybe in that case, it would almost always be a bad idea.
- cm2187 4y ago
  Why would you feel dirty? In this case it is solving for exact equality, ie the same bits, it doesn't matter that the value is a float. Though I have seen some people using a double as a primary key (no idea why) and some database engine (internal, not major vendor) failing to do equality comparisons in certain statements, I suspect because they must be switching to "close enough" which is not what you expect when you write col1 = col2.
- blep_ 4y ago
  This is also really kind of an artifact of how GROUP BY works in most database engines. I've always liked the way MySQL/MariaDB let you omit things from the GROUP BY if they're provably unique in each group (here, if foo_id is a primary key of foo, and you're grouping by it, there can only ever be one foo.some_float for each foo_id). I suspect in practice this would get rid of approximately all occurrences of group-by-float.
cm2187 4y ago
I suspect this is what was causing some linear optimisation libraries (simplex style) to fail to find a solution when I had a problem with inputs in range 0.0-1.0, but outputs expressed in hundreds of billions. If I scaled down my problem by dividing all the coefficients by one million, I am solving the same problem mathematically, but now those solvers are then stable and successful. I suspect they must be using some fixed epsilon to determine if the solved solution is close enough to the objective.
deleted 4y ago
[deleted]
NovemberWhiskey 4y ago
e.g. I'm writing a regression test for a derivative pricing function.
- cygaril 4y ago
  I've done that many times and never used exact equality comparisons. If you do exact comparisons for any non-trivial cases, you'll find different compilers, optimization settings, runtimes, and processors give different results.
cypress66 4y ago
In gamedev many things are floats, and exactly 0.0f can mean basically "null". It's not uncommon to see x != 0.0f. Other than 0.f, basically any other value if for some reason has to be compared, it's done with some margin of error like abs(x - y) < 0.0001f
jillesvangurp 4y ago
I have some geospatial algorithms in my geogeometry library. Unit testing those, you often need to compare coordinates. A good way to do that is by calculating their distance. Equality is really not that relevant with many of these algorithms. Almost everything that you do to those numbers has rounding errors. If you think about it, people use 64 bit doubles for representing latitude and longitude. They don't have a lot of precision. A second of a degree is about 25-30 meters (depending on where you are. that's 1/3600th of a degree. So five decimal points gets you there. With 64 bit numbers, you can probably get to cm/mm level accuracy. Which is plenty considering GPS is not accurate to more than about 5 meter. And distance algorithms are tricky too; they are not that exact. The earth isn't a perfect sphere. So, you are dealing with an inexact representation of doubles that weren't very exact to begin with and the algorithms add more errors. The solution is to not compare equality but distance with some margin of error. So, subtract your expected and actual values and assert that their difference should be less than whatever margin of error is acceptable to you.
- adgjlsfhk1 4y ago
  note that this is a perfect example where you should use scaled integers. you'd get 4000x more precision.
  - jillesvangurp 4y ago
    Data comes as doubles. No choice in the matter there. Conversions just add to the problem.

jbay808 4y ago

Perhaps when you are unit testing a math function on a known input, for a specific platform, and there is a specific value that you are expecting it to return; anything else is an error.

VBprogrammer 4y ago

I think the most common case, though it's wrong in a multitude of ways, is when you accidentally end up with a float representing a money amount. Things which are genuinely representable as a float value testing for equality is very rarely useful.

enriquto 4y ago

> Can someone give an example of a time you would actually want to compare floats for equality? When they are integers. By construction, floats provide exact arithmetic for small ints. It makes sense to compare those for equality. Also, when defining a ``sign'' function, you may want to treat the equality case separately, to avoid introducing biases when the input data is quantized.

cm2187 4y ago
Also should a negative zero be strictly equal to zero?
- enriquto 4y ago
  They have to be different if you want to have positive and negative infinity.
  - cm2187 4y ago
    yes, but if you want to check that a-b = 0.0, you want 0+ to be equal to 0-.
- kps 4y ago
  In IEEE754, yes.

jrootabega 4y ago

As I understand the principles in the article: - The representable values are so dense near zero that there will be less practical difference between strict equality and approximate equality. Strict equality would be theoretically significant if you found it, but not really necessary to check for. You'll see mostly false negatives. - The representable values are so sparse far away from zero that strict equality isn't really valuable theoretically or practically. You'll see mostly false positives. So perhaps there is a region (the location and size of it depending on what you're modelling), where strict equality is just likely enough that you need to check for it, AND that the ULP at that point is meaningful for your application. But philosophically, in that situation, are you really comparing them for equality, or does your epsilon just happen to be zero? Would it be better to interpret your question as: are there situations where you want to check for strict equality no matter what either of the values are?

philh 4y ago

SQL queries sometimes put floats in GROUP BY. E.g. if you have a many-to-one relationship you might do a query like SELECT foo_id, foo.some_float, SUM(bar.some_thing) FROM foo JOIN bar USING (foo_id) GROUP BY foo_id, foo.some_float I feel kinda dirty whenever I do this. Though, I would guess the optimizer (at least in postgres) is smart enough to ensure no float equality checks actually happen under-the-hood. They could be necessary, if the schema was different than I'm imagining; but maybe in that case, it would almost always be a bad idea.

cm2187 4y ago
Why would you feel dirty? In this case it is solving for exact equality, ie the same bits, it doesn't matter that the value is a float. Though I have seen some people using a double as a primary key (no idea why) and some database engine (internal, not major vendor) failing to do equality comparisons in certain statements, I suspect because they must be switching to "close enough" which is not what you expect when you write col1 = col2.
blep_ 4y ago
This is also really kind of an artifact of how GROUP BY works in most database engines. I've always liked the way MySQL/MariaDB let you omit things from the GROUP BY if they're provably unique in each group (here, if foo_id is a primary key of foo, and you're grouping by it, there can only ever be one foo.some_float for each foo_id). I suspect in practice this would get rid of approximately all occurrences of group-by-float.

cm2187 4y ago

I suspect this is what was causing some linear optimisation libraries (simplex style) to fail to find a solution when I had a problem with inputs in range 0.0-1.0, but outputs expressed in hundreds of billions. If I scaled down my problem by dividing all the coefficients by one million, I am solving the same problem mathematically, but now those solvers are then stable and successful. I suspect they must be using some fixed epsilon to determine if the solved solution is close enough to the objective.

deleted 4y ago

[deleted]

NovemberWhiskey 4y ago

e.g. I'm writing a regression test for a derivative pricing function.

cygaril 4y ago
I've done that many times and never used exact equality comparisons. If you do exact comparisons for any non-trivial cases, you'll find different compilers, optimization settings, runtimes, and processors give different results.

cypress66 4y ago

In gamedev many things are floats, and exactly 0.0f can mean basically "null". It's not uncommon to see x != 0.0f. Other than 0.f, basically any other value if for some reason has to be compared, it's done with some margin of error like abs(x - y) < 0.0001f

jillesvangurp 4y ago

I have some geospatial algorithms in my geogeometry library. Unit testing those, you often need to compare coordinates. A good way to do that is by calculating their distance. Equality is really not that relevant with many of these algorithms. Almost everything that you do to those numbers has rounding errors. If you think about it, people use 64 bit doubles for representing latitude and longitude. They don't have a lot of precision. A second of a degree is about 25-30 meters (depending on where you are. that's 1/3600th of a degree. So five decimal points gets you there. With 64 bit numbers, you can probably get to cm/mm level accuracy. Which is plenty considering GPS is not accurate to more than about 5 meter. And distance algorithms are tricky too; they are not that exact. The earth isn't a perfect sphere. So, you are dealing with an inexact representation of doubles that weren't very exact to begin with and the algorithms add more errors. The solution is to not compare equality but distance with some margin of error. So, subtract your expected and actual values and assert that their difference should be less than whatever margin of error is acceptable to you.

adgjlsfhk1 4y ago
note that this is a perfect example where you should use scaled integers. you'd get 4000x more precision.
- jillesvangurp 4y ago
  Data comes as doubles. No choice in the matter there. Conversions just add to the problem.