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: Re: HHH(DD) --- COMPUTE ACTUAL MAPPING FROM INPUT TO OUTPUT --- Using
 Finite String Transformations
Date: Thu, 24 Apr 2025 19:00:29 -0500
Organization: A noiseless patient Spider
Lines: 125
Message-ID: <vuejat$2md4c$2@dont-email.me>
References: <vsnchj$23nrb$2@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>
 <7e071b34937fe58e9523ac4be56ece689b1248ae@i2pn2.org>
 <vueisg$2luer$1@dont-email.me>
 <d366038b4e6cf0210a6e1cb20ed3463f414d3959@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 02:00:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="39160e770cd8a33e2f9b3fd49f54870c";
	logging-data="2831500"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+Sc9EEIr0xQiYQIwSRjjGs"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ANqOykG5jqqAWO/ctxPhzzrTNp8=
X-Antivirus: Norton (VPS 250424-14, 4/24/2025), Outbound message
X-Antivirus-Status: Clean
In-Reply-To: <d366038b4e6cf0210a6e1cb20ed3463f414d3959@i2pn2.org>
Content-Language: en-US
Bytes: 7700

On 4/24/2025 6:56 PM, Richard Damon wrote:
> On 4/24/25 7:52 PM, olcott wrote:
>> On 4/24/2025 6:26 PM, Richard Damon wrote:
>>> 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, 
>>
>> *At least you will quit STUPIDLY saying that HHH is undefined*
>> *At least you will quit STUPIDLY saying that HHH is undefined*
>> *At least you will quit STUPIDLY saying that HHH is undefined*
>> *At least you will quit STUPIDLY saying that HHH is undefined*
>> *At least you will quit STUPIDLY saying that HHH is undefined*
>>
>>
>>
> 
> And you are stuck having to lie about what HHH does, 

I am not the one that stupid repeats that HHH is undefined.

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