Reserving Cleared Mersenne Number

[Uncwilly]

Originally Posted by danc2

Consequently, making a hex of the same length as Prime95 is a little odd. If anyone knows how to create one, it would be appreciated!

When you get to the last step, just report the last 64 bits (in hex). Those who did some early work had shorter ones, like 16 bits. But as extra security, we use more.

[danc2]

Originally Posted by Uncwilly

When you get to the last step, just report the last 64 bits (in hex). Those who did some early work had shorter ones, like 16 bits. But as extra security, we use more.

Many thanks! Your explanation guided my google search .

For those that also want to do something like this in Python, it requires something like this (source here):

>>> padding = 18
>>> residue = 1416317954 # residue 0x00000000546B4C02
>>> f"{residue:#0{padding}x}".upper()
>>> '0x00000000546B4C02' # Residue matches!

[kriesel]

It's very likely that the least significant 64 bits of the interim residue are stored in multiple words. Padding with zero instead of retrieving and assembling the 64 bits gives a falsified residue. (In gpuowl, prime95, etc, it's common that 17 or 18 bits are stored per 64-bit double precision floating point word. Prime95 also uses a pseudorandom number of bits initial shift, so even the first 16 bits may occupy parts of two words, and the full 64bit residue may occupy 5 words and require both reassembly and deshifting.)

[danc2]

Originally Posted by kriesel

It's very likely that the least significant 64 bits of the interim residue are stored in multiple words. Padding with zero instead of retrieving and assembling the 64 bits gives a falsified residue. (In gpuowl, prime95, etc, it's common that 17 or 18 bits are stored per 64-bit double precision floating point word. Prime95 also uses a pseudorandom number of bits initial shift, so even the first 16 bits may occupy parts of two words, and the full 64bit residue may occupy 5 words and require both reassembly and deshifting.)

I think that Python handles the integer being in multiple words (really, the `mpz` type since its a gymp2 object). The result of, for example, 2.00595654682E+018 from the Reference MP LL res64 milestones pdf will not add any improper padding for this number:


>>> padding = 18
>>> residue = residue = gmpy2.mpz(2.00595654682E+018) # should be approximate 0x1BD696D9F03D3002 (spreadsheet error prevented from showing actual value)
>>> f"{residue:#0{padding}x}".upper()
>>> '0X1BD696D9F0134900' # Residue is most likely correct


That being said, I am going to check it against the last residue of a DC I am doing to be sure to see if they are the same. But it will be a while since my program is so slow .

Thank you for mentioning this so I can check!