Representing long decimals in hex in Java

[Paul Uszak]

I think that we both probably have the same pi file! Thanks for your code example. It's a clever idea that I hadn't thought of.

Thing is, my spider sense is tingling because I'm having a hard time understanding how the output can be pi like with less entropy that in the original (2.6 bits versus 3.3). My fear is that the code does not represent pi, but has generated a pseudo random file with characteristics determined exclusively by your code, and not by inherent mathematics. Is there any possibility that your code is acting as a pseudo random generator acting upon an ASCII pi seed?

 

[DrZoidberg]

The file generated by my code is determined by both - pi and the way in which my code does the conversion. There are many different ways to extract random bits out of pi. What's important here is that the output is perfectly random as long as the input is. The amount of information is reduced simply because some of it is thrown away in order to allow the algorithm to be faster.

 

[Paul Uszak]

one can, for example, calculate the quadrillionth (10¹⁵) hexadecimal digit of pi without having to calculate all of the 10¹⁵-1 hexadecimal digits that precede it.

I suspect that it's not quite as easy as you've written it. There's quite a summation to be calculated using arbitrary precision mathematics isn't there..?

 

[Paul Uszak]

you can use the BigInteger class

I thought that this was the silver bullet. Wow, was I wrong

I used BigInteger and output 4MB of pi bytes. It worked perfectly and I've attached a piccy for anyone who wants to see what 3MB of pi looks like. BUT.

The BigInteger technique won't work in practice to process the 1GB file. It tool me 3 hours to process 4MB. I did some tests, and have attached a spreadsheet of my findings. It will take 4ish years to process the full 1GB file. This result is unexpected and not understood. I didn't even bother with memory requirements. It would actually be quicker to generate pi as bytes directly. I'll have to think of something else...

 

[pbuk]

What you are trying to do is ridiculous. The only property of π you are interested in is the randomness of its digits (in any base). The place value of its decimal digits is irrelevant and you have been given a perfectly good method of transforming the decimal digits to binary while preserving entropy (just reducing the overall volume of information), plus a pointer towards methods to generate π in binary directly if that is really what you want to do.

Did you really have to do all that work to realize that performing 10⁹ multiplications of 10⁹ digit numbers (which is what base conversion entails) is not computationally feasible?