Re: Every HHH(DDD) is correct to reject its input --- thorough

On 6/2/2025 10:37 AM, Fred. Zwarts wrote:

Op 02.jun.2025 om 17:13 schreef olcott:

On 6/2/2025 1:56 AM, Fred. Zwarts wrote:

Op 02.jun.2025 om 07:12 schreef olcott:

On 6/1/2025 6:20 AM, Mikko wrote:

On 2025-05-31 19:21:10 +0000, olcott said:
>

On 5/31/2025 2:11 PM, Mr Flibble wrote:

Olcott is doing this:
>
int main()
{
DDD(); // DDD calls HHH
}
>
This is incorrect as it is a category (type) error in the form of
conflation of the EXECUTION of DDD with the SIMULATION of DDD: to
completely and correctly simulate/analyse DDD there must be no execution
of DDD prior to the simulation of DDD.
>
Olcott should be doing this:
>
int main()
{
HHH(DDD);
}

>
I would have left it there except that many dozens of
reviewers have pointed out that they believe that HHH
is supposed to report on the behavior of its caller.

>
A halt decider is required to report on the computation it is asked
about. There is no requirement that a halt decider knows or can find
out whether it is called by the program about which is required to
report. Consequently, whether the computaton asked about calls the
decider is irrelevant.
>

>
void DDD()
{
   HHH(DDD);
   return;
}
>
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*

>
But a finite recursion, because the input includes the code to abort and halt. That HHH is unable to reach this final 'ret' only shows that using a simulator for the analysis is in this case the wrong decision, because it fails the whole specification of the input.
>

>
If Mike is having a hard time on this then it must
be really hard to understand. Mike has fully understood
every other detail of the architecture of HHH.
>
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)...
>
HHH sees its abort criteria just before it is about
to simulate itself simulating DDD a third time.
>
Every nested simulation of HHH has this same behavior
because they all have the same machine code at
the same machine address.
>
The outermost HHH sees its abort criteria one whole
recursive emulation before the next inner one.

 Which is why its abort criteria is wrong. The next inner one would see it the next cycle,

If you are in a foot race
(a) The guy in front of you is first and you
     are ten feet behind him.
(b) You are second and the guy behind you is
     third and ten feet behind you.
If you all go the exact same speed who wins the race?
The guy in first place is the directly executed HHH.
You in second place are the HHH emulated by the above HHH.
You are all going the same speed is every HHH has the
exact same machine code that must behave exactly the same.

unless the outer one aborts it prematurely.
By this premature abort, the specification that the next inner one would abort, does not change. The input specifies an aborting and halting program, but HHH does not see that.
 

This means that unless that outer HHH aborts
none-of-them abort.

 Only if you change not only the outer one, but also the next inner one. But that would mean changing the input. Changing the input means that we no longer talk about the property specified by this input.
 

>
_DDD()
[00002192] 55             push ebp
[00002193] 8bec           mov ebp,esp
[00002195] 6892210000     push 00002192
[0000219a] e833f4ffff     call 000015d2  // call HHH
[0000219f] 83c404         add esp,+04
[000021a2] 5d             pop ebp
[000021a3] c3             ret
Size in bytes:(0018) [000021a3]
>
When the outermost HHH aborts its DDD the entire
recursive emulation chain stops right where it is
never reaching past machine address [0000219a].

 Yes it fails to reach the end, that it would reach if no premature abort were coded.
 

>
So we end up with
>
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*

 Indeed, the input specifies finite recursion and from this it follows:

Finite or infinite DOES NOT MATTER. The only thing
that matters is that DDD correctly emulated by HHH
cannot possibly reach its own
*simulated "return" instruction final halt state*
That is the ultimate definition of non-halting.

The input specifies an aborting and halting program, but HHH is unable to reach that part of the analysis, because of a premature abort.
This shows that simulation is not the right way to analyse this kind of inputs, because the simulator is not able to simulate itself correctly up to the end and misses the most important part of the specification in the input.
 It seems that you do not understand that a premature abort is no ground for the conclusion of non-halting behaviour.

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