| Deutsch English Français Italiano |
|
<105394s$3ev5b$15@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: How do simulating termination analyzers work? ---Truth Maker
Maximalism FULL_TRACE
Date: Mon, 14 Jul 2025 10:53:00 -0500
Organization: A noiseless patient Spider
Lines: 104
Message-ID: <105394s$3ev5b$15@dont-email.me>
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>
<a6849743e4a6af25dc93b3b269e1d39002488efe@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 14 Jul 2025 17:53:01 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e10498e6bc9f284a7eed933d9123bd8c";
logging-data="3636395"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19gCkTLMGNuJN/xjfIsXLPi"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:0OCKRNMut7YYI1KdmQIYJhaTi0U=
X-Antivirus: Norton (VPS 250714-2, 7/14/2025), Outbound message
X-Antivirus-Status: Clean
In-Reply-To: <a6849743e4a6af25dc93b3b269e1d39002488efe@i2pn2.org>
Content-Language: en-US
On 7/14/2025 6:37 AM, Richard Damon wrote:
> 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,
Reaching a final halt state <is> the definition of halting.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer