speedcrunch gives irrational result when it shouldn't

[Eugene Kilachkoff]

I found a formula that produces strange result. Specifically, computing

(2*pi*sqrt(330e-6*10e-6))**-1

produces 2.77053194271996246042e3-214.604481485801913136e-39j

The 2.77...e3 appears correct, but 214.6e-39j part seems wrong due to positive number in the root.

Some observations:

1. Changing number representation, i.e. entering 0.000330 instead of 330e-6 does NOT change the behavior.
2. Changing 330e-6 to e.g. 330.000....long string of zeros...0001e-6 DOES remove the problem.
3. Changing 330e-6 to 330e-5 or 330e-7 DOES remove the problem.
4. Changing 330e-6 to 330e-4 or 330e-8 (and many subsequent even orders of magnitude) does NOT remove the problem.
5. Changing pi to 3.14 DOES remove the problem.
6. Changing sqrt() to ()**(1/2) DOES remove the problem.
7. Rewriting the expression as (sqrt(....)*2*pi)**-1 DOES remove the problem.
8. Changing (...)**-1 to any other power except zero does NOT remove the problem.
9. Removing **-1 altogether DOES solve the problem, but changing to **1 does NOT. Very strange indeed !

Judging by the observations I believe this to be a some sort of floating point number representation or some kind of precision loss, thus I'm initially triaging this to 'mathengine'.

This happens on Debian 9 x86_64, speedcrunch version 0.12.

[Pol Welter]

Huh, that's weird indeed. Thanks for the extensive info.

Btw, if you don't really need complex numbers, you can always disable them in the settings. Square roots, power operation, etc. then use methods that should automatically suppress spurious imaginary parts. But I guess you know this already.

Anyway, this is a proper bug, not just some rounding issue. All the functions should correctly recognize that their arguments are pure real, and act accordingly. Haven't looked at the code yet, but my bet's on the ln function, which is used by the power operation.

The issue is still be present in current master.

[Eugene Kilachkoff]

I think you might be correct about the ln function. I played a bit more and reduced the test case to (2*pi*57.445 626 465 380 2)**-1. If I remove the last 2 the issue disappears.

The number looks kinda special to me, because in binary it is 0b0.0000 0000 0000 0011 1101. Again, removing last 1 helps with the issue. Replacing the last 1 with 01 triggers the problem too.

Another special number is 0b0.0000 1111 01, i.e. the original shifted left 10 bits.

HTH.