20200206, 21:23  #12 
"Yves"
Jul 2017
Belgium
41_{16} Posts 
The problem of long and short scales :https://en.wikipedia.org/wiki/Long_and_short_scales … but 5E13 is already in itself a terrific result !

20200207, 09:19  #13  
"Robert Gerbicz"
Oct 2005
Hungary
2716_{8} Posts 
Quote:
Doable, pretty short words. 

20200207, 09:42  #14 
Romulan Interpreter
Jun 2011
Thailand
9653_{10} Posts 
Do they have a record for the "longest" speaker? Like the person who talked without a pause for a while?
(we wanted to send the former link to swmbo with the title "someone have beaten you already" but it occured to us that she's actually not a fast speaker, so we refrained ourselves on doing such a terrible mistake... ) Last fiddled with by LaurV on 20200207 at 09:45 
20200207, 09:47  #15  
Sep 2016
14E_{16} Posts 
Woah, I go away for a while and didn't notice all these new posts!
Quote:
But there are a few technicalities: The large multiplications are done inplace. So the output overwrites the inputs. (the multiplication is still done using the FFT scratch buffers) 1) One problem is that I don't support checkpointing inside the large multiplications. Thus I can only checkpoint before or after a large multiplication. But if you encapsulate the multiplication into an indivisible operation, it becomes a destructive operation that destroys the inputs. Thus if something goes wrong inside the multiply, you cannot roll back to before the multiply because you've already destroyed the inputs. This inplaceness of the multiplications within the baseconversion will chain up. Thus there's no point where you can do a checkpoint other than before the entire conversion begins. 2) The other problem is that checkpointing is done with filegranularity. I don't support checkpointing parts of a file. The binary>radix conversions involve recursively splitting up the binary input into smaller and smaller portions which you eventually write piecewise into a large output buffer (in the desired radix). The presents a problem. That output buffer is allocated as single contiguous storage region as a single file. I can't write to parts of the file, checkpoint it, then write to other parts. The reason I can't do that is due sector alignment. Let's say the following is a partially written sector that's been checkpointed: 0123456789xxxxxx Then in a later operation, I want to write out the rest of the sector so that it is: 0123456789abcdef However. When you access disk, the entire sector must be read/written at once. The later operation needs to do a readmodifywrite to data that is part of the previous checkpoint. If something goes wrong during this step, it will corrupt the previous checkpoint!  Long story short, I believe both of issues are surmountable. But I haven't done the necessary research into it yet. For example, the inplaceness issue (1) can be overcome by having two working buffers and writing backandforth between them. But the base conversion already uses the most storage of the entire computation. The sectoralignment is probably solvable by keeping a separate mapping that stores backups of all partially written sectors. But saying that this is a mess in the context of the software raid layer and manual errordetection checksums is an understatement. Last fiddled with by Mysticial on 20200207 at 09:55 

20200207, 10:14  #16  
Sep 2016
516_{8} Posts 
Quote:
Each multiply is a middleproduct FFT that splits a 2Nbit binary input into two Nbit binary outputs which are written back into the same memory  overwriting the 2Nbit input. One of the Nbit outputs is the same as the upperhalf of the 2Bbit output. Thus instead of overwriting the entire memory region, the "new" Nbit output overwrites the nolongerneeded portion of the 2Nbit input. This partial write is hard to checkpoint due to problem (2) of the previous post. Since the inplace multiply is the only operation for the entire radix conversion, these inplace multiplications form a dependency chain/tree that prevents any sort of checkpointing at any step. Last fiddled with by Mysticial on 20200207 at 10:20 

20200209, 02:45  #17  
Feb 2017
Nowhere
4,663 Posts 
Quote:
Quote:
Quote:


20200519, 04:32  #18  
Aug 2010
2^{4}·41 Posts 
Quote:
https://www.mersenneforum.org/showpo...&postcount=716 http://www.numberworld.org/digits/Log(2)/ 

20201117, 06:18  #19  
Feb 2019
China
59 Posts 
Quote:
Why can it calculate so many digits? https://www.mersenneforum.org/showpo...0&postcount=14 why we can calculate 50 trillion digits of Pi ,but cannot test a PRP test on F33， F33 only has no more than 2700 billion digits Last fiddled with by bbb120 on 20201117 at 06:20 

20201117, 18:02  #20 
"Daniel Jackson"
May 2011
14285714285714285714
2^{3}·83 Posts 
Because the time complexity for pi calculation is much better/faster than that of primality/PRP tests. Also F33 has 2,585,827,973 digits, not 2.7 trillion (which is more like F43).
Last fiddled with by Stargate38 on 20201117 at 18:07 
20201117, 18:29  #21  
Random Account
Aug 2009
2^{2}·3·163 Posts 
Quote:
Some years ago, I saw a photo of a system built by a man in Japan on a sheet of plywood. He had an array of hard drives totaling 105 TB, I believe it was. 21 drives. The odd drive was OS only. The rest was for storage and swap, like a huge paging file. I don't remember it saying how much RAM he had on it or the CPU type. He had it all arranged very nicely. The drives were in stacked brackets with extra fans on them. The PSU was very large. It looked like a small computer tower sitting off to one side. IIRC, it took him nearly a year to run 11.4 trillion digits, which was a new record at the time. YCruncher seems to prefer vast amounts of swap/storage space on drives over lot of RAM. The Japanese man must have spent a small fortune buying all the parts to build what he had. 

20201118, 01:05  #22  
Feb 2019
China
59 Posts 
Quote:
it should be "F33 only has no more than 2700 million digits" I make a mistake ! floor(2^33*log(2)+1)=floor(2585827973.98) 2,585,827,973=2_585_827_973 (English) 2,585,827,973=25_8582_7973(chinese) I am not familiar with three digits separated number ,all Chinese four digits separated number , so I make a mistake Last fiddled with by bbb120 on 20201118 at 01:10 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Google Cloud Compute 31.4 Trillion Digits of Pi  Mysticial  ycruncher  30  20191011 14:45 
How many digits?  kokakola  Information & Answers  23  20091103 05:08 
15M Digits  Just For Fun  storm5510  Math  7  20090908 04:14 
All 10 Digits  davar55  Puzzles  5  20070618 15:06 
140+ digits which is better  marthamm  GMPECM  4  20060125 17:32 