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

Op 02.jun.2025 om 18:15 schreef olcott:

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?

But if we know that all others have instructions to abort the race after half the distance, there is no need for me to abort the race as well. I will win the race without aborting the other guys.

 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.

The input specifies the second, third, etc. They have code to abort, so we know they will halt. That makes that there is no need for the first one to abort as well.
Except if you change the input and remove the code of the abort, but then you are talking about the behaviour of another input.
sum(2,3) should compute the sum of its input, 2 and 3, not about a changed input 7 and 9.

 

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.

No, it matters. There is a finite recursion and HHH is programmed to be blind forthis  specified behaviour. It aborts (it is irrelevant whether it must halt of not, what matters is that it does halt.) That makes that HHH is blind for the fact that program in the input is coded to abort and halt. That HHH does not see that (whether it could or cannot is not relevant, what matters is that it does not see that), does not change the specification of a halting program.

 

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.