Re: Proof that DD correctly simulated by HH provides the correct halt status criteria

On 6/7/24 5:48 PM, olcott wrote:

*That no counter-example to the following exists proves that it is true*
*That no counter-example to the following exists proves that it is true*
*That no counter-example to the following exists proves that it is true*

Nope, just shows you don't understand the meaning of proves.
No counter example has been given, perhaps because no one has bothered to look as it isn't important.
To PROVE something has a definite procedure which you seem unable to understand.

 Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.

And why do we care about this. A partial simulaition doesn't tell us what will happen after the simulation has been aborted.

 _DD()
[00001e12] 55         push ebp
[00001e13] 8bec       mov  ebp,esp
[00001e15] 51         push ecx
[00001e16] 8b4508     mov  eax,[ebp+08]
[00001e19] 50         push eax      ; push DD
[00001e1a] 8b4d08     mov  ecx,[ebp+08]
[00001e1d] 51         push ecx      ; push DD
[00001e1e] e85ff5ffff call 00001382 ; call HH
 A {correct simulation} means that each instruction of the
above x86 machine language of DD is correctly simulated
by HH and simulated in the correct order.
 Anyone claiming that HH should report on the behavior
of the directly executed DD(DD) is requiring a violation
of the above definition of correct simulation.

So, by making that statement, you are just acknoledging that you understand that you definition of "Correct Simulation" doesn't actually give you the needed data about the direct executiono of the machine described by the input, as would be required for a Halt Decider.

 Halt deciders are required to compute the mapping from their
input to their own accept or reject state based on the behavior
that this input specifies.

Right, as DEFINED by the behavior of the machine that input describes.
Which can also be the behavior of an ACTUAL UTM that doesn't stop until it reaches a final state.

 Simulating halt deciders are not allowed to simulate non-halting
inputs for more than a finite number of steps because all deciders
must halt.

Right, but this need to abort does not give them a license to report that the simulation of the input would not reach a final state "by them", as the not reaching a final state is of a simulation that is not ever stopped until it reaches a final state, even if they themselves can't do that simulation. They need to be able to show that a UTM simulating this input will not reach a final state.

 The basic strategy of a simulating halt decider is to simulate
an input until (a) The input halts or (b) it correctly determines
that the correctly simulated input cannot possibly stop running
unless its simulation has been aborted.

Right, and "Correctly Determining" is the hard part. The key point is that if it does abort its simulation, the simulation that must no stop running is NOT the aborted simulation of the decider, but the ACTUAL CORRECT simulation of that same input by an ACTUAL UTM.

 <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
   If simulating halt decider H correctly simulates its input D
   until H correctly determines that its simulated D would never
   stop running unless aborted then

Right, and that means that H needs to do the actual definition of a UTM simulation, i.e not abort, or be able to show that the UTM simulation of this exact input would not reach a final state.
Your H doesn't do this.

    H can abort its simulation of D and correctly report that D
   specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
 

Which, since your H never meet the first part, you can't do the second part.

*Professor Sipser is the best selling author of this textbook*
Introduction to the Theory of Computation, by Michael Sipser
https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X/
 Here is the earliest version of the proof (that everyone
has simply ignored for three solid years)
 Subject: [Would the simulation of D be infinitely nested unless simulating partial halt decider H terminated its simulation of D?]
On 5/29/2021 2:26 PM, olcott wrote:
Message-ID: <YJKdnZg9v__rCC_9nZ2dnUU7-QXNnZ2d@giganews.com>
http://al.howardknight.net/?STYPE=msgid&MSGI=%3CYJKdnZg9v__rCC_9nZ2dnUU7-QXNnZ2d%40giganews.com%3E
 The fact that the execution trace of D derived by the executed
H and the simulated H exactly matches the machine code of D
proves that each instruction of D was simulated correctly and
in the correct order this conclusively proves that D is correctly
simulated by both of these instances of H.

But not finished, and thus doesn't tell us what happens after that.
To correctly decide non-halting, you need to show that if the simulation was continued for an unbounded number of steps, it would never reach the final state.
And you don't get to "reset" the input as you imagine this, it is always the input that is given to the decider that is actually answering.
Your "Template" version isn't a valid input, only an instance made from a given pairing of the template to a decider.

 I explained these details hundreds of times in the last three
years and no one paid any attention to the fact that I proved
that I am correct. Because of this I provided the above dumbed
down version.
 

But you keep of forgetting that the requirement isn't about "the deciders" simulation (even if correct but partial) but the behavior of the actual machine or the full simulation by a UTM.
So, you are not correct, but mistaken because you lied to yourself about the requirements.