Path: ...!news.snarked.org!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:49:44 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <f5c5afe8e6e6a3de09da3da35b2a81199b8938cb@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>
 <bb4cbe8f07ea2657fa7c19ce626fdb70f8c70e70@i2pn2.org>
 <vvr41q$ks69$2@dont-email.me>
 <25888556ca5d63eba15f3a805e6d952a19e5ec75@i2pn2.org>
 <vvrfch$n9a9$1@dont-email.me>
 <d5709aca70f66affe58643511a2473e67dc81966@i2pn2.org>
 <vvrksr$o2ab$4@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:52 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="124170"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <vvrksr$o2ab$4@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5712
Lines: 103

On 5/11/25 10:03 PM, olcott wrote:
> On 5/11/2025 8:31 PM, Richard Damon wrote:
>> On 5/11/25 8:29 PM, olcott wrote:
>>> On 5/11/2025 6:39 PM, Richard Damon wrote:
>>>> On 5/11/25 5:15 PM, olcott wrote:
>>>>> On 5/11/2025 4:02 PM, Richard Damon wrote:
>>>>>> On 5/11/25 12:44 PM, olcott wrote:
>>>>>>> On 5/11/2025 6:13 AM, joes wrote:
>>>>>>>> Am Sat, 10 May 2025 15:42:13 -0500 schrieb olcott:
>>>>>>>>> On 5/10/2025 3:22 PM, Alan Mackenzie wrote:
>>>>>>>>
>>>>>>>>>> OK, then, give the page and line numbers from Turing's 1936 
>>>>>>>>>> paper where
>>>>>>>>>> this alleged mistake was made.  I would be surprised indeed if 
>>>>>>>>>> you'd
>>>>>>>>>> even looked at Turing's paper, far less understood it.  Yet 
>>>>>>>>>> you're
>>>>>>>>>> ready to denigrate his work.
>>>>>>>>>> Perhaps it is time for you to withdraw these uncalled for 
>>>>>>>>>> insinuations.
>>>>>>>>>>
>>>>>>>>> It is the whole gist of the entire idea of the halting problem 
>>>>>>>>> proof
>>>>>>>>> that is wrongheaded.
>>>>>>>>> (1) It is anchored in the false assumption that an input to a
>>>>>>>>> termination analyzer can actually do this opposite of whatever 
>>>>>>>>> value
>>>>>>>>> that this analyzer returns. No one ever notices that this "do the
>>>>>>>>> opposite" code is unreachable.
>>>>>>>
>>>>>>>> The simulated DDD doesn't matter. HHH returns to DDD, and DDD 
>>>>>>>> then does
>>>>>>>> the opposite.
>>>>>>>>
>>>>>>>
>>>>>>> HHH is only allowed to report on the behavior that
>>>>>>> its actual input actually specifies.
>>>>>>
>>>>>>
>>>>>> Which is DEFINED to be the bahavior of the program that the input 
>>>>>> represents when run.
>>>>>
>>>>> When you define 5 == 6 you are simply wrong.
>>>>> That definition contradicts other axioms.
>>>>>
>>>>
>>>> And where did I do that?
>>>>
>>>
>>> When the definition of the halting problem requires
>>> the termination analyzer H to report on behavior besides
>>> the behavior of the input D simulated by H according
>>> to the rules of the computational language that the
>>> input D is encoded within.
>>>
>>
>> Where do you get that behavior to be decided needs to be based on the 
>> partial simulation of the decider.
>>
> 
> The behavior of the input to HHH(DDD) is only correctly
> measured by the behavior that it actually specifies.

Which, by the definiton of the problem, is the behavior of the direct 
execution of the program the input represent,

> 
> Since DDD <is> a sequence of programming instructions
> this behavior must be measured according to its
> computer language.

Right, and since your input calls a location of memory which has not 
been include, that input is just a category error.

> 
> _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]
> 
> When DDD calls HHH(DDD) HHH is not free to
> "interpret" this call as meaning JMP 00002183.
> 

Right, it must interprete it as push the address 0000217F onto the stack 
and then jump to 000015d2, as that *IS* the definition of the 
instruction in the language. SInce you don't show that next, all those 
traces are just INCORRECT.

It is NOT somehow get into a new call to 00002172, especially since we 
never come to a call or jump to that address, it was only passed as a 
parameter, that was proceessed as data.

Thus the processor will NEVER AGIAN exeucte those insturcions.


Sorry, you are just proving how little you understand of what you lie 
about, causing your lies to be so obvious to those that know even a 
little bit of the field.