(+n) + (-n) + (-n) = baloney ???? [SOLVED]

[argumentum]

Local $a  = 1600 + -1384.92 + -215.08
ConsoleWrite( $a &@CRLF)

my result is "-8.5265128291212e-014" !!!!.

What am I doing wrong ?, how should I handle this ?.

- - - - - - - - - - - - - - - - - - - - 

Edit: I can not say I solved it but going from real to integer and back does it:

Local $a  = ((1600*100) + (-1384.92*100) + (-215.08*100)) /100
ConsoleWrite( "--- >"&$a&"<" &@CRLF)

Is there a more elegant way ?

Edited November 22, 2016 by argumentum

[UEZ]

This is the result of the internal floating point representation of the numbers -> see https://en.wikipedia.org/wiki/Floating_point

As a workaround you can use Round()

ConsoleWrite( Round($a, 10) & @CRLF)

 

[Bowmore]

One of these might be what you are looking for. Its all due to IEEE binary math on decimal numbers

Local $a  = 1600 + -1384.92 + -215.08
ConsoleWrite( $a &@CRLF)
ConsoleWrite( StringFormat("%0.20f",$a) &@CRLF)
ConsoleWrite( StringFormat("%0.12f",$a) &@CRLF)
ConsoleWrite( round($a,12) &@CRLF)

 

 

[Melba23]

argumentum,

Quote

What am I doing wrong ?

Nothing - search the forum for floating point arithmetic and all will become clear. If faced with the same problem I would do something like this:

Local $a[]  = [1600, -1384.92, -215.08]
$nTotal = _Total($a)
ConsoleWrite($nTotal &@CRLF)

Func _Total($aElements)

    $nTotal = 0
    For $i = 0 To UBound($aElements) - 1
        $nTotal += (100 * $aElements[$i])
    Next
    Return $nTotal / 100

EndFunc

Which is basically what you were doing.

M23

Edit: Guten abend, UEZ.

Edited November 22, 2016 by Melba23

[argumentum]

2 minutes ago, UEZ said:

ConsoleWrite( Round($a, 10) & @CRLF)

actually, this is what I ended up doing:

Local $a = Round(((Round(1600, 2) * 100) + (Round(-1384.92, 2) * 100) + (Round(-215.08, 2) * 100)) / 100, 2)
ConsoleWrite("--- >" & $a & "<" & @CRLF)

 

[kylomas]

argumentum,

I get

>"C:\Program Files (x86)\AutoIt3\SciTE\..\AutoIt3.exe" "C:\Program Files (x86)\AutoIt3\SciTE\AutoIt3Wrapper\AutoIt3Wrapper.au3" /run /prod /ErrorStdOut /in "C:\Users\Tom\Desktop\ss.au3" /UserParams    
+>14:28:37 Starting AutoIt3Wrapper v.15.920.938.0 SciTE v.3.6.0.0   Keyboard:00000409  OS:WIN_7/Service Pack 1  CPU:X64 OS:X64    Environment(Language:0409)
+>         SciTEDir => C:\Program Files (x86)\AutoIt3\SciTE   UserDir => C:\Users\Tom\AppData\Local\AutoIt v3\SciTE\AutoIt3Wrapper   SCITE_USERHOME => C:\Users\Tom\AppData\Local\AutoIt v3\SciTE 
>Running AU3Check (3.3.14.2)  from:C:\Program Files (x86)\AutoIt3  input:C:\Users\Tom\Desktop\ss.au3
+>14:28:37 AU3Check ended.rc:0
>Running:(3.3.14.2):C:\Program Files (x86)\AutoIt3\autoit3.exe "C:\Users\Tom\Desktop\ss.au3"    
--> Press Ctrl+Alt+Break to Restart or Ctrl+Break to Stop
--- >0<
+>14:28:37 AutoIt3.exe ended.rc:0
+>14:28:37 AutoIt3Wrapper Finished.
>Exit code: 0    Time: 0.5785

when I run your code...

kylomas

[UEZ]

4 minutes ago, Melba23 said:

Edit: Guten abend, UEZ.

Guten Abend Melba23. 

Edited November 22, 2016 by UEZ

[czardas]

Oh boy, FP arithmetic is so unstable. I see no reason why these very small numbers cannot be added together using FP arithmetic. I would go as far as to say it's absolutely shameful to see this result. It seems you can never rely (100%) on FP for programming or anything else, which kind of defeats the objective.

Edit : Baloney is absolutely the right word.

Edited November 23, 2016 by czardas

[jchd]

I beg to radically differ.

The current IEEE binary FP specifications are very clever and implement the most advanced techniques available for all kind of (binary) FP computations. You really should [try to] read that document to get a feeling of how sophisticated it is.

Binary FP has inherent limitations and it make as much sense to blame your FP unit or any language using it for binary FP rounding errors than to blame your CPU register for using 2's complement integer representation, where max (positive) integer + 1 = min (negative) integer.

If you really want to get rid of binary FP rounding errors, use a radix-10 IEEE 754-2008 library or hardware (e.g. a Power machine), that or a good arbitrary-precision arithmetic library.

[czardas]

You are right I probably should read it; but this appears, for all intents and purposes, to be much more than a rounding error. Even the exponent is way out - so much so that it scares the hell out of me.

Edit : I take it back. I only looked at the exponent and didn't do the maths. Since the answer is meant to be zero, it's close enough. DUH! 

I actually thought it was out by a ratio of billions to one. At least I can laugh at my mistake. 

Edited November 23, 2016 by czardas

[jchd]

For this blasphem, your punishment will be to write an AutoIt program to compute(*) the value of r  (expressed in yards, feet, inches and rational fraction down to 1/128") in the case where the radius R of the field is 405.3 m in the following problem: https://en.wikipedia.org/wiki/Goat_problem

Estimate yourself lucky that the solution is shown in full!

As a side bonus it should also make you feel how practical are imperial units.

(*) without just mutiplicating the numeric value for r=1 by R, please!

Edited November 23, 2016 by jchd

[czardas]

No problem. I'm going to do pounds shillings and pence conversion too!

[MuffinMan]

"Pence Conversion" is a VERY different thing in the US!