Re: My reviewers think that halt deciders must report on the behavior of their caller

Op 10.jul.2025 om 16:46 schreef olcott:

On 7/10/2025 6:17 AM, Fred. Zwarts wrote:

Op 09.jul.2025 om 15:46 schreef olcott:

On 7/9/2025 4:58 AM, Fred. Zwarts wrote:

Op 08.jul.2025 om 16:59 schreef olcott:

On 7/8/2025 3:10 AM, Fred. Zwarts wrote:

Op 07.jul.2025 om 15:23 schreef olcott:

On 7/7/2025 2:36 AM, Fred. Zwarts wrote:

Op 07.jul.2025 om 05:12 schreef olcott:

On 7/6/2025 9:09 PM, Richard Damon wrote:

On 7/6/25 4:06 PM, olcott wrote:

On 7/6/2025 12:00 PM, Richard Damon wrote:

On 7/6/25 11:19 AM, olcott wrote:

>
void DDD()
{
   HHH(DDD);
   return;
}
>
*EVERY BOT FIGURES THIS OUT ON ITS OWN*

>
No, it just isn't smart enough to detect that you lied in your premise.
>

There is no way that DDD simulated by HHH (according
to the semantics of the C programming language)
can possibly reach its own "return" statement final
halt state.

>
And there is no way for HHH to correctly simulate its input and return an answer
>

>
You insistence that a non-terminating input be simulated
until non-existent completion is especially nuts because
you have been told about this dozens of times.
>
What the F is wrong with you?
>

>
It seems you don't understand those words.
>
I don't say that the decider needs to simulate the input to completion, but that it needs to be able to actually PROVE that if this exact input WAS given to a correct simultor (which won't be itself, since it isn't doing the complete simulation) will run for an unbounded number of steps.
>

>
No decider is ever allowed to report on anything
besides the actual behavior that its input actually
specifies.
>

And HHH does not do that. The input specifies a halting program, because it includes the abort code.

>
>
void DDD()
{
   HHH(DDD);
   return;
}
>
_DDD()
[00002192] 55             push ebp
[00002193] 8bec           mov ebp,esp
[00002195] 6892210000     push 00002192  // push DDD
[0000219a] e833f4ffff     call 000015d2  // call HHH
[0000219f] 83c404         add esp,+04
[000021a2] 5d             pop ebp
[000021a3] c3             ret
Size in bytes:(0018) [000021a3]
>
That does have an effect on DDD emulated by HHH according
to the semantics of the x86 language stopping running.
It has no effect on this DDD every reaching its final halt
state. I have corrected your error on this too many times
you don't seem to want an honest dialogue.

>
As usual repeated claims without evidence.

>
100% *complete proof is provided above*
That you don't have sufficient technical
skill to see that this is complete proof
is not my mistake.

>
You fail to see that it is not a 100% proof. It is incomplete. The code has a call to 000015d2 , but you do not show the code there. we know

>
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Shows all of the details. X86UTM is a multi-tasking
operating system, When the emulator instructions are
shown they are mixed in with the emulated instructions.
This makes unraveling the details too difficult.
>
All that need be known is that "call 000015d2"
calls HHH that emulates its input until it detects
a non halting behavior pattern. All of the chat bots
figured out exactly what this pattern is on their own.

>
So, why don't you show the full input?

 I just did show the whole 197 page execution trace.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
 This includes the x86 code for HHH and everything that it calls.
 

So, next time, don't try again to claim that the few lines of DDD are the complete input for HHH. At least add that HHH is an aborting and halting simulator that returns 0. That makes the picture complete.