Deviation of double

Discussion in 'C++' started by Christian Meier, May 17, 2004.

  1. Hallo NG

    My problem is the deviation of the floating point datatypes. 90.625 is not
    exactly 90.625. It is 90.624999999.... on my system. Now I tried to find a
    solution for my problem but I couldn't think of one. So I tried to write a
    work-arround which should solve the problem for the most numbers.
    What do you think of this: (I know it is not a perfect solution....)

    double dValue = ...;

    if (dValue >= 10000000000000LL) {
    nInValue += 0.01;
    } else if (dValue >= 1000000000000LL) {
    nInValue += 0.001;
    } else if (dValue >= 100000000000LL) {
    nInValue += 0.0001;
    } else if (dValue >= 10000000000LL) {
    nInValue += 0.00001;
    } else if (dValue >= 1000000000) {
    nInValue += 0.000001;
    } else if (dValue >= 100000000) {
    nInValue += 0.0000001;
    } else if (dValue >= 10000000) {
    nInValue += 0.00000001;
    } else if (dValue >= 1000000) {
    nInValue += 0.000000001;
    } else if (dValue >= 100000) {
    nInValue += 0.0000000001;
    } else if (dValue >= 10000) {
    nInValue += 0.00000000001;
    } else if (dValue >= 1000) {
    nInValue += 0.000000000001;
    } else if (dValue >= 100) {
    nInValue += 0.0000000000001;
    } else if (dValue >= 10) {
    nInValue += 0.00000000000001;
    } else if (dValue < 0) {
    nInValue -= 0.000000000000001;
    } // if

    Greets Chris
    Christian Meier, May 17, 2004
    #1
    1. Advertising

  2. "Christian Meier" <> wrote in message
    news:c8aaoj$htb$...
    > Hallo NG
    >
    > My problem is the deviation of the floating point datatypes. 90.625 is

    not
    > exactly 90.625. It is 90.624999999.... on my system. Now I tried to find

    a
    > solution for my problem but I couldn't think of one. So I tried to write

    a
    > work-arround which should solve the problem for the most numbers.
    > What do you think of this: (I know it is not a perfect solution....)
    >
    > double dValue = ...;
    >
    > if (dValue >= 10000000000000LL) {
    > nInValue += 0.01;
    > } else if (dValue >= 1000000000000LL) {
    > nInValue += 0.001;
    > } else if (dValue >= 100000000000LL) {
    > nInValue += 0.0001;
    > } else if (dValue >= 10000000000LL) {
    > nInValue += 0.00001;
    > } else if (dValue >= 1000000000) {
    > nInValue += 0.000001;
    > } else if (dValue >= 100000000) {
    > nInValue += 0.0000001;
    > } else if (dValue >= 10000000) {
    > nInValue += 0.00000001;
    > } else if (dValue >= 1000000) {
    > nInValue += 0.000000001;
    > } else if (dValue >= 100000) {
    > nInValue += 0.0000000001;
    > } else if (dValue >= 10000) {
    > nInValue += 0.00000000001;
    > } else if (dValue >= 1000) {
    > nInValue += 0.000000000001;
    > } else if (dValue >= 100) {
    > nInValue += 0.0000000000001;
    > } else if (dValue >= 10) {
    > nInValue += 0.00000000000001;
    > } else if (dValue < 0) {
    > nInValue -= 0.000000000000001;
    > } // if
    >


    I'm not sure what you are trying to achieve by doing this, and what about
    negative numbers? The problem is that many numbers cannot be exactly
    represented in floating point format, just like 1/3 cannot be exactly
    represented with just decimal numbers. Fiddling with floating point values
    will only help in very specific cases at best. If the inevitable rounding
    errors of floating point numbers is not acceptable for your application,
    maybe a fixed point format is more appropriate for your application.

    --
    Peter van Merkerk
    peter.van.merkerk(at)dse.nl
    Peter van Merkerk, May 17, 2004
    #2
    1. Advertising

  3. Christian Meier wrote:
    >
    > Hallo NG
    >
    > My problem is the deviation of the floating point datatypes. 90.625 is not
    > exactly 90.625. It is 90.624999999.... on my system. Now I tried to find a
    > solution for my problem but I couldn't think of one.


    Forgive me. What was your problem?

    > So I tried to write a
    > work-arround which should solve the problem for the most numbers.
    > What do you think of this: (I know it is not a perfect solution....)


    I doesn't look like solution to anything.

    --
    Karl Heinz Buchegger
    Karl Heinz Buchegger, May 17, 2004
    #3
  4. Christian Meier

    bartek Guest

    "Christian Meier" <> wrote in
    news:c8aaoj$htb$:

    > Hallo NG
    >
    > My problem is the deviation of the floating point datatypes. 90.625 is
    > not exactly 90.625. It is 90.624999999.... on my system. Now I tried
    > to find a solution for my problem but I couldn't think of one. So I
    > tried to write a work-arround which should solve the problem for the
    > most numbers. What do you think of this: (I know it is not a perfect
    > solution....)


    (...)

    You can't "work around" the floating point precision limitation. You can
    only use more bits to have a better approximation. An exact representation
    would require an infinite amount of bits, wouldn't it?
    That's how computers work, sorry.

    You can use a specialised extended-precision arithmetics library, though,
    like the GNU MP http://www.swox.com/gmp/ for example.

    --
    :: bartekd [at] o2 [dot] pl
    bartek, May 17, 2004
    #4
  5. bartek wrote:
    > [...]
    > You can't "work around" the floating point precision limitation.


    Yes, he can (and often should). He could use fractions. 90.625 is 725/8.
    If all arithmetic operations are done in fractions, it's possible to
    achieve exact solution (using large enough integers to represent the numbers).

    BTW, to the OP: I have a hard time believing that 90 5/8 is not
    represented precisely on your machine. It's quite possible that you
    _expect_ it to be represented precisely, like after multiplying 0.90625
    with 100, but you don't have your 0.90625 precisely to begin with. That's
    the problem, I believe.

    V
    Victor Bazarov, May 17, 2004
    #5
  6. "Karl Heinz Buchegger" <> schrieb im Newsbeitrag
    news:...
    > Christian Meier wrote:
    > >
    > > Hallo NG
    > >
    > > My problem is the deviation of the floating point datatypes. 90.625 is

    not
    > > exactly 90.625. It is 90.624999999.... on my system. Now I tried to find

    a
    > > solution for my problem but I couldn't think of one.

    >
    > Forgive me. What was your problem?
    >
    > > So I tried to write a
    > > work-arround which should solve the problem for the most numbers.
    > > What do you think of this: (I know it is not a perfect solution....)

    >
    > I doesn't look like solution to anything.
    >
    > --
    > Karl Heinz Buchegger
    >


    Sorry, wasn't a really good description of my problem. I will give more
    infos: I have a function with two parameters. One of type double, the other
    one is an int.
    string func (double dValue, int iDigits);
    This function must return a string which represents the double value.
    iDigits is the number of digits after the point. For this I use sprintf. And
    now I got a problem. When passing 90.625 to the function (iDigits = 2) then
    the function returned 90.62 instead of 90.63. I found out that the double is
    stored as 90.624999999... on my system. So I need a solution for this. The
    function has to return 90.63. So I thought I can add a small value to dValue
    before rounding. And the double has a limit of 15 decimal digits on my
    system. So I tried to write a work-arround as described in my first post.
    Can you now understand my problem?

    Regards,
    Chris
    Christian Meier, May 17, 2004
    #6
  7. "Victor Bazarov" <> schrieb im Newsbeitrag
    news:Cu3qc.230$...
    > bartek wrote:
    > > [...]
    > > You can't "work around" the floating point precision limitation.

    >
    > Yes, he can (and often should). He could use fractions. 90.625 is 725/8.
    > If all arithmetic operations are done in fractions, it's possible to
    > achieve exact solution (using large enough integers to represent the

    numbers).
    >
    > BTW, to the OP: I have a hard time believing that 90 5/8 is not
    > represented precisely on your machine. It's quite possible that you
    > _expect_ it to be represented precisely, like after multiplying 0.90625
    > with 100, but you don't have your 0.90625 precisely to begin with. That's
    > the problem, I believe.
    >
    > V


    It does..... these lines:

    double d = 90.625;
    char c[10];
    sprintf(c, "%.2f", h);
    std::cout << c << std::endl;

    return the following output:
    90.62

    Greetings Chris
    Christian Meier, May 17, 2004
    #7
  8. Victor Bazarov wrote:
    >
    > bartek wrote:
    > > [...]
    > > You can't "work around" the floating point precision limitation.

    >
    > Yes, he can (and often should). He could use fractions. 90.625 is 725/8.
    > If all arithmetic operations are done in fractions, it's possible to
    > achieve exact solution (using large enough integers to represent the numbers).
    >


    Hmm. I wonder how you would represent PI in such a system :)

    --
    Karl Heinz Buchegger
    Karl Heinz Buchegger, May 17, 2004
    #8
  9. Karl Heinz Buchegger wrote:
    > Victor Bazarov wrote:
    >
    >>bartek wrote:
    >>
    >>>[...]
    >>>You can't "work around" the floating point precision limitation.

    >>
    >>Yes, he can (and often should). He could use fractions. 90.625 is 725/8.
    >> If all arithmetic operations are done in fractions, it's possible to
    >>achieve exact solution (using large enough integers to represent the numbers).
    >>

    >
    >
    > Hmm. I wonder how you would represent PI in such a system :)


    22/7 of course (Gods know a better value). On a serious note, however, I
    suspect that the OP starts with integral values. If that's so, then the
    result should be representable as a fractional value, if all operations
    are arithmetic.

    V
    Victor Bazarov, May 17, 2004
    #9
  10. Christian Meier wrote:
    > "Victor Bazarov" <> schrieb im Newsbeitrag
    > news:Cu3qc.230$...
    >
    >>bartek wrote:
    >>
    >>>[...]
    >>>You can't "work around" the floating point precision limitation.

    >>
    >>Yes, he can (and often should). He could use fractions. 90.625 is 725/8.
    >> If all arithmetic operations are done in fractions, it's possible to
    >>achieve exact solution (using large enough integers to represent the

    >
    > numbers).
    >
    >>BTW, to the OP: I have a hard time believing that 90 5/8 is not
    >>represented precisely on your machine. It's quite possible that you
    >>_expect_ it to be represented precisely, like after multiplying 0.90625
    >>with 100, but you don't have your 0.90625 precisely to begin with. That's
    >>the problem, I believe.
    >>
    >>V

    >
    >
    > It does..... these lines:
    >
    > double d = 90.625;
    > char c[10];
    > sprintf(c, "%.2f", h);
    > std::cout << c << std::endl;
    >
    > return the following output:
    > 90.62


    They do????? Declare/define/initialise 'd', then print 'h' and expect
    something sensible? Come on...

    I took your code, fixed it, put it in a write surrounding and got 90.63.
    Try again, this time the right version:

    #include <iostream>
    #include <cstdio>

    using namespace std;

    int main()
    {
    double d = 90.625;
    char c[10];
    sprintf(c, "%.2f", d);
    cout << c << endl;

    return 0;
    }

    V
    Victor Bazarov, May 17, 2004
    #10
  11. Christian Meier wrote:
    > "Karl Heinz Buchegger" <> schrieb im Newsbeitrag
    > news:...
    >
    >>Christian Meier wrote:
    >>
    >>>Hallo NG
    >>>
    >>>My problem is the deviation of the floating point datatypes. 90.625 is

    >
    > not
    >
    >>>exactly 90.625. It is 90.624999999.... on my system. Now I tried to find

    >
    > a
    >
    >>>solution for my problem but I couldn't think of one.

    >>
    >>Forgive me. What was your problem?
    >>
    >>
    >>>So I tried to write a
    >>>work-arround which should solve the problem for the most numbers.
    >>>What do you think of this: (I know it is not a perfect solution....)

    >>
    >>I doesn't look like solution to anything.
    >>
    >>--
    >>Karl Heinz Buchegger
    >>

    >
    >
    > Sorry, wasn't a really good description of my problem. I will give more
    > infos: I have a function with two parameters. One of type double, the other
    > one is an int.
    > string func (double dValue, int iDigits);
    > This function must return a string which represents the double value.
    > iDigits is the number of digits after the point. For this I use sprintf. And
    > now I got a problem. When passing 90.625 to the function (iDigits = 2) then
    > the function returned 90.62 instead of 90.63. I found out that the double is
    > stored as 90.624999999... on my system. So I need a solution for this. The
    > function has to return 90.63. So I thought I can add a small value to dValue
    > before rounding. And the double has a limit of 15 decimal digits on my
    > system. So I tried to write a work-arround as described in my first post.
    > Can you now understand my problem?


    I believe you're confused about rounding. 90.6249999999999 simply _must_
    round to 90.62 if only two decimal digits are required. That's how
    rounding is defined. You cannot assume that "since it's so close to
    90.625, I should begin my rounding from 90.625 (instead of the actual value)".

    If your function "has to return 90.63", add this statement:

    return 90.63;

    to your function. If, OTOH, you want it to work correctly, analyse the
    problem further. Why do you get 90.6249999999999 instead of [expected]
    90.625? Why are you expecting 90.625? What values do you start with?
    What operations are you performing on those values? And so on...

    Victor
    Victor Bazarov, May 17, 2004
    #11
  12. Christian Meier wrote:
    >
    > Sorry, wasn't a really good description of my problem. I will give more
    > infos: I have a function with two parameters. One of type double, the other
    > one is an int.
    > string func (double dValue, int iDigits);
    > This function must return a string which represents the double value.
    > iDigits is the number of digits after the point. For this I use sprintf. And
    > now I got a problem. When passing 90.625 to the function (iDigits = 2) then
    > the function returned 90.62 instead of 90.63. I found out that the double is
    > stored as 90.624999999... on my system. So I need a solution for this. The
    > function has to return 90.63. So I thought I can add a small value to dValue
    > before rounding. And the double has a limit of 15 decimal digits on my
    > system. So I tried to write a work-arround as described in my first post.
    > Can you now understand my problem?


    I see.
    Hmm. There is indeed not much you can do other then adding some
    small constant depending on the number of digits you want
    after comma.

    But note: This doesn't solve your problem, it just hides it
    for that number.
    There will always be some border where one or the other digit
    shows up. If your numbers are close to that border you will
    see exactly that problem. In your case that border is the
    digit 5. By adding some small constant you simply shift
    that border a little bit higher or lower, but the border
    is still there.

    --
    Karl Heinz Buchegger
    Karl Heinz Buchegger, May 17, 2004
    #12
  13. "Victor Bazarov" <> schrieb im Newsbeitrag
    news:224qc.234$...
    > Christian Meier wrote:
    > > "Victor Bazarov" <> schrieb im Newsbeitrag
    > > news:Cu3qc.230$...
    > >
    > >>bartek wrote:
    > >>
    > >>>[...]
    > >>>You can't "work around" the floating point precision limitation.
    > >>
    > >>Yes, he can (and often should). He could use fractions. 90.625 is

    725/8.
    > >> If all arithmetic operations are done in fractions, it's possible to
    > >>achieve exact solution (using large enough integers to represent the

    > >
    > > numbers).
    > >
    > >>BTW, to the OP: I have a hard time believing that 90 5/8 is not
    > >>represented precisely on your machine. It's quite possible that you
    > >>_expect_ it to be represented precisely, like after multiplying 0.90625
    > >>with 100, but you don't have your 0.90625 precisely to begin with.

    That's
    > >>the problem, I believe.
    > >>
    > >>V

    > >
    > >
    > > It does..... these lines:
    > >
    > > double d = 90.625;
    > > char c[10];
    > > sprintf(c, "%.2f", h);
    > > std::cout << c << std::endl;
    > >
    > > return the following output:
    > > 90.62

    >
    > They do????? Declare/define/initialise 'd', then print 'h' and expect
    > something sensible? Come on...
    >
    > I took your code, fixed it, put it in a write surrounding and got 90.63.
    > Try again, this time the right version:
    >
    > #include <iostream>
    > #include <cstdio>
    >
    > using namespace std;
    >
    > int main()
    > {
    > double d = 90.625;
    > char c[10];
    > sprintf(c, "%.2f", d);
    > cout << c << endl;
    >
    > return 0;
    > }
    >
    > V



    Believe me!!! Ok, I'll prove it.... The following is my bash output:
    ~/> cat main.cpp
    #include <iostream>
    #include <cstdio>

    using namespace std;

    int main()
    {
    double d = 90.625;
    char c[10];
    sprintf(c, "%.2f", d);
    cout << c << endl;

    return 0;
    }
    ~/> g++ -o prog main.cpp
    ~/> prog
    90.62

    Do you need more infos that you can believe me?

    Greets Chris
    Christian Meier, May 17, 2004
    #13
  14. "Karl Heinz Buchegger" <> schrieb im Newsbeitrag
    news:...
    > Christian Meier wrote:
    > >
    > > Sorry, wasn't a really good description of my problem. I will give more
    > > infos: I have a function with two parameters. One of type double, the

    other
    > > one is an int.
    > > string func (double dValue, int iDigits);
    > > This function must return a string which represents the double value.
    > > iDigits is the number of digits after the point. For this I use sprintf.

    And
    > > now I got a problem. When passing 90.625 to the function (iDigits = 2)

    then
    > > the function returned 90.62 instead of 90.63. I found out that the

    double is
    > > stored as 90.624999999... on my system. So I need a solution for this.

    The
    > > function has to return 90.63. So I thought I can add a small value to

    dValue
    > > before rounding. And the double has a limit of 15 decimal digits on my
    > > system. So I tried to write a work-arround as described in my first

    post.
    > > Can you now understand my problem?

    >
    > I see.
    > Hmm. There is indeed not much you can do other then adding some
    > small constant depending on the number of digits you want
    > after comma.
    >
    > But note: This doesn't solve your problem, it just hides it
    > for that number.
    > There will always be some border where one or the other digit
    > shows up. If your numbers are close to that border you will
    > see exactly that problem. In your case that border is the
    > digit 5. By adding some small constant you simply shift
    > that border a little bit higher or lower, but the border
    > is still there.
    >
    > --
    > Karl Heinz Buchegger
    >


    Thanks for your help. Yes, you're right. It is not really a solution. And I
    must not estimate the the deviation is only 0.00001.... And I know that I
    really get trouble when someone is calling the function with the argument
    90.6249999999. Because then it should be rounded to 90.62. But as I said...
    it is just a work-arround for my current problem. It is not proper but I
    works now for the most cases.

    Greetings Chris
    Christian Meier, May 17, 2004
    #14
  15. Christian Meier wrote:
    > "Victor Bazarov" <> schrieb im Newsbeitrag
    > news:224qc.234$...
    >
    >>Christian Meier wrote:
    >>
    >>>"Victor Bazarov" <> schrieb im Newsbeitrag
    >>>news:Cu3qc.230$...
    >>>
    >>>
    >>>>bartek wrote:
    >>>>
    >>>>
    >>>>>[...]
    >>>>>You can't "work around" the floating point precision limitation.
    >>>>
    >>>>Yes, he can (and often should). He could use fractions. 90.625 is

    >
    > 725/8.
    >
    >>>> If all arithmetic operations are done in fractions, it's possible to
    >>>>achieve exact solution (using large enough integers to represent the
    >>>
    >>>numbers).
    >>>
    >>>
    >>>>BTW, to the OP: I have a hard time believing that 90 5/8 is not
    >>>>represented precisely on your machine. It's quite possible that you
    >>>>_expect_ it to be represented precisely, like after multiplying 0.90625
    >>>>with 100, but you don't have your 0.90625 precisely to begin with.

    >
    > That's
    >
    >>>>the problem, I believe.
    >>>>
    >>>>V
    >>>
    >>>
    >>>It does..... these lines:
    >>>
    >>> double d = 90.625;
    >>> char c[10];
    >>> sprintf(c, "%.2f", h);
    >>> std::cout << c << std::endl;
    >>>
    >>>return the following output:
    >>>90.62

    >>
    >>They do????? Declare/define/initialise 'd', then print 'h' and expect
    >>something sensible? Come on...
    >>
    >>I took your code, fixed it, put it in a write surrounding and got 90.63.
    >>Try again, this time the right version:
    >>
    >>#include <iostream>
    >>#include <cstdio>
    >>
    >>using namespace std;
    >>
    >>int main()
    >>{
    >> double d = 90.625;
    >> char c[10];
    >> sprintf(c, "%.2f", d);
    >> cout << c << endl;
    >>
    >> return 0;
    >>}
    >>
    >>V

    >
    >
    >
    > Believe me!!! Ok, I'll prove it.... The following is my bash output:
    > ~/> cat main.cpp
    > #include <iostream>
    > #include <cstdio>
    >
    > using namespace std;
    >
    > int main()
    > {
    > double d = 90.625;
    > char c[10];
    > sprintf(c, "%.2f", d);
    > cout << c << endl;
    >
    > return 0;
    > }
    > ~/> g++ -o prog main.cpp
    > ~/> prog
    > 90.62
    >
    > Do you need more infos that you can believe me?


    Sigh...

    So your compiler and my compiler create code that uses different rules for
    rounding... Mine rounds .5 up, yours probably towards the even. Use that
    rule wisely. See my other posts. Heed your own words that you need a
    real solution. What you call "a work-around" is not really a work-around,
    it's painting over a rusty spot, it's hiding the problem. For all we care
    you could simply do

    double myfunctionthatneedstoreturn90point63(double whatever)
    {
    // need to round 'whatever' but for now...
    return 90.63;
    }

    it's just as good a solution as your current "adding a small value".
    Believe me, you'd be better off if you never do anything like that and
    instead solve the real problem using real methods.

    If you need to round 0.5 _always_up_, then you need to do it manually. It
    is not as difficult a task (and we often simply rely on the CPU to do the
    right thing) if you have to roll your own. Look on the web for a
    solution. Somehow I am convinced that there are several in public domain.

    Victor
    Victor Bazarov, May 17, 2004
    #15
  16. Christian Meier

    tom_usenet Guest

    On Mon, 17 May 2004 15:58:57 +0200, "Christian Meier" <>
    wrote:

    >
    >"Karl Heinz Buchegger" <> schrieb im Newsbeitrag
    >news:...
    >> Christian Meier wrote:
    >> >
    >> > Hallo NG
    >> >
    >> > My problem is the deviation of the floating point datatypes. 90.625 is

    >not
    >> > exactly 90.625. It is 90.624999999.... on my system. Now I tried to find

    >a
    >> > solution for my problem but I couldn't think of one.

    >>
    >> Forgive me. What was your problem?
    >>
    >> > So I tried to write a
    >> > work-arround which should solve the problem for the most numbers.
    >> > What do you think of this: (I know it is not a perfect solution....)

    >>
    >> I doesn't look like solution to anything.
    >>
    >> --
    >> Karl Heinz Buchegger
    >>

    >
    >Sorry, wasn't a really good description of my problem. I will give more
    >infos: I have a function with two parameters. One of type double, the other
    >one is an int.
    >string func (double dValue, int iDigits);
    >This function must return a string which represents the double value.
    >iDigits is the number of digits after the point. For this I use sprintf. And
    >now I got a problem. When passing 90.625 to the function (iDigits = 2) then
    >the function returned 90.62 instead of 90.63. I found out that the double is
    >stored as 90.624999999... on my system. So I need a solution for this.


    Yes, the literal 90.625 is not the precise number 90.625. If you're
    having a problem with 90.625, just use 90.626.

    Read the FAQs on this point: http://www.eskimo.com/~scs/C-faq/s14.html

    The
    >function has to return 90.63. So I thought I can add a small value to dValue
    >before rounding. And the double has a limit of 15 decimal digits on my
    >system. So I tried to write a work-arround as described in my first post.
    >Can you now understand my problem?


    Either you're getting these numbers from literals in the code or from
    input of some kind. In the former case, change the literals. In the
    latter case, use a rational class to store the numbers, such as
    boost::rational (see www.boost.org). That way you don't lose precision
    (as long as the numerators and denominators lie in the allowed range).

    Tom
    --
    C++ FAQ: http://www.parashift.com/c -faq-lite/
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    tom_usenet, May 17, 2004
    #16
  17. Christian Meier

    Kurt Watzka Guest

    Christian Meier wrote:

    > Hallo NG
    >
    > My problem is the deviation of the floating point datatypes. 90.625 is not
    > exactly 90.625. It is 90.624999999.... on my system.


    Are you sure? 725 / 8 has an exact representation in a floating point system
    if FLT_RADIX (in <cfloat>) is 2, 4 or 8, and if FLT_DIG is greater than 5.

    Even for

    float a = 1.0f / 8.0f, s = 0.0f;
    for (int i = 0; i < 725; ++i)
    s += a;
    assert(s == 90.625f);

    your chances are quite good that the assertion will hold for reasonable
    floating point implementations. If you want to know which numbers have
    exact representations, or how floating point arithmetic is defined on
    your system, looking at <cfloat> cannot be avoided.

    If you are comparing 90.625f to the result of floating point operations
    that exceeded the possibilities of your floating point representation,
    you cannot expect exact equality. A good strategy to deal with the
    limitations of floating point representations is to think about
    these limitations while you perform flaoting point operations, not
    to assume that "all floating point results are inexact". If you use
    floating point results in further calculation, you have _no_ guarantee
    that 14 _decimal_ digits of your result are exact, even if you use
    double on an implementation with DBL_DIG greater than 14.

    Kurt Watzka
    Kurt Watzka, May 17, 2004
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Sydex
    Replies:
    12
    Views:
    6,473
    Victor Bazarov
    Feb 17, 2005
  2. Replies:
    3
    Views:
    473
    Chris Uppal
    May 25, 2006
  3. Verbal Kint
    Replies:
    10
    Views:
    639
    Keith Thompson
    Jun 30, 2007
  4. Replies:
    15
    Views:
    523
    Bruno Desthuilliers
    Oct 29, 2008
  5. Billy Mays

    Standard Deviation One-liner

    Billy Mays, Jun 3, 2011, in forum: Python
    Replies:
    5
    Views:
    295
    Ethan Furman
    Jun 5, 2011
Loading...

Share This Page