Path: ...!weretis.net!feeder8.news.weretis.net!news.neodome.net!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Defining a correct halt decider
Date: Thu, 5 Sep 2024 22:34:59 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <df484330e3ce2fed1a90c8d0e8caf40987a14c66@i2pn2.org>
References: <vb4npj$1kg8k$1@dont-email.me> <vb6i8p$39fhi$1@dont-email.me>
 <vb72a4$3b4ub$6@dont-email.me> <vbbn7t$8ocm$1@dont-email.me>
 <vbcca2$bdtb$4@dont-email.me>
 <8507e212d2f5266e04f07d0bc87d0c6a0b47ca67@i2pn2.org>
 <vbcfvd$ce62$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 6 Sep 2024 02:35:00 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="993900"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <vbcfvd$ce62$1@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5359
Lines: 95

On 9/5/24 10:41 AM, olcott wrote:
> On 9/5/2024 9:27 AM, joes wrote:
>> Am Thu, 05 Sep 2024 08:39:14 -0500 schrieb olcott:
>>> On 9/5/2024 2:39 AM, Mikko wrote:
>>>> On 2024-09-03 13:17:56 +0000, olcott said:
>>>>> On 9/3/2024 3:44 AM, Mikko wrote:
>>>>>> On 2024-09-02 16:06:11 +0000, olcott said:
>>>>>>
>>>>>>> A correct halt decider is a Turing machine T with one accept state
>>>>>>> and one reject state such that:
>>>>>>> If T is executed with initial tape contents equal to an encoding of
>>>>>>> Turing machine X and its initial tape contents Y, and execution of a
>>>>>>> real machine X with initial tape contents Y eventually halts, the
>>>>>>> execution of T eventually ends up in the accept state and then
>>>>>>> stops.
>>>>>>> If T is executed with initial tape contents equal to an encoding of
>>>>>>> Turing machine X and its initial tape contents Y, and execution of a
>>>>>>> real machine X with initial tape contents Y does not eventually
>>>>>>> halt, the execution of T eventually ends up in the reject state and
>>>>>>> then stops.
>>>>>>
>>>>>> Your "definition" fails to specify "encoding". There is no standard
>>>>>> encoding of Turing machines and tape contents.
>>>>>
>>>>> That is why I made the isomorphic x86utm system.
>>>>> By failing to have such a concrete system all kinds of false
>>>>> assumptions cannot be refuted.
>>>> If it were isnomorphic the same false assumtipns would apply to both.
>>>
>>> They do yet I cannot provide every single details of the source-code of
>>> the Turing machine because these details would be too overwhelming.
>>
>>> So instead every author makes a false assumption that is simply believed
>>> to be true with no sufficient basis to show that it isn't true.
>> What is that assumption?
>>
>>>>> The behavior of DDD emulated by HHH** <is> different than the behavior
>>>>> of the directly executed DDD** **according to the semantics of the x86
>>>>> language
>>>> The halting problem is not about a string but about a behaviour.
>>>
>>> Is is about the behavior that this string specifies.
>> Namely, that DDD halts.
>>
>>> HHH computes the mapping from its input finite string to the behavior
>>> that this finite string specifies on the basis of DDD emulated by HHH.
>> The wrinkle being that it is selfreferential. We are only interested
>> in the case where the DDD that calls an aborting HHH is simulated
>> by that same HHH.
>>
>>> DDD emulated by HHH cannot possibly reach its final halt state and on
>>> this basis alone HHH is correct to reject DDD and report non-halting.
>> HHH cannot simulate something that calls itself; yet it halts.
>>
>>> That no one bothered to notice that the behavior of an input DDD to a
>>> simulating termination analyzer HHH can be different than the behavior
>>> of a directly executed DDD when there is a pathological relationship
>>> between HHH and DDD IS NOT MY MISTAKE.
>> That is exactly your mistake, that you believe the simulation of a
>> different program somehow has the same behaviour.
> 
> DDD emulated by HHH never reaches it final halt state.
> It looks like I have to repeat this 10,000 times before
> anyone ever notices that I said it at least once.

But it does, as was shown.

You keep repeating your *LIE* because you refuse to even try to point 
out an error in the correction to your claim.

> 
> _DDD()
> [00002172] 55         push ebp      ; housekeeping
> [00002173] 8bec       mov ebp,esp   ; housekeeping
> [00002175] 6872210000 push 00002172 ; push DDD
> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
> [0000217f] 83c404     add esp,+04
> [00002182] 5d         pop ebp
> [00002183] c3         ret
> Size in bytes:(0018) [00002183]
> 
> Show the details of how DDD emulated by HHH
> reaches its own machine address 0000217f.
> 
> 00002172, 00002173, 00002175, 0000217a calls HHH(DDD)
> then

goes to 000015d2, so you are just lying.

> 00002172, 00002173, 00002175, 0000217a calls HHH(DDD)...
> 
> 

The full trace can be derived from your 200 page trace, replacing the 
code of main at the beginning and the end with the identical code in DDD.