Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Mike Terry <news.dead.person.stones@darjeeling.plus.com>
Newsgroups: comp.theory
Subject: Re: Halting Problem: What Constitutes Pathological Input
Date: Wed, 7 May 2025 16:44:12 +0100
Organization: A noiseless patient Spider
Lines: 248
Message-ID: <vvfv4c$13nqj$1@dont-email.me>
References: <GE4SP.47558$VBab.42930@fx08.ams4>
 <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> <vvej0u$g8jo$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 07 May 2025 17:44:13 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d2705041d1026a08b93db71d354a828f";
	logging-data="1171283"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+P4SxgcOgYtMWXhXv6jtu8gnjh2JjIznM="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.18.2
Cancel-Lock: sha1:7vI/+JzdaANPeTXdh86iOzKeL68=
In-Reply-To: <vvej0u$g8jo$1@dont-email.me>

On 07/05/2025 04:11, olcott wrote:
> 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*

You need to read what posters actually say.  I said the traces were the same up to the point where 
HHH stops simulating.  I didn't say anything about calls that return or do not return "being the 
same thing" and none of what you relates to whether what I said was correct.

Look, if you insist the traces are not the same up to the point where HHH stops simulating, show the 
two traces and we'll just look and see!  Simples.

At this point, no need to be too formal, just a high level trace, e.g. referencing C code rather 
than instruction addresses...

> 
>>> 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.

Nonsense.  He is taking it as read that the input is not changed.  What he agreed was that the 
actual HHH can base its decision on the hypothetical HHH that never aborts its simulation, running 
against *identical input* DD.  Identical means has identical behaviour to original DD, in particular 
it calls original HHH, not some modified HHH or UTM.

Of course, Sipser would not understand how you have mangled the design of your utmx86 environment. 
He would naturally take it that you were correctly implementing basic features of the TM halting 
problem, like the input data being totally distinct from the TM state table.  So it would simply 
never occur to him that in your world, changing the code of HHH would have any effect on the data 
input DD, which explains why he does not explicitly mention that.

> 
> *would never stop running unless aborted*
> *would never stop running unless aborted*
> *would never stop running unless aborted*
yawn

> 
>> 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.

You are quite incapable of understanding what Sipser was agreeing to.  More generally you have a 
problem understanding what other people believe and what they are communicating to you.  I've 
suggested you have some neural wiring issue, and for sure this would be tied in to that somehow.

Regardless of that, you are trying to use Sipser's quote as an appeal to authority, which you 
understand is a fallacy but think its ok to do it anyway.  [Even though you are quick to accuse 
other people of doing that when it suits you.]

Just stop mentioning Sipser's quote altogether!  It is not helping your case in any shape or form.

> 
>> 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.
>>>>
>>>
========== REMAINDER OF ARTICLE TRUNCATED ==========