Pi is not Pi (3563018237 NE 2188794840)

['09184'30918'0324918'093248'09124]

Hello,

Pi with 1 M digits not equal 3563018237 NE 2188794840

#### Qubes OS version (e.g., `R3.1`): QR32

#### Affected TemplateVMs (e.g., `fedora-23`, if applicable):

The test was done with a Standalone Machine, because of the Mathematica activation policy it is not possible to run it inside a AppVM.

uname -a

Linux localhost 4.4.14-11.pvops.qubes.x86_64 #1 SMP Tue Jul 19 01:14:58 UTC 2016 x86_64 GNU/Linux

user@localhost:~$ free -m
             total       used       free     shared    buffers     cached
Mem:          7179       1078       6101         10         28        421
-/+ buffers/cache:        628       6551
Swap:         1023          0       1023

---

### Expected behavior: Deterministic calculation of mathematical truth on any kind of system and especially Qubes.

Pi Black Box Testing:
Mathematica:

N[Pi,10^n]
Hash[%,"Adler32"]

or (in one line)
 Hash[N[Pi, 10^6], "Adler32"]

1. Calculate the digits of Pi up to 10^n.
2. Calculate a hash
3. Do this on different machines and you should find always the same hashes.

### Actual behavior:
3563018237 NE 2188794840

AMD Qubes R32:
n = 6
hash = 3563018237

Intel Win8
n = 6
hash = 2188794840

NE not equal
3563018237 NE 2188794840

Conclusion: One hash can be only the right one, because math is 100% deterministic.
Computer should be also deterministic, but it is sometimes hard to test them for 100%.

Here is a strong indicator, that at least one system, is not working correct.

Working-hypothesis: The hypervisor has some memory issues, which pop up here with long-integer-calculations.

Will it work for some n?
Yes, e.g. for 3:
680648812

(Let's assume that here all is right, in theory there might be some hash collision took place. There is an option to use other more long hashes, but this seems not bring us to another conclusion, that the calculations don't fit at all systems)

### Steps to reproduce the behavior:

1. Calculate Pi with 1 Million digits
2 Repeat this on different platforms (e.g. Windows versus Qubes versus native Debian)
3. compare the result (e.g. with a common hash)

### General notes:

Mathematica might be a useful tool, to check this out, but there are also many other math-libs or computer algebra programs (sage, maple), but the mathematical output is deterministic by definition and must be correct, otherwise there is some bug around.

Security Considerations: If the mathematical calculations will not lead to a deterministic result, cryptography functions can be affected because they are based on mathematical correct operations.

---

#### Related issues: Potential XEN  MEM

Check last digits: 021 NE 149
Win: 021
Qubes: 149

Kind Regards

[HW42]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

'09184'30918'0324918'093248'09124:

> ### Expected behavior: Deterministic calculation of mathematical truth on
> any kind of system and especially Qubes.
>
> Pi Black Box Testing:
> Mathematica:
>
> N[Pi,10^n]
> Hash[%,"Adler32"]
>
> or (in one line)
> Hash[N[Pi, 10^6], "Adler32"]
>
> 1. Calculate the digits of Pi up to 10^n.
> 2. Calculate a hash
> 3. Do this on different machines and you should find always the same hashes.

You made a small error here. You hash a Mathematica expression instead
of a defined binary representation of the value. Therefore Mathematica
hashes some internal representation, which don't need to be machine
independent. I did not find a documentation of what exactly Hash hashes
if you give it some expression. But for example the documentation of
DumpSave (see [0]) clearly states that it's not system independent:

Files written by DumpSave can only be read on the same type of
computer system on which they were written.

So try again with something like Hash[ToString[N[Pi, 10^6]], "Adler32"]

This will result in 1477199102 (tested with Mathematica under Windows).
You can also verify it without Mathematica, for example using [1] and
Ruby:

$ pi 1000000 | ruby -rzlib -e 'puts Zlib.adler32(gets.chomp)'
1477199102
$

> Let's assume that here all is right, in theory there might be some
> hash collision took place.

A hash collision would not change the determinism of the result.


[0]: https://reference.wolfram.com/language/ref/DumpSave.html
[1]: https://packages.debian.org/jessie/pi
-----BEGIN PGP SIGNATURE-----

iQJDBAEBCgAtFiEEqieyzvOmi9FGaQcT5KzJJ4pkaBYFAlg7bDMPHGh3NDJAaXBz
dW1qLmRlAAoJEOSsySeKZGgWtJIP/js7l7U39gpAurouRhNzT4aiqH3shp74YCM7
NCHhTqUyIZOmQZ0bxflBQ65aN4HcLCt20erOeQ28uPqMngbwcmiZ6c/fl/ifsqUp
+Oh6r5aN0A/if4imVi0zQBoydPxj4ueb7muBxkVKB4ZO60kO0N47+hjjbyI/BVhP
dqbISbeLRExS46mSTL7Xp3HNGLFlnkdos1oWii9FxZdeBscOFI0yy6w8cYl8XVGK
bp3fs6hFf6dM+bK1BYanIIIt1FhlG+eVd+Yoin1F33/sH2HZyYwjmZ1yglfhccJJ
XHvcZR9XM6ijOIYOJT4pPK51waRRRtofHYHDf2p+qy2/rBVcI2pE/c/FeUc7FXZC
o186giNcpvtoUdzOceG7qrihA0Sydob154LeVgW7b8+zy84/twGBr3wZ1O90K4p0
TLLHyy5ttmPD9Wzjd4GP5lIH+gSyI11r7/Fy4/knwi2nTK2CE+8ydHX8ztL4R+vL
YBQ29NxcCZyFSUSIoAGfItrZ23Hr9mCBw3Qfm+FOVhLWHbsfmgJJV+RXVhi9TsS0
ysnlThdX0PFofKlbd5Xxha5qMaw3kqhBn7RlvUI/wLUweR2TuVj4ycIKUupi0LbI
pVXsgxYYKXVe49Pz5N2VsJQ+J8nc21drPHSfsXFRZrKwoFEmIH/vveKygcnKbLYd
iCW/IwwC
=8idc
-----END PGP SIGNATURE-----

['0924358'029458'0294358'098]

Hi HW42,

I think you are right and with Hash[ToString[N[Pi, 10^6]], "Adler32"] I came to the same result for the hashes: 1477199102.

But still the last digits differ:

021 under Windows
149 under Qubes

, which cannot be the truth, or?

What are your last 3 digits of Pi with an accuracy of 1000 000 digits?

Kind Regards

['0943285'0192384'0193284'0943218'098]

Hello HW42,

what are your last 3 digits?

Kind Regards

[01923845'0194328'0913284'093]

Hello,

I checked out:

N[Pi,10⁹ ]

SVM with:
MEM 22171
Size 23402 MiB

RAM 32 GB

Yes the calculation was finally was executed, but I cannot tell you the last 3 digits.
Because I resized the window and some strange grey areas appear and I don't see the scrollbars any more.

Expectation: If the memory is low, the swap will handle it (under native Debian I can use the full swap size for every calculation) .

The window is frozen and I cannot save the result.

I think the Q-Memory Management is not running in the same way like Debian does it to manage also big calculations in a safe way.

Kind Regards

['09832'045982'3049582'039458'09]

Hello,

it might be better to generate just a file:

s1 = "QX8_6";
s2 = s1 <> ".txt";
p1 = N[Pi, 10^6];
Export[s2, p1]

The generation is fine.

But the text-editor is like frozen to show the file (Size is 1 MB).

I copy it to a new VM, but also here it will not open.
After minutes it is now open, but all numbers a written above each other, so I cannot read the last 3 digits.

Why?

Kind Regards

[Ilpo Järvinen]

That's probably editor dependant so I cannot answer to the overlap problem
but you could use cut command with -b switch to extract a smaller part of
the data and inspect just that part.


--
i.