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: Sun, 11 May 2025 21:46:47 -0500
Organization: A noiseless patient Spider
Lines: 101
Message-ID: <vvrnen$sjai$1@dont-email.me>
References: <vv97ft$3fg66$1@dont-email.me>
 <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> <vvo71c$rlt$1@news.muc.de>
 <PlNTP.270466$lZjd.128570@fx05.ams4> <vvochv$15td$2@news.muc.de>
 <vvodn5$3na6l$3@dont-email.me>
 <1276edeb9893085c59b02bbbd59fe2c64011736b@i2pn2.org>
 <vvqk4s$gldn$12@dont-email.me> <vvqln4$g8ck$5@dont-email.me>
 <vvrftj$ndkg$1@dont-email.me> <vvrggs$n9a9$3@dont-email.me>
 <aa56821a00afb05081a2f4684d4ad8fefc9b2376@i2pn2.org>
 <vvrkg9$o2ab$3@dont-email.me> <vvrkm9$mv2a$7@dont-email.me>
 <vvrli3$s6gd$1@dont-email.me> <vvrmcf$s0mk$2@dont-email.me>
 <vvrmr2$sas2$2@dont-email.me> <vvrmvo$s0mk$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 12 May 2025 04:46:48 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="15cac720ddbb61c7f6586fe023932af8";
	logging-data="937298"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18gHfkjnlwb9ZeAMabd0VBc"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:HpCyXjsvVorJJbEb6G64K2q4MIo=
Content-Language: en-US
In-Reply-To: <vvrmvo$s0mk$4@dont-email.me>
X-Antivirus: Norton (VPS 250511-4, 5/11/2025), Outbound message
X-Antivirus-Status: Clean
Bytes: 6290

On 5/11/2025 9:38 PM, dbush wrote:
> On 5/11/2025 10:36 PM, olcott wrote:
>> On 5/11/2025 9:28 PM, dbush wrote:
>>> On 5/11/2025 10:14 PM, olcott wrote:
>>>> On 5/11/2025 8:59 PM, dbush wrote:
>>>>> On 5/11/2025 9:56 PM, olcott wrote:
>>>>>> On 5/11/2025 8:27 PM, Richard Damon wrote:
>>>>>>> On 5/11/25 8:48 PM, olcott wrote:
>>>>>>>> On 5/11/2025 7:38 PM, Mike Terry wrote:
>>>>>>>>> On 11/05/2025 18:11, Richard Heathfield wrote:
>>>>>>>>>> On 11/05/2025 17:44, olcott wrote:
>>>>>>>>>>> Any yes/no question where both yes and no are the
>>>>>>>>>>> wrong answer is an incorrect polar question.
>>>>>>>>>>
>>>>>>>>>> Either DD stops or it doesn't (once it's been hacked around to 
>>>>>>>>>> get it to compile and after we've leeched out all the dodgy 
>>>>>>>>>> programming).
>>>>>>>>>
>>>>>>>>> Done that.  It still stops.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If the computer cannot correctly decide whether or not DD halts, 
>>>>>>>>>
>>>>>>>>> The decider says it doesn't stop..
>>>>>>>>>
>>>>>>>>>> we have an undecidable computation, 
>>>>>>>>>
>>>>>>>>> No no, that doesn't make sense.  DD stops, and there are lots 
>>>>>>>>> of partial halt deciders that will decide that particular input 
>>>>>>>>> correctly.  PO's DD isn't "undecidable".
>>>>>>>>>
>>>>>>>>> No single computation can be undecidable, considered on its 
>>>>>>>>> own! There are only two possibilities: it halts or it doesn't.  
>>>>>>>>> In either case there is a decider which decides that /one 
>>>>>>>>> specific input/ correctly. By extension, any finite number of 
>>>>>>>>> computations is decidable - we just have a giant switch 
>>>>>>>>> statement followed by returning halts/neverhalts as 
>>>>>>>>> appropriate.  If the input domain has just n inputs, there are 
>>>>>>>>> 2^n trivial deciders that together cater for every combination 
>>>>>>>>> of each input halting or never halting.  One of those deciders 
>>>>>>>>> is a correct decider for that (finite domain) problem.
>>>>>>>>>
>>>>>>>>> The HP is asking for a TM (or equiv.) that correctly decides 
>>>>>>>>> EVERY (P,I) in its one finite algorithm.  That is what is 
>>>>>>>>> proven impossible.  The trick of having a big switch statement 
>>>>>>>>> no longer works because there are infinitely many possible inputs.
>>>>>>>>>
>>>>>>>>> Decidability for just one single input is trivial and not 
>>>>>>>>> intersting.
>>>>>>>>>
>>>>>>>>>> and therefore some computations are undecidable, so Turing's 
>>>>>>>>>> conclusion was right. Who knew? (Apart from practically 
>>>>>>>>>> everybody else, I mean.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Mike.
>>>>>>>>
>>>>>>>> DDD emulated by HHH according to the rules of
>>>>>>>> the computational language that DD is encoded
>>>>>>>> within already proves that the HP "impossible"
>>>>>>>> input specifies a non-halting sequence of
>>>>>>>> configurations.
>>>>>>>
>>>>>>> No it doesn't.
>>>>>>>
>>>>>>
>>>>>> _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 all the steps of DDD emulated by simulating
>>>>>> termination analyzer HHH according to the rules
>>>>>> of the x86 language
>>>>>
>>>>> Which it doesn't do as you have admitted on the record:
>>>>>
>>>>
>>>> I am daring you to show what they should be.
>>>> You know you can't because you know you are a liar.
>>>>
>>>
>>> Category error.  Algorithm HHH does one thing and one thing only. 
>>> There is no "what it should be" because it *is* only one thing.
>>>
>>
>> Show the exact sequence of machine address steps of DDD
>> such that the DDD emulated by some HHH 
> 
> Changing the input is not allowed.

There is no change of input you are a liar.

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