Premises:

1. The halting problem is Olcott-self-contradictory.
2. Olcott-self-contradictory problems can't be solved.

Conclusion:

3. The halting problem can't be solved.

On 1/8/2024 11:07 PM, immibis wrote:
> Premises:
>
> 1. The halting problem is Olcott-self-contradictory.
> 2. Olcott-self-contradictory problems can't be solved.
>
> Conclusion:
>
> 3. The halting problem can't be solved.

When D is intentionally defined to do the opposite of
whatever Boolean value that H returns then input D <is>
absolutely self-contradictory to termination analyzer H
when H is required to report on the behavior of the
directly executed D.

*MIT Professor Michael Sipser has agreed that the following verbatim*
*paragraph is correct*
(a) 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
(b) H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.

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

On 1/9/24 15:01, olcott wrote:
> On 1/8/2024 11:07 PM, immibis wrote:
>> Premises:
>>
>> 1. The halting problem is Olcott-self-contradictory.
>> 2. Olcott-self-contradictory problems can't be solved.
>>
>> Conclusion:
>>
>> 3. The halting problem can't be solved.
>
> When D is intentionally defined to do the opposite of
> whatever Boolean value that H returns then input D <is>
> absolutely self-contradictory to termination analyzer H
> when H is required to report on the behavior of the
> directly executed D.
>
> *MIT Professor Michael Sipser has agreed that the following verbatim*
> *paragraph is correct*
> (a) 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

Your simulator does an incorrect simulation because of the undeclared
input of execution history into the inner simulation.

> (b) H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
>
>

On 1/9/2024 5:54 PM, immibis wrote:
> On 1/9/24 15:01, olcott wrote:
>> On 1/8/2024 11:07 PM, immibis wrote:
>>> Premises:
>>>
>>> 1. The halting problem is Olcott-self-contradictory.
>>> 2. Olcott-self-contradictory problems can't be solved.
>>>
>>> Conclusion:
>>>
>>> 3. The halting problem can't be solved.
>>
>> When D is intentionally defined to do the opposite of
>> whatever Boolean value that H returns then input D <is>
>> absolutely self-contradictory to termination analyzer H
>> when H is required to report on the behavior of the
>> directly executed D.
>>
>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>> *paragraph is correct*
>> (a) 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
>
> Your simulator does an incorrect simulation because of the undeclared
> input of execution history into the inner simulation.

If it was incorrect then you could show the exact sequence that
should be simulated. You already said that the simulated D
should call the simulated H.

You know that when it does this that D correctly simulated by H cannot
possible reach its own line 09 and terminate normally (AKA halt).

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

On 1/9/24 9:01 AM, olcott wrote:
> On 1/8/2024 11:07 PM, immibis wrote:
>> Premises:
>>
>> 1. The halting problem is Olcott-self-contradictory.
>> 2. Olcott-self-contradictory problems can't be solved.
>>
>> Conclusion:
>>
>> 3. The halting problem can't be solved.
>
> When D is intentionally defined to do the opposite of
> whatever Boolean value that H returns then input D <is>
> absolutely self-contradictory to termination analyzer H
> when H is required to report on the behavior of the
> directly executed D.

You have a problem with word definitions.

How can D be *SELF*-contradictory to H, since they are not the same thing.

You can only be SELF-contradictory to YOURSELF.

Thus, your arguement begins with an error.

>
> *MIT Professor Michael Sipser has agreed that the following verbatim*
> *paragraph is correct*
> (a) 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
> (b) H can abort its simulation of D and correctly report that D
> specifies a non-halting sequence of configurations.
>
>

ANd since H doesn't "Correctly Simulate" or "Correctly Determine" that a
CORRECT simulation wouldn't halt, you can't use that criteria.

Remember, to Sipser, the only "Correct Simulation" is a COMPLETE simulation.

On 1/9/24 7:44 PM, olcott wrote:
> On 1/9/2024 5:54 PM, immibis wrote:
>> On 1/9/24 15:01, olcott wrote:
>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>> Premises:
>>>>
>>>> 1. The halting problem is Olcott-self-contradictory.
>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>
>>>> Conclusion:
>>>>
>>>> 3. The halting problem can't be solved.
>>>
>>> When D is intentionally defined to do the opposite of
>>> whatever Boolean value that H returns then input D <is>
>>> absolutely self-contradictory to termination analyzer H
>>> when H is required to report on the behavior of the
>>> directly executed D.
>>>
>>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>>> *paragraph is correct*
>>> (a) 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
>>
>> Your simulator does an incorrect simulation because of the undeclared
>> input of execution history into the inner simulation.
>
> If it was incorrect then you could show the exact sequence that
> should be simulated. You already said that the simulated D
> should call the simulated H.
>
> You know that when it does this that D correctly simulated by H cannot
> possible reach its own line 09 and terminate normally (AKA halt).
>

See below, that you yourself posted nearly two years ago.

On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9nZ2dnUU7-V2dnZ2d@giganews.com>
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> H_Hat((u32)H_Hat);
> }
>
>
> _H_Hat()
> [00000b98](01) 55 push ebp
> [00000b99](02) 8bec mov ebp,esp
>
[00000b9b](01) 51 push ecx
> [00000b9c](03) 8b4508 mov eax,[ebp+08]
> [00000b9f](01) 50 push eax
> [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
> [00000ba3](01) 51 push ecx
> [00000ba4](05) e88ffdffff call 00000938
> [00000ba9](03) 83c408 add esp,+08
> [00000bac](03) 8945fc mov [ebp-04],eax
> [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
> [00000bb3](02) 7402 jz 00000bb7
> [00000bb5](02) ebfe jmp 00000bb5
> [00000bb7](02) 8be5 mov esp,ebp
> [00000bb9](01) 5d pop ebp
> [00000bba](01) c3 ret
> Size in bytes:(0035) [00000bba]
>
> _main()
> [00000bc8](01) 55 push ebp
> [00000bc9](02) 8bec mov ebp,esp
> [00000bcb](05) 68980b0000 push 00000b98
> [00000bd0](05) e8c3ffffff call 00000b98
> [00000bd5](03) 83c404 add esp,+04
> [00000bd8](02) 33c0 xor eax,eax
> [00000bda](01) 5d pop ebp
> [00000bdb](01) c3 ret
> Size in bytes:(0020) [00000bdb]
>
> ===============================
> ...[00000bc8][001015d4][00000000](01) 55 push ebp
> ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
> ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98
> ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98
> ...[00000b98][001015c8][001015d4](01) 55 push ebp
> ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
> ...[00000b9b][001015c4][00000000](01) 51 push ecx
> ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][001015c0][00000b98](01) 50 push eax
> ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][001015bc][00000b98](01) 51 push ecx
> ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
> Begin Local Halt Decider Simulation at Machine Address:b98
> ...[00000b98][00211674][00211678](01) 55 push ebp
> ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
> ...[00000b9b][00211670][00201644](01) 51 push ecx
> ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0021166c][00000b98](01) 50 push eax
> ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][00211668][00000b98](01) 51 push ecx
> ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938
> ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
> ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
> ...[00000b9b][0025c098][0024c06c](01) 51 push ecx
> ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0025c094][00000b98](01) 50 push eax
> ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][0025c090][00000b98](01) 51 push ecx
> ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Above decision was from the call the Halts inside H_Hat, deciding that
H_Hat(H_Hat) seems to be non-halting, it then returns that answer and is
processed below:

> ...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08
> ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax
> ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00
> ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7
> ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp
> ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp
> ...[00000bba][001015d0][00000b98](01) c3 ret
> ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04
> ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax
> ...[00000bda][001015d8][00100000](01) 5d pop ebp
> ...[00000bdb][001015dc][00000098](01) c3 ret

SEE IT HALTED!

> Number_of_User_Instructions(39)
> Number of Instructions Executed(26567)

On 1/10/24 01:44, olcott wrote:
> On 1/9/2024 5:54 PM, immibis wrote:
>> On 1/9/24 15:01, olcott wrote:
>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>> Premises:
>>>>
>>>> 1. The halting problem is Olcott-self-contradictory.
>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>
>>>> Conclusion:
>>>>
>>>> 3. The halting problem can't be solved.
>>>
>>> When D is intentionally defined to do the opposite of
>>> whatever Boolean value that H returns then input D <is>
>>> absolutely self-contradictory to termination analyzer H
>>> when H is required to report on the behavior of the
>>> directly executed D.
>>>
>>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>>> *paragraph is correct*
>>> (a) 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
>>
>> Your simulator does an incorrect simulation because of the undeclared
>> input of execution history into the inner simulation.
>
> If it was incorrect then you could show the exact sequence that
> should be simulated.

I could, but why should I do more work when less work is already good
enough? It wouldn't prove anything that wasn't already proved. I'd have
to download your simulator, check it for viruses, figure out how it
works, then change it.

> You already said that the simulated D should call the simulated H.
>
> You know that when it does this that D correctly simulated by H cannot
possible reach its own line 09 and terminate normally (AKA halt).
>

That's right.

On 1/10/24 03:14, Richard Damon wrote:
> On 1/9/24 7:44 PM, olcott wrote:
>> On 1/9/2024 5:54 PM, immibis wrote:
>>> On 1/9/24 15:01, olcott wrote:
>>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>>> Premises:
>>>>>
>>>>> 1. The halting problem is Olcott-self-contradictory.
>>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>>
>>>>> Conclusion:
>>>>>
>>>>> 3. The halting problem can't be solved.
>>>>
>>>> When D is intentionally defined to do the opposite of
>>>> whatever Boolean value that H returns then input D <is>
>>>> absolutely self-contradictory to termination analyzer H
>>>> when H is required to report on the behavior of the
>>>> directly executed D.
>>>>
>>>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>>>> *paragraph is correct*
>>>> (a) 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
>>>
>>> Your simulator does an incorrect simulation because of the undeclared
>>> input of execution history into the inner simulation.
>>
>> If it was incorrect then you could show the exact sequence that
>> should be simulated. You already said that the simulated D
>> should call the simulated H.
>>
>> You know that when it does this that D correctly simulated by H cannot
>> possible reach its own line 09 and terminate normally (AKA halt).
>>
>
> See below, that you yourself posted nearly two years ago.
>
> On 4/27/21 12:55 AM, olcott wrote:
> Message-ID: <Teudndbu59GVBBr9nZ2dnUU7-V2dnZ2d@giganews.com>
>> [snipped: Olcott's execution traces]
>
> SEE IT HALTED!
>

Very good point. If the correct simulation cannot possibly halt, but
Olcott's simulation halts, that proves Olcott's simulation is not correct.

On 1/9/2024 8:17 PM, immibis wrote:
> On 1/10/24 01:44, olcott wrote:
>> On 1/9/2024 5:54 PM, immibis wrote:
>>> On 1/9/24 15:01, olcott wrote:
>>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>>> Premises:
>>>>>
>>>>> 1. The halting problem is Olcott-self-contradictory.
>>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>>
>>>>> Conclusion:
>>>>>
>>>>> 3. The halting problem can't be solved.
>>>>
>>>> When D is intentionally defined to do the opposite of
>>>> whatever Boolean value that H returns then input D <is>
>>>> absolutely self-contradictory to termination analyzer H
>>>> when H is required to report on the behavior of the
>>>> directly executed D.
>>>>
>>>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>>>> *paragraph is correct*
>>>> (a) 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
>>>
>>> Your simulator does an incorrect simulation because of the undeclared
>>> input of execution history into the inner simulation.
>>
>> If it was incorrect then you could show the exact sequence that
>> should be simulated.
>
> I could, but why should I do more work when less work is already good
> enough? It wouldn't prove anything that wasn't already proved. I'd have
> to download your simulator, check it for viruses, figure out how it
> works, then change it.
>
>> You already said that the simulated D should call the simulated H.
>>
>> You know that when it does this that D correctly simulated by H cannot
> possible reach its own line 09 and terminate normally (AKA halt).
>>
>
> That's right.
>

*That is better than anyone else has ever understood*

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

On 1/10/24 03:58, olcott wrote:
> On 1/9/2024 8:17 PM, immibis wrote:
>> On 1/10/24 01:44, olcott wrote:
>>> On 1/9/2024 5:54 PM, immibis wrote:
>>>> On 1/9/24 15:01, olcott wrote:
>>>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>>>> Premises:
>>>>>>
>>>>>> 1. The halting problem is Olcott-self-contradictory.
>>>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>>>
>>>>>> Conclusion:
>>>>>>
>>>>>> 3. The halting problem can't be solved.
>>>>>
>>>>> When D is intentionally defined to do the opposite of
>>>>> whatever Boolean value that H returns then input D <is>
>>>>> absolutely self-contradictory to termination analyzer H
>>>>> when H is required to report on the behavior of the
>>>>> directly executed D.
>>>>>
>>>>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>>>>> *paragraph is correct*
>>>>> (a) 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
>>>>
>>>> Your simulator does an incorrect simulation because of the
>>>> undeclared input of execution history into the inner simulation.
>>>
>>> If it was incorrect then you could show the exact sequence that
>>> should be simulated.
>>
>> I could, but why should I do more work when less work is already good
>> enough? It wouldn't prove anything that wasn't already proved. I'd
>> have to download your simulator, check it for viruses, figure out how
>> it works, then change it.
>>
>>> You already said that the simulated D should call the simulated H.
>>>
>>> You know that when it does this that D correctly simulated by H cannot
>> possible reach its own line 09 and terminate normally (AKA halt).
>>>
>>
>> That's right.
>>
>
> *That is better than anyone else has ever understood*
>
We all understand it, except you.

You refuse to acknowledge this point:

**The correct simulation of a program returns the same result as its
direct execution.**

On 1/9/2024 9:02 PM, immibis wrote:
> On 1/10/24 03:58, olcott wrote:
>> On 1/9/2024 8:17 PM, immibis wrote:
>>> On 1/10/24 01:44, olcott wrote:
>>>> On 1/9/2024 5:54 PM, immibis wrote:
>>>>> On 1/9/24 15:01, olcott wrote:
>>>>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>>>>> Premises:
>>>>>>>
>>>>>>> 1. The halting problem is Olcott-self-contradictory.
>>>>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>>>>
>>>>>>> Conclusion:
>>>>>>>
>>>>>>> 3. The halting problem can't be solved.
>>>>>>
>>>>>> When D is intentionally defined to do the opposite of
>>>>>> whatever Boolean value that H returns then input D <is>
>>>>>> absolutely self-contradictory to termination analyzer H
>>>>>> when H is required to report on the behavior of the
>>>>>> directly executed D.
>>>>>>
>>>>>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>>>>>> *paragraph is correct*
>>>>>> (a) 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
>>>>>
>>>>> Your simulator does an incorrect simulation because of the
>>>>> undeclared input of execution history into the inner simulation.
>>>>
>>>> If it was incorrect then you could show the exact sequence that
>>>> should be simulated.
>>>
>>> I could, but why should I do more work when less work is already good
>>> enough? It wouldn't prove anything that wasn't already proved. I'd
>>> have to download your simulator, check it for viruses, figure out how
>>> it works, then change it.
>>>
>>>> You already said that the simulated D should call the simulated H.
>>>>
>>>> You know that when it does this that D correctly simulated by H cannot
>>> possible reach its own line 09 and terminate normally (AKA halt).
>>>>
>>>
>>> That's right.
>>>
>>
>> *That is better than anyone else has ever understood*
>>
> We all understand it, except you.
>
> You refuse to acknowledge this point:
>
> **The correct simulation of a program returns the same result as its
> direct execution.**

As soon as a termination analyzer correctly determines
that D correctly simulated by H cannot possibly halt
then this termination analyzer is free to abort this
simulation and report non-halting.

Alternatively you are saying that infinite loops cannot
possibly be determined to not halt until they are
simulated forever.

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

On 1/9/2024 8:17 PM, immibis wrote:
> On 1/10/24 01:44, olcott wrote:
>> On 1/9/2024 5:54 PM, immibis wrote:
>>> On 1/9/24 15:01, olcott wrote:
>>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>>> Premises:
>>>>>
>>>>> 1. The halting problem is Olcott-self-contradictory.
>>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>>
>>>>> Conclusion:
>>>>>
>>>>> 3. The halting problem can't be solved.
>>>>
>>>> When D is intentionally defined to do the opposite of
>>>> whatever Boolean value that H returns then input D <is>
>>>> absolutely self-contradictory to termination analyzer H
>>>> when H is required to report on the behavior of the
>>>> directly executed D.
>>>>
>>>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>>>> *paragraph is correct*
>>>> (a) 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
>>>
>>> Your simulator does an incorrect simulation because of the undeclared
>>> input of execution history into the inner simulation.
>>
>> If it was incorrect then you could show the exact sequence that
>> should be simulated.
>
> I could, but why should I do more work when less work is already good
> enough? It wouldn't prove anything that wasn't already proved. I'd have
> to download your simulator, check it for viruses, figure out how it
> works, then change it.
>
>> You already said that the simulated D should call the simulated H.
>>
>> You know that when it does this that D correctly simulated by H cannot
> possible reach its own line 09 and terminate normally (AKA halt).
>>
>
> That's right.
>

HH(D,D) does this and sees the repeated state and then
aborts its simulation. There is no need to simulate
an infinite loop forever to determine that it never halts.

As soon as the Infinite_loop non halting behavior
pattern is matched H is free to abort and report.

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

On 09/01/2024 23:54, immibis wrote:
> On 1/9/24 15:01, olcott wrote:
>> On 1/8/2024 11:07 PM, immibis wrote:
>>> Premises:
>>>
>>> 1. The halting problem is Olcott-self-contradictory.
>>> 2. Olcott-self-contradictory problems can't be solved.
>>>
>>> Conclusion:
>>>
>>> 3. The halting problem can't be solved.
>>
>> When D is intentionally defined to do the opposite of
>> whatever Boolean value that H returns then input D <is>
>> absolutely self-contradictory to termination analyzer H
>> when H is required to report on the behavior of the
>> directly executed D.
>>
>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>> *paragraph is correct*
>> (a) 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
>
> Your simulator does an incorrect simulation because of the undeclared input of execution history
> into the inner simulation.
>

I think you may be off base on your exact explanation here.

It's some time since I looked in any detail at PO's code and traces, but when I last did that it
seemed to me that at the step-by-step x86 instruction level the simulation was ok. The problem is
that H stops simulating before the simulated computation halts, on the grounds that it has spotted
the "PO infinitely recursive simulation pattern". UP TO THAT POINT the simulation faithfully
tracks the states of the actual computation, which continues from that point for a while and then
terminates normally. [..as seen when running D(D) "directly"]

PO is really really really convinced (despite concrete evidence showing otherwise) that his infinite
recursion pattern gives a sound non-halting test, but he is just wrong - it does not imply
non-halting. Other tests coded in his H may (likely) be sound, such as a "tight loop test", but the
one that matches in the D(D) simulation by H is unsound. Anyway, PO believes it is sound, so for PO
there is no debate: once H detects the pattern in the simulated D(D) trace that is (to PO) "proof"
that D(D) (at least "when correctly simulated by H" whatever that means) is non-halting. Since he
acknowledges that D(D) run independently DOES halt, he has to invent further ridiculous explanations
to explain that away - all the stuff about "different questions depending on who is being asked".
To repeat my point above - regardless of who is asked, PO's simulation follows the same correct
sequence of steps UP TO THE POINT where askee stops the simulation. No difference in the simulated
D(D) steps, only in the surrounding conditional code (e.g. in H) driving the simulation steps.

E.g. PO's H1 is a copy of H's code, but changed to look for its own H1 address instead of H's
address inside the simulations it runs. Since the D(D) computation never calls H1, PO's unsound
recursion test never matches, so H1 simulates right through to the natural termination of the D(D)
computation. PO quotes that as proof that "the question has changed when asked to H1", but of
course it is just that H1 is not a proper copy of H - it simply implements different logic, but runs
against the same simulation "trace" data, so no surprise it's result differs from H's. I find it
funny that PO is quite clueless about what his own code is doing! :)

A year or two ago I actually posted PO-style traces of D(D) and H(D,D) SIDE BY SIDE so PO could see
the simulation traces were identical [up to where H elects to stop simulating]. I've found the old
post:

msgid: <tbme1t$1a10$1@gioia.aioe.org>

[ah, AIOE... RIP]

or a GG web link:

<https://groups.google.com/g/comp.theory/c/dP1uDQDLkJI/m/eOaCCBSFAgAJ>

I seriously hope you don't need the GG link - as usual GG has screwed up all the careful spacing in
the Usenet article so it's a dog's dinner to read! (I could recopy the article here to get the
formatting back if required.)

Regards,
Mike.

BTW, I'm not sure how new you are to PO's "traces", so just in case you don't realise:
- they're not "x86 processor traces" in the usual sense, because they consist
of entries from nested simulation levels interleaved, with no clear indication
of this. When you see inner simulation trace entries, remember the simulator
logic in all outer levels is still running and examining the inner simulations
etc., so an outer level is free to stop its simulation at any point.
This is deliberate on PO's part, as he wants viewers to treat it as a single
processor trace. For a single process trace (e.g. if H CALLED D(D) rather
than SIMULATED it, his "infinite recursion pattern" or something similar could
become sound.
We could say that PO's most low level error in the whole "I've refuted HP etc."
claim is his belief that his PO-pattern to detect "infinite recursive simulation"
is sound. And that error in turn is due to PO not understanding the logical
differences between CALL recursion and SIMULATION recursion. [The former can
ONLY break from the innermost loop. The latter can additionally break from the
outer SIMULATION just deciding to stop simulating.]
[Of course, piled on top of this error are heaps of other more blatent higher
level errors, but I feel those came later in PO's attempt to patch up this
original error...]
- trace entries within H are suppressed, so in a PO trace what typically follows
a call to H are entries for instructions being SIMULATED inside H, until
the simulation ends and H returns, at which point entries resume for
the original processor.
- the above apply recursively if a simulated program simulates another and so on,
although I don't think that happened in the code I last looked at, since H
was coded to stop simulating before that would occur...
- PO's "simulations" all occur within a single "address space" sharing all
code and data. He gives them each their own stack, but they are only "stepped"
explictly by the code (e.g. in H) driving the simulation forward.
(I recall in another post you said you weren't sure about how PO did this...)

On 1/9/24 10:20 PM, olcott wrote:
> On 1/9/2024 9:02 PM, immibis wrote:
>> On 1/10/24 03:58, olcott wrote:
>>> On 1/9/2024 8:17 PM, immibis wrote:
>>>> On 1/10/24 01:44, olcott wrote:
>>>>> On 1/9/2024 5:54 PM, immibis wrote:
>>>>>> On 1/9/24 15:01, olcott wrote:
>>>>>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>>>>>> Premises:
>>>>>>>>
>>>>>>>> 1. The halting problem is Olcott-self-contradictory.
>>>>>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>>>>>
>>>>>>>> Conclusion:
>>>>>>>>
>>>>>>>> 3. The halting problem can't be solved.
>>>>>>>
>>>>>>> When D is intentionally defined to do the opposite of
>>>>>>> whatever Boolean value that H returns then input D <is>
>>>>>>> absolutely self-contradictory to termination analyzer H
>>>>>>> when H is required to report on the behavior of the
>>>>>>> directly executed D.
>>>>>>>
>>>>>>> *MIT Professor Michael Sipser has agreed that the following
>>>>>>> verbatim*
>>>>>>> *paragraph is correct*
>>>>>>> (a) 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
>>>>>>
>>>>>> Your simulator does an incorrect simulation because of the
>>>>>> undeclared input of execution history into the inner simulation.
>>>>>
>>>>> If it was incorrect then you could show the exact sequence that
>>>>> should be simulated.
>>>>
>>>> I could, but why should I do more work when less work is already
>>>> good enough? It wouldn't prove anything that wasn't already proved.
>>>> I'd have to download your simulator, check it for viruses, figure
>>>> out how it works, then change it.
>>>>
>>>>> You already said that the simulated D should call the simulated H.
>>>>>
>>>>> You know that when it does this that D correctly simulated by H cannot
>>>> possible reach its own line 09 and terminate normally (AKA halt).
>>>>>
>>>>
>>>> That's right.
>>>>
>>>
>>> *That is better than anyone else has ever understood*
>>>
>> We all understand it, except you.
>>
>> You refuse to acknowledge this point:
>>
>> **The correct simulation of a program returns the same result as its
>> direct execution.**
>
> As soon as a termination analyzer correctly determines
> that D correctly simulated by H cannot possibly halt
> then this termination analyzer is free to abort this
> simulation and report non-halting.
>
> Alternatively you are saying that infinite loops cannot
> possibly be determined to not halt until they are
> simulated forever.
>

No, it needs to determine that D correctly simulated (not just "by H")
or directly run cannot possibly halt.

If no H actually correctly simulates its input, then your termination
analyzer doesn't have any grounds to make a correct decision.

It is just the barber that only shaves people that don't shave themselves.

Note, SOME "infinite loops" can actually be shown in finite time to not
ever reach a final state, even if they were simulated forever. Note,
this is of the exact same program (not a "program template that changed
when you changed the finite decider into a non-aborting simulator).

Since your template doesn't do THAT logic, it isn't sound, but as you
have stated before, just shows itself to be a dishonest liar for not
looking that the input it was actually given, but presuming it is
something else.

(Remember, a specific D is based on a specific H, and thus postulating a
different H looking at this input doesn't change it).

On 1/9/24 10:23 PM, olcott wrote:
> On 1/9/2024 8:17 PM, immibis wrote:
>> On 1/10/24 01:44, olcott wrote:
>>> On 1/9/2024 5:54 PM, immibis wrote:
>>>> On 1/9/24 15:01, olcott wrote:
>>>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>>>> Premises:
>>>>>>
>>>>>> 1. The halting problem is Olcott-self-contradictory.
>>>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>>>
>>>>>> Conclusion:
>>>>>>
>>>>>> 3. The halting problem can't be solved.
>>>>>
>>>>> When D is intentionally defined to do the opposite of
>>>>> whatever Boolean value that H returns then input D <is>
>>>>> absolutely self-contradictory to termination analyzer H
>>>>> when H is required to report on the behavior of the
>>>>> directly executed D.
>>>>>
>>>>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>>>>> *paragraph is correct*
>>>>> (a) 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
>>>>
>>>> Your simulator does an incorrect simulation because of the
>>>> undeclared input of execution history into the inner simulation.
>>>
>>> If it was incorrect then you could show the exact sequence that
>>> should be simulated.
>>
>> I could, but why should I do more work when less work is already good
>> enough? It wouldn't prove anything that wasn't already proved. I'd
>> have to download your simulator, check it for viruses, figure out how
>> it works, then change it.
>>
>>> You already said that the simulated D should call the simulated H.
>>>
>>> You know that when it does this that D correctly simulated by H cannot
>> possible reach its own line 09 and terminate normally (AKA halt).
>>>
>>
>> That's right.
>>
>
> HH(D,D) does this and sees the repeated state and then
> aborts its simulation. There is no need to simulate
> an infinite loop forever to determine that it never halts.
>
> As soon as the Infinite_loop non halting behavior
> pattern is matched H is free to abort and report.
>

THen why does UTM(D,D) or D(D) reach a final state?

Because your D isn't actually a real program, just a program template,
and thus not actually the machine of the proof.

You have admitted to this, that you are just a pathological liar.

On 1/9/2024 9:36 PM, Mike Terry wrote:
> On 09/01/2024 23:54, immibis wrote:
>> On 1/9/24 15:01, olcott wrote:
>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>> Premises:
>>>>
>>>> 1. The halting problem is Olcott-self-contradictory.
>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>
>>>> Conclusion:
>>>>
>>>> 3. The halting problem can't be solved.
>>>
>>> When D is intentionally defined to do the opposite of
>>> whatever Boolean value that H returns then input D <is>
>>> absolutely self-contradictory to termination analyzer H
>>> when H is required to report on the behavior of the
>>> directly executed D.
>>>
>>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>>> *paragraph is correct*
>>> (a) 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
>>
>> Your simulator does an incorrect simulation because of the undeclared
>> input of execution history into the inner simulation.
>>
>
> I think you may be off base on your exact explanation here.
>
> It's some time since I looked in any detail at PO's code and traces, but
> when I last did that it seemed to me that at the step-by-step x86
> instruction level the simulation was ok.  The problem is that H stops
> simulating before the simulated computation halts,

04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }

When N to infinity steps of D are correctly simulated by
any H that can possibly exist none reach their final
instruction at line 09 and halt.

Any attempt to provide a correct simulation of D by
any H such that D reaches its line 09 cannot possibly
succeed.

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

On 1/9/2024 9:36 PM, Mike Terry wrote:
> On 09/01/2024 23:54, immibis wrote:
>> On 1/9/24 15:01, olcott wrote:
>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>> Premises:
>>>>
>>>> 1. The halting problem is Olcott-self-contradictory.
>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>
>>>> Conclusion:
>>>>
>>>> 3. The halting problem can't be solved.
>>>
>>> When D is intentionally defined to do the opposite of
>>> whatever Boolean value that H returns then input D <is>
>>> absolutely self-contradictory to termination analyzer H
>>> when H is required to report on the behavior of the
>>> directly executed D.
>>>
>>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>>> *paragraph is correct*
>>> (a) 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
>>
>> Your simulator does an incorrect simulation because of the undeclared
>> input of execution history into the inner simulation.
>>
>
> I think you may be off base on your exact explanation here.
>
> It's some time since I looked in any detail at PO's code and traces, but
> when I last did that it seemed to me that at the step-by-step x86
> instruction level the simulation was ok.  The problem is that H stops
> simulating before the simulated computation halts,

Try and provide a sequence of D correctly simulated
by any H such that the simulated D reaches its own line 09

04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }

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

On 1/9/24 11:12 PM, olcott wrote:
> On 1/9/2024 9:36 PM, Mike Terry wrote:
>> On 09/01/2024 23:54, immibis wrote:
>>> On 1/9/24 15:01, olcott wrote:
>>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>>> Premises:
>>>>>
>>>>> 1. The halting problem is Olcott-self-contradictory.
>>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>>
>>>>> Conclusion:
>>>>>
>>>>> 3. The halting problem can't be solved.
>>>>
>>>> When D is intentionally defined to do the opposite of
>>>> whatever Boolean value that H returns then input D <is>
>>>> absolutely self-contradictory to termination analyzer H
>>>> when H is required to report on the behavior of the
>>>> directly executed D.
>>>>
>>>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>>>> *paragraph is correct*
>>>> (a) 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
>>>
>>> Your simulator does an incorrect simulation because of the undeclared
>>> input of execution history into the inner simulation.
>>>
>>
>> I think you may be off base on your exact explanation here.
>>
>> It's some time since I looked in any detail at PO's code and traces,
>> but when I last did that it seemed to me that at the step-by-step x86
>> instruction level the simulation was ok.  The problem is that H stops
>> simulating before the simulated computation halts,
>
> 04 int D(ptr x)
> 05 {
> 06   int Halt_Status = H(x, x);
> 07   if (Halt_Status)
> 08     HERE: goto HERE;
> 09   return Halt_Status;
> 10 }
>
> When N to infinity steps of D are correctly simulated by
> any H that can possibly exist none reach their final
> instruction at line 09 and halt.
>
> Any attempt to provide a correct simulation of D by
> any H such that D reaches its line 09 cannot possibly
> succeed.
>

On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9nZ2dnUU7-V2dnZ2d@giganews.com>
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {
> H_Hat((u32)H_Hat);
> }
>
>
> _H_Hat()
> [00000b98](01) 55 push ebp
> [00000b99](02) 8bec mov ebp,esp
>
[00000b9b](01) 51 push ecx
> [00000b9c](03) 8b4508 mov eax,[ebp+08]
> [00000b9f](01) 50 push eax
> [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
> [00000ba3](01) 51 push ecx
> [00000ba4](05) e88ffdffff call 00000938
> [00000ba9](03) 83c408 add esp,+08
> [00000bac](03) 8945fc mov [ebp-04],eax
> [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
> [00000bb3](02) 7402 jz 00000bb7
> [00000bb5](02) ebfe jmp 00000bb5
> [00000bb7](02) 8be5 mov esp,ebp
> [00000bb9](01) 5d pop ebp
> [00000bba](01) c3 ret
> Size in bytes:(0035) [00000bba]
>
> _main()
> [00000bc8](01) 55 push ebp
> [00000bc9](02) 8bec mov ebp,esp
> [00000bcb](05) 68980b0000 push 00000b98
> [00000bd0](05) e8c3ffffff call 00000b98
> [00000bd5](03) 83c404 add esp,+04
> [00000bd8](02) 33c0 xor eax,eax
> [00000bda](01) 5d pop ebp
> [00000bdb](01) c3 ret
> Size in bytes:(0020) [00000bdb]
>
> ===============================
> ...[00000bc8][001015d4][00000000](01) 55 push ebp
> ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
> ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98
> ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98
> ...[00000b98][001015c8][001015d4](01) 55 push ebp
> ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
> ...[00000b9b][001015c4][00000000](01) 51 push ecx
> ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][001015c0][00000b98](01) 50 push eax
> ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][001015bc][00000b98](01) 51 push ecx
> ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
> Begin Local Halt Decider Simulation at Machine Address:b98
> ...[00000b98][00211674][00211678](01) 55 push ebp
> ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
> ...[00000b9b][00211670][00201644](01) 51 push ecx
> ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0021166c][00000b98](01) 50 push eax
> ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][00211668][00000b98](01) 51 push ecx
> ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938
> ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
> ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
> ...[00000b9b][0025c098][0024c06c](01) 51 push ecx
> ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0025c094][00000b98](01) 50 push eax
> ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][0025c090][00000b98](01) 51 push ecx
> ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Above decision was from the call the Halts inside H_Hat, deciding that
H_Hat(H_Hat) seems to be non-halting, it then returns that answer and is
processed below:

> ...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08
> ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax
> ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00
> ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7
> ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp
> ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp
> ...[00000bba][001015d0][00000b98](01) c3 ret
> ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04
> ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax
> ...[00000bda][001015d8][00100000](01) 5d pop ebp
> ...[00000bdb][001015dc][00000098](01) c3 ret

SEE IT HALTED!

> Number_of_User_Instructions(39)
> Number of Instructions Executed(26567)

Any failure to show what is wrong here will be just proof that you are
just a liar.

On 1/10/24 04:36, Mike Terry wrote:
> On 09/01/2024 23:54, immibis wrote:
>>
>> Your simulator does an incorrect simulation because of the undeclared
>> input of execution history into the inner simulation.
>>
>
> I think you may be off base on your exact explanation here.
>
> It's some time since I looked in any detail at PO's code and traces, but
> when I last did that it seemed to me that at the step-by-step x86
> instruction level the simulation was ok.  The problem is that H stops
> simulating before the simulated computation halts, on the grounds that
> it has spotted the "PO infinitely recursive simulation pattern".

Yes.

> UP TO THAT POINT the simulation faithfully tracks the states of the actual
> computation, which continues from that point for a while and then
> terminates normally.  [..as seen when running D(D) "directly"]

Well, sort of. The simulator refuses to simulate the simulator, and
instead does something like incrementing a "simulation level" variable
and then simulating the code the inner simulator would have simulated.

A true simulation of the simulator would find that the simulator
eventually detects the infinite recursion pattern, and then halts.
Olcott's simulator instead behaves as if it knows that the simulator
never halts, which is an obviously untrue fact and a self-delusion of
Olcott.

>
> PO is really really really convinced (despite concrete evidence showing
> otherwise) that his infinite recursion pattern gives a sound non-halting
> test, but he is just wrong - it does not imply non-halting.

Infinite recursion does imply non-halting, but it's detected in a way
that is obviously incorrect.

If the simulator simulated the simulator, it would end up in an
infinitely nested simulation stack that would obviously never finish.
That would be obvious, and a human looking at the program could see that
it could never finish (thus acting as a correct halting decider for this
particular program).

In actuality, the program behaves as if the nested simulation is
launched with different parameters from the outer simulation. One way to
interpret this is that the nested simulation is launched with some
execution history, so that it will behave differently than specified if
it detects that a nested simulator is launched inside it (a
double-nested simulator).

  Other tests
> coded in his H may (likely) be sound, such as a "tight loop test", but
> the one that matches in the D(D) simulation by H is unsound.  Anyway, PO
> believes it is sound, so for PO there is no debate: once H detects the
> pattern in the simulated D(D) trace that is (to PO) "proof" that D(D)
> (at least "when correctly simulated by H" whatever that means) is
> non-halting.  Since he acknowledges that D(D) run independently DOES
> halt, he has to invent further ridiculous explanations to explain that
> away

Yes, I find that to be the most ridiculous part. It's obvious that
H(D,D) says it doesn't halt. It's obvious that D(D) does halt. Therefore
it's obvious that H(D,D) is lying. This is an extremely basic and
obvious fact which is staring Olcott in the face, but I suppose he can't
just give up on 20 years of bullshit in an instant.

- all the stuff about "different questions depending on who is
> being asked". To repeat my point above - regardless of who is asked,
> PO's simulation follows the same correct sequence of steps UP TO THE
> POINT where askee stops the simulation.  No difference in the simulated
> D(D) steps, only in the surrounding conditional code (e.g. in H) driving
> the simulation steps.

Actually I don't believe the simulator correctly simulates a nested
simulation.

> BTW, I'm not sure how new you are to PO's "traces", so just in case you
> don't realise:

He argued with me for 6 months in Stack Overflow chat.

On 1/9/24 11:22 PM, olcott wrote:
> On 1/9/2024 9:36 PM, Mike Terry wrote:
>> On 09/01/2024 23:54, immibis wrote:
>>> On 1/9/24 15:01, olcott wrote:
>>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>>> Premises:
>>>>>
>>>>> 1. The halting problem is Olcott-self-contradictory.
>>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>>
>>>>> Conclusion:
>>>>>
>>>>> 3. The halting problem can't be solved.
>>>>
>>>> When D is intentionally defined to do the opposite of
>>>> whatever Boolean value that H returns then input D <is>
>>>> absolutely self-contradictory to termination analyzer H
>>>> when H is required to report on the behavior of the
>>>> directly executed D.
>>>>
>>>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>>>> *paragraph is correct*
>>>> (a) 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
>>>
>>> Your simulator does an incorrect simulation because of the undeclared
>>> input of execution history into the inner simulation.
>>>
>>
>> I think you may be off base on your exact explanation here.
>>
>> It's some time since I looked in any detail at PO's code and traces,
>> but when I last did that it seemed to me that at the step-by-step x86
>> instruction level the simulation was ok.  The problem is that H stops
>> simulating before the simulated computation halts,
>
> Try and provide a sequence of D correctly simulated
> by any H such that the simulated D reaches its own line 09
>
> 04 int D(ptr x)
> 05 {
> 06   int Halt_Status = H(x, x);
> 07   if (Halt_Status)
> 08     HERE: goto HERE;
> 09   return Halt_Status;
> 10 }
>
>

Done, and ignored.

Showing you are just a liar, liar, heading for the lake of fire.

On 1/9/2024 9:36 PM, Mike Terry wrote:
> On 09/01/2024 23:54, immibis wrote:
>> On 1/9/24 15:01, olcott wrote:
>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>> Premises:
>>>>
>>>> 1. The halting problem is Olcott-self-contradictory.
>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>
>>>> Conclusion:
>>>>
>>>> 3. The halting problem can't be solved.
>>>
>>> When D is intentionally defined to do the opposite of
>>> whatever Boolean value that H returns then input D <is>
>>> absolutely self-contradictory to termination analyzer H
>>> when H is required to report on the behavior of the
>>> directly executed D.
>>>
>>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>>> *paragraph is correct*
>>> (a) 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
>>
>> Your simulator does an incorrect simulation because of the undeclared
>> input of execution history into the inner simulation.
>>
>
> I think you may be off base on your exact explanation here.
>
> It's some time since I looked in any detail at PO's code and traces, but
> when I last did that it seemed to me that at the step-by-step x86
> instruction level the simulation was ok.  The problem is that H stops
> simulating before the simulated computation halts,

04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }

*Maybe you are confused and count an aborted simulation as halting*

There is no possible simulator or simulating termination analyzer
H that correctly simulates N to infinity steps of D such that D
reaches its own line 09 therefore D correctly simulated by H does
not halt.

I just proved the the simulated D cannot possibly reach its own
line 09 and terminate normally.

It is the *strawman deception* to change the subject to a different
sequence of steps than the sequence of steps that H sees.

*Maybe you are confused and count an aborted simulation as halting*

*ALTERNATIVELY* When a termination analyzer must report on the direct
execution of D(D) then:

"What correct Boolean value does H return when D is defined to do
the opposite of whatever value that H returns?"

has no correct answer and *Is rejected as semantically incorrect*

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

On 1/10/2024 5:52 AM, Richard Damon wrote:
> On 1/9/24 11:22 PM, olcott wrote:
>> On 1/9/2024 9:36 PM, Mike Terry wrote:
>>> On 09/01/2024 23:54, immibis wrote:
>>>> On 1/9/24 15:01, olcott wrote:
>>>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>>>> Premises:
>>>>>>
>>>>>> 1. The halting problem is Olcott-self-contradictory.
>>>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>>>
>>>>>> Conclusion:
>>>>>>
>>>>>> 3. The halting problem can't be solved.
>>>>>
>>>>> When D is intentionally defined to do the opposite of
>>>>> whatever Boolean value that H returns then input D <is>
>>>>> absolutely self-contradictory to termination analyzer H
>>>>> when H is required to report on the behavior of the
>>>>> directly executed D.
>>>>>
>>>>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>>>>> *paragraph is correct*
>>>>> (a) 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
>>>>
>>>> Your simulator does an incorrect simulation because of the
>>>> undeclared input of execution history into the inner simulation.
>>>>
>>>
>>> I think you may be off base on your exact explanation here.
>>>
>>> It's some time since I looked in any detail at PO's code and traces,
>>> but when I last did that it seemed to me that at the step-by-step x86
>>> instruction level the simulation was ok.  The problem is that H stops
>>> simulating before the simulated computation halts,
>>
>> Try and provide a sequence of D correctly simulated
>> by any H such that the simulated D reaches its own line 09
>>
>> 04 int D(ptr x)
>> 05 {
>> 06   int Halt_Status = H(x, x);
>> 07   if (Halt_Status)
>> 08     HERE: goto HERE;
>> 09   return Halt_Status;
>> 10 }
>>
>>
>
> Done, and ignored.

Saying DONE and IGNORED is self-contradictory it is either DONE or
IGNORED and not both. If it is DONE provide the message ID where
you did this otherwise everyone knows that DONE is a lie.

>
> Showing you are just a liar, liar, heading for the lake of fire.

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

On 1/10/24 9:44 AM, olcott wrote:
> On 1/10/2024 5:52 AM, Richard Damon wrote:
>> On 1/9/24 11:22 PM, olcott wrote:
>>> On 1/9/2024 9:36 PM, Mike Terry wrote:
>>>> On 09/01/2024 23:54, immibis wrote:
>>>>> On 1/9/24 15:01, olcott wrote:
>>>>>> On 1/8/2024 11:07 PM, immibis wrote:
>>>>>>> Premises:
>>>>>>>
>>>>>>> 1. The halting problem is Olcott-self-contradictory.
>>>>>>> 2. Olcott-self-contradictory problems can't be solved.
>>>>>>>
>>>>>>> Conclusion:
>>>>>>>
>>>>>>> 3. The halting problem can't be solved.
>>>>>>
>>>>>> When D is intentionally defined to do the opposite of
>>>>>> whatever Boolean value that H returns then input D <is>
>>>>>> absolutely self-contradictory to termination analyzer H
>>>>>> when H is required to report on the behavior of the
>>>>>> directly executed D.
>>>>>>
>>>>>> *MIT Professor Michael Sipser has agreed that the following verbatim*
>>>>>> *paragraph is correct*
>>>>>> (a) 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
>>>>>
>>>>> Your simulator does an incorrect simulation because of the
>>>>> undeclared input of execution history into the inner simulation.
>>>>>
>>>>
>>>> I think you may be off base on your exact explanation here.
>>>>
>>>> It's some time since I looked in any detail at PO's code and traces,
>>>> but when I last did that it seemed to me that at the step-by-step
>>>> x86 instruction level the simulation was ok.  The problem is that H
>>>> stops simulating before the simulated computation halts,
>>>
>>> Try and provide a sequence of D correctly simulated
>>> by any H such that the simulated D reaches its own line 09
>>>
>>> 04 int D(ptr x)
>>> 05 {
>>> 06   int Halt_Status = H(x, x);
>>> 07   if (Halt_Status)
>>> 08     HERE: goto HERE;
>>> 09   return Halt_Status;
>>> 10 }
>>>
>>>
>>
>> Done, and ignored.
>
> Saying DONE and IGNORED is self-contradictory it is either DONE or
> IGNORED and not both. If it is DONE provide the message ID where
> you did this otherwise everyone knows that DONE is a lie.

In other words you don't understnad what I said.

I have DONE what you asked for, and YOU have IGNORED it, proving
yourself to be a LIAR.

Note, your arguement, by your own admission, is juyst a dishonest dodge
to avoid the truth.

You admit that the definition of the Halting Problem is that the Decider
is supposed to determine if the Machine described by the input to the
decider will Halt or Not.

You also admit that the definition of "Halting" is that the *Machine*
(and that is the actual machine, and not just something that might be
claimed to be a correct simulation of it) reaches a Final State.

Yes, "UTMs" introducd the concept of Simulaiton as a replacement, but
ONLY if the simulation matches that of a UTM, and such a machine doesn't
stop until it reaches a final state of the machine described

Note also, by the definition of "A Machine", it is the free Running
program, and thus it will not stop until it reaches a final state, so to
be "non-halting" means that even after an unlimited number of steps, it
doesn't reach such a state.

It seems that you are just a natural liar, living in your own fantasy
world where you think yourself to be "God" and rules don't apply to you.

You think that something can be SELF contradictory to something else,
and that programs don't need to be actual program.
>
>>
>> Showing you are just a liar, liar, heading for the lake of fire.
>

On 10/01/2024 07:16, immibis wrote:
> On 1/10/24 04:36, Mike Terry wrote:
>> On 09/01/2024 23:54, immibis wrote:
>>>
>>> Your simulator does an incorrect simulation because of the undeclared input of execution history
>>> into the inner simulation.
>>>
>>
>> I think you may be off base on your exact explanation here.
>>
>> It's some time since I looked in any detail at PO's code and traces, but when I last did that it
>> seemed to me that at the step-by-step x86 instruction level the simulation was ok.  The problem is
>> that H stops simulating before the simulated computation halts, on the grounds that it has spotted
>> the "PO infinitely recursive simulation pattern".
>
> Yes.
>
>> UP TO THAT POINT the simulation faithfully tracks the states of the actual computation, which
>> continues from that point for a while and then terminates normally.  [..as seen when running D(D)
>> "directly"]
>
> Well, sort of. The simulator refuses to simulate the simulator, and instead does something like
> incrementing a "simulation level" variable and then simulating the code the inner simulator would
> have simulated.

I think we diverge here. Perhaps... I would say PO's code "simulates the simulator" in a
reasonable way we could accept for current purposes. (At least for the purposes of discussing where
he is going wrong - IF he went as far as submitting a formal paper to a journal, all sorts of lesser
problems would need addressing regarding the validity of his approach and his x86utm design (sharing
the main code/data across all simulation levels, use of complex x86 instruction set etc.), but
that's never going to happen and meanwhile I don't believe these issues are the source of any actual
problems in his results. He has much simpler basic misunderstandings.)

The basic limitations of PO's x86utm design:
- all simulations share a single address space with shared code and data
- the x86-level instruction simulation is housed in x86utm.exe as opposed to
what I'll call the user (code/data) space, where H,D,H1, code and stack space and
(perhaps) global data reside
- simulation single-stepping etc. is provided as primitives by x86utm to user space code.
(since address space is shared, and register save space used by primitives is in the
user address space, simulators can monitor the progress of their simulations)
I think nested simulation works sort of ok given the above architecture - but also see my very final
comment below...

Also I think there's divergence among posters here re what counts as "simulation", so that might be
a source of misunderstanding? I prefer "simulation" to mean simply the act of calculating the state
changes in a computation, with the understanding that a program might simulate just (say) 10 steps
of a computation, and then stop for whatever reason. I'd say that simulation activity was "correct"
if those 10 steps were calculated correctly i.e. they track the first 10 actual computation steps.

The program will of course perform many other calculations and make other decisions (e.g. the
counting to 10 or other tests to decide when to stop simulating, deciding on its own return code) -
but I don't count those "simulating" or part of the simulator. I.e. the simulator is just a
component the program uses. If the program simulates 10 steps correctly then stops simulating, the
/simulation/ was correct, and if the program proceeds to announce that the computation would never
halt, when in fact it would, that doesn't change that it correctly simulated the 10 steps - the
fault lies in the non-simulating code of the program. [Well, that's how I'd express things...]

Perhaps you use "simulate" in a broader sense, e.g. to include ALL the code in H including what I'd
consider business logic (which for H I'd label "termination analysis")? So when you say "the
simulator /refuses/ to simulate the simulator", maybe you're just saying H is coded to abort its
simulation too early due to a false positive match with its unsound recursion test. [I agree with
that.] But to me I'm reading it as saying x86utm doesn't properly support nested simulation in some
way, whereas to me it seems it does!

E.g. suppose we run H1(D,D). [H1 is the copy of H, but with a modified abort condition that means
in effect it never matches when analysing (D,D) input...]
When H1 simulates D(D), it simulates:
- D calling H,
- H simulating D(D) - including the simulation primitives within H, and all the termination
analysis code such as PO's infinite recursion testing code, abort decision code and so on.
- the simulated simulation being aborted by the simulated H,
- H returning to D [telling simulated D that D(D) never halts!],
- D reaching its final ret, i.e. halting.

Perfect - no issues I can see with nesting of simulations or invalid secret data feeds to inner
simulations altering the course of the inner simulations or anything like that.

The problem when running H(D,D) is simply that while (correctly) simulating D(D), [outer] H spots
PO's "infinite recursion" pattern [which DOES NOT ACTUALLY TEST FOR INFINITE RECURSION despite PO's
name for the test] and aborts the simulation, announcing incorrectly that D(D) doesn't halt when it
does.

That's hardly the fault of the correct (partial) simulation - it's the fault of the faulty
termination analysis logic in H, namely relience use of PO's unsound "infinite recursion" pattern.
Er, that's it!

>
> A true simulation of the simulator would find that the simulator eventually detects the infinite
> recursion pattern, and then halts.

And it does, e.g. when we run H1(D,D) as above.

In my terminology, when running H(D,D) H "correctly" simulates D(D) for a while, but then applies an
unsound test that matches its generated simulation trace, so it incorrectly concludes its simulation
of D(D) "IF continued" would never halt. Actually I'm being sloppy: *H* assumes no such thing as
it's just code. The incorrect assumption is PO's, as the designer.

The point I'd make is that the /reason/ H1 sees simulated D(D) halt while H decides it never halts
is nothing to do with incorrect nested simulation implementation causing nested simulations to
behave differently from outer simulations - like due to invalid use of global data leaking in, or
whatever. AFAICT regardless of the simulation depth, all the simulations behave exactly the same
[up to the point the simulation is aborted of course]. This is where I suspect you diverge?

I think your "true simulator" = my "full simulator" = "simulates to completion"? PO's H is
obviously not a "true simulator" in that sense and PO has never claimed that. PO claims his H
"correctly simulates" D(D) which fits my usage, although his often repeated "..until H correctly
decides that its simulation would never end..." bit doesn't apply - H actually /incorrectly/ decides
blah blah, since it relied on his unsound infinite recursion test.

> Olcott's simulator instead behaves as if it knows that the
> simulator never halts, which is an obviously untrue fact and a self-delusion of Olcott.

Hmm. I'll read that as "PO's "H" behaves as if it knows...". But H is just code, and doesn't do
"as if" or "knowing" (of course). Those ideas may well be in PO's mind, as /designer/ for H, and
readers may benefit from that insight.

But what actually happens? H applies an unsound test which matches (a false-positive), leading it
to incorrectly announce that computation D(D) never halts. That seems a simple account of what's
going on.

>
>>
>> PO is really really really convinced (despite concrete evidence showing otherwise) that his
>> infinite recursion pattern gives a sound non-halting test, but he is just wrong - it does not
>> imply non-halting.
>
> Infinite recursion does imply non-halting, but it's detected in a way that is obviously incorrect.

Exactly. PO's "infinite recursive simulation" test is unsound. It can match both halting and
non-halting computations.

>
> If the simulator simulated the simulator, it would end up in an infinitely nested simulation stack
> that would obviously never finish. That would be obvious, and a human looking at the program could
> see that it could never finish (thus acting as a correct halting decider for this particular program).
>
> In actuality, the program behaves as if the nested simulation is launched with different parameters
> from the outer simulation. One way to interpret this is that the nested simulation is launched with
> some execution history, so that it will behave differently than specified if it detects that a
> nested simulator is launched inside it (a double-nested simulator).

On 1/10/2024 10:14 PM, Mike Terry wrote:
> On 10/01/2024 07:16, immibis wrote:
>> On 1/10/24 04:36, Mike Terry wrote:
>>> On 09/01/2024 23:54, immibis wrote:
>>>>
>>>> Your simulator does an incorrect simulation because of the
>>>> undeclared input of execution history into the inner simulation.
>>>>
>>>
>>> I think you may be off base on your exact explanation here.
>>>
>>> It's some time since I looked in any detail at PO's code and traces,
>>> but when I last did that it seemed to me that at the step-by-step x86
>>> instruction level the simulation was ok.  The problem is that H stops
>>> simulating before the simulated computation halts, on the grounds
>>> that it has spotted the "PO infinitely recursive simulation pattern".
>>
>> Yes.
>>
>>> UP TO THAT POINT the simulation faithfully tracks the states of the
>>> actual computation, which continues from that point for a while and
>>> then terminates normally.  [..as seen when running D(D) "directly"]
>>
>> Well, sort of. The simulator refuses to simulate the simulator, and
>> instead does something like incrementing a "simulation level" variable
>> and then simulating the code the inner simulator would have simulated.
>

*Mike has a very thorough not quite perfectly correct analysis*
(see below)

> I think we diverge here.  Perhaps...  I would say PO's code "simulates
> the simulator" in a reasonable way we could accept for current
> purposes.  (At least for the purposes of discussing where he is going
> wrong - IF he went as far as submitting a formal paper to a journal, all
> sorts of lesser problems would need addressing regarding the validity of
> his approach and his x86utm design (sharing the main code/data across
> all simulation levels, use of complex x86 instruction set etc.), but
> that's never going to happen and meanwhile I don't believe these issues
> are the source of any actual problems in his results.  He has much
> simpler basic misunderstandings.)
>
> The basic limitations of PO's x86utm design:
> -  all simulations share a single address space with shared code and data
> -  the x86-level instruction simulation is housed in x86utm.exe as
> opposed to
>    what I'll call the user (code/data) space, where H,D,H1, code and
> stack space and
>    (perhaps) global data reside
> -  simulation single-stepping etc. is provided as primitives by x86utm
> to user space code.
>    (since address space is shared, and register save space used by
> primitives is in the
>    user address space, simulators can monitor the progress of their
> simulations)
> I think nested simulation works sort of ok given the above architecture
> - but also see my very final comment below...
>
> Also I think there's divergence among posters here re what counts as
> "simulation", so that might be a source of misunderstanding?  I prefer
> "simulation" to mean simply the act of calculating the state changes in
> a computation, with the understanding that a program might simulate just
> (say) 10 steps of a computation, and then stop for whatever reason.  I'd
> say that simulation activity was "correct" if those 10 steps were
> calculated correctly i.e. they track the first 10 actual computation steps.
>
> The program will of course perform many other calculations and make
> other decisions (e.g. the counting to 10 or other tests to decide when
> to stop simulating, deciding on its own return code) - but I don't count
> those  "simulating" or part of the simulator.  I.e. the simulator is
> just a component the program uses.  If the program simulates 10 steps
> correctly then stops simulating, the /simulation/ was correct, and if
> the program proceeds to announce that the computation would never halt,
> when in fact it would, that doesn't change that it correctly simulated
> the 10 steps - the fault lies in the non-simulating code of the
> program.  [Well, that's how I'd express things...]
>
> Perhaps you use "simulate" in a broader sense, e.g. to include ALL the
> code in H including what I'd consider business logic (which for H I'd
> label "termination analysis")?  So when you say "the simulator /refuses/
> to simulate the simulator", maybe you're just saying H is coded to abort
> its simulation too early due to a false positive match with its unsound
> recursion test.  [I agree with that.]  But to me I'm reading it as
> saying x86utm doesn't properly support nested simulation in some way,
> whereas to me it seems it does!
>
> E.g. suppose we run H1(D,D).  [H1 is the copy of H, but with a modified
> abort condition that means in effect it never matches when analysing
> (D,D) input...]

H1 is the exact same code as H exact that D does not call H1.

> When H1 simulates D(D), it simulates:
> -  D calling H,
> -  H simulating D(D) - including the simulation primitives within H, and
> all the termination
>    analysis code such as PO's infinite recursion testing code, abort
> decision code and so on.
> -  the simulated simulation being aborted by the simulated H,
> -  H returning to D [telling simulated D that D(D) never halts!],
> -  D reaching its final ret, i.e. halting.
>
> Perfect - no issues I can see with nesting of simulations or invalid
> secret data feeds to inner simulations altering the course of the inner
> simulations or anything like that.
>
> The problem when running H(D,D) is simply that while (correctly)
> simulating D(D), [outer] H spots PO's "infinite recursion" pattern
> [which DOES NOT ACTUALLY TEST FOR INFINITE RECURSION despite PO's name
> for the test] and aborts the simulation, announcing incorrectly that
> D(D) doesn't halt when it does.

04 int D(ptr x)
05 {
06 int Halt_Status = H(x, x);
07 if (Halt_Status)
08 HERE: goto HERE;
09 return Halt_Status;
10 }

That no one can possibly provide the exact sequence of
the execution trace D correctly simulated by H such
that this simulated D reaches its own line 09 conclusively
proves that D correctly simulated by H never halts.

Every rebuttal to this has always been the pure bluster
of dogma with zero supporting exact execution trace.

> That's hardly the fault of the correct (partial) simulation - it's the
> fault of the faulty termination analysis logic in H, namely relience use
> of PO's unsound "infinite recursion" pattern. Er, that's it!
>
>>
>> A true simulation of the simulator would find that the simulator
>> eventually detects the infinite recursion pattern, and then halts.
>
> And it does, e.g. when we run H1(D,D) as above.
>
> In my terminology, when running H(D,D) H "correctly" simulates D(D) for
> a while, but then applies an unsound test that matches its generated
> simulation trace, so it incorrectly concludes its simulation of D(D) "IF
> continued" would never halt.  Actually I'm being sloppy: *H* assumes no
> such thing as it's just code.  The incorrect assumption is PO's, as the
> designer.
>
> The point I'd make is that the /reason/ H1 sees simulated D(D) halt
> while H decides it never halts is nothing to do with incorrect nested
> simulation implementation causing nested simulations to behave
> differently from outer simulations - like due to invalid use of global
> data leaking in, or whatever.  AFAICT regardless of the simulation
> depth, all the simulations behave exactly the same [up to the point the
> simulation is aborted of course].  This is where I suspect you diverge?
>
> I think your "true simulator" = my "full simulator" = "simulates to
> completion"?  PO's H is obviously not a "true simulator" in that sense
> and PO has never claimed that.  PO claims his H "correctly simulates"
> D(D) which fits my usage, although his often repeated "..until H
> correctly decides that its simulation would never end..." bit doesn't
> apply - H actually /incorrectly/ decides blah blah, since it relied on
> his unsound infinite recursion test.
>
>> Olcott's simulator instead behaves as if it knows that the simulator
>> never halts, which is an obviously untrue fact and a self-delusion of
>> Olcott.
>
> Hmm.  I'll read that as "PO's "H" behaves as if it knows...".  But H is
> just code, and doesn't do "as if" or "knowing" (of course).  Those ideas
> may well be in PO's mind, as /designer/ for H, and readers may benefit
> from that insight.
>
> But what actually happens?  H applies an unsound test which matches (a
> false-positive), leading it to incorrectly announce that computation
> D(D) never halts.  That seems a simple account of what's going on.
>