Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!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:35:02 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <4ac5a1400ece16308c8a19f100e77312b598c3b1@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 6 Sep 2024 02:35:02 -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: <vbcca2$bdtb$4@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
Bytes: 5795
Lines: 132

On 9/5/24 9:39 AM, olcott wrote:
> 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.

No, the CAN NOT be, as a Turing Machine can not have as its input part 
of itself.

It can have a copy of its description given to it, but not a piece of 
itself.

This allows you in your x86 code to do something the Turing Machine can 
not do, and that is compare the "addresss" in the input to itself to 
detect the "self-reference".

Sorry, you just don't know what you are talking about and prove you are 
just a lying idiot.

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

Nope, you just prove that you don't know what you are talking about.

> 
> Once I prove my point as the x86 level I show how the
> same thing applies to the Peter Linz proof.

Nope, first, because you HHH is NOT a "Computation" because it isn't a 
pure function, but uses static memory to relay information (BOTH WAYS) 
and change behavior.

Second, Because of your non-equivalence, you were able to do something 
proved impossible for actual independent computations, and that is to 
accurately detect that the input is using a "copy" of itself.


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

Which is the behavior of the program it represents, and thus needs to 
include ALL the code referenced.

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

But does it incorrectly, because it never completes it.


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

But it does, as you have been told.

You just keep on confusing the behavior of DDD with the behavior of the 
partial emulation of DDD by HHH. They are diffferent, and thus it is an 
error to confuse them.

> When there is a pathological relationship to the decider
> and its input then this behavior must include DDD calling
> HHH to emulated itself again.

Right, which HHH fails to do. HHH must make its decision based on the 
fact that the call to HHH in DDD will do exactly what this HHH decides 
to do.

If this HHH aborts and return, then it must be able to show that if the 
HHH that it is simulating does the same thing, then its answer is correct.

You are just proving you don't know what you are talking about.

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

But it can't and you have accepted that by failing to show the first 
instruction actually correctly emulated by HHH that differed in behavior.

Sorry, you are just proving yourself to be a stupid liar.


> 
>> Your decider is not a halt decider if it answers about another
>> behaviour.
>>
> 
>