Deutsch   English   Français   Italiano  
<7e071b34937fe58e9523ac4be56ece689b1248ae@i2pn2.org>

View for Bookmarking (what is this?)
Look up another Usenet article

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: HHH(DD) --- COMPUTE ACTUAL MAPPING FROM INPUT TO OUTPUT --- Using
 Finite String Transformations
Date: Thu, 24 Apr 2025 19:26:47 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <7e071b34937fe58e9523ac4be56ece689b1248ae@i2pn2.org>
References: <vsnchj$23nrb$2@dont-email.me> <vto4vh$23i07$1@dont-email.me>
 <vto7qu$267in$1@dont-email.me> <k%RLP.1232047$Xb1.539402@fx05.ams4>
 <vtorpb$2uac$1@news.muc.de> <vtp32o$2vb5o$1@dont-email.me>
 <vtqpt5$17ns$1@news.muc.de> <vtrhbc$16pbv$2@dont-email.me>
 <vtrk7l$t44$1@news.muc.de> <vtrmfa$1be3n$1@dont-email.me>
 <vtvkgo$vjvi$1@dont-email.me> <vu2042$34l74$1@dont-email.me>
 <vu519u$1s5f9$1@dont-email.me> <vu6aha$2vn05$3@dont-email.me>
 <vu6dk4$2fq2$1@news.muc.de> <vu6knm$394oo$1@dont-email.me>
 <vu8cgm$2p5e$1@news.muc.de> <vu8gml$v0qa$2@dont-email.me>
 <vu8m2h$vn9b$2@dont-email.me> <vu8pr1$13jl5$8@dont-email.me>
 <vu8qo3$vn9b$4@dont-email.me> <vu8ruc$13jl5$12@dont-email.me>
 <vuaaae$2lbp9$2@dont-email.me>
 <zIWdnaZKufSzmpT1nZ2dnZfqnPadnZ2d@brightview.co.uk>
 <vub1go$3clpn$3@dont-email.me>
 <HcWcnf7heZkdG5T1nZ2dnZfqn_qdnZ2d@brightview.co.uk>
 <vucbg5$mukj$1@dont-email.me> <vucbrv$mukj$2@dont-email.me>
 <b76c7dc89655dcc3f3fb52dee18a2d30f82f6166@i2pn2.org>
 <vue9t9$2d7t8$6@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:26:48 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1749219"; 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: <vue9t9$2d7t8$6@dont-email.me>
Bytes: 7012
Lines: 118

On 4/24/25 5:19 PM, olcott wrote:
> On 4/24/2025 5:53 AM, Richard Damon wrote:
>> On 4/23/25 11:40 PM, olcott wrote:
>>> On 4/23/2025 10:34 PM, olcott wrote:
>>>> On 4/23/2025 7:31 PM, Mike Terry wrote:
>>>>> On 23/04/2025 16:38, olcott wrote:
>>>>>> On 4/23/2025 10:28 AM, Mike Terry wrote:
>>>>>>> On 23/04/2025 10:02, Fred. Zwarts wrote:
>>>>>>>> Op 22.apr.2025 om 21:50 schreef olcott:
>>>>>>>>> On 4/22/2025 2:30 PM, Fred. Zwarts wrote:
>>>>>>>>>> Op 22.apr.2025 om 21:14 schreef olcott:
>>>>>>>>>>> On 4/22/2025 1:10 PM, Fred. Zwarts wrote:
>>>>>>>>>>>> Op 22.apr.2025 om 18:38 schreef olcott:
>>>>>>>>>>>>>
>>>>>>>>>>>>> a function is computable if there exists an algorithm
>>>>>>>>>>>>> that can do the job of the function, i.e. given an input
>>>>>>>>>>>>> of the function domain it can return the corresponding output.
>>>>>>>>>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Turing Machines inputs <are> finite strings, and
>>>>>>>>>>>>> finite string transformation rules <are> applied to
>>>>>>>>>>>>> these finite strings to derive corresponding outputs.
>>>>>>>>>>>>>
>>>>>>>>>>>> And it has been proven that no finite string transformations 
>>>>>>>>>>>> are possible that report the halting behaviour for all 
>>>>>>>>>>>> inputs that specify a correct program. 
>>>>>>>>>>>
>>>>>>>>>>> int sum(int x, int y) { return x + y; }
>>>>>>>>>>> Only when people stupid assume the same thing as
>>>>>>>>>>> sum(3,2) should return the sum of 5 + 3.
>>>>>>>>>>>
>>>>>>>>>> Therefore HHH should report on the actual input, the finite 
>>>>>>>>>> string that describes a halting program. Not on the 
>>>>>>>>>> hypothetical input that does not halt, because it is based on 
>>>>>>>>>> a hypothetical HHH that does not abort.
>>>>>>>>>>
>>>>>>>>>> Why do you maintain that HHH should process the hypothetical 
>>>>>>>>>> input instead of the actual input.
>>>>>>>>>> Do you really believe that 3+2 equals 5+3?
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>> You never showed a proof. You only repeated a dream. You are 
>>>>>>>> dreaming many years without any logic. You failed to show the 
>>>>>>>> first state change where the direct execution is different from 
>>>>>>>> the simulation. You only showed an erroneous HHH that fails to 
>>>>>>>> reach the end of the simulation of a halting program.
>>>>>>>
>>>>>>> Worse than this, on more than one occasion I've actually posted 
>>>>>>> traces of computation DDD(DDD) executed directly and simulated by 
>>>>>>> HHH side by side.  Both traces were of course /identical/, up to 
>>>>>>> the point where HHH stops simulating. 
>>>>>>
>>>>>> *Factually incorrect* (You are usually very careful about these 
>>>>>> things)
>>>>>> The call to HHH(DD) from the directly executed DD returns.
>>>>>> The call to HHH(DD) from DD emulated by HHH cannot possibly return.
>>>>>>
>>>>>
>>>>> ...because HHH stops simulating before reaching that step in the 
>>>>> computation.  Note that I said
>>>>>
>>>>> MT:  Both traces were of course /identical/,
>>>>>       *up to the point where HHH stops simulating*
>>>>>
>>>>> So I was factually correct.
>>>>>
>>>>>
>>>>> Mike.
>>>>>
>>>>
>>>> It *is not* up to the point where HHH stops simulating.
>>>>
>>>> It is up to the point where the simulated versus directly
>>>> executed calls HHH(DD).
>>>>
>>>> This call immediately from the directly executed DD and
>>>> cannot possibility return from DD emulated by HHH according
>>>> to the finite string transformation rules of the x86 language.
>>>>
>>>
>>> According to the finite string transformation rules of the x86 language.
>>> The call from the directly executed DD to HHH(DD) immediately returns.
>>> The call from DD emulated by HHH to HHH(DD) cannot possibility return.
>>
>>
>> According to the rules of the x86 language, your provided input is 
>> invalid as it references code outside the input. PERIOD.
>>
> 
> *Repetition seems to help you overcome your ADD*
> 
> I have told you that the whole Halt.obj is in scope
> for every function in Halt.c several times now.
> 

And thus there is only every that ONE HHH, so HHH *NEVER* correctly 
emulates it input, and you can't talk about what it could return to be 
right, since the one and only HHH doesn't return anything but Zero.

> I have told you that the whole Halt.obj is in scope
> for every function in Halt.c several times now.
> 
> I have told you that the whole Halt.obj is in scope
> for every function in Halt.c several times now.
> 
> I have told you that the whole Halt.obj is in scope
> for every function in Halt.c several times now.
> 
> I have told you that the whole Halt.obj is in scope
> for every function in Halt.c several times now.
> 
> 
> 
> 
>