Path: 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: Sun, 6 Jul 2025 14:14:18 -0500
Organization: A noiseless patient Spider
Lines: 347
Message-ID: <104ehua$2c91h$1@dont-email.me>
References: <102sjg5$2k3e9$1@dont-email.me> <1042l0e$3cik5$1@dont-email.me>
 <1046v71$ctak$1@dont-email.me> <1047vld$n4s2$1@dont-email.me>
 <1048hp0$qd4f$2@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 06 Jul 2025 21:14:19 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1d15e621694ba385b5c4999100d2724d";
	logging-data="2499633"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+rgIjKuxScy3EwcfTTcp3V"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:z6hIktzeu5jUR2kXIpKWa5yxMVY=
Content-Language: en-US
X-Antivirus-Status: Clean
In-Reply-To: <104ed4k$223c$1@news.muc.de>
X-Antivirus: Norton (VPS 250706-4, 7/6/2025), Outbound message

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:
>>> [ Followup-To: set ]
> 
>>> In comp.theory olcott <polcott333@gmail.com> wrote:
>>>> On 7/6/2025 5:16 AM, Alan Mackenzie wrote:
>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>> On 7/5/2025 2:07 PM, Alan Mackenzie wrote:
> 
> [ .... ]
> 
>>> That's what I'm saying.  Those proofs of the halting theorem are free
>>> from mistakes.
> 
>>> More to the point, it is YOU who cannot point to any mistakes in them.
> 
> [ .... ]
> 
>>> They are valid proofs.  Your work, if it contradicts those proofs (which
>>> isn't at all clear) can thus be dismissed without further consideration.
> 
> 
>> The is the ad ignorantiam error.
>> https://en.wikipedia.org/wiki/Argument_from_ignorance
>> Atheists have made that their doctrine.
> 
> Garbage!  I say again, if your proposition contradicts a known truth,
> then it is necessarily false, and can be discarded.
> 

There is a subtle difference between your original
statement and this one. Known truths are not exactly
the same thing as the result of a proof unless the
proof is inherently infallible.

> [ .... ]
> 
>>>>>> Turing machine partial halt deciders compute the mapping
>>>>>> from their actual inputs to the actual behavior that these
>>>>>> inputs specify.
> 
>>>>> And a fourth.  There's some semblance of truth in there, but it's very
>>>>> confused.
> 
> 
>>>> It is not at all confused. I know exactly what it means.
> 
>>> It's very confused to everybody but you, then.
> 
>>>>> Sloppy wording is your technique to get people to go down to your level
>>>>> of discussion.  That involves many posts trying just to tie you down to
>>>>> specific word meanings, and is very tiresome and unrewarding.  I decline
>>>>> to get involved any further.
> 
> 
>>>> *Yet as I claimed you found no actual mistake*
> 
>>> I've found plenty of actual mistakes.  I was a software developer by
>>> profession.
> 
> 
>> 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.

That DD exactly matches the pattern of the halting
problem proof inputs is also a verified fact.

Thus HHH(DD) does correctly determine that the halting
problem's counter-example input *DOES NOT HALT*
That you say this is "valueless" seems quite disingenuous.

>  But analysing it a bit further, it is not clear exactly what
> you mean by "simulated by HHH". 

Do you have any idea what "simulation" means?

_DD()
[00002162] 55             push ebp
[00002163] 8bec           mov ebp,esp
[00002165] 51             push ecx
[00002166] 6862210000     push 00002162
[0000216b] e862f4ffff     call 000015d2
[00002170] 83c404         add esp,+04
[00002173] 8945fc         mov [ebp-04],eax
[00002176] 837dfc00       cmp dword [ebp-04],+00
[0000217a] 7402           jz 0000217e
[0000217c] ebfe           jmp 0000217c
[0000217e] 8b45fc         mov eax,[ebp-04]
[00002181] 8be5           mov esp,ebp
[00002183] 5d             pop ebp
[00002184] c3             ret
Size in bytes:(0035) [00002184]

DD emulated by HHH according tot eh semantics of the x86
language cannot possibly reach its own "ret" instruction
is as concrete as I can get. This might not make sense if
you have no idea what an x86 emulator is.

> It's quite clear that DD will reach its
> return statement if HHH(DD) returns 0.
> 

So you can't see the recursive emulation non-halting
behavior pattern? DO you know what recursion is?

>>>> Let me tell you the punchline so that you can
>>>> see why I said those things.
> 
>>> Despite what I said last post, I will actually go to the trouble of
>>> analysing your sloppy expression.
> 
>>>> Because directly executed Turing machines cannot
>>>> possibly be inputs to Turing machine deciders this
>>>> makes them outside of the domain of these deciders.
> 
>>> It's entirely unclear what a "directly executed Turing machine" is.  Most
>>> of the time turing machines are theoretical constructs used for proving
>>> theorems.  They can be executed, but rarely are.
> 
> No reply to this?  Do you agree with me that "directly executed turning
> machine" is not a coherent notion?
> 
>> typedef void (*ptr)();
>> int HHH(ptr P);
> 
>> void DDD()
>> {
>>    HHH(DDD);
>>    return;
>> }
> 
>> int main()
>> {
>>    HHH(DDD);  // DDD finite string of x86 code emulated by HHH
>>    DDD();     // DDD directly executed
>> }
> 
>>> It's unclear what you mean by a turing machine being an input to a turing
>>> machine.  Read up about universal turing machines to get a bit of
>>> background.
> 
> 
>> The directly executed DDD() is not an input to HHH.
> 
> Vague word salad again.
> 
>> We have the exact same thing in the Linz proof.
> 
> You do not.  There is no concept of "directly executed" in turing
> machines, and Linz's proof concerns turing machines.  Other people here
========== REMAINDER OF ARTICLE TRUNCATED ==========