| Deutsch English Français Italiano |
|
<vf9ihh$1n874$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: news.eternal-september.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: olcott <polcott333@gmail.com> Newsgroups: comp.theory Subject: Re: Premises cannot be shown to be false without proving that they contradict each other Date: Tue, 22 Oct 2024 20:12:17 -0500 Organization: A noiseless patient Spider Lines: 183 Message-ID: <vf9ihh$1n874$1@dont-email.me> References: <vf3eu5$fbb3$2@dont-email.me> <6fa1774ec1e4b13035be3eab85555b609b301d69@i2pn2.org> <vf3os0$hqgf$1@dont-email.me> <de0c3b304ab574b45594ec05085c193fd687f9f7@i2pn2.org> <vf40l9$ja0c$3@dont-email.me> <3570d58cf5fea3a0a8ac8724b653d1596447d0d1@i2pn2.org> <vf5lln$v6n5$2@dont-email.me> <a9302e42f51777b34f4a7c695247ea98f0f060ad@i2pn2.org> <vf5vi4$10jkk$1@dont-email.me> <3db3ceb1eac447b89c8c740dbba31774eeb1ad99@i2pn2.org> <vf6loq$136ja$1@dont-email.me> <9a91d75b6beb959665d2a042677ef61f444608a5@i2pn2.org> <vf6mt7$136ja$2@dont-email.me> <ad43f56a12181e10f59b8a1e6220ed7989b6c973@i2pn2.org> <vf74oh$1a8oo$1@dont-email.me> <525ed75662589a150afa1ea268b199a166a7b98b@i2pn2.org> <vf8ads$1gkf5$1@dont-email.me> <13583474d25855e665daa98d91605e958f5cf472@i2pn2.org> <VDOdne0-D9Orv4X6nZ2dnZfqn_idnZ2d@brightview.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 23 Oct 2024 03:12:18 +0200 (CEST) Injection-Info: dont-email.me; posting-host="766a907a9bb0f5f92f439e6d0440e983"; logging-data="1810660"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1930UDFLx8QnlCMf0BsmHgR" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:NNNQbDC40Z3ASyQb7HsT5XvJVXk= In-Reply-To: <VDOdne0-D9Orv4X6nZ2dnZfqn_idnZ2d@brightview.co.uk> Content-Language: en-US X-Antivirus-Status: Clean X-Antivirus: Norton (VPS 241022-6, 10/22/2024), Outbound message On 10/22/2024 5:07 PM, Mike Terry wrote: > On 22/10/2024 16:18, joes wrote: >> Am Tue, 22 Oct 2024 08:47:39 -0500 schrieb olcott: >>> On 10/22/2024 4:50 AM, joes wrote: >>>> Am Mon, 21 Oct 2024 22:04:49 -0500 schrieb olcott: >>>>> On 10/21/2024 9:42 PM, Richard Damon wrote: >>>>>> On 10/21/24 7:08 PM, olcott wrote: >>>>>>> On 10/21/2024 6:05 PM, Richard Damon wrote: >>>>>>>> On 10/21/24 6:48 PM, olcott wrote: >>>>>>>>> On 10/21/2024 5:34 PM, Richard Damon wrote: >>>>>>>>>> On 10/21/24 12:29 PM, olcott wrote: >>>>>>>>>>> On 10/21/2024 10:17 AM, joes wrote: >>>>>>>>>>>> Am Mon, 21 Oct 2024 08:41:11 -0500 schrieb olcott: >>>>>>>>>>>>> On 10/21/2024 3:39 AM, joes wrote: >> >>>>>>>>>>> Did ChatGPT generate that? >>>>>>>>>>> If it did then I need *ALL the input that caused it to generate >>>>>>>>>>> that* >>>> It's not like it will deterministically regenerate the same output. >> >>>>>>>>>> No, someone using some REAL INTELEGENCE, as opposed to a program >>>>>>>>>> using "artificial intelegence" that had been loaded with false >>>>>>>>>> premises and other lies. >>>>>>>>> I specifically asked it to verify that its key assumption is >>>>>>>>> correct and it did. >>>>>>>> No, it said that given what you told it (which was a lie) >>>>>>> I asked it if what it was told was a lie and it explained how what >>>>>>> it was told is correct. >>>> "naw, I wasn't lied to, they said they were saying the truth" sure >>>> buddy. >>>> >>>>>> Because Chat GPT doesn't care about lying. >>>>> ChatGPT computes the truth and you can't actually show otherwise. >>>> HAHAHAHAHA there isn't anything about truth in there, prove me wrong >> >>>>>> Because what you are asking for is nonsense. >>>>>> Of course an AI that has been programmed with lies might repeat the >>>>>> lies. >>>>>> When it is told the actual definition, after being told your lies, >>>>>> and asked if your conclusion could be right, it said No. >>>>>> Thus, it seems by your logic, you have to admit defeat, as the AI, >>>>>> after being told your lies, still was able to come up with the >>>>>> correct answer, that DDD will halt, and that HHH is just incorrect to >>>>>> say it doesn't. >>>>> I believe that the "output" Joes provided was fake on the basis that >>>>> she did not provide the input to derive that output and did not use >>>>> the required basis that was on the link. >>>> I definitely typed something out in the style of an LLM instead of my >>>> own words /s >>>> >>>>>> If you want me to pay more attention to what you say, you first need >>>>>> to return the favor, and at least TRY to find an error in what I say, >>>>>> and be based on more than just that you think that can't be right. >>>>>> But you can't do that, as you don't actually know any facts about the >>>>>> field that you can point to qualified references. >>>>> You cannot show that my premises are actually false. >>>>> To show that they are false would at least require showing that they >>>>> contradict each other. >>>> Accepting your premises makes the problem uninteresting. >>> That seems to indicate that you are admitting that you cheated when you >>> discussed this with ChatGPT. You gave it a faulty basis and then argued >>> against that. >> Just no. Do you believe that I didn't write this myself after all? >> >>> They also conventional within the context of software engineering. That >>> software engineering conventions seem incompatible with computer science >>> conventions may refute the latter. >> lol >> >>> The a halt decider must report on the behavior that itself is contained >>> within seems to be an incorrect convention. >> Just because you don't like the undecidability of the halting problem? >> >>> u32 HHH1(ptr P) // line 721 >>> u32 HHH(ptr P) // line 801 >>> The above two functions have identical C code except for their name. >>> >>> The input to HHH1(DDD) halts. The input to HHH(DDD) does not halt. This >>> conclusively proves that the pathological relationship between DDD and >>> HHH makes a difference in the behavior of DDD. >> That makes no sense. DDD halts or doesn't either way. HHH and HHH1 may >> give different answers, but then exactly one of them must be wrong. >> Do they both call HHH? How does their execution differ? >> > > DDD halts. HHH says DDD doesn't halt. HHH1 says DDD halts. HHH is > wrong, just as you say. > *ChatGPT explains in complete detail how and why I have always* *been right about this and everyone else has been wrong* https://chatgpt.com/share/6709e046-4794-8011-98b7-27066fb49f3e Perhaps you did not know that the only way that Russell's paradox was resolved was that ZFC corrected the incoherent foundations specified by https://en.wikipedia.org/wiki/Naive_set_theory > PO is totally confused about what his program does and why, so he > invents all sorts of magical explanations for what happens, like > "pathelogical self reference changes simulation behaviour" or whatever. > I have tried in the past to explain VERY CAREFULLY to PO why his "exact > copy" behaves differently from the source of the copy, but it just > washes over his head, and he carries on spouting the same garbage a few > days later. Bottom line: he just doesn't understand his own code. > > He claimed H1 was an exact copy of H and produced a different result > (blamed on PSR) but it turns out... IT WASN'T AN EXACT COPY. H and H1 > test addresses in the global trace entries against the addresses of H > and H1 respectively, so they are not identical after all. No surprise > they give different results for the same input D - nothing mysterious here! > > He claimed HHH1 was an exact copy of HHH and produced a different result > (blamed on PSR) but it turns out... IT WASN'T AN EXACT COPY. HHH and > HHH1 contain /their own/ *local static* variable (execution_trace) to > communicate between their nested simulations. (This is what is tested > to set Root differently for the outer simulation...) The result is that > HHH1 is effectively isolated from all simulations of DDD, because DDD is > using HHH's execution_trace rather than HHH1's. So HHH1 is effectively > a UTM with no abort logic, and sees the full DDD simulation. Long and > short of it: HHH/HHH1 implement different logic and are NOT copies, so > no surprise they give different results for the same input - nothing > mysterious here! > > PO doesn't half talk some bollocks about his own code! :) > > I see in a reply to you he claims: > .. > (b) HHH and HHH1 have verbatim identical c source > code, except for their differing names. > (c) DDD emulated by HHH has different behavior than > DDD emulated by HHH1. > > Well, the criterion for a copy is whether the algorithm described by the > code is exactly the original algorithm, NOT simply whether the C code is > identical. You are merely guessing the reason for the behavioral difference rather than making sure that you are correct. > By putting his naff local static execution_trace variable in > HHH/HHH1 which is shared between DDD [which calls HHH] and HHH, but not > between DDD and HHH1, he makes the /logic/ of HHH/HHH1 different. I > think he knows that because he is deliberately trying to mislead you in > his carefully wording focus on the "C" code being the same. The static variables have no effect what-so-ever on which instructions are emulated. If you pay enough attention to this you will understand. When HHH1(DDD) emulates DDD this DDD reaches its final state. When HHH(DDD) emulates DDD this DDD cannot possibly reach its final state. It is not that hard if you bother to pay enough attention. You are so sure that I am wrong that you simply don't bother to pay enough attention. > Well, if PO had done his coding properly in the first place and stuck to > the obvious restrictions like "no mutable static data" and so on, then ========== REMAINDER OF ARTICLE TRUNCATED ==========