Path: ...!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: Computable Functions --- OUTPUTS MUST CORRESPOND TO INPUTS
Date: Wed, 23 Apr 2025 18:40:02 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <51970b3aaedf7325e812613db4ab5902ed9d8215@i2pn2.org>
References: <vsnchj$23nrb$2@dont-email.me> <vtajkf$10asg$2@dont-email.me>
 <vtbe3g$1vs00$1@dont-email.me>
 <852f89c9196e0261b8156050fea4572fe886933f@i2pn2.org>
 <vth52t$3in23$9@dont-email.me> <vth557$3a127$7@dont-email.me>
 <vth8lr$3n2du$2@dont-email.me>
 <a8ab995b650b894cbfb635478f7406c4eee4d187@i2pn2.org>
 <vthqtc$5g2e$2@dont-email.me>
 <63af93cb608258cc3e12b9bab3a2efa0b7ee7eee@i2pn2.org>
 <vtit6a$15e5s$3@dont-email.me> <vtivmo$19aqd$1@dont-email.me>
 <vtkc4l$2h48g$3@dont-email.me> <vtkdnm$2iqu5$1@dont-email.me>
 <vtkkge$2si58$2@dont-email.me> <vtl56j$3aajg$1@dont-email.me>
 <vtlu0a$3vgp0$1@dont-email.me> <vtm04f$2a90$1@dont-email.me>
 <vtm9q8$aut7$1@dont-email.me> <vtmah8$2a90$2@dont-email.me>
 <vtmgen$gs48$1@dont-email.me>
 <c2ad5086dba36124c070173c3e3252967df2fab9@i2pn2.org>
 <vu8g3q$v0qa$1@dont-email.me> <vu8lse$vn9b$1@dont-email.me>
 <vu8og4$13jl5$7@dont-email.me> <vu8qtv$vn9b$5@dont-email.me>
 <vu8rvt$13jl5$13@dont-email.me> <vuaagi$2lbp9$3@dont-email.me>
 <vub1l6$3clpn$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 23 Apr 2025 22:40:37 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1603571"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vub1l6$3clpn$4@dont-email.me>
Bytes: 6958
Lines: 117

On 4/23/25 11:40 AM, olcott wrote:
> On 4/23/2025 4:05 AM, Fred. Zwarts wrote:
>> Op 22.apr.2025 om 21:51 schreef olcott:
>>> On 4/22/2025 2:33 PM, Fred. Zwarts wrote:
>>>> Op 22.apr.2025 om 20:51 schreef olcott:
>>>>> On 4/22/2025 1:07 PM, Fred. Zwarts wrote:
>>>>>> Op 22.apr.2025 om 18:28 schreef olcott:
>>>>>>> On 4/22/2025 7:57 AM, joes wrote:
>>>>>>>> Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott:
>>>>>>>>> On 4/15/2025 2:03 PM, dbush wrote:
>>>>>>>>>> On 4/15/2025 2:50 PM, olcott wrote:
>>>>>>>>>>> On 4/15/2025 11:05 AM, dbush wrote:
>>>>>>>>>>>> On 4/15/2025 11:29 AM, olcott wrote:
>>>>>>>>
>>>>>>>>>>>>> *corresponding output to the input*
>>>>>>>>>>>>> Not freaking allowed to look at any damn thing else besides 
>>>>>>>>>>>>> the
>>>>>>>>>>>>> freaking input. Must compute whatever mapping ACTUALLY 
>>>>>>>>>>>>> EXISTS FROM
>>>>>>>>>>>>> THIS INPUT.
>>>>>>>>>>>>>
>>>>>>>>>>>> So the algorithm HHH that you've implemented computes *some*
>>>>>>>>>>>> computable function, but it does not compute the halting 
>>>>>>>>>>>> function as
>>>>>>>>>>>> it is not computable.
>>>>>>>>>>>>
>>>>>>>>>>> *corresponding output to the input*
>>>>>>>>>>>
>>>>>>>>>> That doesn't refute anything I said.
>>>>>>>>>>
>>>>>>>>> You continue to stupidly insist that int sum(int x, int y) 
>>>>>>>>> {return x +
>>>>>>>>> y; }
>>>>>>>>> returns 7 for sum(3,2) because you incorrectly understand how 
>>>>>>>>> these
>>>>>>>>> things fundamentally work.
>>>>>>>>>
>>>>>>>>> It is stupidly wrong to expect HHH(DD) report on the direct 
>>>>>>>>> execution of
>>>>>>>>> DD when you are not telling it one damn thing about this direct
>>>>>>>>> execution.
>>>>>>>> What else is it missing that the processor uses to execute it?
>>>>>>>>
>>>>>>>
>>>>>>> int DD()
>>>>>>> {
>>>>>>>    int Halt_Status = HHH(DD);
>>>>>>>    if (Halt_Status)
>>>>>>>      HERE: goto HERE;
>>>>>>>    return Halt_Status;
>>>>>>> }
>>>>>>>
>>>>>>> _DD()
>>>>>>> [00002133] 55         push ebp      ; housekeeping
>>>>>>> [00002134] 8bec       mov ebp,esp   ; housekeeping
>>>>>>> [00002136] 51         push ecx      ; make space for local
>>>>>>> [00002137] 6833210000 push 00002133 ; push DD
>>>>>>> [0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
>>>>>>> [00002141] 83c404     add esp,+04
>>>>>>> [00002144] 8945fc     mov [ebp-04],eax
>>>>>>> [00002147] 837dfc00   cmp dword [ebp-04],+00
>>>>>>> [0000214b] 7402       jz 0000214f
>>>>>>> [0000214d] ebfe       jmp 0000214d
>>>>>>> [0000214f] 8b45fc     mov eax,[ebp-04]
>>>>>>> [00002152] 8be5       mov esp,ebp
>>>>>>> [00002154] 5d         pop ebp
>>>>>>> [00002155] c3         ret
>>>>>>> Size in bytes:(0035) [00002155]
>>>>>>>
>>>>>>> libx86emu <is> a correct x86 processor and does emulate
>>>>>>> its inputs correctly.
>>>>>>
>>>>>> The key thing here is that Olcott consistently does not understand 
>>>>>> that HHH is given a finite string input that according to the 
>>>>>> semantics of the x86 language specifies a halting program,
>>>>>
>>>>> That is stupidly incorrect. The only question that HHH
>>>>> must answer is the behavior that its input specifies.
>>>>>
>>>> Yes and the input, a finite string specifies a halting program 
>>>> according to the unique semantics of the x86 language, as proven by 
>>>> direct execution and world-class simulators. HHH's failure to reach 
>>>> the end of the simulation does not show otherwise.
>>>
>>> I have proven that the directly executed DD and DD
>>> emulated by HHH according to the semantics of the
>>> x86 language have a different set of state changes
>>> many hundreds of times for several years.
>>
>> We have never seen a proof, only your unbased claims. You never showed 
>> the first state change that is different for direct execution and the 
>> simulation. You only showed a HHH that fails to reach the end of a 
>> halting program.
> 
> _DD()
> [00002133] 55         push ebp      ; housekeeping
> [00002134] 8bec       mov ebp,esp   ; housekeeping
> [00002136] 51         push ecx      ; make space for local
> [00002137] 6833210000 push 00002133 ; push DD
> [0000213c] e882f4ffff call 000015c3 ; call HHH(DD)
> [00002141] 83c404     add esp,+04
> [00002144] 8945fc     mov [ebp-04],eax
> [00002147] 837dfc00   cmp dword [ebp-04],+00
> [0000214b] 7402       jz 0000214f
> [0000214d] ebfe       jmp 0000214d
> [0000214f] 8b45fc     mov eax,[ebp-04]
> [00002152] 8be5       mov esp,ebp
> [00002154] 5d         pop ebp
> [00002155] c3         ret
> Size in bytes:(0035) [00002155]
> 
> Even the above is complete proof to everyone that
> knows the x86 language.
> 

Sure, it proves you don't know what you are talking about as the code is 
incomplete as it doesn't include the code at 000015c3, so has no 
actually defined behavior.