Re: Refutation of the Peter Linz Halting Problem proof 2024-03-05 --partial agreement--

On 3/7/24 7:53 AM, olcott wrote:

On 3/7/2024 5:55 AM, Ben Bacarisse wrote:

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>

On 06/03/2024 23:59, immibis wrote:

On 7/03/24 00:55, olcott wrote:

Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn
Correctly reports that Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩ must abort its simulation.
>
H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
Correctly reports that H ⟨Ĥ⟩ ⟨Ĥ⟩ need not abort its simulation.

What are the exact steps which the exact same program with the exact same
input uses to get two different results?
I saw x86utm. In x86utm there is a mistake because Ĥ.H is not defined to
do exactly the same steps as H, which means you failed to do the Linz
procedure.

>
Not sure if we're discussing a general H here, or PO's H/Ĥ under his
x86utm.  (Ĥ is called D under x86utm.)
>
Under x86utm, Ĥ.H is implemented as a call to H from D, whilst H in
implemented as a call to H from main.  So we would expect stack addresses
to differ, but for that not to affect the computation.
>
In both cases, H:
-  simulates D(D) computation
-  spots PO's unsound "infinite recursion" pattern
-  announces it has encountered infinite recursion
-  returns 0  [non-halting]
>
So Ĥ.H does exactly the same steps as H, and reports the same result, as
required for Linz proof. And just as Linz proof proves, the result reported
by H is incorrect, since D(D) halts.  I have compared the instructions
executed by both H/Ĥ and THEY ARE EXACTLY THE SAME.  (In the region of 1000
or so machine instructions, including the handful of simulated
instructions.  Obviously stack addresses differ.  If required I could post
the output log but its quite long.]
>
So... in this case the exact same program is given the exact same input and
gets the exact same result as Linz logic requires, and the outcome is
exactly what Linz says.  There is really no mystery here that needs
explaining by faulty coding/cheating with simulations on PO's part.

>
Yes, this was the crystal clear case that led PO to answer:
>
| do you still assert that H(P,P) == false is the "correct" answer even
| though P(P) halts?
>
PO: Yes that is the correct answer even though P(P) halts.
>
I think your analysis of the traces was a key part of getting that clear
statement from him.
>

 H(D,D) could never provide a return value consistent with the direct
execution of D(D) because it must abort its simulation or it cannot
report at all. From the POV of H(D,D) D(D) does not halt.

There is no "POV" of H that says does not halt. All H sees is that it didn't halt yet, and I see I am walking into a possible trap.

  From the POV of external observers D(D) does halt. H1(D,D)
is one such external observer.
 Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqy ∞ // Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.Hq0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.Hqn   // Ĥ applied to ⟨Ĥ⟩ does not halt
 Since no Turing machine can actually call another the results
that we get from the Linz proof are more applicable.

So, you are now agreeing with Linz?

 

The HH/DD case is different, as that coding is completely broken by misuse
of global variables to divert the course of the code under the simulator.

 Olcott Machines are totally derived From Turing Machines
thus all of their aspects have been fully understood.
 An Olcott machine is merely an ordinary UTM paired
with an arbitrary Turing Machine Description (TMD).
 This UTM always appends the TMD to the end of the
TMD's own tape. The TMD is free to access its TMD
or ignore it.
 This provides each TMD with the functional equivalent
of knowing their own machine address.

Except for all the problems presented that you are just ignoring, showing you are just totally ignorant of the field you are talking about.

 

But since EVEN WHEN THINGS WORK EXACTLY AS PO WANTS his results are in
AGREEMENT with Linz, it seems to me that arguing that his problem is
relating to cheating with the simulation is kind of missing the point.  Um,
not to say there's much point arguing with PO even if making perfectly
"on-point" arguments!  It all makes no difference to PO... :)

>
The irony here is that if one cheats it's possible to have H(D,D) (in
main, say) return 1 and yet have D(D) halt.  This can be done with D
constructed as usual.  It's only H that needs the cheat.  So to his
credit, he is not cheating, just totally at sea.
>

 When you understand the details you will understand
that I am correct.
 

No, we see that you are just an ignorant talking head babbling incoherently about things that they don't understand.
The fact that you can't see this just show how good you were at gas-lighting yourself into beleiving your lies so you have no interest in learning the truth.
This shows that all of you work just needs to be ignored, as it is just infiltrated with your lies.
This becomes very obvious when you keep on describing results and then say, it must be possible to create a machine to do this, without even questioning if it is possible.