Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: Re: My reviewers think that halt deciders must report on the behavior
 of their caller
Date: Thu, 10 Jul 2025 07:41:07 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <50595ac562fb9af5d458484f8596a98accccb8d5@i2pn2.org>
References: <101nq32$99vd$1@dont-email.me> <101oc24$hlr6$2@dont-email.me>
 <101ocpc$hd6o$7@dont-email.me> <101od0p$i3m6$2@dont-email.me>
 <1049edr$10io1$2@dont-email.me>
 <a25b36c514731c7946fc2fb5e003c4dda451452e@i2pn2.org>
 <1049jhv$11mmt$2@dont-email.me>
 <89d2edbab76401270efa67a8fbc135d5c47fefab@i2pn2.org>
 <104bjmr$1hqln$16@dont-email.me>
 <3f64fdd81d67415b7b0e305463d950c0c71e2db7@i2pn2.org>
 <EKKdnXZfl9Qpf_T1nZ2dnZfqlJ-dnZ2d@giganews.com>
 <9dcab3b82e32f9eb8473f8bc5361ab2fbef8b8f8@i2pn2.org>
 <104cud2$1r72a$2@dont-email.me>
 <a346224cd5d8b4001580eb6e5ff8783e58c9b7f5@i2pn2.org>
 <104e46s$28pqb$2@dont-email.me>
 <960c2417e6f691b2b12703506c207990df5b39ab@i2pn2.org>
 <104el09$2dpog$1@dont-email.me>
 <1ca786773f9ff02718c66e082bbc4182b36732ab@i2pn2.org>
 <104fduv$2n8gq$2@dont-email.me> <104ftep$rafj$1@dont-email.me>
 <104ghos$2uc68$1@dont-email.me> <104ijpu$v8i1$1@dont-email.me>
 <104jbnl$3jrpl$7@dont-email.me> <104leg1$13ioh$5@dont-email.me>
 <104lrr0$7l4q$10@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 10 Jul 2025 11:41:42 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="4180109"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <104lrr0$7l4q$10@dont-email.me>

On 7/9/25 9:46 AM, olcott wrote:
> 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.

Except that is a false statement.

As shown in your trace, HHH "thinks" that DDD has a non-halting pattern.

But the trace also shows that the halting function main (which is 
isomorphic to DDD) has that exact same pattern and halts.

Thus, by your own rules, you need to remove that false premise, and thus 
you "proof" fails.

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

And who does that?

IT seems, only you, as you think a call HHH instruction can mean 
anything other that showing next the behavior of the first instruction 
of HHH.

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

But programs can only "stop running" for one reason, reaching the final 
state.

Partial simulation might stop for other reasons, but that is why you 
can't use partial simulations by themselves to show 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.
========== REMAINDER OF ARTICLE TRUNCATED ==========