This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Floating Addition - Loosing data

Hello,

I'm making use of floating math in my application and have run into a little problem with floating addition. It seems that the floating addition operation looses data at some point. I setup the following test program:

#include <intrins.h>

void main(void)
  {
  float t, v;
  unsigned int i;

  while(1)
    {
    // this block uses multiplication
    for(i=1; i<1000; i++)
      {
      t = 5964.1 * i;
      v = t/i;

      if(v != 5964.1)
        _nop_();
      }

    t = 0;

    // this block will continuously add  5964.1
    for(i=1; i<1000; i++)
      {
      t += 5964.1;
      v = t/i;

      if(v != 5964.1)
        _nop_();
      }
    }
  }

My project is setup using the P89C668 with all default options EXCEPT "bits to round for float compare" is set to 1. I tried all levels of optimization and the result was the same in all cases.

I then set a breakpoint on each nop. When I simulate the program and hit run, a break occurs on the second nop. This would indicate that the addition opperation lost some data.

Whats happening here? Why would the addition opperation not properly calculate the result while the multiplication does?

Thanks
Philip

Parents Reply Children
  • Round the results up before displaying them.

    Stefan

  • You have two options for patching this:

    1) change the program. Make it present results cut down to a reasonable number of digits. Avoid showing the noise that's sitting in (at least) the last digit of any floating point result.

    2) change the user. Educate them about floating point comparison. Teach them the old
    dogma: In computing, 10.0 times 0.1 is hardly ever 1.0

  • Avoid showing the noise that's sitting in (at least) the last digit of any floating point result.
    what about noise between 99999 and 100000?

    In computing, 10.0 times 0.1 is hardly ever 1.0
    BS, it ALWAYS is if you do not use the much overused floating point.

    Erik

  • "The question is how to resolve it"

    Do you really need to use floating point?
    As has already been discussed, this will always result in such problems.

    Could you use fixed-point instead?

  • what about noise between 99999 and 100000?

    If you write it in an appropriate way for floating point numbers, that'll be 9.9999e4 and 1.00000e5. And for a 4-byte float, that's
    excessive displayed precision, in other words, you're showing noise. Reduce the format to %.3g and you'll get 1.000e5 in both cases.

    BS, it ALWAYS is if you do not use the much overused floating point

    But if you see a manifest constant written 0.1, that practically always is floating point. I don't think I've seen any programming language in which "10.0 * 0.1" would be evaluated in some fixed point number format. Have you?

    Anyway: it's called a dogma not because it's always actually true, but because by remembering it, you'll learn something useful.

  • But if you see a manifest constant written 0.1, that practically always is floating point. I don't think I've seen any programming language in which "10.0 * 0.1" would be evaluated in some fixed point number format. Have you?
    I have programmed for more years than most and never had to use floating point.

    Floating point is the lazy mans way to handle fractions.

    Erik

  • Could you use fixed-point instead?

    That's what I ALWAYS do in systems where accuracy is important. The following is probably obvious but I'll point it out anyway.

    An int can hold any of the following value ranges EASILY:

     -32768 to 32767
    -3276.8 to 3276.7  (*10)
    -327.68 to 327.67  (*100)
    -32.768 to 32.767  (*1000)
    -3.2768 to 3.2767  (*10000)

    This can be applied to char and long types as well.

    Jon

  • "Floating point is the lazy mans way to handle fractions"
    That what I want to learn!!!Thanks a lot!
    I'm really a lazy man.