random (fwd)

Alex Martelli aleaxit at yahoo.com
Sat Jun 2 15:07:57 EDT 2001


"Lulu of the Lotus-Eaters" <mertz at gnosis.cx> wrote in message
news:mailman.991502104.19290.python-list at python.org...
> Coming, admittedly, a bit late to the conversation on this topic, I'm
> surprised to find Alex a bit too dedicated to his point... and making a
> few errors about which he knows better:
>
> Someone wrote:
> >A physical RNG can have the property that one cannot make
> >any prediction about the value of the next bit even given
> >_complete_ information about how the numbers are being
> >generated.
>
> "Alex Martelli" <aleaxit at yahoo.com> wrote:
> |This says "GIVEN _complete_ information".  Now you say
> |you CANNOT "have complete information".  The two
> |statements are in contradiction.
>
> No contradiction in this.  "If you COULD have complete information you
> can not make a prediction" does not imply that you CAN have complete
> information.

The assertion NOT(<have-complete-info> IMPLIES <can-predict>)
can never hold, if <have-complete-info> is an impossibility, because
in that case (<have-complete-info> IMPLIES X) is true for any X,
so its negation is false.

So, NOT(X IMPLIES Y) *does* imply X is possible.  (X IMPLIES
NOT Y) doesn't.  But "_even given_ X, not Y" looks like it would
be very peculiarly rendered as 'X implies not Y', and 'X does
not imply Y', aka 'NOT(X implies Y)', seems like a much more
natural translation, doesn't it?


> |I _think_ -- but am not a philosopher or mathematician
> |so cannot feel sure -- that part of what Goedel shows is
> |that arithmetic is powerful enough to model any other
> |formal system.
>
> Well...  I *am* a philosopher, and have occassionally pretended to be a
> mathematician (not the most convincing pretense though).  But I don't
> think one needs to be to see what's wrong with the above.
>
> Assuming "Goedel" means his incompleteness theorem in the above, he
> really doesn't show anything like the above.

Sorry, I wasn't thinking specifically of his theorem but rather
of his way of operating towards it.  Given any (finite) axiomatic
system, even 'richer' than arithmetic, can't we MODEL that
richer system with arithmetic, numbering well-formed
formulas &c, by just the same process as Goedel uses to
model arithmetic in itself?  The fact that we added a few
primitive symbols and axioms to the set we started with
for arithmetic (be that Peano's or whatever) doesn't appear
to me to break down the process.  Indeed, doesn't Goedel
specifically model "any finite axiomatic system powerful
enough to model arithmetic" in arithmetic terms, with his
_procedure_ (that he uses to prove his theorem, but that's
by the by in this context...)?

Again, I'm no philosopher nor a mathematician, so I guess
I can't be as sure of such things as you are, but I fail to
see the key step here:

> Let's say, for example, that the Peano axioms model arithmetic for our
> standard.  Given the Goedel machinery, we can derive a specific statment
> of Peano arithmetic, _I_, that is neither a theorem nor a contradiction
> of Peano arithmetic.

So far so good.

> Therefore, we can create a new system Peano+_I_, that is both consistent
> (if arithmetic is)

I'm still following...

> and not modelled by arithmetic.

Please stop right here!  Why can't we _model_ the new system in
the previous one by applying the 'machinery' afresh?  Renumber
the symbols (same number as before in this case, right?) and get
the Goedel numbers for all the axioms (one more than before)?

> Moreover, we can now
> derive an infinite number of new theorems of Peano+_I_ that utilize _I_
> in their derivation and that are independent of Peano arithmetic.

Oh, I didn't know the 'new' theorems will always be infinitely many --
interesting indeed (is it anything deep or just a trivial by-product of
considering "_I_ AND (old theorem)" &c as a new theorem and there
being infinitely many old theorems in arithmetic?).  But definitely
by the by.  Aren't we modeling the new 'arithmetic-plus' in the
terms of the old arithmetic?


Alex






More information about the Python-list mailing list