Path: ...!news.roellig-ltd.de!news.mb-net.net!open-news-network.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: olcott Newsgroups: comp.theory Subject: Re: The actual truth is that ... The only actual issue remaining Date: Sat, 19 Oct 2024 06:09:45 -0500 Organization: A noiseless patient Spider Lines: 85 Message-ID: References: <72315c1456c399b2121b3fffe90b933be73e39b6@i2pn2.org> <1180775691cf24be4a082676bc531877147202e3@i2pn2.org> <7e79306e9771378b032e6832548eeef7429888c4@i2pn2.org> <6d73c2d966d1d04dcef8f7f9e0c849e17bd73352@i2pn2.org> <97040a77da33a22295b056e260c896fd96f1ac94@i2pn2.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 19 Oct 2024 13:09:46 +0200 (CEST) Injection-Info: dont-email.me; posting-host="a2f4596ff028e636d7320aa11ac5f85c"; logging-data="4042774"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/ScInQ7hKFP0T/LeZsVLu7" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:URGj03aSJIGz/1Vq1S6gPSQ2C5I= X-Antivirus: Norton (VPS 241019-2, 10/19/2024), Outbound message Content-Language: en-US X-Antivirus-Status: Clean In-Reply-To: Bytes: 6087 On 10/19/2024 3:47 AM, Mikko wrote: > On 2024-10-16 17:42:43 +0000, olcott said: > >> On 10/16/2024 12:24 PM, joes wrote: >>> Am Wed, 16 Oct 2024 12:13:12 -0500 schrieb olcott: >>>> On 10/16/2024 3:05 AM, Mikko wrote: >>>>> On 2024-10-16 03:52:00 +0000, olcott said: >>>>>> On 10/15/2024 9:11 PM, Richard Damon wrote: >>>>>>> On 10/15/24 8:39 AM, olcott wrote: >>>>>>>> On 10/15/2024 4:58 AM, joes wrote: >>>>>>>>> Am Mon, 14 Oct 2024 20:12:37 -0500 schrieb olcott: >>>>>>>>>> On 10/14/2024 6:50 PM, Richard Damon wrote: >>>>>>>>>>> On 10/14/24 12:05 PM, olcott wrote: >>>>>>>>>>>> On 10/14/2024 6:21 AM, Richard Damon wrote: >>>>>>>>>>>>> On 10/14/24 5:53 AM, olcott wrote: >>>>>>>>>>>>>> On 10/14/2024 3:21 AM, Mikko wrote: >>>>>>>>>>>>>>> On 2024-10-13 12:49:01 +0000, Richard Damon said: >>>>>>>>>>>>>>>> On 10/12/24 8:11 PM, olcott wrote: >>>>>>>>> >>>>>>>>>>>> Trying to change to a different analytical framework than the >>>>>>>>>>>> one that I am stipulating is the strawman deception. >>>>>>>>>>>> *Essentially an intentional fallacy of equivocation error* >>>>>>>>>>> But, you claim to be working on that Halting Problem, >>>>>>>>>> I quit claiming this many messages ago and you didn't bother to >>>>>>>>>> notice. >>>>>>>>> Can you please give the date and time? Did you also explicitly >>>>>>>>> disclaim it or just silently leave it out? >>>>>>>> Even people of low intelligence that are not trying to be as >>>>>>>> disagreeable as possible would be able to notice that a specified C >>>>>>>> function is not a Turing machine. >>>>>>> But it needs to be computationally equivalent to one to ask about >>>>>>> Termination. >>>>>> Not at all. >>>>>> https://en.wikipedia.org/wiki/Pure_function A termination analyzer >>>>>> need not be a Turing computable function. >>>>> There is no known way to construct one that isn't. No computer can >>>>> execute a function that is not Turing computable. >>>> In other words you think that functions that rely on global data such >>>> that they are not a pure function of their inputs are A OK? >>> Says the one with an if(Root). >>> Apart from that, purity has nothing to do with computability. >>> >> >> Quite a few experts agree that the purity of a function >> ensures its computability. It was like pulling teeth to >> get this out of them. > Most computer scientists seems to hat software engineering so when I ask for a mapping between the terminology of the two fields they don't like it. After 1.5 years of dialogue it seems that Turing computable function is a pure function of its inputs. (1) the function return values are identical for identical arguments (no variation with local static variables, non-local variables, mutable reference arguments or input streams, i.e., referential transparency), and (2) the function has no side effects (no mutation of local static variables, non-local variables, mutable reference arguments or input/output streams). https://en.wikipedia.org/wiki/Pure_function HHH(DDD) might be a sufficiently pure function of its inputs because its use of static local data has no effect what-so-ever on the correctness of its emulation of itself emulating DDD. Every sufficiently competent person can correctly determine from the correct execution trace data that it sees that it is correct to determine that DDD emulated by HHH cannot possibly reach its own "return" instruction. (1) HHH does emulate itself emulating DDD correctly. (2) From what we and HHH can see HHH is correct to reject its input. (3) The only issue is whether or not HHH got this correct data properly. > Depends on whom you accpets as an "expert". I wouldn't accept one who > does not understand that there are pure functions that are known to > be uncomputable. > -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer