Simple Addition gone wrong

[SMcNeill]

This looks OK to me, as suggested awhile ago:

Code: (Select All)

DefDbl A-Z
i = 0
stepper = .0000001
While _KeyDown(27) = 0
    Print Using "0.#######  0.#######"; i, itot
    i = i + stepper
    itot = itot + i
    _Limit 2
Wend

This only *looks* okay as you're using the PRINT USING statement to round the answer when displaying it.  The glitch is still there and will affect any IF statement which you might have which relies on absolute precision; you just won't be aware of what's causing it because you'll think the value is something which it really isn't.

Even string math isn't really a solution as you still have to eventually decide some sort of arbitrary cut-off point in your precision.   Doing string math, what is "1 / 3"?

Unless you're writing whole new routines to track repeating values, it's going to be some variation of "0.3333333333333333333333333333", with you deciding arbitrarily how many digits of precision you're going to have with that string math.  It might be 1000 digits, and have a very small margin of error after that, but that error is still going to be there.  

There comes a point where you just have to shrug and say, "Close enough is good enough," and not worry about it after that.  If your PC has 128GB of RAM, it might be after you start adding 64GB string values to 64 GB string values, but eventually you're going to hit some sort of hardware limit, if you don't hit one somewhere else first.

It's why most programs that work in floating point values has an "Allowable Margin of Tolerance" built into them.

IF x = 10 THEN....   <-- this might not trigger if you're doing floating point math inside a loop as x might equal 9.99999999999999 or 10.000000000001.  It'll be *close* but not *exactly* 10 and then you'll never trigger your IF statement.

Instead, the programs that rely on floating point math would be written more like:

IF ABS(x - 10) < 0.000000001 THEN....    Now, we've declared that we accept any value from 9.999999999 to 10.0000000001 as being "close enough" to 10 to be the same as 10 for our purposes.  We build in the tolerance ourselves for the floating point errors that we're going to generate over time.

Floating point is for approximations, speed, and ease of use; it's not for absolute precision.  <-- That's the core lesson that everyone needs to learn when working with any type of floating point value.

[bplus]

We are not dividing so throw out the 1/3 stuff. When adding and subtracting decimals dont change and multiplication the decimals are increased by predictable amounts but HERE in this thread we are only talking about adding. And I did say it ONLY LOOKS OK, never did I say IT WAS.

Here is where I said how to do it right! : https://qb64phoenix.com/forum/showthread...6#pid35476

[Jack]

unfortunately no solution is perfect, it might be close to perfect if you had operator overloading
I think that I said this before, it would be nice if decimal floats were added to QB64, say 8, 16 and 32 digits precision

[Pete]

This is why I get greater precision than you guys, because I run my string math routine on my IBM quantum laptop. I'd show you some examples, but the last time I ran it, I froze my balls off and now that device is floating around in some parallel universe waiting for a pending Windows Update.

Pete

1 + 1 = bigger 1.