MM127
 

does anyone know of a program to CALCULATE [ONLY!] MM127 = 2^(2^127 -1)-1)...i know factoring it is virtually impossible, but calculating it cant be...?? links and other stuff helps alot thx:smile:

[QUOTE=antimath;285469]does anyone know of a program to CALCULATE [ONLY!] MM127 = 2^(2^127 -1)-1)...i know factoring it is virtually impossible, but calculating it cant be...?? links and other stuff helps alot thx:smile:[/QUOTE]
That is 10^(10^(10^1.582413493301632)), go figure how much space it would take to store it, then get back to us.

What do you want to calculate about it? This is just 2^127-1 bits, all of them being 1. So, first you look for about 1.7*10^38 bits of memory, that is not much, just 19807040628566084398385987584 gigabytes, then you fill all of them with 1. What is so difficult???

I'm sure [url=http://www.mersenneforum.org/showthread.php?t=10870]Curtis Cooper[/url] has it written down on a notepad somewhere...

[QUOTE=antimath;285469]does anyone know of a program to CALCULATE [ONLY!] MM127 = 2^(2^127 -1)-1)...i know factoring it is virtually impossible, but calculating it cant be...?? links and other stuff helps alot thx:smile:[/QUOTE]
You can calculate any of its decimal digits if that will satisfy your curiosity: the last 1000, the first 1000, ... or any given digit, for example the 314159265th digit... or not. :rolleyes:

Here's Python code to calculate it, and print it:
[CODE]MM127=2**(2**127-1)-1
print(MM127)[/CODE]
Note: no existing computer will be able to finish this program.

[QUOTE=LaurV;285480]What do you want to calculate about it? This is just 2^127-1 bits, all of them being 1. So, first you look for about 1.7*10^38 bits of memory, that is not much, just 19807040628566084398385987584 gigabytes, then you fill all of them with 1. What is so difficult???[/QUOTE]
Don't worry, it compresses very well. :wink: In fact, with the right algorithm, (i.e. "where the bytes of the file as a number are x, calculate MMx") you can store it in a single byte: 01111111.

[QUOTE=Batalov;285508]the last 1000[/QUOTE]
The last 1000 digits repeat cyclically, so you calculate MM127 modulo the cycle length.

[QUOTE=Batalov;285508]the first 1000[/QUOTE]
I haven't worked out the details, but I think you can track the first 1000+guard digits through successive doublings.

[QUOTE=Batalov;285508]for example the 314159265th digit[/QUOTE]
I don't know how to calculate this one, though.

[QUOTE=wblipp;285657]I haven't worked out the details, but I think you can track the first 1000+guard digits through successive doublings.[/QUOTE]
High precision logs.

IICC (If I calculated correctly), here's the first 1000+ digits (thanks to Pari):

[CODE]54543129001957378843931465896008210589349423685477667235404075275966293201609170424672529973992278171828573751806703589030869420288646093175468495080860272288857861747545862537756437098674222346365647119802401733149549254785201526438888502479253268057826437323564417964170617571980632548850088960037091796035202961108096679669489593720537183768359095819230433170516480756896976957583868764458099770918691408613562982373691771503874318596635831076763107059895504556733884228091178020321255026176317956600127015020809981773938409606830956146639230166636616192287793902321515403831972033102387976040468028125079678482416679257798154403144337229277566440573299804751002923089281341096461023036173103078419500018782121294711493545423257006683412552953435284142491984699944888780205024571856612842698394292710272603587159230032575847392878591995885731587973057009255468614011647081720403109593508461225776234622521599185438521239106860292082598601921729532323579501307651127212407305413121126823059540422578927614...[/CODE]The number itself has 51217599719369681875006054625051616349 digits, which itself has 38 digits.

Done with high precision logs?

Now can you teach us how to find the 314159265th digit?

The last 1000 digits appear to be
[CODE]...5306813365668297450370632400602267153874336893830587374421010744080639147929797090189031583986667245151695093088884848435739003342730983774160532341947281645852376823812191537066336494080616177095839838408723503324460081378144781399003245848814312060755437197330096531689244931436290688877165655112310821396183434300597491515931447277006739103507849853624660079369090487347841908091324793171634834191372487932912287198969725285700588443513422872332657159103300342083888175598493606647054638638459487370356026995048368555266388927554035854210857534541447525830208946429733247652561005894777628061789036981761598323020941762535700923452191914591248662885115946127751862309917152642709665522155340331650424597793571384683791990076270115592503537057996418689035885639996930655711304306774936853288566384077559882136253112332940815617303382922303266378846578148511333994928346239574411949114138364447524053925671023601313393687184931477325492550655458106222489358628350506357958045615739087358437493833727
[/CODE]
I was thinking about the 314159265th digit from the right, actually! ...so - just like the last 1000 digits (and should fit in memory, I think). And if from left, then with even more high precision log? :doh!:

(I was also thinking that maybe someone will find a better way, like it is possible with [SIZE=3][FONT=Times New Roman]π[SIZE=2] [FONT=Verdana]?)[/FONT][/SIZE][/FONT][/SIZE]

[QUOTE=Mini-Geek;285646]
Don't worry, it compresses very well. :wink: In fact, with the right algorithm, (i.e. "where the bytes of the file as a number are x, calculate MMx") you can store it in a single byte: 01111111.[/QUOTE]
Hehe, right! Even on a single bit, with "the right" algorithm (like "MMMMM[TEX]\pi_x[/TEX]") :razz:

[QUOTE=LaurV;285838]Hehe, right! Even on a single bit, with "the right" algorithm (like "MMMMM[TEX]\pi_x[/TEX]") :razz:[/QUOTE]

I stopped at MMx because it fit in one byte, and it wasn't SO specific that it was really only intended for this. E.g. any currently-known double Mersenne could be referred to using <= 4 bytes (i.e. an unsigned 32-bit integer, maxing at p=2[SUP]32[/SUP]-1~=4.3 billion). That could be reduced to 3 bytes by making it MM[TEX]\pi_x+1[/TEX] (+1 because there is no 0th prime; so rather than make the "convert file to number" concept more complicated, I'll just add 1). In fact, this could refer to future Mersenne doubles <= M310248241 ([URL="http://primes.utm.edu/nthprime/"]the 2[SUP]24[/SUP]th prime[/URL]) with just 3 bytes! The trouble with this method (using pi(x) in the calculation) is that it can now require some real work just to get p (sure, an efficient sieve can find that in no time, but you still have to correctly implement, or find, an efficient sieve). I think we can spare the extra byte.
:max: