Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: Richard Damon 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: 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: 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 finite strings, and >>>>>>>>>>>>> finite string transformation rules 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. > > > > >