Re: Representations of Pi, etc.

[Greg Rose <Greg_Rose@sydney.sterling.com>]

  At 3:19 AM 1/5/96, jim bell wrote:

  >But BTW, isn't it interesting, that news item from a few weeks ago, on an
  >algorithm for determining individual bits in Pi, regardless of whether
  >you've calculated all the previous ones.  Only problem is, it only works in
  >hexadecimal (and, obviously, binary, etc, not decimal.
                                             ^^^^^^^^^^^

  ???

  I didn't see this result you mention, but it surprises me. The part about
  how it works in some bases, but not in decimal.

I assume it really works only in binary, and
hexadecimal follows, not the other way around.

  The "hand-waving" (motivational/informal) explanation for why I am
  surprised is that "Nature doesn't care about bipeds with 10 digits vs.
  bipeds, or whatever, with 2 digits or 16 digits." That is, results
  applicable in base 16, hexadecimal, should be easily applicable in base 10.

Sorry, but it is quite possible for this to be the
case. (I don't know for sure whether this is one
of them or not, though, having not seen the result
myself.) But assume for the moment that the
formula, or algorithm, or whatever it is, really
does tell you exactly the value of a contiguous
chunk of "bits", real honest-to-god binary digits.
You cannot translate these to a decimal
representation without knowing all of the bits
leading up to them. For example, you know the last
four bits of an eight bit string:
  XXXX0011

In Hex the last digit is 3. But what is the last
digit in decimal? If the 'X's are all 0, it is 3, but
if the last X is a 1 (making the number 00010011 = 19),
it is not 3 but 9. If only the first X is a one,
it is 1.

There are plenty of places in information theory
where a log base 2 shows up, so I don't doubt
that there might be an algorithm for determining
a particular "bit" of Pi. But just to prove I
have a more concrete example, suppose you have an
encrypted bank transfer, with the numbers
expressed in binary. Further suppose you know it
is encrypted with a one-time-pad (just to be
contraversial) where you know a particular n-bit
chunk of the pad. Given this you can recover the
corresponding n-bit chunk of the amount, but
unless this spans the entire number you can't
express this unambiguously in decimal digits.
This is a simple consequence of the fact that
log(2) and log(10) are not integer multiples of
each other (you know what I mean). The same goes
the other way, of course. Given a string of
decimal digits extracted from the middle of a
number, I can't unambiguously decide what string
of bits these would become without knowing the
rest of the number.

The result is fascinating, assuming it is real.

Greg.

Greg Rose               INTERNET: greg_rose@sydney.sterling.com  
Sterling Software       VOICE:  +61-2-9975 4777    FAX:  +61-2-9975 2921
28 Rodborough Rd.       http://www.sydney.sterling.com:8080/~ggr/
French's Forest         35 0A 79 7D 5E 21 8D 47  E3 53 75 66 AC FB D9 45
NSW 2086 Australia.     co-mod sci.crypt.research, USENIX Director.