Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.theory
Subject: =?UTF-8?Q?Re=3A_Computable_Functions_---_finite_string_transformati?=
 =?UTF-8?Q?on_rules_---_0_=E2=89=A01?=
Date: Sat, 26 Apr 2025 20:19:02 +0200
Organization: A noiseless patient Spider
Lines: 143
Message-ID: <vuj82m$2uahf$1@dont-email.me>
References: <vsnchj$23nrb$2@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>
 <6bd35d1c5fb0d281a29dc8e56458f2b83f63d878@i2pn2.org>
 <vugl27$it5g$2@dont-email.me> <vui73e$217h6$1@dont-email.me>
 <vuj0rf$2lf64$5@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 26 Apr 2025 20:19:03 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6a4185bda8a6e97ede9eb2148f614f66";
	logging-data="3090991"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX194KT4iuVItToKQiIZ7To0Y"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:eZJrWWBKdFOV9HQXjX5WjcaqdIE=
In-Reply-To: <vuj0rf$2lf64$5@dont-email.me>
Content-Language: nl, en-GB

Op 26.apr.2025 om 18:15 schreef olcott:
> On 4/26/2025 3:56 AM, Fred. Zwarts wrote:
>> Op 25.apr.2025 om 20:42 schreef olcott:
>>> On 4/25/2025 8:36 AM, Richard Damon wrote:
>>>> On 4/25/25 9:08 AM, olcott wrote:
>>>>> 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)
>>>>> immediately returns and DD reaches its final halt state.
>>>>
>>>> No it doesn't, 
>>>
>>> I will say that more accurately.
>>> The call from the directly executed DD returns.
>>>
>>> The call from DD emulated by HHH to HHH(DD)
>>> (according to the finite string transformation
>>> rules of the x86 language) CANNOT POSSIBLY RETURN.
>> Indeed, HHH is programmed such that it fails to reach the end
> 
> _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]
> 
> When any HHH emulates DD according to the finite
> string transformation rules specified by the x86
> language (the line of demarcation between correct
> and incorrect emulation) no emulated DD can possibly
> reach its final halt state and halt.
> 
This behaviour of HHH blocks the analysis of the behaviour of DD.
This failure of HHH shows that it is not the right tool to analyse DD.
There are other tools that have no problem to reach the final end.