Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Incorrect requirements --- Computing the mapping from the input
 to HHH(DD)
Date: Mon, 12 May 2025 22:42:04 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <1a237cee25a04881fe362c6cfd4e809b94ae1277@i2pn2.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 13 May 2025 03:53:51 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="124170"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <vvrkg9$o2ab$3@dont-email.me>
Bytes: 5275
Lines: 97

On 5/11/25 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]

Not a valid input,

> 
> Show all the steps of DDD emulated by simulating
> termination analyzer HHH according to the rules
> of the x86 language where the emulated DDD reaches
> its "ret" instruction.

Why? That isn't the criteria.

> 
> You can't only because you know that you are
> lying about this.

No, I am pointing out your stupidity, and you just repeat it to make it 
more obvious.

> 
> Your static data trick was clever yet your HHH
> was not a simulating termination analyzer.
> 


Sure it was. At the outer layer it fully emulates its input.

That is more than yours does.

Of course, your concept of that is just a category error and a lie.