Re: D correctly simulated by H cannot possibly reach its own line 06 and halt --- Mike Terry

On 6/2/2024 2:49 AM, Mikko wrote:

On 2024-06-01 15:15:05 +0000, olcott said:
 

On 6/1/2024 3:49 AM, Fred. Zwarts wrote:

Op 31.mei.2024 om 21:54 schreef olcott:

On 5/31/2024 2:35 PM, Fred. Zwarts wrote:

Op 31.mei.2024 om 21:07 schreef olcott:

On 5/31/2024 1:55 PM, Fred. Zwarts wrote:

Op 31.mei.2024 om 20:22 schreef olcott:

On 5/31/2024 11:18 AM, Fred. Zwarts wrote:

Op 31.mei.2024 om 17:54 schreef olcott:

On 5/31/2024 10:37 AM, Fred. Zwarts wrote:

Op 31.mei.2024 om 16:25 schreef olcott:

On 5/31/2024 2:50 AM, Fred. Zwarts wrote:

Op 31.mei.2024 om 00:01 schreef olcott:

On 5/30/2024 4:54 PM, joes wrote:

Am Thu, 30 May 2024 09:55:24 -0500 schrieb olcott:
>

typedef int (*ptr)();  // ptr is pointer to int function in C
00       int H(ptr p, ptr i);
01       int D(ptr p)
02       {
03         int Halt_Status = H(p, p);
04         if (Halt_Status)
05           HERE: goto HERE;
06         return Halt_Status;
07       }
08
09       int main()
10       {
11         H(D,D);
12         return 0;
13       }
>
The left hand-side are line numbers of correct C code.
This code does compile and does conform to c17.
>
Everyone with sufficient knowledge of C can easily determine that D
correctly emulated by any *pure function* H (using an x86 emulator)
cannot possibly reach its own simulated final state at line 06 and halt.

Yeah, of course not, if H doesn’t halt.
>

>
To actually understand my words (as in an actual honest dialogue)
you must pay careful attention to every single word. Maybe you
had no idea that *pure functions* must always halt.
>
Or maybe you did not know that every computation that never reaches
its own final state *DOES NOT HALT* even if it stops running because
it is no longer simulated.

>
Since the claim is that H is also a computation, it holds for H, as well. That means that H *DOES NOT HALT* even if it stops running because it is no longer simulated.
>

>
*pure function H definitely halts you are confused*
>

>
You can assume a unicorn, but that does not make it existent. You can assume a simulating H that is a pure function and halts, but that does not make them existent. The set of such H is empty.

>
You simply ignored my proof that you are wrong.
>
D correctly simulated by pure function HH cannot possibly reach
its own final state at line 06 in any finite number of steps of
correct simulation.

>
I do not ignore your claim. It is in fact exactly your claim that D does not reach line 04 that proves that the simulation of HH does not reach its own final state.
>
HH correctly simulated by HH cannot possibly reach its own final state and return to D in any finite number of steps of correct simulation.
>

*HH correctly simulated by HH*
*HH correctly simulated by HH*
*HH correctly simulated by HH*
*HH correctly simulated by HH*
*HH correctly simulated by HH*
>
That is the dishonest dodge of the strawman deception
CHANGE-THE-SUBJECT fake rebuttal
>
*THAT DOES CHANGE THE SUBJECT AWAY FROM THIS*
*DD correctly simulated by HH*
*DD correctly simulated by HH*
*DD correctly simulated by HH*
*DD correctly simulated by HH*
*DD correctly simulated by HH*
>
cannot possibly reach its own final state and return to D in any finite number of steps of correct simulation.
>
>

>
It is not dishonest and not a change of subject.
The correct simulation of D includes the correct simulation of HH, because HH is part of D.

>
OK then my mistake.
HH(DD,DD) does simulate DD and does simulate itself simulating DD
and then HH halts.
>

The only reason why the simulation of D does not continue with line 04 is that the correct simulation of HH by HH does not halt. Why do you refuse to accept this simple fact?

>
I have proven this is false by the actual fully operational HH.
>

>
OK, that was what I asked. Correct me if I am wrong.
>
What I understood up to now was that the simulated HH was aborted after 1-∞ steps, so that the simulated HH did not halt. But now I understand that your fully operational code does simulate HH up to its final state.
>

>
HH(DD,DD)
(a) Simulates DD and then
(b) Simulates itself simulating DD and then
(c) Detects that DD repeated a state and then
(d) Aborts its simulation of DD and reports that DD does not halt.

>
So, it does not prove that the simulation of HH halts.

>
This earliest version of my paper proves that HH halts on input DD.
The very early version uses different names for HH and DD and shows
the repeating state basis for HH to abort its simulation of DD.
>
On 5/27/2021 12:07 AM, olcott wrote: Earliest version of earliest paper
Halting problem undecidability and infinitely nested simulation
https://www.liarparadox.org/Halting_problem_undecidability_and_infinitely_nested_simulation.pdf
>
*When we can see WHY HH halts then we know that HH DOES HALT*

 That does not make sense. When we can see why HH halts we can also see
that HH halts. If HH does not halt we only saw mirages.
 

This is nearly my earliest paper on simulating halt deciders and
shows the actual execution trace, proves that this trace is correct
and shows why and how its simulating halt decider halts.
Pages 4-5 of
*The 2021-09-26 version of my first paper on simulating halt deciders*
*Halting problem undecidability and infinitely nested simulation*
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation H(P,P) correctly determines that its input correctly simulated by H
cannot possibly halt on the basis of the repeating state of P correctly
simulated by H.
Whenever H initializes another simulation it allocates the equivalent
of a portion of its own Turing machine tape to the subordinate instances
of itself. This enables H to watch the execution traces of P at every
recursive simulation level.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer