XPost: comp.theory, sci.logic

On 5/2/2022 6:10 PM, Ben wrote:

olcott <polcott2@gmail.com> writes:

On 5/2/2022 11:39 AM, Ben wrote:

olcott <polcott2@gmail.com> writes:

It is clear that the input to H(P,P) specifies infinitely nested
simulation to H.

What two pointers must be passed to H for H to tell up about the halting >>> of P(P)? If H can't report on the halting of the computation P(P) it is >>> not a halt decider, and you have already told use that H(P,P) == false
and that P(P) halts.

If H can report on the halting of non-input P(P) then it is not a
decider because deciders only compute the mapping from inputs to final
states.

TM deciders compute mappings from inputs to final states /according to
some property of the inputs/

That par is exactly correct.

-- whether the input represents, for

That part has been the key error of everyone in that they all believe
that is can represent something other than what it actually specifies.
The correct simulation of the input to H(P,P) specifies non-halting
behavior.

Clueless wonders that don't know the first thing about the x86 language
assume that this simulation is incorrect even though is is nearly
trivial to determine that the simulation is correct as a verified fact.

That they contradict verified facts entirely one the basis that they are incompetent to verify that it is a fact is the worst hubris.

example, an even number, a prime number or a halting computation.

According to you there is no "input" (in reality a pair of pointers)
that represents the halting computation P(P). Why should anyone care
about this H if it does not decide what we want -- the halting of the function call represented by the two arguments to H? Whatever H is
actually deciding is not interesting.

(a) H does correctly decide its input
(b) H is only required to decide its input.
(c) Therefore H(P,P) is entirely correct on the "impossible" input.

Also, I wonder why you wasted so much time justifying the fact that
H(P,P) == false "even though P(P) halts" when H(P,P) is, apparently, not
even supposed to be deciding the halting P(P). Well, we know, of
course. You realised you were in a hole so you started to dig sideways.
You used to know that H(X,Y) had to decide the halting of X(Y). You're
now pretending it never did!

That you expect a halt decider to compute the mapping from non-inputs
is a little nuts when you know that deciders can't possibly do this.

Don't be silly. They decide properties of inputs -- parity, halting and
so on. You'd know this if you'd done even the warm-up exercises I set.

The problem here is that you expect that the property of an input not be
the actual property of the actual input but the property of a non-input.

The halting property of the input to H(P,P) is the actual behavior of
the correct simulation of this input and thus not at all what you simply imagine this property should be.

How are they coming along? It looks like you have found an excuse to
bail out again:

It is coming along great and it is wonderful fun.
I think that it is a great idea to move in this direction.
I may eventually convert C copy of the TM into a RASP machine.
I probably won't begin to do that until after we finish our exercises.

It turns out that I can create a whole TM interpreter from scratch
quicker than I can learn the extraneous complexity of the TM
Interpreter http://www.lns.mit.edu/~dsw/turing/turing.html

I doubt it. But I suppose you think that's a reasonable excuse. Of
course, some of us remember you saying writing such a thing would take
about a week three years ago. I remember wondering how such a simple
program could take you a week to write.

As soon as I complete the detailed design I should have an accurate
estimate of the total time. It currently looks like < 4 hours. I have
spent 15 minutes on the detailed design and it looks like it will take
45 more minutes.

One thing that is great is that I have fully recovered from what could
have been a life threatening infection. I was in the hospital getting IV antibiotics for nearly two days. Chemotherapy patients have a few days
after chemotherapy where their immune system is very close to zero.

Of course you don't need an interpreter to write E or specify P, but you
must find some excuse for bailing out.

It is much better (and more fun) if I make this totally concrete.
One can not effectively debug code by desk checking.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic, sci.math

On 5/4/2022 9:16 AM, Ben wrote:

olcott <polcott2@gmail.com> writes:

On 5/2/2022 6:10 PM, Ben wrote:

olcott <polcott2@gmail.com> writes:

On 5/2/2022 11:39 AM, Ben wrote:

olcott <polcott2@gmail.com> writes:

It is clear that the input to H(P,P) specifies infinitely nested
simulation to H.

What two pointers must be passed to H for H to tell up about the halting >>>>> of P(P)? If H can't report on the halting of the computation P(P) it is >>>>> not a halt decider, and you have already told use that H(P,P) == false >>>>> and that P(P) halts.

If H can report on the halting of non-input P(P) then it is not a
decider because deciders only compute the mapping from inputs to final >>>> states.

TM deciders compute mappings from inputs to final states /according to
some property of the inputs/

That par is exactly correct.

-- whether the input represents, for

That part has been the key error of everyone in that they all believe
that is can represent something other than what it actually specifies.

So now, after thinking otherwise for years, you claim that there is no
way to even specify the computation P(P) for you pseudo-C halt decider
H. At least that is a clear admission that the halting of function
calls like P(P) can not be decided because, apparently, passing P and P
to H does not specify that computation, and you can't say what two
arguments /would/ specify it.

A clear and unambiguous statement that no D such that D(X,Y) == true if
and only if X(Y) halts and false otherwise is possible would be the
honest way to move things on. If you were clear about this, maybe
someone will talk to you about whether it is that your H is deciding.

I adapted my system so that I could empirically test this:
H1(P,P)==true is empirically proven to be correct
H(P,P)==false is empirically proven to be correct

Both deciders correctly report on the actual behavior of their actual
input. This can be verified by carefully studying their execution trace.

example, an even number, a prime number or a halting computation.
According to you there is no "input" (in reality a pair of pointers)
that represents the halting computation P(P). Why should anyone care
about this H if it does not decide what we want -- the halting of the
function call represented by the two arguments to H? Whatever H is
actually deciding is not interesting.

(a) H does correctly decide its input

But no one cares about that as it's not what we want a decider for.

(b) H is only required to decide its input.

And it seems that you agree that no D such that D(X,Y) == true if and
only if X(Y) halts and false otherwise is possible. That's the D that
the world cares about.

(c) Therefore H(P,P) is entirely correct on the "impossible" input.

It decides some property of the pair of pointers P and P, but not the
one people care about: the halting or otherwise of the function call
P(P).

Also, I wonder why you wasted so much time justifying the fact that
H(P,P) == false "even though P(P) halts" when H(P,P) is, apparently, not >>> even supposed to be deciding the halting P(P). Well, we know, of
course. You realised you were in a hole so you started to dig sideways. >>> You used to know that H(X,Y) had to decide the halting of X(Y). You're
now pretending it never did!

Why /did/ you waste so much time trying to convince us that H(P,P) ==
false was correct even though P(P) halted if you never intended H(P,P)
to report on the halting of P(P)?

You'd know this if you'd done even the warm-up exercises I set.

<snip the usual waffle>

How are they coming along? It looks like you have found an excuse to
bail out again:

It is coming along great and it is wonderful fun.

It's good that it's fun, but it seems to be taking a long time. I'd
expect students to be able to write E and specify P "live" in a tutorial
-- i.e. it would take a couple of minutes and we could the discuss more interesting examples.

I have had some serious health issues that could have killed me last week.

The specification of TM's is your stumbling block, so you could be doing
that in parallel.

I like to go through all of the best steps in order. Having a machine to execute TM's is the first step.

(a) Deciding to get around to start this project took weeks when dealing
with my other issues.

(b) No setting up the tedious syntax of reading a file of text lines
took much longer than usual, I usually cut-and-paste.

(c) I studied enough of the
http://www.lns.mit.edu/~dsw/turing/turing.html
To realize it was a superb architecture yet an overly complex
implementation.

Other people can read much faster than me, yet they lose a lot of
meaning when they read this fast. I usually read something over and over
until I have 100% complete understanding.

When I was reading the specs for how VISA changed their system so that I
could adapt the bank's system to meet these changed specs I had to read
the VISA material 17 times. I only had to read the Discover card changes
three times.

I think that it is a great idea to move in this direction.
I may eventually convert C copy of the TM into a RASP machine.

Do ever read what you write? What is a "C copy of the TM"? I think you
mean the TM interpreter that you've decided to write so as to delay
actually writing even a trivial TM.

I am going to write a TM interpreter in C++. Sometime after I get done
with this I may adapt it to becoming an RASP machine. I will keep the
original TM interpreter and not simply overwrite it with the RASP
machine. This requires that the changes must be to a copy of the TM interpreter.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)