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

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?
Exactly that is the failure of HHH: It detects a non-existent non-halting behaviour. HHH has a bug, which makes that it does not see that there is only a finite recursion. It claims that there is a infinite recursion.

 

that this code is the HHH that aborts and halts, so a correct simulation will then reach 0000219f and then reach the final halt state.

 when you define "correct" as violating the semantics
of the x86 language then you would be "correct".

No, HHH violates the semantics of the x86 language by aborting the simulation without a valid reason. The x86 semantics requires it to continue and if it would do so, it would reach the final halt state.
Of course it cannot do that, because it cannot change its own buggy code.

 This might also seem true when you define halting
as stopping running for any reason what-so-ever
and not requiring reaching a final halt state.

A proper definition of halting would be reaching the halt state when not disturbed. When a halting program does not reach its final halts state because the computer is switched off too soon, or when the simulation is aborted too soon, then that is not counted as non-halting.

 

We also know that HHH fails to reach that final halt state, because of a premature abort. A proof with so many errors, is far from 100%.
You can close your eyes for these errors and pretend that they do not exists, but that would be childish.
>

>

It is a pity that you ignore or do not understand the corrections that have been pointed out to you. Not understanding something is not stupid, but resistance against learning from errors is.
>

>
DDD correctly simulated by HHH calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...

>
Using falsehoods to prove your case is not convincing. We know that HHH aborts before 6 cycles have been simulated.
>

>
That you cannot see that this is the behavior
that the input to HHH(DDD) specifies is your
own lack of technical skill.

>
That you do not even understand your own code, where HHH aborts after a few cycles, does not change the fact that the real behaviour specified is a halting program. But as usual, you and HHH close your eyes and pretend that what you do not see does not exist.
>

>
*Maybe it is time to reveal credentials*
I have taken all but one of the courses
for a computer science degree and been a
C++ software engineer for two decades.
Mensa scored my IQ is in the top 3%.
>

We have pointed out already many times that this cannot be the whole input. At 0000219a there is a call to 000015d2 , but the code at 000015d2 is not specified.

>
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
Because of the required cooperative multi-tasking
it is a little too difficult to see which the
actual trace.

>
Even that trace proves that HHH aborts before it can see the full behaviour specified in the input. Then it closes it eyes and pretends that what it does not see does not exist.
>

>

We have to take it from another source, your Halt7.c. There we see that HHH is a function that returns with a value 0 with this input. So, a correct simulation will then continue at 0000219f

>
DDD simulated by HHH according to the semantics of the x86
language cannot possibly ever get there even of your lack
of sufficient technical skill tells you so.
>
*Feel free to dig through this full trace and see*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
>

with this value and even a beginner sees that the simulation will then reach a natural end.

>
*DDD simulated by HHH NEVER REACHES ITS FINAL HALT STATE*
DDD correctly simulated by HHH calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...

>
Again the same falsehood. HHH aborts way before simulating 6 cycles.
Using falsehoods to prove your case does not make your case any stronger.
>

>

This is the full specification of the input.
This is also proven when exactly the same input is used in direct execution, or by world-class simulators, even by HHH1.
So, the following still holds:
>

>

But HHH gives up before it reaches that part of the specification and the final halt state.

If HHH does not see the full specification, it does not change the specification. It only illustrates the failure of the simulation to complete.
There is nothing wrong with aborting a simulation, because it is known that simulation is not always the correct tool to determine halting/ non- halting behaviour. In such cases other tools are needed to determine halting/non-halting behaviour.

>
>

>