Problem with comparing values

[mLipok]

I have such example:

_Example()

Func _Example()
    Local $sKwota_Naliczona = _String_AsRounded_Number('6.05')
    Local $sKwota_Pobrana_Wczesniej = 0.00
    Local $sKwota_Pobieram = _String_AsRounded_Number('4.19')
    Local $sKwota_Do_Pobrania = _String_AsRounded_Number('1.86')
    Local $bTesting_1 = $sKwota_Naliczona - $sKwota_Pobrana_Wczesniej - $sKwota_Pobieram
    Local $bTesting__A = ($bTesting_1 = $sKwota_Do_Pobrania)
    Local $bTesting__B = ($bTesting_1 == $sKwota_Do_Pobrania)
    ConsoleWrite( _
            'Test pobrania kosztu - ' & $bTesting__A & ' / ' & $bTesting__B & _
            ' ( testowano: ' & $sKwota_Naliczona & ' - ' & $sKwota_Pobrana_Wczesniej & ' - ' & $sKwota_Pobieram & ' = ' & $sKwota_Do_Pobrania & ' )' _
             & @CRLF)
EndFunc   ;==>_Example

Func _String_AsRounded_Number($sData)
    Return Round(Number(StringReplace($sData, ",", ".")), 2)
EndFunc   ;==>_String_AsRounded_Number

QUESTION:
Why $bTesting__A is False instead True ?

[Subz]

It looks like the two var types are not equal even though both are "double", you can use the following though:

Local $bTesting__A = (String($bTesting_1) = String($sKwota_Do_Pobrania))

 

[TheXman]

This should help you see why they are not equal:

_Example()

Func _Example()
    Local $sKwota_Naliczona = _String_AsRounded_Number('6.05')
    Local $sKwota_Pobrana_Wczesniej = 0.00
    Local $sKwota_Pobieram = _String_AsRounded_Number('4.19')
    Local $sKwota_Do_Pobrania = _String_AsRounded_Number('1.86')
    Local $bTesting_1  = $sKwota_Naliczona - $sKwota_Pobrana_Wczesniej - $sKwota_Pobieram
    Local $bTesting__A = ($bTesting_1 = $sKwota_Do_Pobrania)
    Local $bTesting__B = ($bTesting_1 == $sKwota_Do_Pobrania)

    ConsoleWrite(StringFormat("$sKwota_Do_Pobrania = %.15f", $sKwota_Do_Pobrania) & @CRLF)
    ConsoleWrite(StringFormat("$bTesting_1         = %.15f", $bTesting_1) & @CRLF)

    ConsoleWrite( _
            'Test pobrania kosztu - ' & $bTesting__A & ' / ' & $bTesting__B & _
            ' ( testowano: ' & $sKwota_Naliczona & ' - ' & $sKwota_Pobrana_Wczesniej & ' - ' & $sKwota_Pobieram & ' = ' & $sKwota_Do_Pobrania & ' )' _
             & @CRLF)
EndFunc   ;==>_Example

Func _String_AsRounded_Number($sData)
    Return Round(Number(StringReplace($sData, ",", ".")), 2)
EndFunc   ;==>_String_AsRounded_Number

Output:

$sKwota_Do_Pobrania = 1.860000000000000
$bTesting_1         = 1.859999999999999
Test pobrania kosztu - False / True ( testowano: 6.05 - 0 - 4.19 = 1.86 )

 

When comparing floating point values for equality, it is best to make sure that they are both rounded to the same decimal place.  $bTesting1 was not rounded.

 

Edited March 4, 2020 by TheXman

[Nine]

If you want more disturbing :

Local $fN1 = 6.05000000
    Local $fN2 = 4.19000000
    Local $fRes = 1.86000000
    If $fN1 - $fN2 = $fRes Then
      MsgBox (0,"","right")
    Else
      MsgBox (0,"","wrong")
    EndIf

 

[jchd]

Here are more gory details, with the string values used and how this translates in double format:

Input value = 6.05
0x4018333333333333
Sign        = +
Exponent    = 2
Scaling     = 2^2 = 4
Mantissa    = 1/2 + 1/128 + 1/256 + 1/2048 + 1/4096 + 1/32768 + 1/65536 + 1/524288 + 1/1048576 + 1/8388608 + 1/16777216 + 1/134217728 + 1/268435456 + 1/2147483648 + 1/4294967296 + 1/34359738368 + 1/68719476736 + 1/549755813888 + 1/1099511627776 + 1/8796093022208 + 1/17592186044416 + 1/140737488355328 + 1/281474976710656 + 1/2251799813685248 + 1/4503599627370496

Previous    = +6.0499999999999989341858963598497211933135986328125
Double      = +6.04999999999999982236431605997495353221893310546875
Next        = +6.050000000000000710542735760100185871124267578125

Input value = 1.86
0x3FFDC28F5C28F5C3
Sign        = +
Exponent    = 0
Scaling     = 2^0 = 1
Mantissa    = 1/2 + 1/4 + 1/16 + 1/32 + 1/64 + 1/2048 + 1/8192 + 1/131072 + 1/262144 + 1/524288 + 1/1048576 + 1/4194304 + 1/16777216 + 1/33554432 + 1/67108864 + 1/2147483648 + 1/8589934592 + 1/137438953472 + 1/274877906944 + 1/549755813888 + 1/1099511627776 + 1/4398046511104 + 1/17592186044416 + 1/35184372088832 + 1/70368744177664 + 1/2251799813685248 + 1/4503599627370496

Previous    = +1.859999999999999875655021241982467472553253173828125
Double      = +1.8600000000000000976996261670137755572795867919921875
Next        = +1.86000000000000031974423109204508364200592041015625

Input value = 4.19
0x4010C28F5C28F5C3
Sign        = +
Exponent    = 2
Scaling     = 2^2 = 4
Mantissa    = 1/32 + 1/64 + 1/2048 + 1/8192 + 1/131072 + 1/262144 + 1/524288 + 1/1048576 + 1/4194304 + 1/16777216 + 1/33554432 + 1/67108864 + 1/2147483648 + 1/8589934592 + 1/137438953472 + 1/274877906944 + 1/549755813888 + 1/1099511627776 + 1/4398046511104 + 1/17592186044416 + 1/35184372088832 + 1/70368744177664 + 1/2251799813685248 + 1/4503599627370496

Previous    = +4.1899999999999995026200849679298698902130126953125
Double      = +4.19000000000000039079850466805510222911834716796875
Next        = +4.190000000000001278976924368180334568023681640625

That's why you can check by yourself:

;  6.04999999999999982236431605997495353221893310546875
; -1.8600000000000000976996261670137755572795867919921875
; ========================================================
;  4.1899999999999997246646898929611779749393463134765625
;
; a completely different value than what you expect, which is
;  4.19000000000000039079850466805510222911834716796875

 

[Nine]

Guys stop making assumptions about translation.  Look at my simple math script and it returns WRONG !. 

[jchd]

Follow up.

Your result of ULPs(6.05 - 1.86) is "just" one ULP away:

Input value = 4.19
0x4010C28F5C28F5C2
Sign        = +
Exponent    = 2
Scaling     = 2^2 = 4
Mantissa    = 1/32 + 1/64 + 1/2048 + 1/8192 + 1/131072 + 1/262144 + 1/524288 + 1/1048576 + 1/4194304 + 1/16777216 + 1/33554432 + 1/67108864 + 1/2147483648 + 1/8589934592 + 1/137438953472 + 1/274877906944 + 1/549755813888 + 1/1099511627776 + 1/4398046511104 + 1/17592186044416 + 1/35184372088832 + 1/70368744177664 + 1/2251799813685248

Previous    = +4.18999999999999861444166526780463755130767822265625
Double      = +4.1899999999999995026200849679298698902130126953125
Next        = +4.19000000000000039079850466805510222911834716796875

Previous of 6.05 - 1.86 is = value of double 4.19, the difference being exactly 1/4503599627370496

[jchd]

I'm making zero assumption about IEEE computations, I just put plain, exact values that are dealt with inside the FP unit.

The code I use isn't perfect in that it doesn't (yet) handle NaNs nor denormals. It could, but I'm too busy for that.

FP computations aren't wrong per se, they are what the standard force them to be. It's just that binary isn't decimal and we use a finite binary representation. For instance, 6.05 is coded 0x4018333333333333 as a double and would require an infinite number of 33333... appended to be represented exactly, which is clearly impossible.

[Nine]

 you talking about.  Simple math should give simple result.  If you want to explain that this is a bug, I don't need your pseudo-mathematical-logic. 

I Have a bug that wasn't solved for so many years.  After awhile, I finally got it a workaround with  something like this :

Local $fN1 = 6.05000000
    Local $fN2 = 4.19000000
    Local $fRes = 1.86000000

  $iN1 = Int ($fN1*100)
  $iN2 = Int ($fN2*100)

    If $iN1 - $iN2 = Int($fRes*100) Then
      MsgBox (0,"","right")
    Else
      MsgBox (0,"","wrong")
    EndIf

 

[argumentum]

expandcollapse popup

_Example()

Func _Example()
    Local $sKwota_Naliczona = _String_AsRounded_Number(6.05)
    Local $sKwota_Pobrana_Wczesniej = 0.00
    Local $sKwota_Pobieram = _String_AsRounded_Number(4.19)
    Local $sKwota_Do_Pobrania = _String_AsRounded_Number(1.86)
    Local $bTesting_1 = $sKwota_Naliczona - $sKwota_Pobrana_Wczesniej - $sKwota_Pobieram

    ConsoleWrite(VarGetType($bTesting_1) & " >" & $bTesting_1 & "<" & @CRLF) ; Double >1.86<
    ConsoleWrite(VarGetType($sKwota_Do_Pobrania) & " >" & $sKwota_Do_Pobrania & "<" & @CRLF) ; Double >1.86<

    ConsoleWrite(($bTesting_1 = $sKwota_Do_Pobrania)  & @CRLF) ;   Double >1.86< = Double >1.86<
    ConsoleWrite(($bTesting_1 == $sKwota_Do_Pobrania) & @CRLF) ;   Double >1.86< != Double >1.86<

    $bTesting_1 *= 100
    $sKwota_Do_Pobrania *= 100
    ConsoleWrite(VarGetType($bTesting_1) & " >" & $bTesting_1 & "<" & @CRLF)
    ConsoleWrite(VarGetType($sKwota_Do_Pobrania) & " >" & $sKwota_Do_Pobrania & "<" & @CRLF)
    ConsoleWrite(($bTesting_1 = $sKwota_Do_Pobrania)  & @CRLF) ;
    ConsoleWrite(($bTesting_1 == $sKwota_Do_Pobrania) & @CRLF) ;

    $bTesting_1 = Int($bTesting_1)
    $sKwota_Do_Pobrania = Int($sKwota_Do_Pobrania)
    ConsoleWrite(VarGetType($bTesting_1) & " >" & $bTesting_1 & "<" & @CRLF)
    ConsoleWrite(VarGetType($sKwota_Do_Pobrania) & " >" & $sKwota_Do_Pobrania & "<" & @CRLF)
    ConsoleWrite(($bTesting_1 = $sKwota_Do_Pobrania)  & @CRLF)
    ConsoleWrite(($bTesting_1 == $sKwota_Do_Pobrania) & @CRLF)

    $bTesting_1 /= 100
    $sKwota_Do_Pobrania /= 100
    ConsoleWrite(VarGetType($bTesting_1) & " >" & $bTesting_1 & "<" & @CRLF)
    ConsoleWrite(VarGetType($sKwota_Do_Pobrania) & " >" & $sKwota_Do_Pobrania & "<" & @CRLF)
    ConsoleWrite(($bTesting_1 = $sKwota_Do_Pobrania)  & @CRLF)
    ConsoleWrite(($bTesting_1 == $sKwota_Do_Pobrania) & @CRLF)

EndFunc   ;==>_Example

Func _String_AsRounded_Number($sData)
    Return Number(Round(StringReplace($sData, ",", "."), 2))
EndFunc   ;==>_String_AsRounded_Number

..is a good question. In my experience ( and posting with your same observation ), you can only do math in integers on a PC.

[jchd]

Jeez, this isn't pseudo-math, it's IEEE!

What you experience isn't a bug, at all, it's a consequence of confusing a decimal representation and a finite binary representation.

[argumentum]

lol, I'm not saying it is ( pseudo-math ) . And I get your answer at a subconscious level ( .. don't understand IEEE rationally ).
But to the layperson looking at the console, ..is mind boggling.

Edited March 5, 2020 by argumentum

[Nine]

I don't give a shit about IEEE.  I have been programming for tens of years, and that simple maths was always resolve correctedly in Fortran, Cobol, C, C++, Oracle, Speed II, Delphi, FoxPro, dBase III, etc.

[jchd]

Not you, @Nine was saying.

I posted the way FP represents the various values of the OP. That shows why you can't expect an equality.

@Nine are you sure that in C you get 6.05 - 1.86 == 4.19 return true?

[Nine]

I am done with this BS.

[jchd]

@argumentum even when you don't dig inside the FPU registers, you can easily see what happens:

ConsoleWrite('Hex representation of 6.05 - 1.86: 0x' & Hex(6.05 - 1.86) & @LF)
ConsoleWrite('Hex representation of 4.19:        0x' & Hex(4.19) & @LF)

It's easy to see that the only difference is the last bit of the double values, called one ULP (Unit in the Last Place) in IEEE parlance.

BTW, launch your favorite SQL engine and run select 6.05 - 1.86 == 4.19; to get 0 or False. Same with almost all other languages.

[argumentum]

I am not a scholar. Can barely remember my name. But, internally, AutoIt could do the

1) do float to int
2) do the math equation
3) do the int to float and return the expected value.

Again, I do math in integers ( with the 3 steps above ), but the real number / floating point conundrum, could be solved internally by the interpreter ( AutoIt )

Do you feel ( or just plain know ), why is this not possible or desired ? Would it lead to anything I'm not taking into account ?

PS: I do understand:

ConsoleWrite( 0xFFFFFFFFFFFFFFF + 1 & @CRLF) ;  = 1152921504606846976
ConsoleWrite( 0xFFFFFFFFFFFFFFFF + 1 & @CRLF) ; = 0

there are limits, but most decimals are 2 places, and the mantissa(s) should be known by the interpreter, so it should be possible and use IEEE if not within the range of what is possible.

Edited March 5, 2020 by argumentum

[argumentum]

IEEE-754 Floating Point Converter.

This page allows you to convert between the decimal representation of numbers (like "1.02") and the binary format used by all modern CPUs (IEEE 754 floating point).

Edited March 5, 2020 by argumentum

[jchd]

The range of FP double is sooo huge that int64 are only a very tiny small portion of what FP can represent.
Of course one can write functions doing what you dream of, but then it's just easier to scale the input values so that they fit in int64s in the first place. Or you can simply use the BigNum.au3 UDF:

ConsoleWrite(_BigNum_Add('6.05', '-1.86') & @LF)
ConsoleWrite(_BigNum_Add('4.19', '0') & @LF)
ConsoleWrite((_BigNum_Add('6.05', '-1.86') = _BigNum_Add('4.19', '0')) & @LF)

The web page you link to is only for 32-bit FP, so-called single FP while my function explodes the full 64-bit FP values in understandable form (sort of!). In AutoIt and most languages double FP is by default.

The advent of 10-based FP as the latest IEEE standard describes isn't going to be fully implemented tomorrow even if software libraries are poping up. That's a huge and complex and slow thing!

[argumentum]

...brain storming ... . I come to think that my wish, is day dreaming BUT, an Opt("NoIEEE", n) would, if declared ( default as Opt("NoIEEE", 0) = leave it alone ), have the Option to internally regard in all floating point, to move the decimal point n places ( to a max. of 5 ) in behalf of the user opting it's declaration.

So this idea should be in a ticket to add the feature. I'm not to open the ticket but nevertheless, is in my view a good ( non-script braking ) idea  

( link to BigNum.au3 UDF ) 

Edited March 5, 2020 by argumentum