Deutsch English Français Italiano |
<v5srjn$o1o0$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: olcott <polcott333@gmail.com> Newsgroups: comp.theory,sci.logic Subject: Re: People are still trying to get away with disagreeing with the semantics of the x86 language Date: Sun, 30 Jun 2024 19:00:55 -0500 Organization: A noiseless patient Spider Lines: 160 Message-ID: <v5srjn$o1o0$1@dont-email.me> References: <v5pbjf$55h$1@dont-email.me> <v5r5q9$ekvf$1@dont-email.me> <v5s40h$jvgt$1@dont-email.me> <v5sbpt$1kfbr$2@i2pn2.org> <v5sjsa$msl0$1@dont-email.me> <v5skc9$1kfbr$7@i2pn2.org> <v5smuk$n7a2$1@dont-email.me> <v5sorr$1kfbr$10@i2pn2.org> <v5sp4v$nnko$1@dont-email.me> <v5sr4t$1kfbq$1@i2pn2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 01 Jul 2024 02:00:56 +0200 (CEST) Injection-Info: dont-email.me; posting-host="f83257e6e5a87f489aa8241c55498376"; logging-data="788224"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18jMf6/4v0fa8m1wb/h3MBb" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:x1pvZ29/e62Jp5mzr01WvrjTJd8= In-Reply-To: <v5sr4t$1kfbq$1@i2pn2.org> Content-Language: en-US Bytes: 8016 On 6/30/2024 6:53 PM, Richard Damon wrote: > On 6/30/24 7:18 PM, olcott wrote: >> On 6/30/2024 6:14 PM, Richard Damon wrote: >>> On 6/30/24 6:41 PM, olcott wrote: >>>> On 6/30/2024 4:57 PM, Richard Damon wrote: >>>>> On 6/30/24 5:48 PM, olcott wrote: >>>>>> On 6/30/2024 2:31 PM, Richard Damon wrote: >>>>>>> On 6/30/24 1:18 PM, olcott wrote: >>>>>>>> On 6/30/2024 3:42 AM, Mikko wrote: >>>>>>>>> On 2024-06-29 16:09:19 +0000, olcott said: >>>>>>>>> >>>>>>>>>> People are still trying to get away with disagreeing with >>>>>>>>>> the semantics of the x86 language. That is isomorphic to >>>>>>>>>> trying to get away with disagreeing with arithmetic. >>>>>>>>>> >>>>>>>>>> typedef void (*ptr)(); >>>>>>>>>> int H0(ptr P); >>>>>>>>>> >>>>>>>>>> void Infinite_Loop() >>>>>>>>>> { >>>>>>>>>> HERE: goto HERE; >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> void Infinite_Recursion() >>>>>>>>>> { >>>>>>>>>> Infinite_Recursion(); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> void DDD() >>>>>>>>>> { >>>>>>>>>> H0(DDD); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> int main() >>>>>>>>>> { >>>>>>>>>> H0(Infinite_Loop); >>>>>>>>>> H0(Infinite_Recursion); >>>>>>>>>> H0(DDD); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> Every C programmer that knows what an x86 emulator is knows >>>>>>>>>> that when H0 emulates the machine language of Infinite_Loop, >>>>>>>>>> Infinite_Recursion, and DDD that it must abort these emulations >>>>>>>>>> so that itself can terminate normally. >>>>>>>>>> >>>>>>>>>> When this is construed as non-halting criteria then simulating >>>>>>>>>> termination analyzer H0 is correct to reject these inputs as >>>>>>>>>> non-halting by returning 0 to its caller. >>>>>>>>>> >>>>>>>>>> Simulating termination analyzers must report on the behavior >>>>>>>>>> that their finite string input specifies thus H0 must report >>>>>>>>>> that DDD correctly emulated by H0 remains stuck in recursive >>>>>>>>>> simulation. >>>>>>>>>> >>>>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>> 10/13/2022> >>>>>>>>>> If simulating halt decider H correctly simulates its input D >>>>>>>>>> until H correctly determines that its simulated D would >>>>>>>>>> never >>>>>>>>>> stop running unless aborted then >>>>>>>>>> >>>>>>>>>> H can abort its simulation of D and correctly report that D >>>>>>>>>> specifies a non-halting sequence of configurations. >>>>>>>>>> </MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>> 10/13/2022> >>>>>>>>>> >>>>>>>>>> People are trying to get away with disagreeing with the semantics >>>>>>>>>> of the x86 language by disagreeing that >>>>>>>>>> >>>>>>>>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly >>>>>>>>>> emulated by any pure function x86 emulator HHH cannot possibly >>>>>>>>>> return. >>>>>>>>>> >>>>>>>>>> _DDD() >>>>>>>>>> [00002172] 55 push ebp ; housekeeping >>>>>>>>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>>>>>>>> [00002175] 6872210000 push 00002172 ; push DDD >>>>>>>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>>>>>>>>> [0000217f] 83c404 add esp,+04 >>>>>>>>>> [00002182] 5d pop ebp >>>>>>>>>> [00002183] c3 ret >>>>>>>>>> Size in bytes:(0018) [00002183] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *A 100% complete and total rewrite of the prior paper* >>>>>>>>>> https://www.researchgate.net/publication/381636432_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_P >>>>>>>>> >>>>>>>>> Nothing above is or points to any evdence about the alleged >>>>>>>>> disagreement. >>>>>>>>> >>>>>>>> >>>>>>>> Of course not. I only said the actual truth. >>>>>>>> >>>>>>>> Richard just said that he affirms that when DDD correctly >>>>>>>> simulated by HHH calls HHH(DDD) that this call returns even >>>>>>>> though the semantics of the x86 language disagrees. >>>>>>> >>>>>>> What in the sematics of the x86 language, which INCLUDES that >>>>>>> ever instruction WILL be followed by the next instruction, says >>>>>>> that the HHH that is calld by DDD won't eventually return. >>>>>>> >>>>>>> Since you assert that HHH(DDD) called by main returns, then by >>>>>>> your requreement that HHH be a "pure function" ALL copies of it >>>>>>> will do the same thing. >>>>>>> >>>>>>> Yes, the EMULATION of HHH by HHH, but that can not be the >>>>>>> "behavior of the input" as that "behavior" depends on more than >>>>>>> just the input. >>>>>>> >>>>>> >>>>>> Therefore DDD correctly simulated by HHH DOES NOT HALT. >>>>>> Thus HHH correctly reports that DDD DOES NOT HALT. >>>>>> >>>>> >>>>> And then it doesn't correct emulate the input, and thus is a LIAR. >>>>> >>>> >>>> You already know that you are the liar here and are >>>> lying about not knowing this. >>>> >>>> _DDD() >>>> [00002172] 55 push ebp ; housekeeping >>>> [00002173] 8bec mov ebp,esp ; housekeeping >>>> [00002175] 6872210000 push 00002172 ; push DDD >>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD) >>>> [0000217f] 83c404 add esp,+04 >>>> [00002182] 5d pop ebp >>>> [00002183] c3 ret >>>> Size in bytes:(0018) [00002183] >>>> >>>> The call from DDD to HHH(DDD) when N steps of DDD are >>>> correctly emulated by any pure function x86 emulator >>>> HHH at machine address 0000217a cannot possibly return. >>>> >>> >>> The problem is that the N steps emulated by HHH are not, and CAN NOT >>> be the "behavior of the input", >> They need not be the FULL behavior of the input. >> >> H correctly simulates its input D until >> H correctly simulates its input D until >> H correctly simulates its input D until > > And that can NOT be the "Behavior of the Input" as it depends on more > that just the input. > DDD correctly emulated by HHH calls an emulated HHH that emulates its own DDD THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT? THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT? THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT? THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT? THIS SEQUENCE CANNOT POSSIBLY RETURN WHY PERSISTENTLY LIE ABOUT IT? -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer