Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
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 16:03:50 -0500
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <vugtbm$pke9$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>
 <27ad43944610a34eae992bd99d6e0fb0c083c90b@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 25 Apr 2025 23:03:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="cda93a9fcc5460bc8f96c9b00569a78d";
	logging-data="840137"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19uQeOOBxnunhosXLJcAlBE"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:LGK9/9V34XeQGqdsmu776bGr5Ig=
X-Antivirus: Norton (VPS 250425-6, 4/25/2025), Outbound message
In-Reply-To: <27ad43944610a34eae992bd99d6e0fb0c083c90b@i2pn2.org>
X-Antivirus-Status: Clean
Content-Language: en-US
Bytes: 5927

On 4/25/2025 3:01 PM, joes wrote:
> Am Fri, 25 Apr 2025 13:42:15 -0500 schrieb 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:
> 
>>>>>>>>>>>>> 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,
> The call starts simulating DD calling HHH, just like in the simulated DD.
> 
>> 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.

> It would return if HHH could simulate it. It is not non-halting, only
> HHH descends ever deeper into the simulation.
> 

It is really not that hard.
Many C programmers said they get this (two of them
with masters degrees in computer science)

Is there any hypothetical HHH that emulates 0 to ∞
steps of DD where DD reaches its final halt state?
No !!!

-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer