Path: nntp.eternal-september.org!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: How do simulating termination analyzers work? ---Truth Maker
 Maximalism FULL_TRACE
Date: Mon, 14 Jul 2025 07:37:55 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <a6849743e4a6af25dc93b3b269e1d39002488efe@i2pn2.org>
References: <102sjg5$2k3e9$1@dont-email.me>
 <66c00d5703907e846f537310dfb201485e1b7b2a@i2pn2.org>
 <10492eb$u8g5$1@dont-email.me> <104b5l9$fnl$1@news.muc.de>
 <104ben3$1hqln$1@dont-email.me> <104bt5h$1l1g$1@news.muc.de>
 <104bunk$1kcb5$1@dont-email.me> <104did7$hlh$1@news.muc.de>
 <104e164$2852a$1@dont-email.me> <104e6nd$12ua$1@news.muc.de>
 <104e93k$29rpg$1@dont-email.me> <104ed4k$223c$1@news.muc.de>
 <104ehua$2c91h$1@dont-email.me> <104epfu$nqi$1@news.muc.de>
 <104fdma$2n8gq$1@dont-email.me> <104gkad$2f8e$1@news.muc.de>
 <10515pj$2v547$1@dont-email.me>
 <c1fa8b9a19b4a102d7f5c2d58cf4b9b127c30955@i2pn2.org>
 <1051r18$36s16$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 14 Jul 2025 11:48:07 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="580302"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <1051r18$36s16$3@dont-email.me>

On 7/13/25 10:46 PM, olcott wrote:
> On 7/13/2025 8:33 PM, Richard Damon wrote:
>> On 7/13/25 4:43 PM, olcott wrote:
>>> On 7/7/2025 9:07 AM, Alan Mackenzie wrote:
>>>> olcott <polcott333@gmail.com> wrote:
>>>>> On 7/6/2025 4:23 PM, Alan Mackenzie wrote:
>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>> On 7/6/2025 12:52 PM, Alan Mackenzie wrote:
>>>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>>>> On 7/6/2025 11:02 AM, Alan Mackenzie wrote:
>>>>
>>>>>> [ .... ]
>>>>
>>>>>>>>> int DD()
>>>>>>>>> {
>>>>>>>>>      int Halt_Status = HHH(DD);
>>>>>>>>>      if (Halt_Status)
>>>>>>>>>        HERE: goto HERE;
>>>>>>>>>      return Halt_Status;
>>>>>>>>> }
>>>>
>>>>>>>>> Then you should know that DD simulated by HHH
>>>>>>>>> according to the semantics of the C programming
>>>>>>>>> language cannot possibly reach its own "return"
>>>>>>>>> statement final halt state.
>>>>
>>>>>>>> An argument like this is at such a low level of abstraction as 
>>>>>>>> to be near
>>>>>>>> valuless.
>>>>
>>>>>>> It is really weird that you are calling a 100% complete
>>>>>>> concrete specification "a low level of abstraction".
>>>>>>> That HHH(DD) correctly determines that DD simulated by
>>>>>>> HHH cannot possibly halt is a proven fact.
>>>>
>>>>>> A complete concrete specification would necessarily include a 
>>>>>> description
>>>>>> of what you mean by "simulation".
>>>>
>>>>> I specifically mean that this x86 machine code
>>>> [ .... ]
>>>>> Is emulated by an x86 emulator named HHH.
>>>>
>>>> That's no adequate description.  To make it so, you'd have to say what
>>>> you mean by an "x86 emulator".  The name you give it is irrelevant
>>>>
>>>>>>   But my point was that rather than
>>>>>> sticking to the abstract nature of the proof, you're chipping tiny 
>>>>>> pieces
>>>>>> out of it and dealing with those.  The proof you claim to refute 
>>>>>> has no
>>>>>> notion of simulation, for example; it doesn't need it.
>>>>
>>>>
>>>>> *Not at all there are two pieces*
>>>>> (1) HHH(DD) does correctly determine that its input
>>>>>      specifies non halting behavior.
>>>>> (2) The directly executed DD() does not contradict this.
>>>>
>>>> The word "correctly" is fully redundant there.
>>>>
>>>> The proof does not state whether the constructed function returns 
>>>> true or
>>>> false, i.e. whether it specifies non halting behaviour. 
>>>
>>> The proof is purported to prove THAT DD is an undecidable
>>> input for HHH. This is its counter example refuting the
>>> claim that a universal halt decider can exist.
>>>
>>>
>>>
>>
>> But since your DD by your own admission is a category error for a halt 
>> decider, as you have specifically stated it isn't a program as the 
>> input doesn't include the code of the specific HHH that it calls, you 
>> proof is just invalid.
>>
>> Sorry, all you proved is that you don't know what you are talking about.
> 
> That you keep trying to get away with refuting
> this easily verified fact says a about about you
> 
> _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]
> 
> When one or more instructions of DDD are emulated
> according to the semantics of the x86 language by
> some HHH, no DDD ever reaches its "ret" instruction.
> 

Which isn't the definition of Non-Halting, thus proving you are just a 
liar using a strawman.

Non-Halting is a property of the PROGRAM itself, whicn means you need to 
start with a PROGRAM, which means that it DOES include the SPECIFIC HHH 
that it calls.

If that HHH returns the answer 0, as you claim is correct for it to do, 
then DDD will halt when run, and thus your HHH is proved wrong, and you 
proved to have lied.

If that HHH doesn't return the answer 0 as you claim would be correct, 
then you are just admitting that your HHH doesn't return the correct 
answer, and thus you admit you lied when you said it did,

Either way, you are proved to have lied, by the use of a strawman.

Sorry, all you have done is sunk your reputation in that lake of fire 
reserved for liars.