Is Using Increment (Operator++) on Floats Bad Style

Is using increment (operator++) on floats bad style?

In general ++/-- is not defined for floats, since it's not clear with which value the float should be incremented. So, you may have luck on one system where ++ leads to f += 1.0f but there may be situations where this is not valid. Therefore, for floats, you'll have to provide a specific value.

++/-- is defined as "increment/decrement by 1". Therefore this is applicable to floating point values. However, personally i think, that this can be confusing to someone who isn't aware of this definition (or only applies it to integers), so i would recommend using f += 1.0f.

Access to class member by increment operator

Will it be works correctly, when I'll use increment operator for access to y and z members?

No. Undefined behavior. You can't perform pointer arithmetic across objects and you can't guarantee struct padding.

You can do stuff like this though:

class Vector
{
    float v[3];
    int& x() { return v[0]; }
    int  x() const { return v[0]; }
    // and so on ...
};

Accuracy of Adding Floats vs. Multiplying Float by Integer

Because 1.0 + ((10.0 - 1.0) / 10.0) * 10.0 does only 1 calculation with inexact values, thus 1 rounding error, it is more accurate than doing 10 additions of float's representation of 0.9f. I think that is the principal which is intended to be taught in this example.

The key issue is that 0.1 cannot be represented exactly in floating point.
So 0.9 has errors in it, which add up in the function loop.

The "exact" number, is probably shown so because of a clever output formatting routine. When I first used computers, they loved to put such numbers out in an absurd scientific fixed digit format, which was not human friendly.

I think to understand what's going on I'll find Koenig's Dr Dobbs blog post on this topic, it's an enlightening read, the series culiminates by showing how languages like perl, python & probably java make calculations look exact if they're precise enough.

Koenig's Dr Dobbs article on floating point

Even Simple Floating-Point Output Is Complicated

Don't be too surprised if fixed point arithmetic gets added to CPUs 5-10 years out, financial people like sums to be exact.

addition operator has no affect

You could use += instead of +, as this will set begrate to begrate+inc. The better solution would be to have a temporary loop variable that starts equal to begrate then increment it.

for (float i=1;i<year;i++){
    cout << "Year:  " << "     ";
    for(float j = begrate;j<endrate;j+=inc){
        cout << "Test " << j << endl;
    }
}

Technical reasons behind formatting when incrementing by 1 in a 'for' loop?

I have decided to list the most informative answers as this question is getting a little crowded.

DenverCoder8's bench marking clearly deserves some recognition as well as the compiled versions of the loops by Lucas. Tim Gee has shown the differences between pre & post increment while User377178 has highlighted some of the pros and cons of < and !=. Tenacious Techhunter has written about loop optimizations in general and is worth a mention.

There you have my top 5 answers.

1. DenverCoder8
2. Lucas
3. Tim Gee
4. User377178
5. Tenacious Techhunter

Glsl error when trying to increment a variable inside a for loop

AFAICT it's a bug in regl? It works if you use

    uniforms: { 
      "refPoints[0]": 0.,
      "refPoints[1]": 1.,
      "refPoints[2]": 0.,
    }

var regl = createREGL()
var drawTriangle = regl({  vert: `  precision mediump float;  attribute vec2 position;
  void main () {    gl_Position = vec4(position, 0, 1);  }  `,
  frag: `  precision mediump float;  uniform float refPoints[3];  varying vec3 fcolor;
  void main () {    float a_value = refPoints[1];    for(int i=0;i<3;++i) {      a_value += 1.; // <-- this line is causing the error    }    gl_FragColor = vec4(1, 1, 1, 1);  }  `,  attributes: {    position: [      [1, 0],      [0, 1],      [-1, -1]    ],  },  uniforms : {    "refPoints[0]" : 0.,    "refPoints[1]" : 1.,    "refPoints[2]" : 0.,  },  count: 3})
regl.frame(function () {  regl.clear({    color: [0, 0, 0, 1],    depth: 1  })  drawTriangle()})

<script src="https://npmcdn.com/regl/dist/regl.js"></script>

Do you consider this bad coding style?

There's nothing compiler-dependent in the behavior of this code (besides possible overflow behavior). Whether it is a good style is a matter of personal preference. I generally avoid making modifications in conditionals, but sometimes it can be useful and even elegant.

This code is guaranteed to compare the new value to 10 (i.e. 9 is compared to 10 in your example). Formally, it is incorrect to say that the comparison takes place after counter gets incremented. There's no "before" or "after" here. The new value can get pre-calculated and compared to 10 even before it is physically placed into counter.

In other words, the evaluation of ++counter == 10 can proceed as

counter = counter + 1
result = (counter == 10)

or as

result = ((counter + 1) == 10)
counter = counter + 1

Note that in the first case counter is incremented before the comparison, while in the second case it is incremented after the comparison. Both scenarios are valid and perfectly possible in practice. Both scenarios produce the same result required by the language specification.

---

Related Topics