6

Are we safe to use floats as loop-counters and to increment/decrement them by fractional amounts at each iteration,like in the seemingly risk-free program below?Of course I know that using floats as operands for the == operator is a dumb thing to do.But what's wrong with using floats as operands for other comparison operations for "normal" purposes? By "normal" I mean that,well,even though floats may not be the exact numerical representation of the number,but isn't a variation like 0.000000001 irrelevant and can be ignored in most cases? (For example in the following program that isn't even apparent)

But that said, here is my apprehension.Suppose the representation isn't exact and 5.0 is actually 4.999999.So as we go on decrementing by 0.5 at each iteration,the last comparison with 0 may turn out false and the loop may exit due to a difference of 0.000001,and the last line of current output will not be displayed. I hope you are getting my drift.How wrong am I?

#include<stdio.h>

int main(void)
{
float f;

for(f=5.0;f>=0;f-=0.5)
printf("%f\n",f);
}

Output: 

5.000000
4.500000
4.000000
3.500000
3.000000
2.500000
2.000000
1.500000
1.000000
0.500000
0.000000
Rüppell's Vulture
  • 3,583
  • 7
  • 35
  • 49

5 Answers5

13

No, it's not safe, for the reasons given in your very question. Consider this:

#include<stdio.h>

int main(void) {
  float f = 1.0;

  for(;f>0;f-=0.1)
     printf("%f\n",f);
  return 0;
}

This example seems to work quite ok when f is initialized by 1.0. But change this to 3.0 - and things start to get way more interesting pretty soon:

2.600000
2.500000
2.400001
...
0.000001

... leading to the infamous 'off-by-one' failure.

You think that you might be safe with >= instead of >? Think again:

float f = 5.0;
for(;f>=1;f-=0.4)
  printf("%f\n",f);

...
3.400000
3.000000
2.599999
2.199999
1.799999
1.399999

... and off-by-one we go again (as 0.99999 is less than 1).

raina77ow
  • 103,633
  • 15
  • 192
  • 229
10

As long as the starting value, the decrement amount and the result of all the decrements can be represented with no error within the precision provided by the floating point type, then it is safe to use. Note that "no error" here means 0 absolute error, very small error is still consider an error.

In your case, the starting value 5.0 and the decrement amount 0.5 can be represented with no error, and 4.5, 4.0, 3.5, ..., 0.0 can also be represented with no error within 23-bit precision of float. It is safe in your case.

If let's say the starting value is 4000000.0 and the decrement amount is 0.00390625 (2-8), then you are in trouble, because the result of the decrement cannot be represented without error in 23-bit precision of float type, although the starting value and the decrement amount can be correctly represented.

However, I see no point in using floating point, when integral type is more reliable in such case. You don't have to waste brain cell in checking whether the condition I stated above applies or not.

nhahtdh
  • 55,989
  • 15
  • 126
  • 162
  • It should be clear that these criteria apply to loops terminating at zero. If you have a loop that runs from +X to -Y, for example, then errors can occur if Y is greater than X. – Eric Postpischil May 17 '13 at 12:03
  • @EricPostpischil: I think the condition that the resulting value in between must be representable covers that case? – nhahtdh May 17 '13 at 12:26
  • @nhahtdh: It seemed to me your text was stating that if the initial value, the decrement, and the result of one decrement were representable, the loop arithmetic would have no errors. If the loop ends at zero, or any point finer than (has a lesser exponent than) the initial value, then that is true. You do not need to test all the other values; the fact that the first decrement produces a representable result guarantees the necessary fineness in the iterator. But, if you continue through zero and up to a coarser (larger exponent) range, you do need a stronger condition. – Eric Postpischil May 17 '13 at 12:36
  • @EricPostpischil: My condition is that the result of all the decrements must be representable. Edited to make that clearer. (Actually from my example, I kinda implies that all the results of the decrements must be representable, but it is not clear enough). – nhahtdh May 17 '13 at 12:39
6

Prefer integer values over floating point whenever possible simply because of the issues with floating point representation.

Instead of using the floating point number as your loop control, rework your logic to use integers:

Need to decrement your counter by .5? Double your starting value and decrement by 1:

float f = 5.0;
int i = f * 2;

for(; i >= 0; i--)
    printf("%f\n", i / 2.0);

Need to decrement by .1?

float f = 5.0;
int i = f * 10;

for(; i >= 0; i--)
    printf("%f\n", i / 10.0);

This is a simple approach for the example in the question. Certainly not the only approach or the most correct. A more complex example may require reworking the logic a bit different. Whatever fits the situation.

My point I suppose is to hold off working with the actual floating point value until the last possible moment to reduce introduction of errors due to representation.

Dave Rager
  • 8,002
  • 3
  • 33
  • 52
  • +1 for the examples showing the better way to loop over floats. – Wayne Conrad May 17 '13 at 13:35
  • 2
    @WayneConrad Adding a non-optimizable division for each iteration of the loop is hardly some universal “the better way”. It is “a way”, and whether it is better depends on the user's expectation (which as usual for floating-point questions, are not stated in the question). For the specific values `5.0` and `0.5`, the code in the question is optimal. The code in the question is only better in some ways when the reciprocal of the increment is represented exactly as floating-point; when this is not the case that version has no redeeming qualities. – Pascal Cuoq Sep 04 '18 at 12:00
0

Engineers and scientists frequently write iterative programs in which a floating point value steps through a range of values in small increments.

For example, suppose the "time" variable needs to change from a low of tMin to a high of tMax in steps of deltaT, where all these variables are doubles.

The obvious BUT INCORRECT approach is as follows:

`for( time = tMin; time <= tMax; time += deltaT ) {
            // Use the time variable in the loop
}
`

So why is this so wrong?

If deltaT is small and/or the range is large ( or both ), the loop may execute for thousands of iterations.

That means that by the end of the loop, time has been calculated by the summation of thousands of addition operations.

Numbers that seem "exact" to us in decimal form, such as 0.01 are not exact when the computer stores them in binary, which means that the value used for deltaT is really an approximation to the exact value.

Therefore each addition step introduces a very small amount of roundoff error, and by the time you add up thousands of these errors, the total error can be significant.

The correct approach is as follows, if you know the minimum and maximum values and the desired change on each iteration:

`int nTimes = ( tMax - tMin ) / deltaT + 1;
 for( int i = 0; i < nTimes; i++ ) {
 time = tMin + i * deltaT;
}
 // NOW use a more accurate time variable
 // Or alternatively if you know the minimum, maximum, and number of desired iterations:
 double deltaT = ( tMax - tMin ) / ( nTimes - 1 );
 for( int i = 0; i < nTimes; i++ ) {
 time = tMin + i * deltaT;
 // NOW use a more accurate time variable
}
`

In general there are four values that can be used to specify stepping through a range - the low end of the range, the high end of the range, the number of step to take, and the increment to take on each step - and if you know any three of them, then you can calculate the fourth one.

The correct loop should use an integer counter to complete the loop a given number of times, and use the low end of the range and the increment as shown to calculate the floating point loop variable at the beginning of each iteration of the loop. So why is that better?

The number of times that the loop executes is now controlled by an integer, which does not have any roundoff error upon incrementation, so there is no chance of performing one too many or one too few iterations due to accumulated roundoff.

The time variable is now calculated from a single multiplication and a single addition, which can still introduce some roundoff error, but far less than thousands of additions. Where does that +1 come from?

The +1 is needed in order to include both endpoints of the range. Suppose tMax were 20 and tMin were 10, and deltaT were 2.

The desired times would be 10, 12, 14, 16, 18, 20, which is a total of 6 time values, not 5. ( Five intervals if you want to look at it that way. ) ( 20 - 10 ) / 2 yields 5, so you have to add the extra 1 to get the correct number of times of 6.

Another way of looking at this is that if nTimes is the number of data points in the range, then nTimes - 1 is the number of gaps between the data points.

Example: interpolate.c is a quick-and-dirty example of interpolating floating point numbers in a loop, that was whipped up in 10 minutes in class. It is NOT an example of good code, but it is an example of how a quick little program can be used to test out, play with, or in this case demonstrate a new or unfamiliar concept.

This example interpolates the function f( x ) = x^3 over the range from -1.0 to 4.0 in steps of 0.5, using three approachs:

Constant - Take the average of the inputs at the endpoints, evaluate f( average input ), and assume the function is constant over the range.

Linear - Evaluate the function at the endpoints, and then use a linear interpolation of the endpoint function values in between.

Non-Linear - Linearly interpolate the function inputs over the range, and at each evaluation point, evaluate the function of the interpolated inputs.

Sanjit Kumar Mishra
  • 1,153
  • 13
  • 32
0

Do not use floating-point variables as loop counters. The reason is that the floating-pint variables in computer only approximately represent the real numbers, not precise as integer.

There are two cases that cause failure: Case 1: compare function needs precision

    for(float val = 0.1f; x<=1.0f; x+=0.1f){
      /*loop may iterate 9 or 10 times, depend on the precision of compare function*/
    }

Case 2: big float value increase/decrease small float value, doesn't change the big float value with its precision

for(float bigVal = 1000000000.f; bigVal>10.f; bigVal -= 1.0f;){
  /*Dead loop, loop forever, bigVal doesn't change after each iteration*/
}

You may refer to this helpful web page: https://wiki.sei.cmu.edu/confluence/display/c/FLP30-C.+Do+not+use+floating-point+variables+as+loop+counters

Yong Yang
  • 126
  • 6