CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 2 FirstFirst 12
Results 16 to 18 of 18
  1. #16
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: A question regarding float and double

    Quote Originally Posted by 2kaud View Post
    Please can some kind guru explain what is happening here as I don't understand.

    The only change being the highlighed line which should have no effect on the calculations.
    In a release build...
    The one example optimizes differently than the other.

    In the first example it's possible to keep the intermediate result in the FPU (as a 10byte floating point)
    In the 2Nd example this can't be done and the intermediate is stored in memory (as a double (8 byte))

    So even though "it can't have an effect on calculations". Such assumptions can't be made about floating point intermediates.

  2. #17
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    4,626

    Re: A question regarding float and double

    Quote Originally Posted by razzle View Post
    As you can see I've changed the accumulating d calculation to a direct multipliction with powers of 10 because otherwise small errors may accumulate and become big.
    better, but still not ideal. I wouldn't call it "fixed", but within the confines of that particular test, yes, maybe.
    and still subject to work within only a set range of values.

    This may be adequate, or it may not be, there are alternative ways to the problem, but it depends on what the real question is, is it just a matter of "how many decimals after the dot" or "need to know the mantissa in decimal", or "something else entirely".


    There are two major no-nos when doing floating point:
    there are more than 2

    1. don't compare for equality, and
    2. don't accumulate constants.
    1. comparing for equality is possible depending on the problem area.
    2. this isn't correct. It's more "beware of accumulating errors"
    What many people new to floating point don't realise is that floating point values are NOT decimally accurate. 0.1 is not "really" 0.1, it's an approximation in the same way as 0.33 is an approximation of 1/3. This approximation means there is a slight "error" in the decimal result you SEE displayed, and the actual value stored.

    Calculating with these approximations means you will increase the relative error on every calculation.

    To explain in decimal... so while 0.33 is only off by 1% of the actual value of 1/3. 0.33 * 0.33 = 0.1089 (as opposed to 1/3 * 1/3 or 1/9 or 0.1111111111) is 2% off the actual value. A single multiplication doubled the error range.
    For an addition in this case, the error stays the same. 0.33+0.33 = 0.66 which is 1% off 2/3 (addition won't always keep the relative error the same)

    Depending on the calculations done, you can increase the relative error (could be a lot, could be minor), keep it stable, or even reduce it. If you use calculated intermediated to do more calculations on you run into a case where the accumulated error may be so great that it starts to affect your results.



    If you want accuracy, and especially decimal accuracy... don't use floating points. They're unsuited for "accuracy" problems. (accounting, finances, ...), if you're in this case, you should either use a fixed point lib, a BCD lib or a string-based lib, you'll have to make it yourself or find one, as it doesn't come with C++ by default.

    floating point are good for stuff like 3D modeling, CAD, mathematical problems, statistics, where precision is important, but accuracy isn't. That isn't to say that accuracy can't creep in these type apps as well depending on what calculations are being done.

    this isn't a C++ specific issue, it's present in any language that's based on IEEE floating points.

  3. #18
    2kaud's Avatar
    2kaud is offline Super Moderator Power Poster
    Join Date
    Dec 2012
    Location
    England
    Posts
    7,822

    Re: A question regarding float and double

    Quote Originally Posted by OReubens View Post
    In a release build...
    The one example optimizes differently than the other.

    In the first example it's possible to keep the intermediate result in the FPU (as a 10byte floating point)
    In the 2Nd example this can't be done and the intermediate is stored in memory (as a double (8 byte))

    So even though "it can't have an effect on calculations". Such assumptions can't be made about floating point intermediates.
    Thanks.
    All advice is offered in good faith only. All my code is tested (unless stated explicitly otherwise) with the latest version of Microsoft Visual Studio (using the supported features of the latest standard) and is offered as examples only - not as production quality. I cannot offer advice regarding any other c/c++ compiler/IDE or incompatibilities with VS. You are ultimately responsible for the effects of your programs and the integrity of the machines they run on. Anything I post, code snippets, advice, etc is licensed as Public Domain https://creativecommons.org/publicdomain/zero/1.0/ and can be used without reference or acknowledgement. Also note that I only provide advice and guidance via the forums - and not via private messages!

    C++23 Compiler: Microsoft VS2022 (17.6.5)

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured