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 --- finite string transformation rules
Date: Thu, 24 Apr 2025 19:02:19 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <2cc2a999ace99eeb69855db59eec48da5cd8eea6@i2pn2.org>
References: <vsnchj$23nrb$2@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>
 <6d9ae3ac08bbbe4407fc3612441fc2032f949a3d@i2pn2.org>
 <vub168$3clpn$2@dont-email.me>
 <7ac75991b443ba53d52960ddb1932524dea8e03f@i2pn2.org>
 <40b048f71fe2ed2a8ef11d2d587c765c8fcbc977@i2pn2.org>
 <vucrgq$148pf$1@dont-email.me> <vudkt8$1ona3$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 24 Apr 2025 23:25:16 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1749012"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <vudkt8$1ona3$2@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5486
Lines: 94

On 4/24/25 11:21 AM, olcott wrote:
> On 4/24/2025 3:07 AM, Fred. Zwarts wrote:
>> Op 24.apr.2025 om 05:22 schreef polcott333:
>>> 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 
>>
>> *finite*
>>
>>  > 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).
>>>
>>> You can't pop any other execution trace from the input
>>> to HHH(DD) than that.
>>>
>>
>> You can't abort a halting sequence and claim that it does not halt.
> 
> Halting means reaching its own final halt state.
> Mathematical induction proves that DD emulated
> by HHH according to finite string transformation
> rules of the x86 language cannot possibly reach
> its own final halt state even after an infinite
> number of steps.

No, you can't do your induction, becuase HHH can't be changed to do it.

Sorry you checkmated your argument by fixing HHH to be the one in Halt7.c

And, even when you can change HHH, you have the problem that each input 
is a seperate input, so while you can prove that no verison of HHH can 
correctly emulate its input to the final state, you haven't proved that 
a correct and complete emulation of any of those input will not.

You just are proving you don't know what you are talking about.

> 
>> You can't claim a incorrectly coded program to be correct only it does 
>> what its code specifies.
> 
>