Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: =?UTF-8?Q?Re=3A_Computable_Functions_---_finite_string_transformati?=
 =?UTF-8?Q?on_rules_---_0_=E2=89=A01?=
Date: Fri, 25 Apr 2025 21:56:07 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <9145f91ee4d9df77630e30c091b76481006565ca@i2pn2.org>
References: <vsnchj$23nrb$2@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>
 <6d9ae3ac08bbbe4407fc3612441fc2032f949a3d@i2pn2.org>
 <vub168$3clpn$2@dont-email.me>
 <7ac75991b443ba53d52960ddb1932524dea8e03f@i2pn2.org>
 <40b048f71fe2ed2a8ef11d2d587c765c8fcbc977@i2pn2.org>
 <bf0ee557f7c0eba386944a4551e607895c620d44@i2pn2.org>
 <vue9im$2d7t8$5@dont-email.me>
 <09bba11868dafecb6800ba8aec152304fec97553@i2pn2.org>
 <vuej7d$2md4c$1@dont-email.me>
 <51a4be0ebc0ddc76954fd2e5ec1c5951b5f306e3@i2pn2.org>
 <vug1gc$116u$1@dont-email.me> <vug2qi$kv7$1@dont-email.me>
 <vugtll$pke9$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 26 Apr 2025 02:01:57 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1904724"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <vugtll$pke9$3@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0

On 4/25/25 5:09 PM, olcott wrote:
> On 4/25/2025 8:30 AM, Fred. Zwarts wrote:
>> Op 25.apr.2025 om 15:08 schreef olcott:
>>> On 4/24/2025 7:07 PM, Richard Damon wrote:
>>>> On 4/24/25 7:58 PM, olcott wrote:
>>>>> On 4/24/2025 6:14 PM, Richard Damon wrote:
>>>>>> On 4/24/25 5:13 PM, olcott wrote:
>>>>>>> On 4/24/2025 5:59 AM, Richard Damon wrote:
>>>>>>>> On 4/23/25 11:22 PM, polcott333 wrote:
>>>>>>>>> On 4/23/2025 9:41 PM, Richard Damon wrote:
>>>>>>>>>> On 4/23/25 11:32 AM, olcott wrote:
>>>>>>>>>>> On 4/23/2025 6:25 AM, joes wrote:
>>>>>>>>>>>> Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb 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:
>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>> No, DD halts (when executed directly). HHH is not a halt 
>>>>>>>>>>>> decider, not even
>>>>>>>>>>>> for DD only.
>>>>>>>>>>>>
>>>>>>>>>>>>> People here stupidly assume that the outputs are not 
>>>>>>>>>>>>> required to
>>>>>>>>>>>>> correspond to the inputs.
>>>>>>>>>>>> But the direct execution of DD is computable from its 
>>>>>>>>>>>> description.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Not as an input to HHH.
>>>>>>>>>>
>>>>>>>>>> But neither the "direct execution" or the "simulation by HHH" 
>>>>>>>>>> are "inputs" to HHH. What is the input is the representation 
>>>>>>>>>> of the program to be decided on.
>>>>>>>>>>
>>>>>>>>>>> When HHH computes halting for DD is is only allowed
>>>>>>>>>>> to apply the finite string transformations specified
>>>>>>>>>>> by the x86 language to the machine code of DD.
>>>>>>>>>>
>>>>>>>>>> It is only ABLE to apply them.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The input to HHH(DD) does specify the recursive emulation
>>>>>>>>> of DD including HHH emulating itself emulating DD when
>>>>>>>>> one applies the finite string transformation rules of the
>>>>>>>>> x86 language to THE INPUT to HHH(DD).
>>>>>>>>
>>>>>>>> Yes, the input specifies FINITE recusive PARTIAL emulation, as 
>>>>>>>> the HHH that DD calls will emulate only a few instructions of DD 
>>>>>>>> and then return,
>>>>>>>>
>>>>>>>
>>>>>>> *You are technically incompetent on this point*
>>>>>>> When the finite string transformation rules of the
>>>>>>> x86 language are applied to the input to HHH(DD)
>>>>>>> THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE
>>>>>>> not even after an infinite number of emulated steps.
>>>>>>
>>>>>> Sure it does, just after the point that HHH gives up on those 
>>>>>> transformation and aborts its (now incorrect) emulation of the input.
>>>>>>
>>>>>
>>>>> THAT IS COUNTER FACTUAL !!!
>>>>>
>>>>> The directly executed DD has zero recursive invocations.
>>>>> DD emulated by HHH has one recursive invocation.
>>>>>
>>>>> Did you know that zero does not equal one?
>>>>>
>>>>
>>>> But the direct execution DOES have a recursiove invocation, as DD 
>>>> calls HHH(DD) that emulated DD, just like the directly exeucted HHH 
>>>> will emulate DD calling HHH(DD).
>>>>
>>>
>>> The call from the directly executed DD to HHH(DD)
>>
>> ... causes HHH to simulate DD. In this simulation DD calls HHH, but 
>> the simulating HHH aborts and after that ...
>>
>>> immediately returns and DD reaches its final halt state.
>>>
>>> The call to HHH(DD) from DD emulated by HHH causes
>>> HHH to emulate itself emulating DD. 
>>
>> The simulating HHH prevents the simulated DD to call the simulated 
>> HHH, so that it prevents DD to reach its end.
>> This is against the rules of the x86 language.
>>
> 
> One call returns that other call cannot possibly return.
> Are you merely troll?
> 

Why doesn't the other call return? because HHH gave up too soon, It does 
return from a correct and complete emulation.