4 ms·

How can you tell if the results are accurate?

by patrickg_zill 8y ago

curiousgal 8y ago
Why would you need to do that? It's not like those digits are useful for anything at all.
- onion2k 8y ago
  I guess it depends on your definition of "useful", but one potential way to use pi would be as a way to transmit compressed data incredibly efficiently. If you could find the data you want to transmit in pi somewhere you'd only need to transmit an offset and a length to send anything than can be represented numerically. The hard part would be finding what you want to send though... ;)
  - gliptic 8y ago
    Unless it's not clear, the size of that offset would be about the same size as whatever you wanted to encode.
  - mkup 8y ago
    Offset and a length in Pi are not going to be shorter than original data to transmit.
    - thaumaturgy 8y ago
      Not necessarily. A double gets you pretty far into pi for a cost of just 8 bytes. A little bit of rounding, or checksumming, or other tomfoolery in principle should make it possible to reach absurdly far into pi for a byte or two more.
      - onion2k 8y ago
        If your offset is a million digits long you need to be sending more than a million digits of data to make it worthwhile, but the chance of your chosen million digits being available in that space is effectively zero. :)
        perl4ever 8y ago
        Regardless of the actual distribution of values in pi, it seems to me that the best case scenario can't compress all data on average when you include the offset and length, because of the pigeonhole principle. Same as any compression method, except practically worse/useless because pi isn't constructed to have the values that occur in practical situations come first.
      - jerf 8y ago
        Given that I personally have to have seen this proposal at least a dozen times myself, and I'm not even particularly "in the field", if it was as easy as people supposed, we'd be using it. I will point out you're thinking of it incorrectly, though. The challenge with compression isn't to "reach far into pi". The challenge is to reach correctly into pi. A double can identify 2^64 places to reach into pi. It doesn't really matter how you specify those 2^64 locations, that's all it can do, by the simple argument that one double can't specify more than one location. The location of the US Constitution in pi may be "far", but it's not the "far" we have in our fuzzy human brains where things sort of logarithmically just pile together until there's no meaningful difference to us humans between the 1,839,837,237,938,739,837,954th position of pi and the 1,839,827,237,938,739,837,954th position. But a compression algorithm off by that much is useless; indeed, even being off by one digit (in your choice of base) is going to produce garbage. So it's not just about being able to reach "far", it's about being able to reach far and precisely. It doesn't matter how you arrange the possible 2^64 locations a machine word can point to; specify it as 1,739,837,237,938,739,837,954 + the binary as a 64-bit int for all it matters. That reaches "far" into pi. But you won't find anything useful enough to pay off the 64bits you spent getting there. (I mean, you want to reach far into Pi, I give you "Go BusyBeaver(64-bit int) digits into Pi". That's reaching in pretty darned far. But it's still useless as a compression algorithm, even with the mighty power of BusyBeaver there.) (Amusingly, at BB(42) digits into Pi, you get "42" as the next digits, proving that 42 really is the answer. Prove me wrong!)
        thaumaturgy 8y ago
        I would expect that about zero of the propositions have ever been serious. It's just a well-known, long-running amusement among programmers. An IEEE 754 double type has a range from about 10^−324 to about 10^308. You start losing precision once you exceed 2^51, but beyond that it should be possible to add an extra byte or a few as an offset. So a handful of bytes would get us addresses far in excess of the current storage capacity of the internet (estimated around 10^24 bytes a few years ago) ... if only pi were certain to contain every possible number sequence up to some arbitrary length (which last I heard isn't known yet) and if we had some reasonable way to search and index all of that content (which we don't).
  - patrickg_zill 8y ago
    You've kind of re-invented, in a way, using DCT transforms to encode music more efficiently...
- DannyB2 8y ago
  > Why would you need to do that? It's not like those digits are useful for anything at all. People complain about that. But . . . why do we have athletic competitions? It's not like it is useful for anything at all. Or Reality TV for that matter.
chris_overseas 8y ago
This is explained in the second paragraph: > Yee independently verified the calculation using Bellard's formula[0] and BBP formula[1] [0] https://en.wikipedia.org/wiki/Bellard%27s_formula https://en.wikipedia.org/wiki/Bellard%27s_formula [1] https://en.wikipedia.org/wiki/Bailey%E2%80%93Borwein%E2%80%93Plouffe_formula https://en.wikipedia.org/wiki/Bailey%E2%80%93Borwein%E2%80%9...
- audiometry 8y ago
  Disappointed the Wikipedia article didn’t explain how in the world they arrived at that formula, why it even works. This type of stuff is pure magic to me.
  - aboutruby 8y ago
    There is a proof linked from the Wikipedia article: https://www.davidhbailey.com/dhbpapers/digits.pdf https://www.davidhbailey.com/dhbpapers/digits.pdf
  - mhh__ 8y ago
    https://bellard.org/pi/pi_bin.pdf https://bellard.org/pi/pi_bin.pdf
onion2k 8y ago
Something quite interesting about pi is that you don't need to start at the beginning to calculate any particular digit, so you can check if the 31.4trillionth digit is correct yourself. The algorithm you'd need to use is the Bailey–Borwein–Plouffe formula - https://en.wikipedia.org/wiki/Bailey%E2%80%93Borwein%E2%80%93Plouffe_formula https://en.wikipedia.org/wiki/Bailey%E2%80%93Borwein%E2%80%9... (I think there are others too.)

How can you tell if the results are accurate?

curiousgal 8y ago

Why would you need to do that? It's not like those digits are useful for anything at all.

onion2k 8y ago
I guess it depends on your definition of "useful", but one potential way to use pi would be as a way to transmit compressed data incredibly efficiently. If you could find the data you want to transmit in pi somewhere you'd only need to transmit an offset and a length to send anything than can be represented numerically. The hard part would be finding what you want to send though... ;)
- gliptic 8y ago
  Unless it's not clear, the size of that offset would be about the same size as whatever you wanted to encode.
- mkup 8y ago
  Offset and a length in Pi are not going to be shorter than original data to transmit.
  - thaumaturgy 8y ago
    Not necessarily. A double gets you pretty far into pi for a cost of just 8 bytes. A little bit of rounding, or checksumming, or other tomfoolery in principle should make it possible to reach absurdly far into pi for a byte or two more.
    - onion2k 8y ago
      If your offset is a million digits long you need to be sending more than a million digits of data to make it worthwhile, but the chance of your chosen million digits being available in that space is effectively zero. :)
      - perl4ever 8y ago
        Regardless of the actual distribution of values in pi, it seems to me that the best case scenario can't compress all data on average when you include the offset and length, because of the pigeonhole principle. Same as any compression method, except practically worse/useless because pi isn't constructed to have the values that occur in practical situations come first.
    - jerf 8y ago
      Given that I personally have to have seen this proposal at least a dozen times myself, and I'm not even particularly "in the field", if it was as easy as people supposed, we'd be using it. I will point out you're thinking of it incorrectly, though. The challenge with compression isn't to "reach far into pi". The challenge is to reach correctly into pi. A double can identify 2^64 places to reach into pi. It doesn't really matter how you specify those 2^64 locations, that's all it can do, by the simple argument that one double can't specify more than one location. The location of the US Constitution in pi may be "far", but it's not the "far" we have in our fuzzy human brains where things sort of logarithmically just pile together until there's no meaningful difference to us humans between the 1,839,837,237,938,739,837,954th position of pi and the 1,839,827,237,938,739,837,954th position. But a compression algorithm off by that much is useless; indeed, even being off by one digit (in your choice of base) is going to produce garbage. So it's not just about being able to reach "far", it's about being able to reach far and precisely. It doesn't matter how you arrange the possible 2^64 locations a machine word can point to; specify it as 1,739,837,237,938,739,837,954 + the binary as a 64-bit int for all it matters. That reaches "far" into pi. But you won't find anything useful enough to pay off the 64bits you spent getting there. (I mean, you want to reach far into Pi, I give you "Go BusyBeaver(64-bit int) digits into Pi". That's reaching in pretty darned far. But it's still useless as a compression algorithm, even with the mighty power of BusyBeaver there.) (Amusingly, at BB(42) digits into Pi, you get "42" as the next digits, proving that 42 really is the answer. Prove me wrong!)
      - thaumaturgy 8y ago
        I would expect that about zero of the propositions have ever been serious. It's just a well-known, long-running amusement among programmers. An IEEE 754 double type has a range from about 10^−324 to about 10^308. You start losing precision once you exceed 2^51, but beyond that it should be possible to add an extra byte or a few as an offset. So a handful of bytes would get us addresses far in excess of the current storage capacity of the internet (estimated around 10^24 bytes a few years ago) ... if only pi were certain to contain every possible number sequence up to some arbitrary length (which last I heard isn't known yet) and if we had some reasonable way to search and index all of that content (which we don't).
- patrickg_zill 8y ago
  You've kind of re-invented, in a way, using DCT transforms to encode music more efficiently...
DannyB2 8y ago
> Why would you need to do that? It's not like those digits are useful for anything at all. People complain about that. But . . . why do we have athletic competitions? It's not like it is useful for anything at all. Or Reality TV for that matter.

chris_overseas 8y ago

This is explained in the second paragraph: > Yee independently verified the calculation using Bellard's formula[0] and BBP formula[1] [0] https://en.wikipedia.org/wiki/Bellard%27s_formula https://en.wikipedia.org/wiki/Bellard%27s_formula [1] https://en.wikipedia.org/wiki/Bailey%E2%80%93Borwein%E2%80%93Plouffe_formula https://en.wikipedia.org/wiki/Bailey%E2%80%93Borwein%E2%80%9...

audiometry 8y ago
Disappointed the Wikipedia article didn’t explain how in the world they arrived at that formula, why it even works. This type of stuff is pure magic to me.
- aboutruby 8y ago
  There is a proof linked from the Wikipedia article: https://www.davidhbailey.com/dhbpapers/digits.pdf https://www.davidhbailey.com/dhbpapers/digits.pdf
- mhh__ 8y ago
  https://bellard.org/pi/pi_bin.pdf https://bellard.org/pi/pi_bin.pdf

onion2k 8y ago

Something quite interesting about pi is that you don't need to start at the beginning to calculate any particular digit, so you can check if the 31.4trillionth digit is correct yourself. The algorithm you'd need to use is the Bailey–Borwein–Plouffe formula - https://en.wikipedia.org/wiki/Bailey%E2%80%93Borwein%E2%80%93Plouffe_formula https://en.wikipedia.org/wiki/Bailey%E2%80%93Borwein%E2%80%9... (I think there are others too.)