Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: The actual truth is that ... Turing computability issues have
 been addressed --- marathon winner
Date: Wed, 16 Oct 2024 10:54:50 -0500
Organization: A noiseless patient Spider
Lines: 77
Message-ID: <veonka$29dtl$4@dont-email.me>
References: <ve39pb$24k00$1@dont-email.me> <vedibm$4891$2@dont-email.me>
 <72315c1456c399b2121b3fffe90b933be73e39b6@i2pn2.org>
 <vee6s1$7l0f$1@dont-email.me>
 <1180775691cf24be4a082676bc531877147202e3@i2pn2.org>
 <veec23$8jnq$1@dont-email.me>
 <c81fcbf97a35bd428495b0e70f3b54e545e8ae59@i2pn2.org>
 <vef37r$bknp$2@dont-email.me>
 <7e79306e9771378b032e6832548eeef7429888c4@i2pn2.org>
 <veikaf$14fb3$1@dont-email.me> <veipmb$15764$2@dont-email.me>
 <c56fcfcf793d65bebd7d17db4fccafd1b8dea072@i2pn2.org>
 <vejfg0$1879f$3@dont-email.me>
 <bde5947ebdcfb62ecd6e8968052cb3a25c4b1fec@i2pn2.org>
 <vekfi5$1d7rn$1@dont-email.me>
 <6d73c2d966d1d04dcef8f7f9e0c849e17bd73352@i2pn2.org>
 <velnqn$1n3gb$3@dont-email.me>
 <b06c4952248d83881642c7d84207d3d39c56c59f@i2pn2.org>
 <vend90$22rqh$1@dont-email.me>
 <9be1b2bcd63e5888c1bd83b37320c4ad6e79449c@i2pn2.org>
 <veoctg$284qn$2@dont-email.me>
 <abc2dcf00ed5b5684c58c0eb90dbd33615d5f90c@i2pn2.org>
 <veofue$284qn$4@dont-email.me>
 <56d6dc2f898b67941f43673a306f31c7ddd3311d@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 16 Oct 2024 17:54:50 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f097d53e4abea8ea9babea4b430282e3";
	logging-data="2406325"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19bzySlFpDAOu9DTJ32IH0c"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:RJV/6jb9BjlLaJRLO0Xzoe3nPnk=
Content-Language: en-US
In-Reply-To: <56d6dc2f898b67941f43673a306f31c7ddd3311d@i2pn2.org>
Bytes: 5734

On 10/16/2024 9:50 AM, joes wrote:
> Am Wed, 16 Oct 2024 08:43:42 -0500 schrieb olcott:
>> On 10/16/2024 8:10 AM, joes wrote:
>>> Am Wed, 16 Oct 2024 07:52:00 -0500 schrieb olcott:
>>>> On 10/16/2024 1:32 AM, joes wrote:
>>>>> Am Tue, 15 Oct 2024 22:52:00 -0500 schrieb olcott:
>>>>>> On 10/15/2024 9:11 PM, Richard Damon wrote:
>>>>>>> On 10/15/24 8:39 AM, olcott wrote:
>>>>>>>> On 10/15/2024 4:58 AM, joes wrote:
>>>>>>>>> Am Mon, 14 Oct 2024 20:12:37 -0500 schrieb olcott:
>>>>>>>>>> On 10/14/2024 6:50 PM, Richard Damon wrote:
>>>>>>>>>>> On 10/14/24 12:05 PM, olcott wrote:
>>>>>>>>>>>> On 10/14/2024 6:21 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 10/14/24 5:53 AM, olcott wrote:
>>>>>>>>>>>>>> On 10/14/2024 3:21 AM, Mikko wrote:
>>>>>>>>>>>>>>> On 2024-10-13 12:49:01 +0000, Richard Damon said:
>>>>>>>>>>>>>>>> On 10/12/24 8:11 PM, olcott wrote:
>>>>>>>>>
>>>>>>>>>>>> Trying to change to a different analytical framework than the
>>>>>>>>>>>> one that I am stipulating is the strawman deception.
>>>>>>>>>>>> *Essentially an intentional fallacy of equivocation error*
>>>>>>>>>>> But, you claim to be working on that Halting Problem,
>>>>>>>>>> I quit claiming this many messages ago and you didn't bother to
>>>>>>>>>> notice.
>>>>>>>>> Can you please give the date and time? Did you also explicitly
>>>>>>>>> disclaim it or just silently leave it out?
>>>>>>>> Even people of low intelligence that are not trying to be as
>>>>>>>> disagreeable as possible would be able to notice that a specified
>>>>>>>> C function is not a Turing machine.
>>>>>>> But it needs to be computationally equivalent to one to ask about
>>>>>>> Termination.
>>>>>> Not at all. A termination analyzer need not be a Turing computable
>>>>>> function.
>>>>> It definitely does. An uncomputable analyser is useless.
>>>> It is true that a termination analyzer is not required to work
>>>> correctly for all inputs.
>>> But it should work for DDD.
> 
>>>> That there is one way that HHH can consistently catch the
>>>> non-terminating pattern of its input proves that this can be done.
>>> DDD does terminate. Otherwise it would contradict the HP.
>>>
>>>> Mike suggested some different ways that would seem to be Turing
>>>> computable yet too convoluted to be time consuming for me to implement
>>>> in practice.
>>> What are those ways?
> 
>>>> The basic approach involves the idea that every state change of the
>>>> emulations of emulations is data that belongs to the outermost
>>>> directly executed HHH.
>>> Nothing special. They aren't even running on the hardware proper.
>>>
>>>> It is too convoluted for me to provide a way for HHH to look inside
>>>> all of the emulations of emulations and pull out the data that it
>>>> needs, so knowing that this is possible is enough to know that it is
>>>> Turing computable.
>>> It cannot dig into an infinite simulation chain.
>> It need not dig into an infinite emulation chain. It merely needs to see
>> that DDD calls HHH(DDD) twice in sequence having no termination
>> condition within DDD.
> If it sees no termination condition in itself (it's a recursion), being
> the same program, it also doesn't have one, so cannot abort.
> 

HHH is not even being asked that question.

HHH is being asked can DDD emulated by HHH
according to the semantics of the x86 language
(which includes HHH emulating itself emulating DDD)
possibly reach the "return" instruction of DDD?
(The industry standard definition of a terminating C function.



-- 
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer