Number Puzzle

[jchd]

But Bach IS back with its masterpiece played by two unmatched masters: https://www.youtube.com/watch?v=Z4LFjuWvwzw which I'd just love to get in .flac

Their interpretation is for me and by far and further the best ever, well above and deeper than Menuhin/Oistrakh. Interistingly, 1043's 3rd movement is a good candidate for a rock-structured band. But I'm digressing...

[czardas]

Do you mean the movement starting 11'35"? I agree that could be turned into an awesome rock track. The first movement is really good too. How did he come up with this stuff? I think Bach's music is the most fascinating of all the composers. Anyway now we both digress!

Edited September 1, 2015 by czardas

[jvanegmond]

czardas, if you can break whole numbers you probably should stay away from the floating point implementation. It's a nightmare in any implementation/language to deal with if you need to guarantee any kind of precision (among other problems). What are you doing anyway where you ran into this bug?

[czardas]

What are you doing anyway where you ran into this bug?

LOL. It's all part of the learning curve. The issue occured when using Execute() in  __OverflowDetect() in this thread: https://www.autoitscript.com/forum/topic/176620-operator64/ I have some improvements to add to that code, but I'm not quite ready to post it yet. Even the improved code is still painfully slow dispite an on average five fold speed improvement for the _Power64() function. Anyway I don't need this to be fast, it just has to do the job. Then I'll update some of my other scripts - making them compatible with Int-64, particularly this UDF https://www.autoitscript.com/forum/topic/165558-fraction/

Then I'll probably give up using floats for good.

Edited September 5, 2015 by czardas

[czardas]

I'm not sure if this is related (probably not), but I thought I ought to post my findings just in case: the effect is quite similar. Numeric conversion of doubles to integers appears to break beyond +/- 562949953421311. Perhaps double precision simply cannot store these integers accurately. I have run several tests with larger input ranges and the results have always been the same. This function is a depreciated early version.

For $i = 562949953421315 To 562949953420000 Step -1
    $iVal = Number($i, 3) ; or use ==> $iVal = $i / 1
    $iVal = __DoubleTo64MOD1($iVal)

    If @error Then ConsoleWrite($iVal & " - " & Number($iVal, 2) & @LF)
Next

Func __DoubleTo64MOD1($nValue)
    ; conversion appears to be unreliable for FP integers outside the range +/- 5.62949953421311e+014
    Local $iVal64 = Number($nValue, 2) ; Int-64
    ; Check to see if integer conversion was a success or not
    If $iVal64 = $nValue And $nValue < 1.0e+015 And $nValue > -1.0e+015 Then Return ($iVal64 > 2147483647 Or $iVal64 < -2147483648) ? $iVal64 : Number($iVal64, 1) ; Int-64 or Int-32
    Return SetError(1, 1, $nValue)
EndFunc ;==> __DoubleTo64

Output:

562949953421315 - 562949953421316
562949953421314 - 562949953421315
562949953421313 - 562949953421314
562949953421312 - 562949953421313

I'm currently testing this version:

; conversion appears to be unreliable for FP integers outside the range +/- 5.62949953421311e+014
Func __DoubleTo64($nValue)
    If $nValue > -1.0e+015 And $nValue < 1.0e+015 Then
        Local $iVal64 = Number($nValue, 2) ; Int-64
        If $iVal64 = $nValue Then ; Check to see if integer conversion was a success or not
            Return ($iVal64 > 2147483647 Or $iVal64 < -2147483648) ? $iVal64 : Number($iVal64, 1) ; Int-64 or Int-32
        ElseIf $iVal64 -1 = $nValue Then ; attempt to adjust for inaccuracies
            Return $iVal64 -1
        ElseIf $iVal64 +1 = $nValue Then ; as above
            Return $iVal64 +1
        EndIf
    EndIf

    Return SetError(1, 0, $nValue) ; conversion failed
EndFunc ;==> __DoubleTo64

It seems to, and should, work for FP integers up to 15 digits; both now, and presumably, in the foreseeable future. If anyone has any suggestions, please make them. I might have overlooked something.

Edited September 8, 2015 by czardas

[jvanegmond]

I see you are using a loop through the results and probably manually checking for correctness. For this type of code I really recommend to write unit tests. Use a small unit test library like this which is then used like this. Best approach is a small number of asserts per script that tests a single functionality/possible error. In your case you will mainly focus on edge-case testing. Find the edges of your behavior (eg 1.0e+015) and do the test -1 the edge, at the edge, +1 the edge. You can even run all test scripts in sequence for which you can use something like this.

[czardas]

Thanks. I haven't calculated the time it would take to run a complete test, but I doubt it would complete within my lifetime on this machine. Anyway I appreciate the suggestions. Only edge-case testing seems reasonable..

[jvanegmond]

The problem with testing every case is that you should specify expected results manually. If you use an algorithm to generate the expected results, what are you really testing? The "code under test" or the "test implementation"?

As for run-time, you seriously underestimate the speed of your computer. On my development machine, I regularly run 10,000s different and complex unit tests in minutes. The point is that they are simple and fast to execute. How to do that is for another time.

[czardas]

I have another computer I could use. This one's almost ready for the trash can. Don't ask!