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
Subject: Re: My reviewers think that halt deciders must report on the behavior
 of their caller
Date: Wed, 9 Jul 2025 07:44:33 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <6e8be9ed51dfe82150849a119c5f6433bf7e2082@i2pn2.org>
References: <101nq32$99vd$1@dont-email.me> <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>
 <104h475$324da$1@dont-email.me>
 <a5f81886d091790185fb6434782dba91ad075fa5@i2pn2.org>
 <104hmkm$35gkb$2@dont-email.me>
 <f4f7163b6a6afcf9886f9d72d5b06075c0592338@i2pn2.org>
 <104i0ar$36mma$1@dont-email.me>
 <775a1f21c8d308989a8ef2a0afaae66c1609912b@i2pn2.org>
 <104jc8l$3jrpl$9@dont-email.me>
 <b8e7a597f05663513a7b08172a8f2f66a696e358@i2pn2.org>
 <104jpu7$3np76$1@dont-email.me> <104jsnj$3o6as$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 9 Jul 2025 12:00:53 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="4037452"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <104jsnj$3o6as$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0

On 7/8/25 3:49 PM, olcott wrote:
> On 7/8/2025 2:01 PM, Mike Terry wrote:
>> On 08/07/2025 17:07, joes wrote:
>>> Am Tue, 08 Jul 2025 10:08:05 -0500 schrieb olcott:
>>>> On 7/8/2025 6:13 AM, Richard Damon wrote:
>>>>> On 7/7/25 10:38 PM, olcott wrote:
>>>>>> On 7/7/2025 9:18 PM, Richard Damon wrote:
>>>>>>> On 7/7/25 7:52 PM, olcott wrote:
>>>>>>>> On 7/7/2025 5:41 PM, Richard Damon wrote:
>>>>>>>>> On 7/7/25 2:38 PM, olcott wrote:
>>>>>>>>>> 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:
>>>
>>>>>>>>>>>>>>> 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.
>>> Ah, but your HHH does report on a *hypothetical* input that wouldn't
>>> call the aborting simulator HHH, but instead a *different* (possibly
>>> similar) simulator that would *not* abort.
>>>
>>>>>>>>>>> And HHH does not do that. The input specifies a halting program,
>>>>>>>>>>> because it includes the abort code. But HHH gives up before it
>>>>>>>>>>> reaches that part of the specification and the final halt state.
>>>>>>>>>>
>>>>>>>>>> I have corrected you on this too many times.
>>>>>>>>>> You have sufficiently proven that you are dishonest or
>>>>>>>>>> incompetent.
>>>>>>>>>> *This code proves that you are wrong*
>>>>>>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c That you
>>>>>>>>>> are too F-ing stupid to see this is less than no rebuttal at all.
>>>>>>>>>>
>>>>>>>>> No, that code proves that HHH, as defined, always aborts its
>>>>>>>>> simulation of DDD and returns 0,
>>>>>>>> That is counter-factual and you would know this if you had good C++
>>>>>>>> skills.
>>>>>>>>
>>>>>>> How is it "Counter-Factual"?
>>>>>>> It is YOU that is just counter-factual.
>>>>>>>
>>>>>> "No, that code proves that HHH, as defined,
>>>>>>    always aborts its simulation of DDD"
>>>>>> That is a false statement. If you understood the code you would know
>>>>>> your error.
>>>>>>
>>>>> Really, so how does that code NOT aboft its simulation of DDD?
>>>>
>>>> You have a reading comprehension problem.
>>>> When critique words you are strictly not allowed to change even a 
>>>> single
>>>> word without being dishonest.
>>>> "No, that code proves that HHH as defined
>>>>      always aborts its simulation of DDD"
>>>> If you can't figure how how that is false we have conclusively proved
>>>> your lack of sufficient technical competence.
>>> Wow. Can't you just answer the question? Also, "we" and "proved"? Not
>>> being understood isn't very convincing. So how does HHH not abort?
>>
>> This is one of PO's practiced tactics - he makes a claim, and 
>> regardless of how patently false that claim appears, he refuses to 
>> logically defend the claim beyond saying "the claim is true, and if 
>> you understood xxx you would realise it is true".
>>
> 
> All of my claims are easily verified facts to those
> with the capacity to verify them.
> 
> 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]

Not a program, must include the code for HHH to be simulatable.

> 
> I am utterly shocked that you can't understand
> that DDD emulated by HHH according to the semantics
> of the x86 language cannot possibly reach past
> it own machine address [0000219a].

But that DDD Can't be simulated by HHH without including the code that 
you refuse to accept is part of the input.

After all, the DEFINITION of the call instruction includes that the 
instruciton at the target address WILL be executed next.

Since it isn't part of "DDD" by your definition, HHH can't "Simulated 
DDD" and access something that isn't part of it,

> 
> To me that is like an auto mechanic that has no
> idea what a spark plug is or an MD that has no
> idea what an infection is.

So, why don't YOU understand that the code for HHH needs to be part of 
"the input" for HHH (and HHH1) to use it?

> 
> Several of my reviewers simply "don't believe"
> that HHH does simulate itself simulating DDD
> even after I conclusively prove it by this
> full execution trace.
> 
> https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
> 
> 

But that listing shows that HHH is part of the input, which you refuse 
to accepts.

If HHH is part of the input, then HHH thinking that the HHH that DDD 
calls does something other than what that HHH actuall does is just an error.

DDD doesn't call an HHH that doesn't abort, it calls the HHH that DOES 
abort and return 0, and thus the ONLY correct simulation of the call to 
HHH(DDD) must show that it will eventually return 0, or that simulation 
is just incorrect.

It seems you are a "logician" that doesn't understand what Truth means, 
or what it means to PROVE something.

Sorry, you really are showing that you are that stupid.