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: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Sat, 10 May 2025 13:47:36 -0500
Organization: A noiseless patient Spider
Lines: 146
Message-ID: <vvo709$3m1oc$1@dont-email.me>
References: <vv97ft$3fg66$1@dont-email.me> <vvj2j6$23gk7$1@dont-email.me>
 <as9TP.251456$lZjd.93653@fx05.ams4> <87msbmeo3b.fsf@nosuchdomain.example.com>
 <vvjcge$27753$2@dont-email.me> <vvjeqf$28555$1@dont-email.me>
 <vvjffg$28g5i$1@dont-email.me> <875xiaejzg.fsf@nosuchdomain.example.com>
 <vvjgt1$28g5i$5@dont-email.me> <87jz6qczja.fsf@nosuchdomain.example.com>
 <vvjotc$28g5i$12@dont-email.me>
 <vvnh9u$3hd96$1@raubtier-asyl.eternal-september.org>
 <vvno4e$3in62$2@dont-email.me>
 <5b14da4260c0b7e3235ce05f752c092fade4d70e.camel@gmail.com>
 <vvnsae$3in62$9@dont-email.me>
 <11cc09876004107c47467b9481f614f45f450f2c.camel@gmail.com>
 <vvnu9k$3k258$2@dont-email.me>
 <674a661e498281cca55b322cbd5905a1988a6171.camel@gmail.com>
 <vvnvut$3kher$3@dont-email.me>
 <088556c03067d8de7184bf88dd01cc6b8c99ba1b.camel@gmail.com>
 <vvo1ni$3l14p$1@dont-email.me>
 <c09f468e8485c22150cedb12a9010b401f292054.camel@gmail.com>
 <vvo58a$3lnkd$1@dont-email.me>
 <dc76ef3215a83481dfddc40c466bb9ebc0e77341.camel@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 10 May 2025 20:47:37 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7be348abb5bc2ec0a70724586a3ca680";
	logging-data="3868428"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19WBtUINUdjWN4p/2MCNyWL"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:LdazlqxuThwn97eF1qBFM8sTTMQ=
In-Reply-To: <dc76ef3215a83481dfddc40c466bb9ebc0e77341.camel@gmail.com>
X-Antivirus-Status: Clean
X-Antivirus: Norton (VPS 250510-4, 5/10/2025), Outbound message
Content-Language: en-US
Bytes: 8106

On 5/10/2025 1:37 PM, wij wrote:
> On Sat, 2025-05-10 at 13:17 -0500, olcott wrote:
>> On 5/10/2025 1:09 PM, wij wrote:
>>> On Sat, 2025-05-10 at 12:17 -0500, olcott wrote:
>>>> On 5/10/2025 12:01 PM, wij wrote:
>>>>> On Sat, 2025-05-10 at 11:47 -0500, olcott wrote:
>>>>>> On 5/10/2025 11:29 AM, wij wrote:
>>>>>>> On Sat, 2025-05-10 at 11:19 -0500, olcott wrote:
>>>>>>>> On 5/10/2025 11:06 AM, wij wrote:
>>>>>>>>> On Sat, 2025-05-10 at 10:45 -0500, olcott wrote:
>>>>>>>>>> On 5/10/2025 10:28 AM, wij wrote:
>>>>>>>>>>> On Sat, 2025-05-10 at 09:33 -0500, olcott wrote:
>>>>>>>>>>>> On 5/10/2025 7:37 AM, Bonita Montero wrote:
>>>>>>>>>>>>> Am 09.05.2025 um 04:22 schrieb olcott:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Look at their replies to this post.
>>>>>>>>>>>>>> Not a one of them will agree that
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void DDD()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>          HHH(DDD);
>>>>>>>>>>>>>>          return; // final halt state
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When 1 or more instructions of DDD are correctly
>>>>>>>>>>>>>> simulated by HHH then the correctly simulated DDD cannot
>>>>>>>>>>>>>> possibly reach its "return" instruction (final halt state).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> They have consistently disagreed with this
>>>>>>>>>>>>>> simple point for three years.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I guess that not even a professor of theoretical computer
>>>>>>>>>>>>> science would spend years working on so few lines of code.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I created a whole x86utm operating system.
>>>>>>>>>>>> It correctly determines that the halting problem's
>>>>>>>>>>>> otherwise "impossible" input is actually non halting.
>>>>>>>>>>>>
>>>>>>>>>>>> int DD()
>>>>>>>>>>>> {
>>>>>>>>>>>>          int Halt_Status = HHH(DD);
>>>>>>>>>>>>          if (Halt_Status)
>>>>>>>>>>>>            HERE: goto HERE;
>>>>>>>>>>>>          return Halt_Status;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/plolcott/x86utm
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Nope.
>>>>>>>>>>>       From I know HHH(DD) decides whether the input DD is "impossible" input or
>>>>>>>>>>> not.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> DD has the standard form of the "impossible" input.
>>>>>>>>>> HHH merely rejects it as non-halting.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You said 'merely' rejects it as non-halting.
>>>>>>>>> So, POOH do not answer the input of any other function?
>>>>>>>>>
>>>>>>>>
>>>>>>>> The input that has baffled computer scientists for 90
>>>>>>>> years is merely correctly determined to be non-halting
>>>>>>>> when the behavior of this input is measured by HHH
>>>>>>>> emulating this input according to the rules of the x86
>>>>>>>> language.
>>>>>>>>
>>>>>>>> The same thing applies to the Linz proof yet cannot
>>>>>>>> be understood until after HHH(DDD) and HHH(DD) are
>>>>>>>> fully understood.
>>>>>>>>
>>>>>>>
>>>>>>> HHH(DDD) (whatever) at most says DDD is a pathological/midtaken input.
>>>>>>> Others of what you say are your imagine and wishes, so far so true.
>>>>>>>
>>>>>>
>>>>>> DDD emulated by HHH accor not the 'HHH' that makes the final decision
>>> (otherwise, it will be an infinite recursive call which you agreed)
>>>
>>>>>> ding to the rules of
>>>>>> the x86 language specifies recursive emulation
>>>>>> that cannot possibly reach the final halt state
>>>>>> of DDD.
>>>>>>
>>>>>
>>>>> I have no problem with that. And, you said HHH merely rejects it as non-halting.
>>>>> You had denied HHH can decide the halting property of any input, except DDD/DD/D..
>>>>>
>>>>
>>>> As long as HHH correctly determines the halt status
>>>> of a single input that has no inputs then HHH is
>>>> a correct termination analyzer for that input.
>>>
>>> Go it, that is a stronger statement that HHH ONLY decides DD.
>>> I have no problem with that, but be noticed that the HHH inside DD
>>> is not the 'HHH' that makes the final decision (otherwise, the 'HHH'
>>> will be an infinite recursive which cannot make any decision, which
>>> you had agreed)
>>>
>>
>> HHH(DD) correctly determines that its input specifies
>> recursive emulation when this input is emulated by HHH
>> HHH according to the rules of the x86 language.
> 
>  From the about, so you are talking about 'the HHH' which does not compute the final decision.
> 

HHH does recognize the recursive emulation pattern
of DDD emulated by HHH according to the rules of
the x86 language.

>> *Thus exactly meets the following specification*
>> <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
>>
>>       H can abort its simulation of D and correctly report that D
> 
> This H won't be the same HHH inside the DD, otherwise an infinite recursive call happens.
> 

It must always be the outermost HHH that does this
because it has seen one entire recursive emulation
more than the next inner HHH.

>>       specifies a non-halting sequence of configurations.
>> </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>
>> Professor Sipser is the best selling author of theory of
>> computation textbooks.
>> It is a pity that he could never take the five more minutes
>> required to understand the notion of recursive emulation and
>> thus see the significance of my work.
> 
> You can cite any one, I don't know who Sipsper is.
> But yes, it is also a pity that Socrites and Turing did not know POOH.
> 

https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X

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