Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.theory
Subject: Re: Every HHH(DDD) is correct to reject its input --- thorough
Date: Tue, 3 Jun 2025 10:40:34 +0200
Organization: A noiseless patient Spider
Lines: 171
Message-ID: <101mce1$3sodg$2@dont-email.me>
References: <bvI_P.425446$o31.351189@fx04.ams4>
 <101fkr6$1db6f$1@dont-email.me> <101hd2e$21nfj$1@dont-email.me>
 <101jbrq$31e9g$1@dont-email.me> <101jhus$33i6m$1@dont-email.me>
 <101kf3h$3bfvj$3@dont-email.me> <101kgg2$3avrd$2@dont-email.me>
 <101kim7$3bfvj$11@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 03 Jun 2025 10:40:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e071329eba132dccb11419e24c8933e6";
	logging-data="4088240"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX181SiQ2B4Z7dOt2r3SKDBDO"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:esowsm9EqC28ZhWc/tW1/Q9KpI4=
In-Reply-To: <101kim7$3bfvj$11@dont-email.me>
Content-Language: nl, en-GB

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.
> 
>