Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: Halting Problem: What Constitutes Pathological Input
Date: Tue, 6 May 2025 22:11:25 -0500
Organization: A noiseless patient Spider
Lines: 190
Message-ID: <vvej0u$g8jo$1@dont-email.me>
References: <GE4SP.47558$VBab.42930@fx08.ams4> <vvan7q$o4v0$1@dont-email.me>
 <ts5SP.113145$_Npd.41800@fx01.ams4> <vvat0g$vtiu$1@dont-email.me>
 <vvatf3$o4v0$3@dont-email.me> <vvaut0$vtiu$4@dont-email.me>
 <vvav6o$o4v0$4@dont-email.me> <vvb329$15u5b$1@dont-email.me>
 <vvb37g$1451r$1@dont-email.me> <vvb43f$15u5b$4@dont-email.me>
 <vvb4ok$o4v0$9@dont-email.me> <vvb52g$15u5b$6@dont-email.me>
 <vvb5ca$o4v0$10@dont-email.me> <vvb5vp$15u5b$7@dont-email.me>
 <vvb675$o4v0$11@dont-email.me> <vvb9d7$1av94$3@dont-email.me>
 <vvbani$1b6l1$1@dont-email.me> <vvbb6s$1av94$4@dont-email.me>
 <vvbcb3$1b6l1$2@dont-email.me> <vvbe0j$1av94$8@dont-email.me>
 <vvbecc$1b6l1$6@dont-email.me> <vvbhk0$1ijna$1@dont-email.me>
 <vvc7t9$29pp8$1@dont-email.me> <vvc86c$2a4cs$1@dont-email.me>
 <vvcufi$2sk4a$3@dont-email.me> <vvdlff$3i09b$2@dont-email.me>
 <vvdo96$3lapa$1@dont-email.me> <vvdr87$3n3t4$1@dont-email.me>
 <vve3mf$3vva3$1@dont-email.me> <vve4ut$f5c$1@dont-email.me>
 <vvehuu$g8eg$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 07 May 2025 05:11:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ee5137430f56269cd3e6381ddf24cf46";
	logging-data="533112"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+0WbOhYvjPqBXgSZg8DuGT"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:wSaqr1H6Q09TLJbMf4tf3nH3qCA=
In-Reply-To: <vvehuu$g8eg$1@dont-email.me>
X-Antivirus-Status: Clean
Content-Language: en-US
X-Antivirus: Norton (VPS 250506-6, 5/6/2025), Outbound message
Bytes: 8904

On 5/6/2025 9:53 PM, Mike Terry wrote:
> On 07/05/2025 00:11, olcott wrote:
>> On 5/6/2025 5:49 PM, Mike Terry wrote:
>>> On 06/05/2025 21:25, olcott wrote:
>>>> On 5/6/2025 2:35 PM, dbush wrote:
>>>>> On 5/6/2025 2:47 PM, olcott wrote:
>>>>>> On 5/6/2025 7:14 AM, dbush wrote:
>>>>>>> On 5/6/2025 1:54 AM, olcott wrote:
>>>>>>>> On 5/6/2025 12:49 AM, Richard Heathfield wrote:
>>>>>>>>> On 06/05/2025 00:29, olcott wrote:
>>>>>>>>>
>>>>>>>>> <snip>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It is the problem incorrect specification that creates
>>>>>>>>>> the contradiction.
>>>>>>>>>
>>>>>>>>> Not at all. The contradiction arises from the fact that it is 
>>>>>>>>> not possible to construct a universal decider.
>>>>>>>>>
>>>>>>>>>> Everyone here insists that functions computed
>>>>>>>>>> by models of computation can ignore inputs and
>>>>>>>>>> base their output on something else.
>>>>>>>>>
>>>>>>>>> I don't think anyone's saying that.
>>>>>>>>>
>>>>>>>>> Maybe you don't read so well.
>>>>>>>>>
>>>>>>>>
>>>>>>>> What are the exact steps for DD to be emulated by HHH
>>>>>>>> according to the semantics of the x86 language?
>>>>>>>> *Only an execution trace will do*
>>>>>>>
>>>>>>> The exact same steps for DD to be emulated by UTM.
>>>>>>>
>>>>>>
>>>>>> _DD()
>>>>>> [00002133] 55         push ebp      ; housekeeping
>>>>>> [00002134] 8bec       mov ebp,esp   ; housekeeping
>>>>>> [00002136] 51         push ecx      ; make space for local
>>>>>> [00002137] 6833210000 push 00002133 ; push DD
>>>>>> [0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
>>>>>> [00002141] 83c404     add esp,+04
>>>>>> [00002144] 8945fc     mov [ebp-04],eax
>>>>>> [00002147] 837dfc00   cmp dword [ebp-04],+00
>>>>>> [0000214b] 7402       jz 0000214f
>>>>>> [0000214d] ebfe       jmp 0000214d
>>>>>> [0000214f] 8b45fc     mov eax,[ebp-04]
>>>>>> [00002152] 8be5       mov esp,ebp
>>>>>> [00002154] 5d         pop ebp
>>>>>> [00002155] c3         ret
>>>>>> Size in bytes:(0035) [00002155]
>>>>>>
>>>>>> Machine address by machine address specifics
>>>>>> that you know that you cannot provide because
>>>>>> you know that you are wrong.
>>>>>>
>>>>>
>>>>> HHH and UTM emulate DD exactly the same up until the point that HHH 
>>>>> aborts, 
>>>>
>>>> When you trace through the actual steps you
>>>> will see that this is counter-factual.
>>>
>>> No, it is exactly right.  Remember, I posted a comparison of the two 
>>> traces side by side some time ago, and they were indeed IDENTICAL 
>>> line for line up to the point where HHH decided to discontinue 
>>> simulating. 
>>
>> That is counter-factual.
> 
> Dude!  :/  I posted the comparison and the traces were the same up to 
> the point where HHH discontinued the simulation.  How can it be 
> "counter-factual"?
> 

HHH1(DD) the call from DD to HHH(DD) returns.
HHH(DD) the call from DD to HHH(DD) cannot possibly return.

A call that returns and a call that cannot possibly
return *are not exactly the same thing*

>> HHH1(DD) the call from DD to HHH(DD) returns.
>> HHH(DD) the call from DD to HHH(DD) cannot possibly return.
>>
>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>      If simulating halt decider H correctly simulates its
>>      input D until H correctly determines that its simulated D
>>      *would never stop running unless aborted* then
>>
>>      *input D* refers to the actual HHH/DD pair
> 
> ..which is not to be changed during hypothetical modifications to H
>>
>>      *would never stop running unless aborted*
>>       refers to the hypothetical HHH/DD pair where
>>       HHH and DDD are exactly the same except that
>>       this hypothetical HHH does not abort the
>>       simulation of its input.
> 
> No, that doesn't work in your x86utm because you mix up code (HHH) and 
> data (DD, which directly calls HHH).  DD must be "exactly the same" / 
> including all its subroutines/, 

Not at all. Professor Sipser agreed that the actual
HHH/DD must base its decision on the hypothetical
HHH/DD that never aborts its simulation.

*would never stop running unless aborted*
*would never stop running unless aborted*
*would never stop running unless aborted*

> but DD calls HHH so HHH must be exactly 
> the same, otherwise the input has been changed which is NOT ALLOWED.
> 

Intuitively it would seem that way until you examine
every single detail 100% completely.

> To make this work you have to create a /new/ "HHH that does not abort 
> the simulation".  

Professor Sipser already agreed that the actual HHH/DD
must base its decision on the hypothetical HHH/DD
that never aborts.

> E.g. clone HHH to HHH_hypothetical then take out the 
> abort logic from HHH_hypothetical.  From main() call 
> HHH_hypothetical(DD).  That way DD is unchanged as required.
> 
>>
>>> The trace by UTM continued further, with DD returning some time later.
>>>
>>
>> The above HHH1(DD) is this UTM.
> 
> HHH1 will serve in this case, since it happens to not abort due to your 
> coding errors. 

It does not happen to not abort due to coding
errors. That is a reckless disregard for the truth.
The code has specified exactly why it need not
abort for several years now.

>  It would be cleaner to make a function UTM() which just 
> has the DebugStep loop and no abort logic.
> 

Professor Sipser already agreed that the actual HHH/DD
must base its decision on the hypothetical HHH/DD
that never aborts, AKA your UTM.

> So... are you saying that HHH has seen enough of the simulation to 
> correctly determined that HHH1(DD) never returns?  That would be 
> bizarre, since you know HHH1(DD) /does/ return.
> 

Functions computed by models of computation must
apply the steps of an algorithm *to the input*
to derive the outputs.

HHH has seen enough of the execution trace of DD
========== REMAINDER OF ARTICLE TRUNCATED ==========