Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: Every HHH(DDD) is correct to reject its input --- thorough
Date: Mon, 2 Jun 2025 11:15:03 -0500
Organization: A noiseless patient Spider
Lines: 149
Message-ID: <101kim7$3bfvj$11@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 02 Jun 2025 18:15:03 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="01672d8ae9aa1e0fec727857b1cb5419";
	logging-data="3522547"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/d1mUVeLi1YbmXZKODCCd5"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:MRkqq0queN7B6mQBweI+AH1ehGI=
X-Antivirus: Norton (VPS 250602-6, 6/2/2025), Outbound message
Content-Language: en-US
X-Antivirus-Status: Clean
In-Reply-To: <101kgg2$3avrd$2@dont-email.me>
Bytes: 6911

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