Path: 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:36:18 -0500
Organization: A noiseless patient Spider
Lines: 103
Message-ID: <vvrmr2$sas2$2@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 12 May 2025 04:36:19 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="15cac720ddbb61c7f6586fe023932af8";
	logging-data="928642"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX195K2MOLvYO+gVcn2tOxk7R"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:0F5nyqeah+TbrerqmogER3OsY4E=
X-Antivirus: Norton (VPS 250511-4, 5/11/2025), Outbound message
Content-Language: en-US
In-Reply-To: <vvrmcf$s0mk$2@dont-email.me>
X-Antivirus-Status: Clean

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 according to the
rules of the x86 language reaches its "ret" instruction
final halt state.

You will perpetually refuse to do that because you know
that you are are a liar.

This may get you condemned to actual Hell if such a
place exists.

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