Hacker News Reader

Comment by spacechild1 | Hacker News Reader

In general, this is good advice.

However, there are cases where comparing floating point numbers for equality works just fine. For example, if you have a variable 'v' and want to update it to a new value 'f', you can do 'if (v == f)' to check if the variable would change. Or if you have a sentinel value -1.0, it is perfectly ok to do 'if (a == -1.0)'

In general, if you look for a number 'f' in variable 'v', you can safely use equality as along as you expect 'v' to be set to 'f', i.e. the value of 'v' is not the result of a computation. This may sound trivial, but this is often omitted when discussing floating point comparison. If someone knows a scenario where the examples above would break, I would be curious to hear! (My main field is audio programming and code like this is omnipresent.)

View on HN

cesaref's comment is not good advice, it's not advice at all, it's a snarky take on how floating point is trickier than it looks

almost invariably floating-point calculations end up in some kind of comparison; if they didn't we'd probably do the calculations in a galois field or something instead

even equality comparison of floats is useful; there are an abundance of seminumerical algorithms which use it correctly on the results of computations. a trivial example is computing an attractive fixpoint by iterating a function and comparing each hare result to the previous iteration and to a tortoise. you have to be especially careful about x87 extended precision here

ieee-754 requires bit-exact results for the five fundamental operations

here is an example where your 'safe' generalization is not safe:

    #include <stdio.h>

    int main()
    {
      float f = 0.7;
      printf(f == 0.7 ? "ok\n" : "wtf\n");
      return 0;
    }

this prints 'wtf' on, for example, x86_64-linux-gnu

well you shouldn't expect much if you are comparing floats to doubles

True, but it's an easy mistake to make.

It's an easy mistake to make in C (and C++) because of their lackadaisical approach to type safety.

In Rust if we insist we want to compare an f32 (what C would call float) to an f64 (double), the language says it doesn't have a way to do that, highlighting our mistake. If we just try to compare an f32 with value 0.7 against 0.7, the type inference concludes 0.7 is also an f32 so it's equal, and if we do the same with an f64, this time by inference 0.7 is an f64 and so again it's equal.

Rust's behavior makes so much more sense! IMO, implicit conversions is one of C++ biggest weaknesses. Yes, it may save some keystrokes, but it can easily lead to subtle (or not so subtle) bugs.

agreed

> almost invariably floating-point calculations end up in some kind of comparison

I'm pretty sure OP meant comparison for equality, not comparison in general (which would be absurd, indeed).

> even equality comparison of floats is useful

That's exactly what I tried to point out. However, these are really special cases and you need to be careful and know what you are doing.

i think he was snarkily making an absurd comment for the humor value

I know there is a fair bit of division on this point but I've always liked type mixing, in languages where this is available, to handle signal values and preferred separate variables where it is not. I'd prefer to `if (v IS NULL)` a nullable float compared to checking a constant value - or else to use a guard value to test the validity i.e. `if x = FREQUENCY_SET // enter logic involving the frequency stored in v` - that approach is even better if you can use tuples/structs to glue the status and value fields together.

I am a quickly crustifying developer who was an enthusiatic value packer in their younger years but I've changed my tune to be less afraid of using more variables if they are clearer - even if that comes at a cost to data efficiency (and like, an extremely negligible cost in most situations). Though I don't have any objections to value packing for serialization - that's a fundamentally different domain.

> For example, if you have a variable 'v' and want to update it to a new value 'f', you can do 'if (v == f)' to check if the variable would change.

Isn't it strictly faster to simply assign? No branching, no branch predictions, only one instruction in all cases.

Assuming that all you want to do is assign, then sure. If you want to log the change or do any additional conditional logic, then that wouldn't work.

It depends on whether you need a set operation or a test-and-set operation.

A typically pattern is:

  float freq = getParameter(FILTER_FREQUENCY);
  float coeff;
  if (freq != mFreq) {
    coeff = calculateCoeffFromFrequency(freq); // expensive
    mFreq = freq;
    mCoeff = coeff;
  } else {
    coeff = mCoeff; // use cached value
  }
  // use coeff

Could you do some threshold-based comparison? What if freq is changed only a little tiny bit?

I can certainly imagine cases where this would make sense.

Reply on news.ycombinator.com