| Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 17 12:22PM +0100 On Sun, 17 Jul 2022 04:17:31 -0700 (PDT) > A function which maps all of its inputs to one of two possible return > values; and a function which maps all of its inputs to one of two > possible exceptions are semantically equivalent. However a function which maps all of its inputs to one of THREE possible OUTCOMES is what we are actually talking about. > They answer one yes/no question. Whether the answer is signalled via > return value; or via an exception is just implementation detail. This > is how information works. But I am asserting that it isn't a yes/no question, I am asserting that it is a yes/no/invalid question. > Bye, Olcott. Derp. /Flibble |
| Skep Dick <skepdick22@gmail.com>: Jul 17 04:27AM -0700 On Sunday, 17 July 2022 at 13:22:30 UTC+2, Mr Flibble wrote: > However a function which maps all of its inputs to one of THREE > possible OUTCOMES is what we are actually talking about. Yes. So it's a M:3 (Many-to-3) mapping. You can implement that as a void function which throws one of three possible exceptions. Or you can implement this as an function which returns 0,1 or 2. They are semantically equivalent. |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 17 12:30PM +0100 On Sun, 17 Jul 2022 04:27:16 -0700 (PDT) > possible exceptions. Or you can implement this as an function which > returns 0,1 or 2. > They are semantically equivalent. However that is different to a halt decider that returns a value to its caller (halts/doesn't halt) OR throws an exception: throwing an exception is NOT semantically equivalent to returning a value to a caller. /Flibble |
| Skep Dick <skepdick22@gmail.com>: Jul 17 04:37AM -0700 On Sunday, 17 July 2022 at 13:30:34 UTC+2, Mr Flibble wrote: > its caller (halts/doesn't halt) OR throws an exception: throwing an > exception is NOT semantically equivalent to returning a value to a > caller. The fact that you can't grasp that it's semantically equivalent is where all of your confusion lies. The caller is asking a simple question: Does this function halt? The possible answers from a halting-decider are: Yes, No, I don't know. Whether you represent those answers as integers, or exceptions is arbitrary (and inconsequential) implementation detail. Yes <-> (return 0) <-> throw yes() No <-> (return 1) <-> throw no() Don't know <-> (return 2) <-> throw undecidable() |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 17 12:44PM +0100 On Sun, 17 Jul 2022 04:37:27 -0700 (PDT) > Yes <-> (return 0) <-> throw yes() > No <-> (return 1) <-> throw no() > Don't know <-> (return 2) <-> throw undecidable() I am not confused, you are. The third outcome isn't "don't know", the third outcome is "invalid input". Another reason you are wrong is that you are assuming the exception that is thrown is an exception made within the simulation itself (so would be catchable by the simulated input): it isn't, it is an exception thrown by the simulator EXTERNALLY to the simulation. /Flibble |
| Skep Dick <skepdick22@gmail.com>: Jul 17 04:53AM -0700 On Sunday, 17 July 2022 at 13:45:02 UTC+2, Mr Flibble wrote: > I am not confused, you are. OK, Olcott. > The third outcome isn't "don't know", the > third outcome is "invalid input". Potato, Potatoh. Yes <-> return 0 <-> throw Yes() No <-> return 1 <-> throw No() Invalid input <-> return 2 <-> throw invalid() > within the simulation itself (so would be catchable by the simulated > input): it isn't, it is an exception thrown by the simulator > EXTERNALLY to the simulation. I am not making any such assumptions. I am pointing out that as the caller to a function I can observe its return values just as effectively as I can observe its exceptions. Whether I choose to handle those exceptions or not is entirely up to me. In [1]: def f(): ...: return True ...: In [2]: def g(): ...: raise RuntimeError ...: In [3]: f() Out[3]: True In [4]: g() RuntimeError |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 17 12:59PM +0100 On Sun, 17 Jul 2022 04:53:37 -0700 (PDT) > Out[3]: True > In [4]: g() > RuntimeError A function returning a value to its caller is quite different to a function raising an exception UNLESS the caller is aware of the possibility of such an exception AND catches it. This is why the two are semantically different. /Flibble |
| Skep Dick <skepdick22@gmail.com>: Jul 17 05:03AM -0700 On Sunday, 17 July 2022 at 13:59:55 UTC+2, Mr Flibble wrote: > function raising an exception UNLESS the caller is aware of the > possibility of such an exception AND catches it. This is why the two > are semantically different. I don't want to catch; or handle the exception. I have observed it. Like I observed the return value. My question is answered. The end. |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 17 01:04PM +0100 On Sun, 17 Jul 2022 05:03:45 -0700 (PDT) > I don't want to catch; or handle the exception. I have observed it. > Like I observed the return value. > My question is answered. The end. You have been shown your mistake. The end. /Flibble |
| Skep Dick <skepdick22@gmail.com>: Jul 17 05:11AM -0700 On Sunday, 17 July 2022 at 14:05:15 UTC+2, Mr Flibble wrote: > You have been shown your mistake. The end. See! It's Olcott. |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 17 01:24PM +0100 On Sun, 17 Jul 2022 05:11:16 -0700 (PDT) > On Sunday, 17 July 2022 at 14:05:15 UTC+2, Mr Flibble wrote: > > You have been shown your mistake. The end. > See! It's Olcott. The difference between me and Olcott is that I am not going to waste years of life on a problem that even if solved (I believe my signaling decider refutes the HP proofs) has no practical utility unless quantum computing can make it practical. /Flibble |
| Skep Dick <skepdick22@gmail.com>: Jul 17 05:31AM -0700 On Sunday, 17 July 2022 at 14:24:53 UTC+2, Mr Flibble wrote: > years of life on a problem that even if solved (I believe my > signaling decider refutes the HP proofs) has no practical utility unless > quantum computing can make it practical. The similarity between you and Olcott: same fragile ego - incapable of self-correction. |
| olcott <polcott2@gmail.com>: Jul 17 07:48AM -0500 On 7/16/2022 12:32 PM, David Brown wrote: > C and C++ newsgroups. The same applies to Skep Dick, Chris Thomasson, > and others who encourage this online vandal. > (My email address is valid if you want to comment directly.) I responded in email again last night at Jul 16, 2022, 7:11 PM (12 hours ago) -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| olcott <NoOne@NoWhere.com>: Jul 17 08:04AM -0500 On 7/17/2022 7:31 AM, Skep Dick wrote: >> signaling decider refutes the HP proofs) has no practical utility unless >> quantum computing can make it practical. > The similarity between you and Olcott: same fragile ego - incapable of self-correction. You just aren't bright enough to follow the key details and you take your lack of comprehension as evidence that I am incorrect. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| David Brown <david.brown@hesbynett.no>: Jul 17 03:25PM +0200 On 17/07/2022 14:48, olcott wrote: >> (My email address is valid if you want to comment directly.) > I responded in email again last night at > Jul 16, 2022, 7:11 PM (12 hours ago) To be clear here - these threads are entirely inappropriate for c.l.c and c.l.c++, and have apparently ruined comp.theory. We do not want them here. If people want to discuss Olcott's theories with him in a serious manner, then they can do so by email. (We have had a couple of emails back and forth, outside this newsgroup. Whether we make any progress remains to be seen, but it is not bothering other people.) If you do not get useful responses from him by email, you certainly will not do so here in these Usenet groups. So please, Olcott, Flibble, and others - stick to email, or find a different and /appropriate/ forum for these discussions. It is not really asking too much, just basic politeness and human decency. |
| olcott <NoOne@NoWhere.com>: Jul 17 08:33AM -0500 On 7/17/2022 8:25 AM, David Brown wrote: > So please, Olcott, Flibble, and others - stick to email, or find a > different and /appropriate/ forum for these discussions. It is not > really asking too much, just basic politeness and human decency. Flibble is clueless, SkepDick seems mostly clueless, Richard is only clueless on the most important points. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 17 02:38PM +0100 On Sat, 16 Jul 2022 19:32:53 +0200 > (or work on /real/ computability > theory topics, as it is an interesting field). A field is no longer interesting if so called experts in that field, people who have invested years of their life into it, dismiss anything that contradicts what they consider to be "accepted", "solved" or "settled" when all it actually is is something that they have learned by rote. /Flibble |
| Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 17 02:40PM +0100 On Sun, 17 Jul 2022 08:33:36 -0500 > > really asking too much, just basic politeness and human decency. > Flibble is clueless, SkepDick seems mostly clueless, Richard is only > clueless on the most important points. If I am clueless then explain why my signaling decider answers the following correctly whilst your naive decider does not? void Px(void (*x)()) { (void) H(x, x); return; } /Flibble |
| Skep Dick <skepdick22@gmail.com>: Jul 17 06:49AM -0700 On Sunday, 17 July 2022 at 15:04:23 UTC+2, olcott wrote: > You just aren't bright enough to follow the key details and you take > your lack of comprehension as evidence that I am incorrect. No. I am taking the fact that you are incorrect as evidence that you are incorrect. But as David has pointed out engagement is counter-productive here. We all know you are basically exploiting Cunningham's law, and so I refuse to give you my time any further till you recognise and acknowledge your error. |
| Skep Dick <skepdick22@gmail.com>: Jul 17 06:59AM -0700 On Sunday, 17 July 2022 at 15:38:41 UTC+2, Mr Flibble wrote: > that contradicts what they consider to be "accepted", "solved" or > "settled" when all it actually is is something that they have learned by > rote. The error you are making is that you think what you are doing contradicts the field. It doesn't. What you are doing only contradicts your naive misunderstanding of the field. It's a good old strawman. |
| olcott <NoOne@NoWhere.com>: Jul 17 09:03AM -0500 On 7/17/2022 8:25 AM, David Brown wrote: > So please, Olcott, Flibble, and others - stick to email, or find a > different and /appropriate/ forum for these discussions. It is not > really asking too much, just basic politeness and human decency. Our email dialogue seems to be going so well that I may get closure very soon and not need to talk on USENET about this. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Richard Damon <Richard@Damon-Family.org>: Jul 17 07:37AM -0400 On 7/16/22 11:11 PM, olcott wrote: > H(P,P) the simulated P remains stuck calling H(P,P) to simulate itself > again thus forever preventing this simulated P from ever terminating > normally by reaching its C:"return" or x86:"ret" instruction. Except it doesn't because H is KNOWN to abort its simulation when it sees that the simulation will reach the first call to H in the simulation. You logic is based on the assumption that H actually won't stop simulating its input, when in actual fact it will. Thus you have a false premise in your logic, so H never actually proved its fact considering the H that it is. Yes, H can prove that IF H never aborts, that this makes a P that never halts. But since this is NOT the definition of H, that doesn't say anything about what the machine where H does abort its simulation. This points us to the fundamental issue, you are using an unproven definition of what a Halting Decider decides on. The REAL definition is based on if the machine when run will come to a halt or not. Your definition is based on the potentially partial simulation by H, you need to prove the condtions match, EVEN IF THE INPUT REFERS TO THE DECIDER H (since that is an allowed condition). In particular, you definition must match the results for the program P as defined or it is proved to not be equivalent, which it does not. > *H(P,P) correctly determines that its input never halts* FALSE. You use an incorrect rule. The fact that P(P) calls H(P,P) with no conditional in P does NOT prove that its input will never halt if H has code that detects this case and stops its simulation, as that demonstartionally doesn't have infinite behavior. H needs to look at the program that IS there, including ALL the behavior of H which is part of it. |
| olcott <NoOne@NoWhere.com>: Jul 17 08:23AM -0500 On 7/17/2022 6:37 AM, Richard Damon wrote: > Yes, H can prove that IF H never aborts, that this makes a P that never > halts. But since this is NOT the definition of H, that doesn't say > anything about what the machine where H does abort its simulation. Halting means terminated normally when the correctly simulated P reaches its last instruction. Even though I have corrected you on this many hundreds of times you still fail to understand that an aborted simulation does not mean that the simulated input halted. You are moronically stupid on this point. Unless the concept of a UTM is bogus the actual behavior of the correctly simulated input does specify the behavior that H must examine. As soon as any simulating halt decider correctly determines that its simulated input would never terminate normally it is correct to report this simulation and report non-halting. > based on if the machine when run will come to a halt or not. > Your definition is based on the potentially partial simulation by H, you > need to prove the condtions match, I did do this you just aren't smart enough to understand. (1) Function H() is called from P(). (2) With the same arguments to H(). (3) With no instructions in P preceding its invocation of H(P,P) that could escape repeated simulations. The above shows that the simulated P cannot possibly (reachs it "return" instruction and) terminate normally. H(P,P) simulates its input then P calls H(P,P) to simulate itself again. When H sees that this otherwise infinitely nested simulation would never end it aborts its simulation of P and rejects P as non-halting. > DECIDER H (since that is an allowed condition). > In particular, you definition must match the results for the program P > as defined or it is proved to not be equivalent, which it does not. Then you continue to reject the concept of a UTM. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| olcott <NoOne@NoWhere.com>: Jul 17 08:24AM -0500 On 7/17/2022 6:37 AM, Richard Damon wrote: >> terminating normally by reaching its C:"return" or x86:"ret" instruction. > Except it doesn't because H is KNOWN to abort its simulation when it > sees that the simulation will reach the first call to H in the simulation. The problem here is that you remain moronically stupid on this point, initially took it as dishonesty because I would not believe that someone was actually that stupid. *Mike already corrected you on this moronically stupid point* On 7/16/2022 2:28 PM, Mike Terry wrote: -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| olcott <NoOne@NoWhere.com>: Jul 17 07:51AM -0500 On 7/17/2022 5:35 AM, Skep Dick wrote: > Your closure-seeking loop seems to be stuck in an infinite loop. > If your halting decider actually worked you would've terminated your closure-seeking loop by now. > Irony has a certain flavour... The problem is that I perfectly makes my point and my reviewers simply ignore all these words and change the subject. -- Copyright 2022 Pete Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment