Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

"I'm not afraid of dying, I just don't want to be there when it happens." -- Woody Allen


devel / comp.theory / Re: A plea...

SubjectAuthor
* A plea...Gawr Gura
`* A plea...olcott
 +* A plea...Mr Flibble
 |`* A plea...Richard Damon
 | `* A plea...Mr Flibble
 |  `* A plea...Richard Damon
 |   `* A plea...Mr Flibble
 |    `* A plea...Richard Damon
 |     `* A plea...Mr Flibble
 |      `* A plea...Richard Damon
 |       `* A plea...Mr Flibble
 |        `* A plea...Richard Damon
 |         `* A plea...Mr Flibble
 |          +* A plea...olcott
 |          |`- A plea...Mr Flibble
 |          `* A plea...Richard Damon
 |           `* A plea...Mr Flibble
 |            `* A plea...Richard Damon
 |             `* A plea...Mr Flibble
 |              `* A plea...Richard Damon
 |               `* A plea...Mr Flibble
 |                `* A plea...Richard Damon
 |                 `* A plea...Mr Flibble
 |                  `* A plea...Richard Damon
 |                   +- A plea...Mr Flibble
 |                   `* A plea...Mr Flibble
 |                    `* A plea...Richard Damon
 |                     `* A plea...Mr Flibble
 |                      `* A plea...Richard Damon
 |                       `* A plea...Mr Flibble
 |                        `* A plea...Richard Damon
 |                         `- A plea...Richard Harnden
 `- A plea...Richard Damon

Pages:12
Re: A plea...

<20220719180138.00004db7@reddwarf.jmc.corp>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35849&group=comp.theory#35849

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!feeder.usenetexpress.com!tr2.eu1.usenetexpress.com!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx07.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc.corp (Mr Flibble)
Newsgroups: comp.theory
Subject: Re: A plea...
Message-ID: <20220719180138.00004db7@reddwarf.jmc.corp>
References: <87k08c79ys.fsf@bsb.me.uk> <tb1ioe$3pvna$1@dont-email.me> <qqmdnSf3Qa8sy0n_nZ2dnUU7_8zNnZ2d@giganews.com> <20220717200508.000078e9@reddwarf.jmc.corp> <1AZAK.598124$wIO9.69713@fx12.iad> <20220717205331.0000461e@reddwarf.jmc.corp> <fc%AK.397559$vAW9.238590@fx10.iad> <20220717224436.00002c66@reddwarf.jmc.corp> <qE%AK.514397$ntj.427354@fx15.iad> <20220717230620.00001532@reddwarf.jmc.corp> <Um0BK.514846$ntj.83746@fx15.iad> <20220717235402.00002719@reddwarf.jmc.corp> <hO0BK.48201$Ae2.4639@fx35.iad> <20220718002744.00002d25@reddwarf.jmc.corp> <up2BK.40810$Sf2.38749@fx34.iad> <20220718021821.000056d2@reddwarf.jmc.corp> <qN2BK.57711$sZ1.19122@fx07.iad> <20220718073646.000070ff@reddwarf.jmc.corp> <GobBK.581682$JVi.394817@fx17.iad> <20220718172136.000029ad@reddwarf.jmc.corp> <tXlBK.517864$ntj.364914@fx15.iad> <20220719083420.00005f0f@reddwarf.jmc.corp> <vrwBK.33025$8f2.30099@fx38.iad>
Organization: Jupiter Mining Corporation
X-Newsreader: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Lines: 512
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Tue, 19 Jul 2022 17:01:38 UTC
Date: Tue, 19 Jul 2022 18:01:38 +0100
X-Received-Bytes: 22952
 by: Mr Flibble - Tue, 19 Jul 2022 17:01 UTC

On Tue, 19 Jul 2022 07:19:55 -0400
Richard Damon <Richard@Damon-Family.org> wrote:

> On 7/19/22 3:34 AM, Mr Flibble wrote:
> > On Mon, 18 Jul 2022 19:23:04 -0400
> > Richard Damon <Richard@Damon-Family.org> wrote:
> >
> >> On 7/18/22 12:21 PM, Mr Flibble wrote:
> >>> On Mon, 18 Jul 2022 07:23:17 -0400
> >>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>
> >>>> On 7/18/22 2:36 AM, Mr Flibble wrote:
> >>>>> On Sun, 17 Jul 2022 21:35:18 -0400
> >>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>
> >>>>>> On 7/17/22 9:18 PM, Mr Flibble wrote:
> >>>>>>> On Sun, 17 Jul 2022 21:09:45 -0400
> >>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>
> >>>>>>>> On 7/17/22 7:27 PM, Mr Flibble wrote:
> >>>>>>>>> On Sun, 17 Jul 2022 19:19:40 -0400
> >>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 7/17/22 6:54 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Sun, 17 Jul 2022 18:50:28 -0400
> >>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 7/17/22 6:06 PM, Mr Flibble wrote:
> >>>>>>>>>>>>> On Sun, 17 Jul 2022 18:00:54 -0400
> >>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 7/17/22 5:44 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>> On Sun, 17 Jul 2022 17:30:50 -0400
> >>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 7/17/22 3:53 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 15:39:40 -0400
> >>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 7/17/22 3:05 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 13:36:32 -0500
> >>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On 7/17/2022 1:00 PM, Gawr Gura wrote:
> >>>>>>>>>>>>>>>>>>>>> On 7/16/22 19:24, Ben Bacarisse wrote:
> >>>>>>>>>>>>>>>>>>>>>> Please don't respond to Peter Olcott's posts
> >>>>>>>>>>>>>>>>>>>>>> here. His threads have taken over comp.theory,
> >>>>>>>>>>>>>>>>>>>>>> but there is no reason that comp.lang c (or
> >>>>>>>>>>>>>>>>>>>>>> comp.lang.c++) should suffer the same fate.
> >>>>>>>>>>>>>>>>>>>>>> These two groups have had many interesting
> >>>>>>>>>>>>>>>>>>>>>> threads over the years, but they will die if
> >>>>>>>>>>>>>>>>>>>>>> they fill up with junk.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> If you want to reply to him, just pick any of
> >>>>>>>>>>>>>>>>>>>>>> the thousands of posts in comp.theory and
> >>>>>>>>>>>>>>>>>>>>>> he'll be as happy to insult you and call you
> >>>>>>>>>>>>>>>>>>>>>> ignorant there as he is here.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I've not made this a head post because I don't
> >>>>>>>>>>>>>>>>>>>>>> want to single anyone out.  Everyone who'd got
> >>>>>>>>>>>>>>>>>>>>>> something out of comp.lang.c should care about
> >>>>>>>>>>>>>>>>>>>>>> its curation...
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Ben, I think the cranks have taken over the
> >>>>>>>>>>>>>>>>>>>>> asylum.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Flibble is a crank because he created a
> >>>>>>>>>>>>>>>>>>>> pathological input detector and continues to
> >>>>>>>>>>>>>>>>>>>> leave out the core piece, the criterion measure
> >>>>>>>>>>>>>>>>>>>> of detecting a pathological input.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The design of my signaling decider clearly sets
> >>>>>>>>>>>>>>>>>>> out how pathological input is detected:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> https://github.com/i42output/halting-problem/blob/main/README.txt
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The implementation details of how halting or
> >>>>>>>>>>>>>>>>>>> non-halting are actually decided are not described
> >>>>>>>>>>>>>>>>>>> in the design nor need they be for me to not be a
> >>>>>>>>>>>>>>>>>>> "crank".
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The one problem with your design is that you have
> >>>>>>>>>>>>>>>>>> adopted the same faulty simulate the input in the
> >>>>>>>>>>>>>>>>>> same program memory space as the decider that Peter
> >>>>>>>>>>>>>>>>>> uses, which means that you won't actually be able
> >>>>>>>>>>>>>>>>>> to convert the design into two seperate Turing
> >>>>>>>>>>>>>>>>>> Machines, one for the H that is being asked to
> >>>>>>>>>>>>>>>>>> decide, and one for P that has its own copy of H,
> >>>>>>>>>>>>>>>>>> which needs to be run as a machine to see what its
> >>>>>>>>>>>>>>>>>> answer is and also given to H to see what it
> >>>>>>>>>>>>>>>>>> decides (though the second might be able to be
> >>>>>>>>>>>>>>>>>> extracted out of the run of the first).
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The problem here is that H can't just simply
> >>>>>>>>>>>>>>>>>> compare "addresses" to detect calls to "itself",
> >>>>>>>>>>>>>>>>>> but needs to be able to detect a "copy" of itself
> >>>>>>>>>>>>>>>>>> embedded in another machine.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> In the slightly faulty execution description that
> >>>>>>>>>>>>>>>>>> Peter uses, which means there are some machines you
> >>>>>>>>>>>>>>>>>> can not provide to your machine, you system works
> >>>>>>>>>>>>>>>>>> if the program calls YOU H, and not a copy of it.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> [Strachey 1965] doesn't require two separate Turing
> >>>>>>>>>>>>>>>>> Machines as far as I can tell:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> rec routine P
> >>>>>>>>>>>>>>>>> § L : if T[P] goto L
> >>>>>>>>>>>>>>>>> Return §
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> [Strachey 1965] only talks about functions and not
> >>>>>>>>>>>>>>>>> Turing Machines: T is defined to be a *function
> >>>>>>>>>>>>>>>>> returning a boolean*.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I am less familiar with Strachey, if I remember
> >>>>>>>>>>>>>>>> right, T[P] passes to T the source code of P, and I
> >>>>>>>>>>>>>>>> guess he allows that source code to directly
> >>>>>>>>>>>>>>>> reference the decider that it is confounding.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Maybe you can make the class of deciders you are
> >>>>>>>>>>>>>>>> working on, with the added paradoxical output for
> >>>>>>>>>>>>>>>> that form, but it doesn't extend to the classical
> >>>>>>>>>>>>>>>> problem based on Turing Machines.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Of course, the issue is that T is defined to return
> >>>>>>>>>>>>>>>> boolean, and not an exception, and it still doesn't
> >>>>>>>>>>>>>>>> show that you CAN build a Halt Decider, just that
> >>>>>>>>>>>>>>>> this one simple counter example can be filtered out.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> T still returns a boolean for my signaling decider;
> >>>>>>>>>>>>>>> the exception is only thrown later on when pathology
> >>>>>>>>>>>>>>> is determined.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Which means it has 3 return conditions, returning true,
> >>>>>>>>>>>>>> returning false, or throwing the pathological
> >>>>>>>>>>>>>> exception. That is really a form of "return" for a
> >>>>>>>>>>>>>> function, just with a somewhat different method.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> If you translate into a Turing Machine, it just
> >>>>>>>>>>>>>> becomes a 3rd final state.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It only returns true or false to P; the exception is
> >>>>>>>>>>>>> thrown later, out of band.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> It Can't.
> >>>>>>>>>>>
> >>>>>>>>>>> It can and does.
> >>>>>>>>>>
> >>>>>>>>>> HOW. You use T to decide on P by writing T[P] just like P
> >>>>>>>>>> calls it.
> >>>>>>>>>
> >>>>>>>>> It returns BOTH true AND false to P as it doesn't YET know
> >>>>>>>>> if P is pathological and if it isn't whether it halts or
> >>>>>>>>> not; it will find that out as the simulation continues.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Your confusing what the actual function T does and how T
> >>>>>>>> simulates recursive calls to T.
> >>>>>>>>
> >>>>>>>> If T sees a call to T with the same parameter(s) as a
> >>>>>>>> previous call to T (or the original call to T) had, you
> >>>>>>>> replace them with a split where you return true to one side
> >>>>>>>> and return false to the other and process.
> >>>>>>>>
> >>>>>>>> When T is called by an actually running P, it needs to return
> >>>>>>>> the full decision, including the exception to that P, just as
> >>>>>>>> it does if directly asked (by main or just asked depending on
> >>>>>>>> how the language works).
> >>>>>>>
> >>>>>>> That is where we disagree: I see no reason why my scheme is
> >>>>>>> invalid: P doesn't actually care what T does, it acts on what
> >>>>>>> T returns. T returns both halting decisions to two copies of
> >>>>>>> P and allows the simulation to proceed with no recursion.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> The question then becomes, what does P do with that third
> >>>>>>>> answer? What are programs ALLOWED to do with that third
> >>>>>>>> answer.
> >>>>>>>
> >>>>>>> I already told you that P never sees the "third answer"
> >>>>>>> (exception) as that happens out of band.
> >>>>>>>
> >>>>>>
> >>>>>> The directly executed P does, at least if T[P] ever generates
> >>>>>> that third answer as an answer and "reports" it to its caller.
> >>>>>>
> >>>>>
> >>>>> Stop being so obtuse. The exception is not reported to its
> >>>>> caller (P) as it is not known at the point in the simulation if
> >>>>> the exceptional condition exits. My solution, unlike PO's, is
> >>>>> NOT infinitely recursive: think about what that actually means
> >>>>> and try re-reading my proposal AGAIN but this time try to
> >>>>> fucking comprehend it. The exception is an out of band signal.
> >>>>>
> >>>>
> >>>> I repeat, I am not talking about in the simulation, but in the
> >>>> initial call to H.
> >>>>
> >>>> What would be the results of:
> >>>>
> >>>> void P(x) {
> >>>> bool r = H(x,x);
> >>>> while (r) continue;
> >>>> }
> >>>>
> >>>> void main() {
> >>>> P(P);
> >>>> }
> >>>>
> >>>> I.e. main calls P(P) which calls your H(P,P), what happens THERE
> >>>> at THAT call site.
> >>>
> >>> sNaP exception due to H being passed an input from within the
> >>> input that has not previously been passed to H from outside the
> >>> input.
> >>
> >> So, you said it was like sNaN, so the program can be configured to
> >> catch this exception, right? Like show below.
> >
> > The "program" is that which is being decided by the decider so sNaP
> > is not observable/catchable/throwable by the "program".
> >
> >>
> >>>
> >>>>
> >>>> If sNaP is just like sNaN what happens if instead I make P be:
> >>>>
> >>>> void P(x) {
> >>>> bool r;
> >>>> try {
> >>>> r = H(P,P)l
> >>>> } catch(sNaO) {
> >>>> // Do something here like:
> >>>> r = true;
> >>>> }
> >>>> while (r) continue;
> >>>> }
> >>>
> >>> Inputs can't observe/catch the sNaP exception as it is
> >>> private to the decider.
> >>
> >> P isn't "Just an input", remember main CALLS P(P) so it is a
> >> program too.
> >>
> >> So, are you saying that the decider doesn't tell anyone about the
> >> exception, but it just means the whole machine stops?
> >
> > sNaP exception will be thrown for same reason given previously. The
> > "program" is that which is being decided by the decider so sNaP is
> > not observable/catchable/throwable by the "program".
> >
> >
> >>
> >> i.e. it is a Blue Screen of Death?
> >>
> >>>
> >>>>
> >>>>
> >>>> Also, what happens if I do:
> >>>>
> >>>> void P(x) {
> >>>> throw sNaP;
> >>>> }
> >>>>
> >>>> bool T(x) {
> >>>> return H(x,x);
> >>>> }
> >>>>
> >>>> void main() {
> >>>> Output(T(P,P));
> >>>> }
> >>>
> >>> Inputs can't throw the sNaP exception as it is private to the
> >>> decider.
> >>
> >> But other programs can as T for the computation system to be Turing
> >> Compllete, T can't be given powers to do things that other programs
> >> don't have.
> >>
> >> Since programs can throw, then inputs can represent programs that
> >> throw.
> >
> > The "program" is that which is being decided by the decider so sNaP
> > is not observable/catchable/throwable by the "program".
> >
> >>
> >>>
> >>>>
> >>>> i.e. what is the defined answer for an input that throws sNaP? If
> >>>> sNaP is like a signalling sNaN, and functions can return it,
> >>>> then H needs to process functions that can return it.
> >>>
> >>> Inputs can't throw the sNaP exception as it is private to the
> >>> decider.
> >>
> >> IMPOSSIBLE. Either the "results" of sNaP is a defined behavior of
> >> the computation system or it isn't
> >>
> >> If it is, then ANYONE can throw it.
> >>
> >> If it isn't, then NO ONE can throw it.
> >>
> >> If your computation system isn't complete in this manner, that
> >> Halting can be decidable, as if P can't generate the sNaP result,
> >> it can't be allowed to call T.
> >>
> >> Many non-Turing Complete systems can have Halting deciders if the
> >> decider has powers that the things it is deciding on can't have.
> >
> > The "program" is that which is being decided by the decider so sNaP
> > is not observable/catchable/throwable by the "program".
> >
> >>>
> >>>>
> >>>> These are the sorts of questions you need to think about and
> >>>> answer if you really want to create a new sort of decider to see
> >>>> what it can do.
> >>>
> >>> I have thought about them and I have provided you with answers. I
> >>> did state previously that I don't have to go into implementation
> >>> details of the signaling decider: the high level design should be
> >>> sufficient as long as the reader can apply a bit of intelligence
> >>> when reading it.
> >>
> >> You don't need to necessarily say how H does its job, but you do
> >> need to specify precisely AND COMPLETELY what that job is. That
> >> means you need to think about the corner cases. If only T can
> >> generate the exception, then T is NOT a program in the computaton
> >> system you have defined, as it is doing something "programs"
> >> aren't allowed to do.
> >>
> >> That makes T a not very interesting decider, as the Halting Problem
> >> has other possible solutions when the decider is a more powerful
> >> machine than what it is deciding on.
> >
> > Refuting [Strachey 1965] and associated proofs is quite
> > "interesting".
> >>
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>>>>
> >>>>>>>> Unstopable exceptions (FATAL ERRORS) become very unfriendly
> >>>>>>>> in use, but may be simpler to deal with in theory (but a lot
> >>>>>>>> less useful).
> >>>>>>>
> >>>>>>> In your opinion; again I disagree.
> >>>>>>
> >>>>>> How often does YOUR computer just shut itself down in reponse
> >>>>>> to being given a bad probem?
> >>>>>>
> >>>>>> THAT is the actual effect of a truely unstoppable exception.
> >>>>>>
> >>>>>> BLUE SCREEN OF DEATH time.
> >>>>>
> >>>>> An operating system panic is quite different to a userland
> >>>>> program raising an exception. The sNaP exception is equivalent
> >>>>> to the sNaN exception of IEEE 754 floating point.
> >>>>
> >>>> Nope, that is the result of a exception that can not be caught at
> >>>> all. The only way to keep software from catching the exception is
> >>>> to shut the system down.
> >>>
> >>> The input cannot catch the sNaP exception as it is private to the
> >>> decider.
> >>
> >> Note the "Input" but the CALLER of the decider, that supposedly you
> >> are returning an answer too.
> >
> > The "program" is that which is being decided by the decider so sNaP
> > is not observable/catchable/throwable by the "program".
> >
> >>
> >>>
> >>>>
> >>>> Remember, in basic computation theory, there is no such thing as
> >>>> "userland", so no saying that the exception goes through userland
> >>>> to the operating system.
> >>>
> >>> I can choose to present my solution within whatever domain I see
> >>> fit.
> >>
> >> Yes, and it can be a worthless solution if you restrict the problem
> >> domain to somethng uninteresting.
> >
> > Opinion.
> >
> >>
> >>>
> >>>>
> >>>> The sNaN exception is a CATCHABLE exception, that the program can
> >>>> cature and do something with it.
> >>>
> >>> The input cannot catch the sNaP exception as it is private to the
> >>> decider.
> >>
> >> I'm not saying the "INPUT", I'm saying to the CALLER of the
> >> decider.
> >>
> >> A decider that doesn't answer to its caller with its answer is to
> >> computation theory WORTHLESS.
> >
> > The decider does answer to its caller unless the input is
> > pathological in which case sNaP will be signaled.
> >
>
> So your decider is definied to Blue Screen of Death on pathological
> input.
>
> Note, Blue Screen of Death, likeyour sNaP is NOT an "Answer", because
> it is NOT given to the asker.
>
> That means that your sNaP is NOT like sNaN, as the later can, and
> normally IS captured by the program doing the operation, and in fact
> is DESIGNED to be captured by the program in use.
>
> Being signalling rather than quiet says the program MUST do something
> about it (or get aborted).
>
> >>
> >>>
> >>>>>>>> If you can't write a program that does something like, try to
> >>>>>>>> do thing 1, but if that throws a contradiction error, do
> >>>>>>>> thing 2 instead.
> >>>>>>>>
> >>>>>>>> This brings up the interesting question, if the input to T
> >>>>>>>> throws a contradiction error, what should T return? If
> >>>>>>>> contradiction errors are uncatchable, then the only choice is
> >>>>>>>> to return that same contradiction error, EVEN IF THE OTHER
> >>>>>>>> PATH HAD A GOOD ANSWER.
> >>>>>>>
> >>>>>>> You need to re-read my proposal again but this time try to
> >>>>>>> FULLY UNDERSTAND IT and understand the implications.
> >>>>>>
> >>>>>> It says that pathology is detected and reported.
> >>>>>>
> >>>>>> In Computation Theory a function "reports" by returning an
> >>>>>> answer in some way to its caller.
> >>>>>
> >>>>> The sNaP exception is reported by the simulator not by the
> >>>>> function H called by P: I have already told you what that H
> >>>>> does: it returns both true and false to copies of P and then
> >>>>> PROCEEDS WITH THE SIMULATION.
> >>>>
> >>>> Then you H is not the decider you claim. This is the error Peter
> >>>> had years ago when it was pointed out that if x86utm was the
> >>>> actual decider that then P would need to invoke x86utm with the
> >>>> input being itself applied to itself, but x86utm can't handle
> >>>> calls to things like system that would preform that action.
> >>>
> >>> The decider is the decider I claim, it is in fact EXACTLY the
> >>> decider I claim and it bears no resemblance to Peter's efforts.
> >>>
> >>> [snip]
> >>>
> >>> /Flibble
> >>>
> >>
> >> You keep on ignoring what the decider is returning to the actual
> >> program that is the CALLER of the decider.
> >>
> >> A decider that can't actually be called is totally uninteresting to
> >> Computation Theory.
> >
> > The "program" is that which is being decided by the decider so sNaP
> > is not observable/catchable/throwable by the "program".
> >
> > /Flibble
> >
>
> No, the "Program" is something that is run.
>
> If I Run P1, and P1 calls T[P2] then P1 is the caller program and P2
> is the input to T, which happens to represent a Program too.
>
> You seem to want to define your sNaP event as a Blue Screen of Death
> that immediately ends all computations, which makes it NOT a "answer"
> in the computation sense.
>
> Yes, maybe you see it as answering to the User who is operating the
> system, but that is not the normal step goal of a computation, as it
> means it can't be used to build up other operations.
>
> Yes, it is just about as useful as having a program somehow
> intentionally create a BSOD as a way to create an "answer".


Click here to read the complete article
Re: A plea...

<20220719181344.00001568@reddwarf.jmc.corp>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35850&group=comp.theory#35850

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!aioe.org!feeder1.feed.usenet.farm!feed.usenet.farm!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx07.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc.corp (Mr Flibble)
Newsgroups: comp.theory
Subject: Re: A plea...
Message-ID: <20220719181344.00001568@reddwarf.jmc.corp>
References: <87k08c79ys.fsf@bsb.me.uk>
<tb1ioe$3pvna$1@dont-email.me>
<qqmdnSf3Qa8sy0n_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220717200508.000078e9@reddwarf.jmc.corp>
<1AZAK.598124$wIO9.69713@fx12.iad>
<20220717205331.0000461e@reddwarf.jmc.corp>
<fc%AK.397559$vAW9.238590@fx10.iad>
<20220717224436.00002c66@reddwarf.jmc.corp>
<qE%AK.514397$ntj.427354@fx15.iad>
<20220717230620.00001532@reddwarf.jmc.corp>
<Um0BK.514846$ntj.83746@fx15.iad>
<20220717235402.00002719@reddwarf.jmc.corp>
<hO0BK.48201$Ae2.4639@fx35.iad>
<20220718002744.00002d25@reddwarf.jmc.corp>
<up2BK.40810$Sf2.38749@fx34.iad>
<20220718021821.000056d2@reddwarf.jmc.corp>
<qN2BK.57711$sZ1.19122@fx07.iad>
<20220718073646.000070ff@reddwarf.jmc.corp>
<GobBK.581682$JVi.394817@fx17.iad>
<20220718172136.000029ad@reddwarf.jmc.corp>
<tXlBK.517864$ntj.364914@fx15.iad>
<20220719083420.00005f0f@reddwarf.jmc.corp>
<vrwBK.33025$8f2.30099@fx38.iad>
Organization: Jupiter Mining Corporation
X-Newsreader: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Lines: 532
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Tue, 19 Jul 2022 17:13:44 UTC
Date: Tue, 19 Jul 2022 18:13:44 +0100
X-Received-Bytes: 23797
 by: Mr Flibble - Tue, 19 Jul 2022 17:13 UTC

On Tue, 19 Jul 2022 07:19:55 -0400
Richard Damon <Richard@Damon-Family.org> wrote:

> On 7/19/22 3:34 AM, Mr Flibble wrote:
> > On Mon, 18 Jul 2022 19:23:04 -0400
> > Richard Damon <Richard@Damon-Family.org> wrote:
> >
> >> On 7/18/22 12:21 PM, Mr Flibble wrote:
> >>> On Mon, 18 Jul 2022 07:23:17 -0400
> >>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>
> >>>> On 7/18/22 2:36 AM, Mr Flibble wrote:
> >>>>> On Sun, 17 Jul 2022 21:35:18 -0400
> >>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>
> >>>>>> On 7/17/22 9:18 PM, Mr Flibble wrote:
> >>>>>>> On Sun, 17 Jul 2022 21:09:45 -0400
> >>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>
> >>>>>>>> On 7/17/22 7:27 PM, Mr Flibble wrote:
> >>>>>>>>> On Sun, 17 Jul 2022 19:19:40 -0400
> >>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 7/17/22 6:54 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Sun, 17 Jul 2022 18:50:28 -0400
> >>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 7/17/22 6:06 PM, Mr Flibble wrote:
> >>>>>>>>>>>>> On Sun, 17 Jul 2022 18:00:54 -0400
> >>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 7/17/22 5:44 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>> On Sun, 17 Jul 2022 17:30:50 -0400
> >>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 7/17/22 3:53 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 15:39:40 -0400
> >>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 7/17/22 3:05 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 13:36:32 -0500
> >>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On 7/17/2022 1:00 PM, Gawr Gura wrote:
> >>>>>>>>>>>>>>>>>>>>> On 7/16/22 19:24, Ben Bacarisse wrote:
> >>>>>>>>>>>>>>>>>>>>>> Please don't respond to Peter Olcott's posts
> >>>>>>>>>>>>>>>>>>>>>> here. His threads have taken over comp.theory,
> >>>>>>>>>>>>>>>>>>>>>> but there is no reason that comp.lang c (or
> >>>>>>>>>>>>>>>>>>>>>> comp.lang.c++) should suffer the same fate.
> >>>>>>>>>>>>>>>>>>>>>> These two groups have had many interesting
> >>>>>>>>>>>>>>>>>>>>>> threads over the years, but they will die if
> >>>>>>>>>>>>>>>>>>>>>> they fill up with junk.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> If you want to reply to him, just pick any of
> >>>>>>>>>>>>>>>>>>>>>> the thousands of posts in comp.theory and
> >>>>>>>>>>>>>>>>>>>>>> he'll be as happy to insult you and call you
> >>>>>>>>>>>>>>>>>>>>>> ignorant there as he is here.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I've not made this a head post because I don't
> >>>>>>>>>>>>>>>>>>>>>> want to single anyone out.  Everyone who'd got
> >>>>>>>>>>>>>>>>>>>>>> something out of comp.lang.c should care about
> >>>>>>>>>>>>>>>>>>>>>> its curation...
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Ben, I think the cranks have taken over the
> >>>>>>>>>>>>>>>>>>>>> asylum.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Flibble is a crank because he created a
> >>>>>>>>>>>>>>>>>>>> pathological input detector and continues to
> >>>>>>>>>>>>>>>>>>>> leave out the core piece, the criterion measure
> >>>>>>>>>>>>>>>>>>>> of detecting a pathological input.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The design of my signaling decider clearly sets
> >>>>>>>>>>>>>>>>>>> out how pathological input is detected:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> https://github.com/i42output/halting-problem/blob/main/README.txt
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The implementation details of how halting or
> >>>>>>>>>>>>>>>>>>> non-halting are actually decided are not described
> >>>>>>>>>>>>>>>>>>> in the design nor need they be for me to not be a
> >>>>>>>>>>>>>>>>>>> "crank".
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The one problem with your design is that you have
> >>>>>>>>>>>>>>>>>> adopted the same faulty simulate the input in the
> >>>>>>>>>>>>>>>>>> same program memory space as the decider that Peter
> >>>>>>>>>>>>>>>>>> uses, which means that you won't actually be able
> >>>>>>>>>>>>>>>>>> to convert the design into two seperate Turing
> >>>>>>>>>>>>>>>>>> Machines, one for the H that is being asked to
> >>>>>>>>>>>>>>>>>> decide, and one for P that has its own copy of H,
> >>>>>>>>>>>>>>>>>> which needs to be run as a machine to see what its
> >>>>>>>>>>>>>>>>>> answer is and also given to H to see what it
> >>>>>>>>>>>>>>>>>> decides (though the second might be able to be
> >>>>>>>>>>>>>>>>>> extracted out of the run of the first).
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The problem here is that H can't just simply
> >>>>>>>>>>>>>>>>>> compare "addresses" to detect calls to "itself",
> >>>>>>>>>>>>>>>>>> but needs to be able to detect a "copy" of itself
> >>>>>>>>>>>>>>>>>> embedded in another machine.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> In the slightly faulty execution description that
> >>>>>>>>>>>>>>>>>> Peter uses, which means there are some machines you
> >>>>>>>>>>>>>>>>>> can not provide to your machine, you system works
> >>>>>>>>>>>>>>>>>> if the program calls YOU H, and not a copy of it.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> [Strachey 1965] doesn't require two separate Turing
> >>>>>>>>>>>>>>>>> Machines as far as I can tell:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> rec routine P
> >>>>>>>>>>>>>>>>> § L : if T[P] goto L
> >>>>>>>>>>>>>>>>> Return §
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> [Strachey 1965] only talks about functions and not
> >>>>>>>>>>>>>>>>> Turing Machines: T is defined to be a *function
> >>>>>>>>>>>>>>>>> returning a boolean*.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I am less familiar with Strachey, if I remember
> >>>>>>>>>>>>>>>> right, T[P] passes to T the source code of P, and I
> >>>>>>>>>>>>>>>> guess he allows that source code to directly
> >>>>>>>>>>>>>>>> reference the decider that it is confounding.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Maybe you can make the class of deciders you are
> >>>>>>>>>>>>>>>> working on, with the added paradoxical output for
> >>>>>>>>>>>>>>>> that form, but it doesn't extend to the classical
> >>>>>>>>>>>>>>>> problem based on Turing Machines.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Of course, the issue is that T is defined to return
> >>>>>>>>>>>>>>>> boolean, and not an exception, and it still doesn't
> >>>>>>>>>>>>>>>> show that you CAN build a Halt Decider, just that
> >>>>>>>>>>>>>>>> this one simple counter example can be filtered out.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> T still returns a boolean for my signaling decider;
> >>>>>>>>>>>>>>> the exception is only thrown later on when pathology
> >>>>>>>>>>>>>>> is determined.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Which means it has 3 return conditions, returning true,
> >>>>>>>>>>>>>> returning false, or throwing the pathological
> >>>>>>>>>>>>>> exception. That is really a form of "return" for a
> >>>>>>>>>>>>>> function, just with a somewhat different method.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> If you translate into a Turing Machine, it just
> >>>>>>>>>>>>>> becomes a 3rd final state.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It only returns true or false to P; the exception is
> >>>>>>>>>>>>> thrown later, out of band.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> It Can't.
> >>>>>>>>>>>
> >>>>>>>>>>> It can and does.
> >>>>>>>>>>
> >>>>>>>>>> HOW. You use T to decide on P by writing T[P] just like P
> >>>>>>>>>> calls it.
> >>>>>>>>>
> >>>>>>>>> It returns BOTH true AND false to P as it doesn't YET know
> >>>>>>>>> if P is pathological and if it isn't whether it halts or
> >>>>>>>>> not; it will find that out as the simulation continues.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Your confusing what the actual function T does and how T
> >>>>>>>> simulates recursive calls to T.
> >>>>>>>>
> >>>>>>>> If T sees a call to T with the same parameter(s) as a
> >>>>>>>> previous call to T (or the original call to T) had, you
> >>>>>>>> replace them with a split where you return true to one side
> >>>>>>>> and return false to the other and process.
> >>>>>>>>
> >>>>>>>> When T is called by an actually running P, it needs to return
> >>>>>>>> the full decision, including the exception to that P, just as
> >>>>>>>> it does if directly asked (by main or just asked depending on
> >>>>>>>> how the language works).
> >>>>>>>
> >>>>>>> That is where we disagree: I see no reason why my scheme is
> >>>>>>> invalid: P doesn't actually care what T does, it acts on what
> >>>>>>> T returns. T returns both halting decisions to two copies of
> >>>>>>> P and allows the simulation to proceed with no recursion.
> >>>>>>>
> >>>>>>>>
> >>>>>>>> The question then becomes, what does P do with that third
> >>>>>>>> answer? What are programs ALLOWED to do with that third
> >>>>>>>> answer.
> >>>>>>>
> >>>>>>> I already told you that P never sees the "third answer"
> >>>>>>> (exception) as that happens out of band.
> >>>>>>>
> >>>>>>
> >>>>>> The directly executed P does, at least if T[P] ever generates
> >>>>>> that third answer as an answer and "reports" it to its caller.
> >>>>>>
> >>>>>
> >>>>> Stop being so obtuse. The exception is not reported to its
> >>>>> caller (P) as it is not known at the point in the simulation if
> >>>>> the exceptional condition exits. My solution, unlike PO's, is
> >>>>> NOT infinitely recursive: think about what that actually means
> >>>>> and try re-reading my proposal AGAIN but this time try to
> >>>>> fucking comprehend it. The exception is an out of band signal.
> >>>>>
> >>>>
> >>>> I repeat, I am not talking about in the simulation, but in the
> >>>> initial call to H.
> >>>>
> >>>> What would be the results of:
> >>>>
> >>>> void P(x) {
> >>>> bool r = H(x,x);
> >>>> while (r) continue;
> >>>> }
> >>>>
> >>>> void main() {
> >>>> P(P);
> >>>> }
> >>>>
> >>>> I.e. main calls P(P) which calls your H(P,P), what happens THERE
> >>>> at THAT call site.
> >>>
> >>> sNaP exception due to H being passed an input from within the
> >>> input that has not previously been passed to H from outside the
> >>> input.
> >>
> >> So, you said it was like sNaN, so the program can be configured to
> >> catch this exception, right? Like show below.
> >
> > The "program" is that which is being decided by the decider so sNaP
> > is not observable/catchable/throwable by the "program".
> >
> >>
> >>>
> >>>>
> >>>> If sNaP is just like sNaN what happens if instead I make P be:
> >>>>
> >>>> void P(x) {
> >>>> bool r;
> >>>> try {
> >>>> r = H(P,P)l
> >>>> } catch(sNaO) {
> >>>> // Do something here like:
> >>>> r = true;
> >>>> }
> >>>> while (r) continue;
> >>>> }
> >>>
> >>> Inputs can't observe/catch the sNaP exception as it is
> >>> private to the decider.
> >>
> >> P isn't "Just an input", remember main CALLS P(P) so it is a
> >> program too.
> >>
> >> So, are you saying that the decider doesn't tell anyone about the
> >> exception, but it just means the whole machine stops?
> >
> > sNaP exception will be thrown for same reason given previously. The
> > "program" is that which is being decided by the decider so sNaP is
> > not observable/catchable/throwable by the "program".
> >
> >
> >>
> >> i.e. it is a Blue Screen of Death?
> >>
> >>>
> >>>>
> >>>>
> >>>> Also, what happens if I do:
> >>>>
> >>>> void P(x) {
> >>>> throw sNaP;
> >>>> }
> >>>>
> >>>> bool T(x) {
> >>>> return H(x,x);
> >>>> }
> >>>>
> >>>> void main() {
> >>>> Output(T(P,P));
> >>>> }
> >>>
> >>> Inputs can't throw the sNaP exception as it is private to the
> >>> decider.
> >>
> >> But other programs can as T for the computation system to be Turing
> >> Compllete, T can't be given powers to do things that other programs
> >> don't have.
> >>
> >> Since programs can throw, then inputs can represent programs that
> >> throw.
> >
> > The "program" is that which is being decided by the decider so sNaP
> > is not observable/catchable/throwable by the "program".
> >
> >>
> >>>
> >>>>
> >>>> i.e. what is the defined answer for an input that throws sNaP? If
> >>>> sNaP is like a signalling sNaN, and functions can return it,
> >>>> then H needs to process functions that can return it.
> >>>
> >>> Inputs can't throw the sNaP exception as it is private to the
> >>> decider.
> >>
> >> IMPOSSIBLE. Either the "results" of sNaP is a defined behavior of
> >> the computation system or it isn't
> >>
> >> If it is, then ANYONE can throw it.
> >>
> >> If it isn't, then NO ONE can throw it.
> >>
> >> If your computation system isn't complete in this manner, that
> >> Halting can be decidable, as if P can't generate the sNaP result,
> >> it can't be allowed to call T.
> >>
> >> Many non-Turing Complete systems can have Halting deciders if the
> >> decider has powers that the things it is deciding on can't have.
> >
> > The "program" is that which is being decided by the decider so sNaP
> > is not observable/catchable/throwable by the "program".
> >
> >>>
> >>>>
> >>>> These are the sorts of questions you need to think about and
> >>>> answer if you really want to create a new sort of decider to see
> >>>> what it can do.
> >>>
> >>> I have thought about them and I have provided you with answers. I
> >>> did state previously that I don't have to go into implementation
> >>> details of the signaling decider: the high level design should be
> >>> sufficient as long as the reader can apply a bit of intelligence
> >>> when reading it.
> >>
> >> You don't need to necessarily say how H does its job, but you do
> >> need to specify precisely AND COMPLETELY what that job is. That
> >> means you need to think about the corner cases. If only T can
> >> generate the exception, then T is NOT a program in the computaton
> >> system you have defined, as it is doing something "programs"
> >> aren't allowed to do.
> >>
> >> That makes T a not very interesting decider, as the Halting Problem
> >> has other possible solutions when the decider is a more powerful
> >> machine than what it is deciding on.
> >
> > Refuting [Strachey 1965] and associated proofs is quite
> > "interesting".
> >>
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>>>>
> >>>>>>>> Unstopable exceptions (FATAL ERRORS) become very unfriendly
> >>>>>>>> in use, but may be simpler to deal with in theory (but a lot
> >>>>>>>> less useful).
> >>>>>>>
> >>>>>>> In your opinion; again I disagree.
> >>>>>>
> >>>>>> How often does YOUR computer just shut itself down in reponse
> >>>>>> to being given a bad probem?
> >>>>>>
> >>>>>> THAT is the actual effect of a truely unstoppable exception.
> >>>>>>
> >>>>>> BLUE SCREEN OF DEATH time.
> >>>>>
> >>>>> An operating system panic is quite different to a userland
> >>>>> program raising an exception. The sNaP exception is equivalent
> >>>>> to the sNaN exception of IEEE 754 floating point.
> >>>>
> >>>> Nope, that is the result of a exception that can not be caught at
> >>>> all. The only way to keep software from catching the exception is
> >>>> to shut the system down.
> >>>
> >>> The input cannot catch the sNaP exception as it is private to the
> >>> decider.
> >>
> >> Note the "Input" but the CALLER of the decider, that supposedly you
> >> are returning an answer too.
> >
> > The "program" is that which is being decided by the decider so sNaP
> > is not observable/catchable/throwable by the "program".
> >
> >>
> >>>
> >>>>
> >>>> Remember, in basic computation theory, there is no such thing as
> >>>> "userland", so no saying that the exception goes through userland
> >>>> to the operating system.
> >>>
> >>> I can choose to present my solution within whatever domain I see
> >>> fit.
> >>
> >> Yes, and it can be a worthless solution if you restrict the problem
> >> domain to somethng uninteresting.
> >
> > Opinion.
> >
> >>
> >>>
> >>>>
> >>>> The sNaN exception is a CATCHABLE exception, that the program can
> >>>> cature and do something with it.
> >>>
> >>> The input cannot catch the sNaP exception as it is private to the
> >>> decider.
> >>
> >> I'm not saying the "INPUT", I'm saying to the CALLER of the
> >> decider.
> >>
> >> A decider that doesn't answer to its caller with its answer is to
> >> computation theory WORTHLESS.
> >
> > The decider does answer to its caller unless the input is
> > pathological in which case sNaP will be signaled.
> >
>
> So your decider is definied to Blue Screen of Death on pathological
> input.
>
> Note, Blue Screen of Death, likeyour sNaP is NOT an "Answer", because
> it is NOT given to the asker.
>
> That means that your sNaP is NOT like sNaN, as the later can, and
> normally IS captured by the program doing the operation, and in fact
> is DESIGNED to be captured by the program in use.
>
> Being signalling rather than quiet says the program MUST do something
> about it (or get aborted).
>
> >>
> >>>
> >>>>>>>> If you can't write a program that does something like, try to
> >>>>>>>> do thing 1, but if that throws a contradiction error, do
> >>>>>>>> thing 2 instead.
> >>>>>>>>
> >>>>>>>> This brings up the interesting question, if the input to T
> >>>>>>>> throws a contradiction error, what should T return? If
> >>>>>>>> contradiction errors are uncatchable, then the only choice is
> >>>>>>>> to return that same contradiction error, EVEN IF THE OTHER
> >>>>>>>> PATH HAD A GOOD ANSWER.
> >>>>>>>
> >>>>>>> You need to re-read my proposal again but this time try to
> >>>>>>> FULLY UNDERSTAND IT and understand the implications.
> >>>>>>
> >>>>>> It says that pathology is detected and reported.
> >>>>>>
> >>>>>> In Computation Theory a function "reports" by returning an
> >>>>>> answer in some way to its caller.
> >>>>>
> >>>>> The sNaP exception is reported by the simulator not by the
> >>>>> function H called by P: I have already told you what that H
> >>>>> does: it returns both true and false to copies of P and then
> >>>>> PROCEEDS WITH THE SIMULATION.
> >>>>
> >>>> Then you H is not the decider you claim. This is the error Peter
> >>>> had years ago when it was pointed out that if x86utm was the
> >>>> actual decider that then P would need to invoke x86utm with the
> >>>> input being itself applied to itself, but x86utm can't handle
> >>>> calls to things like system that would preform that action.
> >>>
> >>> The decider is the decider I claim, it is in fact EXACTLY the
> >>> decider I claim and it bears no resemblance to Peter's efforts.
> >>>
> >>> [snip]
> >>>
> >>> /Flibble
> >>>
> >>
> >> You keep on ignoring what the decider is returning to the actual
> >> program that is the CALLER of the decider.
> >>
> >> A decider that can't actually be called is totally uninteresting to
> >> Computation Theory.
> >
> > The "program" is that which is being decided by the decider so sNaP
> > is not observable/catchable/throwable by the "program".
> >
> > /Flibble
> >
>
> No, the "Program" is something that is run.
>
> If I Run P1, and P1 calls T[P2] then P1 is the caller program and P2
> is the input to T, which happens to represent a Program too.
>
> You seem to want to define your sNaP event as a Blue Screen of Death
> that immediately ends all computations, which makes it NOT a "answer"
> in the computation sense.
>
> Yes, maybe you see it as answering to the User who is operating the
> system, but that is not the normal step goal of a computation, as it
> means it can't be used to build up other operations.
>
> Yes, it is just about as useful as having a program somehow
> intentionally create a BSOD as a way to create an "answer".


Click here to read the complete article
Re: A plea...

<THGBK.573696$X_i.35184@fx18.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35851&group=comp.theory#35851

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx18.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.11.0
Subject: Re: A plea...
Content-Language: en-US
Newsgroups: comp.theory
References: <87k08c79ys.fsf@bsb.me.uk> <tb1ioe$3pvna$1@dont-email.me>
<qqmdnSf3Qa8sy0n_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220717200508.000078e9@reddwarf.jmc.corp>
<1AZAK.598124$wIO9.69713@fx12.iad>
<20220717205331.0000461e@reddwarf.jmc.corp>
<fc%AK.397559$vAW9.238590@fx10.iad>
<20220717224436.00002c66@reddwarf.jmc.corp>
<qE%AK.514397$ntj.427354@fx15.iad>
<20220717230620.00001532@reddwarf.jmc.corp> <Um0BK.514846$ntj.83746@fx15.iad>
<20220717235402.00002719@reddwarf.jmc.corp> <hO0BK.48201$Ae2.4639@fx35.iad>
<20220718002744.00002d25@reddwarf.jmc.corp> <up2BK.40810$Sf2.38749@fx34.iad>
<20220718021821.000056d2@reddwarf.jmc.corp> <qN2BK.57711$sZ1.19122@fx07.iad>
<20220718073646.000070ff@reddwarf.jmc.corp>
<GobBK.581682$JVi.394817@fx17.iad>
<20220718172136.000029ad@reddwarf.jmc.corp>
<tXlBK.517864$ntj.364914@fx15.iad>
<20220719083420.00005f0f@reddwarf.jmc.corp> <vrwBK.33025$8f2.30099@fx38.iad>
<20220719181344.00001568@reddwarf.jmc.corp>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <20220719181344.00001568@reddwarf.jmc.corp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 549
Message-ID: <THGBK.573696$X_i.35184@fx18.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Tue, 19 Jul 2022 19:00:03 -0400
X-Received-Bytes: 24525
 by: Richard Damon - Tue, 19 Jul 2022 23:00 UTC

On 7/19/22 1:13 PM, Mr Flibble wrote:
> On Tue, 19 Jul 2022 07:19:55 -0400
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 7/19/22 3:34 AM, Mr Flibble wrote:
>>> On Mon, 18 Jul 2022 19:23:04 -0400
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 7/18/22 12:21 PM, Mr Flibble wrote:
>>>>> On Mon, 18 Jul 2022 07:23:17 -0400
>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>
>>>>>> On 7/18/22 2:36 AM, Mr Flibble wrote:
>>>>>>> On Sun, 17 Jul 2022 21:35:18 -0400
>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>
>>>>>>>> On 7/17/22 9:18 PM, Mr Flibble wrote:
>>>>>>>>> On Sun, 17 Jul 2022 21:09:45 -0400
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>
>>>>>>>>>> On 7/17/22 7:27 PM, Mr Flibble wrote:
>>>>>>>>>>> On Sun, 17 Jul 2022 19:19:40 -0400
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 7/17/22 6:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Sun, 17 Jul 2022 18:50:28 -0400
>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7/17/22 6:06 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 18:00:54 -0400
>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 7/17/22 5:44 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 17:30:50 -0400
>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 7/17/22 3:53 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 15:39:40 -0400
>>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 7/17/22 3:05 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 13:36:32 -0500
>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 7/17/2022 1:00 PM, Gawr Gura wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 7/16/22 19:24, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Please don't respond to Peter Olcott's posts
>>>>>>>>>>>>>>>>>>>>>>>> here. His threads have taken over comp.theory,
>>>>>>>>>>>>>>>>>>>>>>>> but there is no reason that comp.lang c (or
>>>>>>>>>>>>>>>>>>>>>>>> comp.lang.c++) should suffer the same fate.
>>>>>>>>>>>>>>>>>>>>>>>> These two groups have had many interesting
>>>>>>>>>>>>>>>>>>>>>>>> threads over the years, but they will die if
>>>>>>>>>>>>>>>>>>>>>>>> they fill up with junk.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> If you want to reply to him, just pick any of
>>>>>>>>>>>>>>>>>>>>>>>> the thousands of posts in comp.theory and
>>>>>>>>>>>>>>>>>>>>>>>> he'll be as happy to insult you and call you
>>>>>>>>>>>>>>>>>>>>>>>> ignorant there as he is here.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I've not made this a head post because I don't
>>>>>>>>>>>>>>>>>>>>>>>> want to single anyone out.  Everyone who'd got
>>>>>>>>>>>>>>>>>>>>>>>> something out of comp.lang.c should care about
>>>>>>>>>>>>>>>>>>>>>>>> its curation...
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Ben, I think the cranks have taken over the
>>>>>>>>>>>>>>>>>>>>>>> asylum.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Flibble is a crank because he created a
>>>>>>>>>>>>>>>>>>>>>> pathological input detector and continues to
>>>>>>>>>>>>>>>>>>>>>> leave out the core piece, the criterion measure
>>>>>>>>>>>>>>>>>>>>>> of detecting a pathological input.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The design of my signaling decider clearly sets
>>>>>>>>>>>>>>>>>>>>> out how pathological input is detected:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> https://github.com/i42output/halting-problem/blob/main/README.txt
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The implementation details of how halting or
>>>>>>>>>>>>>>>>>>>>> non-halting are actually decided are not described
>>>>>>>>>>>>>>>>>>>>> in the design nor need they be for me to not be a
>>>>>>>>>>>>>>>>>>>>> "crank".
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The one problem with your design is that you have
>>>>>>>>>>>>>>>>>>>> adopted the same faulty simulate the input in the
>>>>>>>>>>>>>>>>>>>> same program memory space as the decider that Peter
>>>>>>>>>>>>>>>>>>>> uses, which means that you won't actually be able
>>>>>>>>>>>>>>>>>>>> to convert the design into two seperate Turing
>>>>>>>>>>>>>>>>>>>> Machines, one for the H that is being asked to
>>>>>>>>>>>>>>>>>>>> decide, and one for P that has its own copy of H,
>>>>>>>>>>>>>>>>>>>> which needs to be run as a machine to see what its
>>>>>>>>>>>>>>>>>>>> answer is and also given to H to see what it
>>>>>>>>>>>>>>>>>>>> decides (though the second might be able to be
>>>>>>>>>>>>>>>>>>>> extracted out of the run of the first).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The problem here is that H can't just simply
>>>>>>>>>>>>>>>>>>>> compare "addresses" to detect calls to "itself",
>>>>>>>>>>>>>>>>>>>> but needs to be able to detect a "copy" of itself
>>>>>>>>>>>>>>>>>>>> embedded in another machine.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> In the slightly faulty execution description that
>>>>>>>>>>>>>>>>>>>> Peter uses, which means there are some machines you
>>>>>>>>>>>>>>>>>>>> can not provide to your machine, you system works
>>>>>>>>>>>>>>>>>>>> if the program calls YOU H, and not a copy of it.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> [Strachey 1965] doesn't require two separate Turing
>>>>>>>>>>>>>>>>>>> Machines as far as I can tell:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> rec routine P
>>>>>>>>>>>>>>>>>>> § L : if T[P] goto L
>>>>>>>>>>>>>>>>>>> Return §
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> [Strachey 1965] only talks about functions and not
>>>>>>>>>>>>>>>>>>> Turing Machines: T is defined to be a *function
>>>>>>>>>>>>>>>>>>> returning a boolean*.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I am less familiar with Strachey, if I remember
>>>>>>>>>>>>>>>>>> right, T[P] passes to T the source code of P, and I
>>>>>>>>>>>>>>>>>> guess he allows that source code to directly
>>>>>>>>>>>>>>>>>> reference the decider that it is confounding.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Maybe you can make the class of deciders you are
>>>>>>>>>>>>>>>>>> working on, with the added paradoxical output for
>>>>>>>>>>>>>>>>>> that form, but it doesn't extend to the classical
>>>>>>>>>>>>>>>>>> problem based on Turing Machines.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Of course, the issue is that T is defined to return
>>>>>>>>>>>>>>>>>> boolean, and not an exception, and it still doesn't
>>>>>>>>>>>>>>>>>> show that you CAN build a Halt Decider, just that
>>>>>>>>>>>>>>>>>> this one simple counter example can be filtered out.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> T still returns a boolean for my signaling decider;
>>>>>>>>>>>>>>>>> the exception is only thrown later on when pathology
>>>>>>>>>>>>>>>>> is determined.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Which means it has 3 return conditions, returning true,
>>>>>>>>>>>>>>>> returning false, or throwing the pathological
>>>>>>>>>>>>>>>> exception. That is really a form of "return" for a
>>>>>>>>>>>>>>>> function, just with a somewhat different method.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If you translate into a Turing Machine, it just
>>>>>>>>>>>>>>>> becomes a 3rd final state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It only returns true or false to P; the exception is
>>>>>>>>>>>>>>> thrown later, out of band.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It Can't.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It can and does.
>>>>>>>>>>>>
>>>>>>>>>>>> HOW. You use T to decide on P by writing T[P] just like P
>>>>>>>>>>>> calls it.
>>>>>>>>>>>
>>>>>>>>>>> It returns BOTH true AND false to P as it doesn't YET know
>>>>>>>>>>> if P is pathological and if it isn't whether it halts or
>>>>>>>>>>> not; it will find that out as the simulation continues.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Your confusing what the actual function T does and how T
>>>>>>>>>> simulates recursive calls to T.
>>>>>>>>>>
>>>>>>>>>> If T sees a call to T with the same parameter(s) as a
>>>>>>>>>> previous call to T (or the original call to T) had, you
>>>>>>>>>> replace them with a split where you return true to one side
>>>>>>>>>> and return false to the other and process.
>>>>>>>>>>
>>>>>>>>>> When T is called by an actually running P, it needs to return
>>>>>>>>>> the full decision, including the exception to that P, just as
>>>>>>>>>> it does if directly asked (by main or just asked depending on
>>>>>>>>>> how the language works).
>>>>>>>>>
>>>>>>>>> That is where we disagree: I see no reason why my scheme is
>>>>>>>>> invalid: P doesn't actually care what T does, it acts on what
>>>>>>>>> T returns. T returns both halting decisions to two copies of
>>>>>>>>> P and allows the simulation to proceed with no recursion.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The question then becomes, what does P do with that third
>>>>>>>>>> answer? What are programs ALLOWED to do with that third
>>>>>>>>>> answer.
>>>>>>>>>
>>>>>>>>> I already told you that P never sees the "third answer"
>>>>>>>>> (exception) as that happens out of band.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The directly executed P does, at least if T[P] ever generates
>>>>>>>> that third answer as an answer and "reports" it to its caller.
>>>>>>>>
>>>>>>>
>>>>>>> Stop being so obtuse. The exception is not reported to its
>>>>>>> caller (P) as it is not known at the point in the simulation if
>>>>>>> the exceptional condition exits. My solution, unlike PO's, is
>>>>>>> NOT infinitely recursive: think about what that actually means
>>>>>>> and try re-reading my proposal AGAIN but this time try to
>>>>>>> fucking comprehend it. The exception is an out of band signal.
>>>>>>>
>>>>>>
>>>>>> I repeat, I am not talking about in the simulation, but in the
>>>>>> initial call to H.
>>>>>>
>>>>>> What would be the results of:
>>>>>>
>>>>>> void P(x) {
>>>>>> bool r = H(x,x);
>>>>>> while (r) continue;
>>>>>> }
>>>>>>
>>>>>> void main() {
>>>>>> P(P);
>>>>>> }
>>>>>>
>>>>>> I.e. main calls P(P) which calls your H(P,P), what happens THERE
>>>>>> at THAT call site.
>>>>>
>>>>> sNaP exception due to H being passed an input from within the
>>>>> input that has not previously been passed to H from outside the
>>>>> input.
>>>>
>>>> So, you said it was like sNaN, so the program can be configured to
>>>> catch this exception, right? Like show below.
>>>
>>> The "program" is that which is being decided by the decider so sNaP
>>> is not observable/catchable/throwable by the "program".
>>>
>>>>
>>>>>
>>>>>>
>>>>>> If sNaP is just like sNaN what happens if instead I make P be:
>>>>>>
>>>>>> void P(x) {
>>>>>> bool r;
>>>>>> try {
>>>>>> r = H(P,P)l
>>>>>> } catch(sNaO) {
>>>>>> // Do something here like:
>>>>>> r = true;
>>>>>> }
>>>>>> while (r) continue;
>>>>>> }
>>>>>
>>>>> Inputs can't observe/catch the sNaP exception as it is
>>>>> private to the decider.
>>>>
>>>> P isn't "Just an input", remember main CALLS P(P) so it is a
>>>> program too.
>>>>
>>>> So, are you saying that the decider doesn't tell anyone about the
>>>> exception, but it just means the whole machine stops?
>>>
>>> sNaP exception will be thrown for same reason given previously. The
>>> "program" is that which is being decided by the decider so sNaP is
>>> not observable/catchable/throwable by the "program".
>>>
>>>
>>>>
>>>> i.e. it is a Blue Screen of Death?
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> Also, what happens if I do:
>>>>>>
>>>>>> void P(x) {
>>>>>> throw sNaP;
>>>>>> }
>>>>>>
>>>>>> bool T(x) {
>>>>>> return H(x,x);
>>>>>> }
>>>>>>
>>>>>> void main() {
>>>>>> Output(T(P,P));
>>>>>> }
>>>>>
>>>>> Inputs can't throw the sNaP exception as it is private to the
>>>>> decider.
>>>>
>>>> But other programs can as T for the computation system to be Turing
>>>> Compllete, T can't be given powers to do things that other programs
>>>> don't have.
>>>>
>>>> Since programs can throw, then inputs can represent programs that
>>>> throw.
>>>
>>> The "program" is that which is being decided by the decider so sNaP
>>> is not observable/catchable/throwable by the "program".
>>>
>>>>
>>>>>
>>>>>>
>>>>>> i.e. what is the defined answer for an input that throws sNaP? If
>>>>>> sNaP is like a signalling sNaN, and functions can return it,
>>>>>> then H needs to process functions that can return it.
>>>>>
>>>>> Inputs can't throw the sNaP exception as it is private to the
>>>>> decider.
>>>>
>>>> IMPOSSIBLE. Either the "results" of sNaP is a defined behavior of
>>>> the computation system or it isn't
>>>>
>>>> If it is, then ANYONE can throw it.
>>>>
>>>> If it isn't, then NO ONE can throw it.
>>>>
>>>> If your computation system isn't complete in this manner, that
>>>> Halting can be decidable, as if P can't generate the sNaP result,
>>>> it can't be allowed to call T.
>>>>
>>>> Many non-Turing Complete systems can have Halting deciders if the
>>>> decider has powers that the things it is deciding on can't have.
>>>
>>> The "program" is that which is being decided by the decider so sNaP
>>> is not observable/catchable/throwable by the "program".
>>>
>>>>>
>>>>>>
>>>>>> These are the sorts of questions you need to think about and
>>>>>> answer if you really want to create a new sort of decider to see
>>>>>> what it can do.
>>>>>
>>>>> I have thought about them and I have provided you with answers. I
>>>>> did state previously that I don't have to go into implementation
>>>>> details of the signaling decider: the high level design should be
>>>>> sufficient as long as the reader can apply a bit of intelligence
>>>>> when reading it.
>>>>
>>>> You don't need to necessarily say how H does its job, but you do
>>>> need to specify precisely AND COMPLETELY what that job is. That
>>>> means you need to think about the corner cases. If only T can
>>>> generate the exception, then T is NOT a program in the computaton
>>>> system you have defined, as it is doing something "programs"
>>>> aren't allowed to do.
>>>>
>>>> That makes T a not very interesting decider, as the Halting Problem
>>>> has other possible solutions when the decider is a more powerful
>>>> machine than what it is deciding on.
>>>
>>> Refuting [Strachey 1965] and associated proofs is quite
>>> "interesting".
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Unstopable exceptions (FATAL ERRORS) become very unfriendly
>>>>>>>>>> in use, but may be simpler to deal with in theory (but a lot
>>>>>>>>>> less useful).
>>>>>>>>>
>>>>>>>>> In your opinion; again I disagree.
>>>>>>>>
>>>>>>>> How often does YOUR computer just shut itself down in reponse
>>>>>>>> to being given a bad probem?
>>>>>>>>
>>>>>>>> THAT is the actual effect of a truely unstoppable exception.
>>>>>>>>
>>>>>>>> BLUE SCREEN OF DEATH time.
>>>>>>>
>>>>>>> An operating system panic is quite different to a userland
>>>>>>> program raising an exception. The sNaP exception is equivalent
>>>>>>> to the sNaN exception of IEEE 754 floating point.
>>>>>>
>>>>>> Nope, that is the result of a exception that can not be caught at
>>>>>> all. The only way to keep software from catching the exception is
>>>>>> to shut the system down.
>>>>>
>>>>> The input cannot catch the sNaP exception as it is private to the
>>>>> decider.
>>>>
>>>> Note the "Input" but the CALLER of the decider, that supposedly you
>>>> are returning an answer too.
>>>
>>> The "program" is that which is being decided by the decider so sNaP
>>> is not observable/catchable/throwable by the "program".
>>>
>>>>
>>>>>
>>>>>>
>>>>>> Remember, in basic computation theory, there is no such thing as
>>>>>> "userland", so no saying that the exception goes through userland
>>>>>> to the operating system.
>>>>>
>>>>> I can choose to present my solution within whatever domain I see
>>>>> fit.
>>>>
>>>> Yes, and it can be a worthless solution if you restrict the problem
>>>> domain to somethng uninteresting.
>>>
>>> Opinion.
>>>
>>>>
>>>>>
>>>>>>
>>>>>> The sNaN exception is a CATCHABLE exception, that the program can
>>>>>> cature and do something with it.
>>>>>
>>>>> The input cannot catch the sNaP exception as it is private to the
>>>>> decider.
>>>>
>>>> I'm not saying the "INPUT", I'm saying to the CALLER of the
>>>> decider.
>>>>
>>>> A decider that doesn't answer to its caller with its answer is to
>>>> computation theory WORTHLESS.
>>>
>>> The decider does answer to its caller unless the input is
>>> pathological in which case sNaP will be signaled.
>>>
>>
>> So your decider is definied to Blue Screen of Death on pathological
>> input.
>>
>> Note, Blue Screen of Death, likeyour sNaP is NOT an "Answer", because
>> it is NOT given to the asker.
>>
>> That means that your sNaP is NOT like sNaN, as the later can, and
>> normally IS captured by the program doing the operation, and in fact
>> is DESIGNED to be captured by the program in use.
>>
>> Being signalling rather than quiet says the program MUST do something
>> about it (or get aborted).
>>
>>>>
>>>>>
>>>>>>>>>> If you can't write a program that does something like, try to
>>>>>>>>>> do thing 1, but if that throws a contradiction error, do
>>>>>>>>>> thing 2 instead.
>>>>>>>>>>
>>>>>>>>>> This brings up the interesting question, if the input to T
>>>>>>>>>> throws a contradiction error, what should T return? If
>>>>>>>>>> contradiction errors are uncatchable, then the only choice is
>>>>>>>>>> to return that same contradiction error, EVEN IF THE OTHER
>>>>>>>>>> PATH HAD A GOOD ANSWER.
>>>>>>>>>
>>>>>>>>> You need to re-read my proposal again but this time try to
>>>>>>>>> FULLY UNDERSTAND IT and understand the implications.
>>>>>>>>
>>>>>>>> It says that pathology is detected and reported.
>>>>>>>>
>>>>>>>> In Computation Theory a function "reports" by returning an
>>>>>>>> answer in some way to its caller.
>>>>>>>
>>>>>>> The sNaP exception is reported by the simulator not by the
>>>>>>> function H called by P: I have already told you what that H
>>>>>>> does: it returns both true and false to copies of P and then
>>>>>>> PROCEEDS WITH THE SIMULATION.
>>>>>>
>>>>>> Then you H is not the decider you claim. This is the error Peter
>>>>>> had years ago when it was pointed out that if x86utm was the
>>>>>> actual decider that then P would need to invoke x86utm with the
>>>>>> input being itself applied to itself, but x86utm can't handle
>>>>>> calls to things like system that would preform that action.
>>>>>
>>>>> The decider is the decider I claim, it is in fact EXACTLY the
>>>>> decider I claim and it bears no resemblance to Peter's efforts.
>>>>>
>>>>> [snip]
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> You keep on ignoring what the decider is returning to the actual
>>>> program that is the CALLER of the decider.
>>>>
>>>> A decider that can't actually be called is totally uninteresting to
>>>> Computation Theory.
>>>
>>> The "program" is that which is being decided by the decider so sNaP
>>> is not observable/catchable/throwable by the "program".
>>>
>>> /Flibble
>>>
>>
>> No, the "Program" is something that is run.
>>
>> If I Run P1, and P1 calls T[P2] then P1 is the caller program and P2
>> is the input to T, which happens to represent a Program too.
>>
>> You seem to want to define your sNaP event as a Blue Screen of Death
>> that immediately ends all computations, which makes it NOT a "answer"
>> in the computation sense.
>>
>> Yes, maybe you see it as answering to the User who is operating the
>> system, but that is not the normal step goal of a computation, as it
>> means it can't be used to build up other operations.
>>
>> Yes, it is just about as useful as having a program somehow
>> intentionally create a BSOD as a way to create an "answer".
>
> OK, to progress this lets dig down into your most interesting test case:
>
> void P(x) {
> bool r;
> try {
> r = H(P,P);
> } catch(sNaP) {
> // Do something here like:
> r = true;
> }
> while (r) continue;
> }
>
> void main() {
> P(P);
> }
>
> It is a basic requirement of my signaling decider that the program
> or function being analyzed must be run from within the decider. As H(P,
> P) is being called from within P before P has been passed to the
> decider the sNaP exception will be signaled. The fact that P catches
> this exception and invokes non-halting behavior is irrelevant as far as
> my decider is concerned as that particular *invocation* of P is not
> being run from within the decider so is in contravention of a basic
> requirement of my decider.
>
> You might now claim that my signaling decider isn't a proper decider as
> far as the HP is concerned due to the presence of the above requirement
> but I respectfully disagree. You will have to show WHY such a
> requirement is in conflict with the definition of a halting decider.
>
> /Flibble
>


Click here to read the complete article
Re: A plea...

<20220720003151.00000bd7@reddwarf.jmc.corp>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35852&group=comp.theory#35852

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!news.uzoreto.com!news-out.netnews.com!news.alt.net!fdc2.netnews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx01.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc.corp (Mr Flibble)
Newsgroups: comp.theory
Subject: Re: A plea...
Message-ID: <20220720003151.00000bd7@reddwarf.jmc.corp>
References: <87k08c79ys.fsf@bsb.me.uk>
<qqmdnSf3Qa8sy0n_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220717200508.000078e9@reddwarf.jmc.corp>
<1AZAK.598124$wIO9.69713@fx12.iad>
<20220717205331.0000461e@reddwarf.jmc.corp>
<fc%AK.397559$vAW9.238590@fx10.iad>
<20220717224436.00002c66@reddwarf.jmc.corp>
<qE%AK.514397$ntj.427354@fx15.iad>
<20220717230620.00001532@reddwarf.jmc.corp>
<Um0BK.514846$ntj.83746@fx15.iad>
<20220717235402.00002719@reddwarf.jmc.corp>
<hO0BK.48201$Ae2.4639@fx35.iad>
<20220718002744.00002d25@reddwarf.jmc.corp>
<up2BK.40810$Sf2.38749@fx34.iad>
<20220718021821.000056d2@reddwarf.jmc.corp>
<qN2BK.57711$sZ1.19122@fx07.iad>
<20220718073646.000070ff@reddwarf.jmc.corp>
<GobBK.581682$JVi.394817@fx17.iad>
<20220718172136.000029ad@reddwarf.jmc.corp>
<tXlBK.517864$ntj.364914@fx15.iad>
<20220719083420.00005f0f@reddwarf.jmc.corp>
<vrwBK.33025$8f2.30099@fx38.iad>
<20220719181344.00001568@reddwarf.jmc.corp>
<THGBK.573696$X_i.35184@fx18.iad>
Organization: Jupiter Mining Corporation
X-Newsreader: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Lines: 573
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Tue, 19 Jul 2022 23:31:52 UTC
Date: Wed, 20 Jul 2022 00:31:51 +0100
X-Received-Bytes: 26666
 by: Mr Flibble - Tue, 19 Jul 2022 23:31 UTC

On Tue, 19 Jul 2022 19:00:03 -0400
Richard Damon <Richard@Damon-Family.org> wrote:

> On 7/19/22 1:13 PM, Mr Flibble wrote:
> > On Tue, 19 Jul 2022 07:19:55 -0400
> > Richard Damon <Richard@Damon-Family.org> wrote:
> >
> >> On 7/19/22 3:34 AM, Mr Flibble wrote:
> >>> On Mon, 18 Jul 2022 19:23:04 -0400
> >>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>
> >>>> On 7/18/22 12:21 PM, Mr Flibble wrote:
> >>>>> On Mon, 18 Jul 2022 07:23:17 -0400
> >>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>
> >>>>>> On 7/18/22 2:36 AM, Mr Flibble wrote:
> >>>>>>> On Sun, 17 Jul 2022 21:35:18 -0400
> >>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>
> >>>>>>>> On 7/17/22 9:18 PM, Mr Flibble wrote:
> >>>>>>>>> On Sun, 17 Jul 2022 21:09:45 -0400
> >>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 7/17/22 7:27 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Sun, 17 Jul 2022 19:19:40 -0400
> >>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 7/17/22 6:54 PM, Mr Flibble wrote:
> >>>>>>>>>>>>> On Sun, 17 Jul 2022 18:50:28 -0400
> >>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 7/17/22 6:06 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>> On Sun, 17 Jul 2022 18:00:54 -0400
> >>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 7/17/22 5:44 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 17:30:50 -0400
> >>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 7/17/22 3:53 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 15:39:40 -0400
> >>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On 7/17/22 3:05 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 13:36:32 -0500
> >>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On 7/17/2022 1:00 PM, Gawr Gura wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On 7/16/22 19:24, Ben Bacarisse wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> Please don't respond to Peter Olcott's posts
> >>>>>>>>>>>>>>>>>>>>>>>> here. His threads have taken over
> >>>>>>>>>>>>>>>>>>>>>>>> comp.theory, but there is no reason that
> >>>>>>>>>>>>>>>>>>>>>>>> comp.lang c (or comp.lang.c++) should suffer
> >>>>>>>>>>>>>>>>>>>>>>>> the same fate. These two groups have had
> >>>>>>>>>>>>>>>>>>>>>>>> many interesting threads over the years, but
> >>>>>>>>>>>>>>>>>>>>>>>> they will die if they fill up with junk.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> If you want to reply to him, just pick any of
> >>>>>>>>>>>>>>>>>>>>>>>> the thousands of posts in comp.theory and
> >>>>>>>>>>>>>>>>>>>>>>>> he'll be as happy to insult you and call you
> >>>>>>>>>>>>>>>>>>>>>>>> ignorant there as he is here.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> I've not made this a head post because I
> >>>>>>>>>>>>>>>>>>>>>>>> don't want to single anyone out.  Everyone
> >>>>>>>>>>>>>>>>>>>>>>>> who'd got something out of comp.lang.c
> >>>>>>>>>>>>>>>>>>>>>>>> should care about its curation...
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Ben, I think the cranks have taken over the
> >>>>>>>>>>>>>>>>>>>>>>> asylum.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Flibble is a crank because he created a
> >>>>>>>>>>>>>>>>>>>>>> pathological input detector and continues to
> >>>>>>>>>>>>>>>>>>>>>> leave out the core piece, the criterion measure
> >>>>>>>>>>>>>>>>>>>>>> of detecting a pathological input.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> The design of my signaling decider clearly sets
> >>>>>>>>>>>>>>>>>>>>> out how pathological input is detected:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> https://github.com/i42output/halting-problem/blob/main/README.txt
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> The implementation details of how halting or
> >>>>>>>>>>>>>>>>>>>>> non-halting are actually decided are not
> >>>>>>>>>>>>>>>>>>>>> described in the design nor need they be for me
> >>>>>>>>>>>>>>>>>>>>> to not be a "crank".
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> The one problem with your design is that you have
> >>>>>>>>>>>>>>>>>>>> adopted the same faulty simulate the input in the
> >>>>>>>>>>>>>>>>>>>> same program memory space as the decider that
> >>>>>>>>>>>>>>>>>>>> Peter uses, which means that you won't actually
> >>>>>>>>>>>>>>>>>>>> be able to convert the design into two seperate
> >>>>>>>>>>>>>>>>>>>> Turing Machines, one for the H that is being
> >>>>>>>>>>>>>>>>>>>> asked to decide, and one for P that has its own
> >>>>>>>>>>>>>>>>>>>> copy of H, which needs to be run as a machine to
> >>>>>>>>>>>>>>>>>>>> see what its answer is and also given to H to
> >>>>>>>>>>>>>>>>>>>> see what it decides (though the second might be
> >>>>>>>>>>>>>>>>>>>> able to be extracted out of the run of the
> >>>>>>>>>>>>>>>>>>>> first).
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> The problem here is that H can't just simply
> >>>>>>>>>>>>>>>>>>>> compare "addresses" to detect calls to "itself",
> >>>>>>>>>>>>>>>>>>>> but needs to be able to detect a "copy" of itself
> >>>>>>>>>>>>>>>>>>>> embedded in another machine.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> In the slightly faulty execution description that
> >>>>>>>>>>>>>>>>>>>> Peter uses, which means there are some machines
> >>>>>>>>>>>>>>>>>>>> you can not provide to your machine, you system
> >>>>>>>>>>>>>>>>>>>> works if the program calls YOU H, and not a copy
> >>>>>>>>>>>>>>>>>>>> of it.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> [Strachey 1965] doesn't require two separate
> >>>>>>>>>>>>>>>>>>> Turing Machines as far as I can tell:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> rec routine P
> >>>>>>>>>>>>>>>>>>> § L : if T[P] goto L
> >>>>>>>>>>>>>>>>>>> Return §
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> [Strachey 1965] only talks about functions and not
> >>>>>>>>>>>>>>>>>>> Turing Machines: T is defined to be a *function
> >>>>>>>>>>>>>>>>>>> returning a boolean*.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I am less familiar with Strachey, if I remember
> >>>>>>>>>>>>>>>>>> right, T[P] passes to T the source code of P, and I
> >>>>>>>>>>>>>>>>>> guess he allows that source code to directly
> >>>>>>>>>>>>>>>>>> reference the decider that it is confounding.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Maybe you can make the class of deciders you are
> >>>>>>>>>>>>>>>>>> working on, with the added paradoxical output for
> >>>>>>>>>>>>>>>>>> that form, but it doesn't extend to the classical
> >>>>>>>>>>>>>>>>>> problem based on Turing Machines.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Of course, the issue is that T is defined to return
> >>>>>>>>>>>>>>>>>> boolean, and not an exception, and it still doesn't
> >>>>>>>>>>>>>>>>>> show that you CAN build a Halt Decider, just that
> >>>>>>>>>>>>>>>>>> this one simple counter example can be filtered
> >>>>>>>>>>>>>>>>>> out.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> T still returns a boolean for my signaling decider;
> >>>>>>>>>>>>>>>>> the exception is only thrown later on when pathology
> >>>>>>>>>>>>>>>>> is determined.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Which means it has 3 return conditions, returning
> >>>>>>>>>>>>>>>> true, returning false, or throwing the pathological
> >>>>>>>>>>>>>>>> exception. That is really a form of "return" for a
> >>>>>>>>>>>>>>>> function, just with a somewhat different method.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> If you translate into a Turing Machine, it just
> >>>>>>>>>>>>>>>> becomes a 3rd final state.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It only returns true or false to P; the exception is
> >>>>>>>>>>>>>>> thrown later, out of band.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> It Can't.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It can and does.
> >>>>>>>>>>>>
> >>>>>>>>>>>> HOW. You use T to decide on P by writing T[P] just like P
> >>>>>>>>>>>> calls it.
> >>>>>>>>>>>
> >>>>>>>>>>> It returns BOTH true AND false to P as it doesn't YET know
> >>>>>>>>>>> if P is pathological and if it isn't whether it halts or
> >>>>>>>>>>> not; it will find that out as the simulation continues.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Your confusing what the actual function T does and how T
> >>>>>>>>>> simulates recursive calls to T.
> >>>>>>>>>>
> >>>>>>>>>> If T sees a call to T with the same parameter(s) as a
> >>>>>>>>>> previous call to T (or the original call to T) had, you
> >>>>>>>>>> replace them with a split where you return true to one side
> >>>>>>>>>> and return false to the other and process.
> >>>>>>>>>>
> >>>>>>>>>> When T is called by an actually running P, it needs to
> >>>>>>>>>> return the full decision, including the exception to that
> >>>>>>>>>> P, just as it does if directly asked (by main or just
> >>>>>>>>>> asked depending on how the language works).
> >>>>>>>>>
> >>>>>>>>> That is where we disagree: I see no reason why my scheme is
> >>>>>>>>> invalid: P doesn't actually care what T does, it acts on
> >>>>>>>>> what T returns. T returns both halting decisions to two
> >>>>>>>>> copies of P and allows the simulation to proceed with no
> >>>>>>>>> recursion.
> >>>>>>>>>>
> >>>>>>>>>> The question then becomes, what does P do with that third
> >>>>>>>>>> answer? What are programs ALLOWED to do with that third
> >>>>>>>>>> answer.
> >>>>>>>>>
> >>>>>>>>> I already told you that P never sees the "third answer"
> >>>>>>>>> (exception) as that happens out of band.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> The directly executed P does, at least if T[P] ever generates
> >>>>>>>> that third answer as an answer and "reports" it to its
> >>>>>>>> caller.
> >>>>>>>
> >>>>>>> Stop being so obtuse. The exception is not reported to its
> >>>>>>> caller (P) as it is not known at the point in the simulation
> >>>>>>> if the exceptional condition exits. My solution, unlike
> >>>>>>> PO's, is NOT infinitely recursive: think about what that
> >>>>>>> actually means and try re-reading my proposal AGAIN but this
> >>>>>>> time try to fucking comprehend it. The exception is an out
> >>>>>>> of band signal.
> >>>>>>
> >>>>>> I repeat, I am not talking about in the simulation, but in the
> >>>>>> initial call to H.
> >>>>>>
> >>>>>> What would be the results of:
> >>>>>>
> >>>>>> void P(x) {
> >>>>>> bool r = H(x,x);
> >>>>>> while (r) continue;
> >>>>>> }
> >>>>>>
> >>>>>> void main() {
> >>>>>> P(P);
> >>>>>> }
> >>>>>>
> >>>>>> I.e. main calls P(P) which calls your H(P,P), what happens
> >>>>>> THERE at THAT call site.
> >>>>>
> >>>>> sNaP exception due to H being passed an input from within the
> >>>>> input that has not previously been passed to H from outside the
> >>>>> input.
> >>>>
> >>>> So, you said it was like sNaN, so the program can be configured
> >>>> to catch this exception, right? Like show below.
> >>>
> >>> The "program" is that which is being decided by the decider so
> >>> sNaP is not observable/catchable/throwable by the "program".
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>> If sNaP is just like sNaN what happens if instead I make P be:
> >>>>>>
> >>>>>> void P(x) {
> >>>>>> bool r;
> >>>>>> try {
> >>>>>> r = H(P,P)l
> >>>>>> } catch(sNaO) {
> >>>>>> // Do something here like:
> >>>>>> r = true;
> >>>>>> }
> >>>>>> while (r) continue;
> >>>>>> }
> >>>>>
> >>>>> Inputs can't observe/catch the sNaP exception as it is
> >>>>> private to the decider.
> >>>>
> >>>> P isn't "Just an input", remember main CALLS P(P) so it is a
> >>>> program too.
> >>>>
> >>>> So, are you saying that the decider doesn't tell anyone about the
> >>>> exception, but it just means the whole machine stops?
> >>>
> >>> sNaP exception will be thrown for same reason given previously.
> >>> The "program" is that which is being decided by the decider so
> >>> sNaP is not observable/catchable/throwable by the "program".
> >>>
> >>>
> >>>>
> >>>> i.e. it is a Blue Screen of Death?
> >>>>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> Also, what happens if I do:
> >>>>>>
> >>>>>> void P(x) {
> >>>>>> throw sNaP;
> >>>>>> }
> >>>>>>
> >>>>>> bool T(x) {
> >>>>>> return H(x,x);
> >>>>>> }
> >>>>>>
> >>>>>> void main() {
> >>>>>> Output(T(P,P));
> >>>>>> }
> >>>>>
> >>>>> Inputs can't throw the sNaP exception as it is private to the
> >>>>> decider.
> >>>>
> >>>> But other programs can as T for the computation system to be
> >>>> Turing Compllete, T can't be given powers to do things that
> >>>> other programs don't have.
> >>>>
> >>>> Since programs can throw, then inputs can represent programs that
> >>>> throw.
> >>>
> >>> The "program" is that which is being decided by the decider so
> >>> sNaP is not observable/catchable/throwable by the "program".
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>> i.e. what is the defined answer for an input that throws sNaP?
> >>>>>> If sNaP is like a signalling sNaN, and functions can return it,
> >>>>>> then H needs to process functions that can return it.
> >>>>>
> >>>>> Inputs can't throw the sNaP exception as it is private to the
> >>>>> decider.
> >>>>
> >>>> IMPOSSIBLE. Either the "results" of sNaP is a defined behavior of
> >>>> the computation system or it isn't
> >>>>
> >>>> If it is, then ANYONE can throw it.
> >>>>
> >>>> If it isn't, then NO ONE can throw it.
> >>>>
> >>>> If your computation system isn't complete in this manner, that
> >>>> Halting can be decidable, as if P can't generate the sNaP result,
> >>>> it can't be allowed to call T.
> >>>>
> >>>> Many non-Turing Complete systems can have Halting deciders if the
> >>>> decider has powers that the things it is deciding on can't have.
> >>>>
> >>>
> >>> The "program" is that which is being decided by the decider so
> >>> sNaP is not observable/catchable/throwable by the "program".
> >>>
> >>>>>
> >>>>>>
> >>>>>> These are the sorts of questions you need to think about and
> >>>>>> answer if you really want to create a new sort of decider to
> >>>>>> see what it can do.
> >>>>>
> >>>>> I have thought about them and I have provided you with answers.
> >>>>> I did state previously that I don't have to go into
> >>>>> implementation details of the signaling decider: the high level
> >>>>> design should be sufficient as long as the reader can apply a
> >>>>> bit of intelligence when reading it.
> >>>>
> >>>> You don't need to necessarily say how H does its job, but you do
> >>>> need to specify precisely AND COMPLETELY what that job is. That
> >>>> means you need to think about the corner cases. If only T can
> >>>> generate the exception, then T is NOT a program in the computaton
> >>>> system you have defined, as it is doing something "programs"
> >>>> aren't allowed to do.
> >>>>
> >>>> That makes T a not very interesting decider, as the Halting
> >>>> Problem has other possible solutions when the decider is a more
> >>>> powerful machine than what it is deciding on.
> >>>
> >>> Refuting [Strachey 1965] and associated proofs is quite
> >>> "interesting".
> >>>>
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Unstopable exceptions (FATAL ERRORS) become very unfriendly
> >>>>>>>>>> in use, but may be simpler to deal with in theory (but a
> >>>>>>>>>> lot less useful).
> >>>>>>>>>
> >>>>>>>>> In your opinion; again I disagree.
> >>>>>>>>
> >>>>>>>> How often does YOUR computer just shut itself down in reponse
> >>>>>>>> to being given a bad probem?
> >>>>>>>>
> >>>>>>>> THAT is the actual effect of a truely unstoppable exception.
> >>>>>>>>
> >>>>>>>> BLUE SCREEN OF DEATH time.
> >>>>>>>
> >>>>>>> An operating system panic is quite different to a userland
> >>>>>>> program raising an exception. The sNaP exception is equivalent
> >>>>>>> to the sNaN exception of IEEE 754 floating point.
> >>>>>>
> >>>>>> Nope, that is the result of a exception that can not be caught
> >>>>>> at all. The only way to keep software from catching the
> >>>>>> exception is to shut the system down.
> >>>>>
> >>>>> The input cannot catch the sNaP exception as it is private to
> >>>>> the decider.
> >>>>
> >>>> Note the "Input" but the CALLER of the decider, that supposedly
> >>>> you are returning an answer too.
> >>>
> >>> The "program" is that which is being decided by the decider so
> >>> sNaP is not observable/catchable/throwable by the "program".
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>> Remember, in basic computation theory, there is no such thing
> >>>>>> as "userland", so no saying that the exception goes through
> >>>>>> userland to the operating system.
> >>>>>
> >>>>> I can choose to present my solution within whatever domain I see
> >>>>> fit.
> >>>>
> >>>> Yes, and it can be a worthless solution if you restrict the
> >>>> problem domain to somethng uninteresting.
> >>>
> >>> Opinion.
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>> The sNaN exception is a CATCHABLE exception, that the program
> >>>>>> can cature and do something with it.
> >>>>>
> >>>>> The input cannot catch the sNaP exception as it is private to
> >>>>> the decider.
> >>>>
> >>>> I'm not saying the "INPUT", I'm saying to the CALLER of the
> >>>> decider.
> >>>>
> >>>> A decider that doesn't answer to its caller with its answer is to
> >>>> computation theory WORTHLESS.
> >>>
> >>> The decider does answer to its caller unless the input is
> >>> pathological in which case sNaP will be signaled.
> >>>
> >>
> >> So your decider is definied to Blue Screen of Death on pathological
> >> input.
> >>
> >> Note, Blue Screen of Death, likeyour sNaP is NOT an "Answer",
> >> because it is NOT given to the asker.
> >>
> >> That means that your sNaP is NOT like sNaN, as the later can, and
> >> normally IS captured by the program doing the operation, and in
> >> fact is DESIGNED to be captured by the program in use.
> >>
> >> Being signalling rather than quiet says the program MUST do
> >> something about it (or get aborted).
> >>
> >>>>
> >>>>>
> >>>>>>>>>> If you can't write a program that does something like, try
> >>>>>>>>>> to do thing 1, but if that throws a contradiction error, do
> >>>>>>>>>> thing 2 instead.
> >>>>>>>>>>
> >>>>>>>>>> This brings up the interesting question, if the input to T
> >>>>>>>>>> throws a contradiction error, what should T return? If
> >>>>>>>>>> contradiction errors are uncatchable, then the only choice
> >>>>>>>>>> is to return that same contradiction error, EVEN IF THE
> >>>>>>>>>> OTHER PATH HAD A GOOD ANSWER.
> >>>>>>>>>
> >>>>>>>>> You need to re-read my proposal again but this time try to
> >>>>>>>>> FULLY UNDERSTAND IT and understand the implications.
> >>>>>>>>
> >>>>>>>> It says that pathology is detected and reported.
> >>>>>>>>
> >>>>>>>> In Computation Theory a function "reports" by returning an
> >>>>>>>> answer in some way to its caller.
> >>>>>>>
> >>>>>>> The sNaP exception is reported by the simulator not by the
> >>>>>>> function H called by P: I have already told you what that H
> >>>>>>> does: it returns both true and false to copies of P and then
> >>>>>>> PROCEEDS WITH THE SIMULATION.
> >>>>>>
> >>>>>> Then you H is not the decider you claim. This is the error
> >>>>>> Peter had years ago when it was pointed out that if x86utm was
> >>>>>> the actual decider that then P would need to invoke x86utm
> >>>>>> with the input being itself applied to itself, but x86utm
> >>>>>> can't handle calls to things like system that would preform
> >>>>>> that action.
> >>>>>
> >>>>> The decider is the decider I claim, it is in fact EXACTLY the
> >>>>> decider I claim and it bears no resemblance to Peter's efforts.
> >>>>>
> >>>>> [snip]
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> You keep on ignoring what the decider is returning to the actual
> >>>> program that is the CALLER of the decider.
> >>>>
> >>>> A decider that can't actually be called is totally uninteresting
> >>>> to Computation Theory.
> >>>
> >>> The "program" is that which is being decided by the decider so
> >>> sNaP is not observable/catchable/throwable by the "program".
> >>>
> >>> /Flibble
> >>>
> >>
> >> No, the "Program" is something that is run.
> >>
> >> If I Run P1, and P1 calls T[P2] then P1 is the caller program and
> >> P2 is the input to T, which happens to represent a Program too.
> >>
> >> You seem to want to define your sNaP event as a Blue Screen of
> >> Death that immediately ends all computations, which makes it NOT a
> >> "answer" in the computation sense.
> >>
> >> Yes, maybe you see it as answering to the User who is operating the
> >> system, but that is not the normal step goal of a computation, as
> >> it means it can't be used to build up other operations.
> >>
> >> Yes, it is just about as useful as having a program somehow
> >> intentionally create a BSOD as a way to create an "answer".
> >
> > OK, to progress this lets dig down into your most interesting test
> > case:
> >
> > void P(x) {
> > bool r;
> > try {
> > r = H(P,P);
> > } catch(sNaP) {
> > // Do something here like:
> > r = true;
> > }
> > while (r) continue;
> > }
> >
> > void main() {
> > P(P);
> > }
> >
> > It is a basic requirement of my signaling decider that the program
> > or function being analyzed must be run from within the decider. As
> > H(P, P) is being called from within P before P has been passed to
> > the decider the sNaP exception will be signaled. The fact that P
> > catches this exception and invokes non-halting behavior is
> > irrelevant as far as my decider is concerned as that particular
> > *invocation* of P is not being run from within the decider so is in
> > contravention of a basic requirement of my decider.
> >
> > You might now claim that my signaling decider isn't a proper
> > decider as far as the HP is concerned due to the presence of the
> > above requirement but I respectfully disagree. You will have to
> > show WHY such a requirement is in conflict with the definition of a
> > halting decider.
> >
> > /Flibble
> >
>
> And, a fundamental issue is that for a simulation to be "correct" it
> must match the behavior of the actual program.
>
> If the answer tp H(P,P) doesn't match the behavior of P(P), then it
> is hard to call the answer "correct".
>
> Yes, it can make sense to define that some cases will result in H
> needing to give a "This program is acting contradictory to may
> prediction so it is impossible to give an answer", but once you
> define that answer as "throwing an exception", and thus have
> introduced "throwing an exception" into you list of possible
> behaviors, you need to define how your decider will handle inputs
> that do that.
>
> If you are going to to make an "useful" answer by adding such an
> extension to the behaviors of machines, you need to FULLY define how
> that works.


Click here to read the complete article
Re: A plea...

<DuIBK.86909$f81.35526@fx43.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35853&group=comp.theory#35853

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx43.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.11.0
Subject: Re: A plea...
Content-Language: en-US
Newsgroups: comp.theory
References: <87k08c79ys.fsf@bsb.me.uk>
<qqmdnSf3Qa8sy0n_nZ2dnUU7_8zNnZ2d@giganews.com>
<20220717200508.000078e9@reddwarf.jmc.corp>
<1AZAK.598124$wIO9.69713@fx12.iad>
<20220717205331.0000461e@reddwarf.jmc.corp>
<fc%AK.397559$vAW9.238590@fx10.iad>
<20220717224436.00002c66@reddwarf.jmc.corp>
<qE%AK.514397$ntj.427354@fx15.iad>
<20220717230620.00001532@reddwarf.jmc.corp> <Um0BK.514846$ntj.83746@fx15.iad>
<20220717235402.00002719@reddwarf.jmc.corp> <hO0BK.48201$Ae2.4639@fx35.iad>
<20220718002744.00002d25@reddwarf.jmc.corp> <up2BK.40810$Sf2.38749@fx34.iad>
<20220718021821.000056d2@reddwarf.jmc.corp> <qN2BK.57711$sZ1.19122@fx07.iad>
<20220718073646.000070ff@reddwarf.jmc.corp>
<GobBK.581682$JVi.394817@fx17.iad>
<20220718172136.000029ad@reddwarf.jmc.corp>
<tXlBK.517864$ntj.364914@fx15.iad>
<20220719083420.00005f0f@reddwarf.jmc.corp> <vrwBK.33025$8f2.30099@fx38.iad>
<20220719181344.00001568@reddwarf.jmc.corp> <THGBK.573696$X_i.35184@fx18.iad>
<20220720003151.00000bd7@reddwarf.jmc.corp>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <20220720003151.00000bd7@reddwarf.jmc.corp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 582
Message-ID: <DuIBK.86909$f81.35526@fx43.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Tue, 19 Jul 2022 21:02:25 -0400
X-Received-Bytes: 26911
 by: Richard Damon - Wed, 20 Jul 2022 01:02 UTC

On 7/19/22 7:31 PM, Mr Flibble wrote:
> On Tue, 19 Jul 2022 19:00:03 -0400
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 7/19/22 1:13 PM, Mr Flibble wrote:
>>> On Tue, 19 Jul 2022 07:19:55 -0400
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 7/19/22 3:34 AM, Mr Flibble wrote:
>>>>> On Mon, 18 Jul 2022 19:23:04 -0400
>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>
>>>>>> On 7/18/22 12:21 PM, Mr Flibble wrote:
>>>>>>> On Mon, 18 Jul 2022 07:23:17 -0400
>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>
>>>>>>>> On 7/18/22 2:36 AM, Mr Flibble wrote:
>>>>>>>>> On Sun, 17 Jul 2022 21:35:18 -0400
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>
>>>>>>>>>> On 7/17/22 9:18 PM, Mr Flibble wrote:
>>>>>>>>>>> On Sun, 17 Jul 2022 21:09:45 -0400
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 7/17/22 7:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Sun, 17 Jul 2022 19:19:40 -0400
>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7/17/22 6:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 18:50:28 -0400
>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 7/17/22 6:06 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 18:00:54 -0400
>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 7/17/22 5:44 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 17:30:50 -0400
>>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 7/17/22 3:53 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 15:39:40 -0400
>>>>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 7/17/22 3:05 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 13:36:32 -0500
>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 7/17/2022 1:00 PM, Gawr Gura wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 7/16/22 19:24, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Please don't respond to Peter Olcott's posts
>>>>>>>>>>>>>>>>>>>>>>>>>> here. His threads have taken over
>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory, but there is no reason that
>>>>>>>>>>>>>>>>>>>>>>>>>> comp.lang c (or comp.lang.c++) should suffer
>>>>>>>>>>>>>>>>>>>>>>>>>> the same fate. These two groups have had
>>>>>>>>>>>>>>>>>>>>>>>>>> many interesting threads over the years, but
>>>>>>>>>>>>>>>>>>>>>>>>>> they will die if they fill up with junk.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> If you want to reply to him, just pick any of
>>>>>>>>>>>>>>>>>>>>>>>>>> the thousands of posts in comp.theory and
>>>>>>>>>>>>>>>>>>>>>>>>>> he'll be as happy to insult you and call you
>>>>>>>>>>>>>>>>>>>>>>>>>> ignorant there as he is here.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I've not made this a head post because I
>>>>>>>>>>>>>>>>>>>>>>>>>> don't want to single anyone out.  Everyone
>>>>>>>>>>>>>>>>>>>>>>>>>> who'd got something out of comp.lang.c
>>>>>>>>>>>>>>>>>>>>>>>>>> should care about its curation...
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Ben, I think the cranks have taken over the
>>>>>>>>>>>>>>>>>>>>>>>>> asylum.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Flibble is a crank because he created a
>>>>>>>>>>>>>>>>>>>>>>>> pathological input detector and continues to
>>>>>>>>>>>>>>>>>>>>>>>> leave out the core piece, the criterion measure
>>>>>>>>>>>>>>>>>>>>>>>> of detecting a pathological input.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The design of my signaling decider clearly sets
>>>>>>>>>>>>>>>>>>>>>>> out how pathological input is detected:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> https://github.com/i42output/halting-problem/blob/main/README.txt
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> The implementation details of how halting or
>>>>>>>>>>>>>>>>>>>>>>> non-halting are actually decided are not
>>>>>>>>>>>>>>>>>>>>>>> described in the design nor need they be for me
>>>>>>>>>>>>>>>>>>>>>>> to not be a "crank".
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The one problem with your design is that you have
>>>>>>>>>>>>>>>>>>>>>> adopted the same faulty simulate the input in the
>>>>>>>>>>>>>>>>>>>>>> same program memory space as the decider that
>>>>>>>>>>>>>>>>>>>>>> Peter uses, which means that you won't actually
>>>>>>>>>>>>>>>>>>>>>> be able to convert the design into two seperate
>>>>>>>>>>>>>>>>>>>>>> Turing Machines, one for the H that is being
>>>>>>>>>>>>>>>>>>>>>> asked to decide, and one for P that has its own
>>>>>>>>>>>>>>>>>>>>>> copy of H, which needs to be run as a machine to
>>>>>>>>>>>>>>>>>>>>>> see what its answer is and also given to H to
>>>>>>>>>>>>>>>>>>>>>> see what it decides (though the second might be
>>>>>>>>>>>>>>>>>>>>>> able to be extracted out of the run of the
>>>>>>>>>>>>>>>>>>>>>> first).
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> The problem here is that H can't just simply
>>>>>>>>>>>>>>>>>>>>>> compare "addresses" to detect calls to "itself",
>>>>>>>>>>>>>>>>>>>>>> but needs to be able to detect a "copy" of itself
>>>>>>>>>>>>>>>>>>>>>> embedded in another machine.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> In the slightly faulty execution description that
>>>>>>>>>>>>>>>>>>>>>> Peter uses, which means there are some machines
>>>>>>>>>>>>>>>>>>>>>> you can not provide to your machine, you system
>>>>>>>>>>>>>>>>>>>>>> works if the program calls YOU H, and not a copy
>>>>>>>>>>>>>>>>>>>>>> of it.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> [Strachey 1965] doesn't require two separate
>>>>>>>>>>>>>>>>>>>>> Turing Machines as far as I can tell:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> rec routine P
>>>>>>>>>>>>>>>>>>>>> § L : if T[P] goto L
>>>>>>>>>>>>>>>>>>>>> Return §
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> [Strachey 1965] only talks about functions and not
>>>>>>>>>>>>>>>>>>>>> Turing Machines: T is defined to be a *function
>>>>>>>>>>>>>>>>>>>>> returning a boolean*.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I am less familiar with Strachey, if I remember
>>>>>>>>>>>>>>>>>>>> right, T[P] passes to T the source code of P, and I
>>>>>>>>>>>>>>>>>>>> guess he allows that source code to directly
>>>>>>>>>>>>>>>>>>>> reference the decider that it is confounding.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Maybe you can make the class of deciders you are
>>>>>>>>>>>>>>>>>>>> working on, with the added paradoxical output for
>>>>>>>>>>>>>>>>>>>> that form, but it doesn't extend to the classical
>>>>>>>>>>>>>>>>>>>> problem based on Turing Machines.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Of course, the issue is that T is defined to return
>>>>>>>>>>>>>>>>>>>> boolean, and not an exception, and it still doesn't
>>>>>>>>>>>>>>>>>>>> show that you CAN build a Halt Decider, just that
>>>>>>>>>>>>>>>>>>>> this one simple counter example can be filtered
>>>>>>>>>>>>>>>>>>>> out.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> T still returns a boolean for my signaling decider;
>>>>>>>>>>>>>>>>>>> the exception is only thrown later on when pathology
>>>>>>>>>>>>>>>>>>> is determined.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Which means it has 3 return conditions, returning
>>>>>>>>>>>>>>>>>> true, returning false, or throwing the pathological
>>>>>>>>>>>>>>>>>> exception. That is really a form of "return" for a
>>>>>>>>>>>>>>>>>> function, just with a somewhat different method.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If you translate into a Turing Machine, it just
>>>>>>>>>>>>>>>>>> becomes a 3rd final state.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It only returns true or false to P; the exception is
>>>>>>>>>>>>>>>>> thrown later, out of band.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It Can't.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It can and does.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> HOW. You use T to decide on P by writing T[P] just like P
>>>>>>>>>>>>>> calls it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> It returns BOTH true AND false to P as it doesn't YET know
>>>>>>>>>>>>> if P is pathological and if it isn't whether it halts or
>>>>>>>>>>>>> not; it will find that out as the simulation continues.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Your confusing what the actual function T does and how T
>>>>>>>>>>>> simulates recursive calls to T.
>>>>>>>>>>>>
>>>>>>>>>>>> If T sees a call to T with the same parameter(s) as a
>>>>>>>>>>>> previous call to T (or the original call to T) had, you
>>>>>>>>>>>> replace them with a split where you return true to one side
>>>>>>>>>>>> and return false to the other and process.
>>>>>>>>>>>>
>>>>>>>>>>>> When T is called by an actually running P, it needs to
>>>>>>>>>>>> return the full decision, including the exception to that
>>>>>>>>>>>> P, just as it does if directly asked (by main or just
>>>>>>>>>>>> asked depending on how the language works).
>>>>>>>>>>>
>>>>>>>>>>> That is where we disagree: I see no reason why my scheme is
>>>>>>>>>>> invalid: P doesn't actually care what T does, it acts on
>>>>>>>>>>> what T returns. T returns both halting decisions to two
>>>>>>>>>>> copies of P and allows the simulation to proceed with no
>>>>>>>>>>> recursion.
>>>>>>>>>>>>
>>>>>>>>>>>> The question then becomes, what does P do with that third
>>>>>>>>>>>> answer? What are programs ALLOWED to do with that third
>>>>>>>>>>>> answer.
>>>>>>>>>>>
>>>>>>>>>>> I already told you that P never sees the "third answer"
>>>>>>>>>>> (exception) as that happens out of band.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The directly executed P does, at least if T[P] ever generates
>>>>>>>>>> that third answer as an answer and "reports" it to its
>>>>>>>>>> caller.
>>>>>>>>>
>>>>>>>>> Stop being so obtuse. The exception is not reported to its
>>>>>>>>> caller (P) as it is not known at the point in the simulation
>>>>>>>>> if the exceptional condition exits. My solution, unlike
>>>>>>>>> PO's, is NOT infinitely recursive: think about what that
>>>>>>>>> actually means and try re-reading my proposal AGAIN but this
>>>>>>>>> time try to fucking comprehend it. The exception is an out
>>>>>>>>> of band signal.
>>>>>>>>
>>>>>>>> I repeat, I am not talking about in the simulation, but in the
>>>>>>>> initial call to H.
>>>>>>>>
>>>>>>>> What would be the results of:
>>>>>>>>
>>>>>>>> void P(x) {
>>>>>>>> bool r = H(x,x);
>>>>>>>> while (r) continue;
>>>>>>>> }
>>>>>>>>
>>>>>>>> void main() {
>>>>>>>> P(P);
>>>>>>>> }
>>>>>>>>
>>>>>>>> I.e. main calls P(P) which calls your H(P,P), what happens
>>>>>>>> THERE at THAT call site.
>>>>>>>
>>>>>>> sNaP exception due to H being passed an input from within the
>>>>>>> input that has not previously been passed to H from outside the
>>>>>>> input.
>>>>>>
>>>>>> So, you said it was like sNaN, so the program can be configured
>>>>>> to catch this exception, right? Like show below.
>>>>>
>>>>> The "program" is that which is being decided by the decider so
>>>>> sNaP is not observable/catchable/throwable by the "program".
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> If sNaP is just like sNaN what happens if instead I make P be:
>>>>>>>>
>>>>>>>> void P(x) {
>>>>>>>> bool r;
>>>>>>>> try {
>>>>>>>> r = H(P,P)l
>>>>>>>> } catch(sNaO) {
>>>>>>>> // Do something here like:
>>>>>>>> r = true;
>>>>>>>> }
>>>>>>>> while (r) continue;
>>>>>>>> }
>>>>>>>
>>>>>>> Inputs can't observe/catch the sNaP exception as it is
>>>>>>> private to the decider.
>>>>>>
>>>>>> P isn't "Just an input", remember main CALLS P(P) so it is a
>>>>>> program too.
>>>>>>
>>>>>> So, are you saying that the decider doesn't tell anyone about the
>>>>>> exception, but it just means the whole machine stops?
>>>>>
>>>>> sNaP exception will be thrown for same reason given previously.
>>>>> The "program" is that which is being decided by the decider so
>>>>> sNaP is not observable/catchable/throwable by the "program".
>>>>>
>>>>>
>>>>>>
>>>>>> i.e. it is a Blue Screen of Death?
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Also, what happens if I do:
>>>>>>>>
>>>>>>>> void P(x) {
>>>>>>>> throw sNaP;
>>>>>>>> }
>>>>>>>>
>>>>>>>> bool T(x) {
>>>>>>>> return H(x,x);
>>>>>>>> }
>>>>>>>>
>>>>>>>> void main() {
>>>>>>>> Output(T(P,P));
>>>>>>>> }
>>>>>>>
>>>>>>> Inputs can't throw the sNaP exception as it is private to the
>>>>>>> decider.
>>>>>>
>>>>>> But other programs can as T for the computation system to be
>>>>>> Turing Compllete, T can't be given powers to do things that
>>>>>> other programs don't have.
>>>>>>
>>>>>> Since programs can throw, then inputs can represent programs that
>>>>>> throw.
>>>>>
>>>>> The "program" is that which is being decided by the decider so
>>>>> sNaP is not observable/catchable/throwable by the "program".
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> i.e. what is the defined answer for an input that throws sNaP?
>>>>>>>> If sNaP is like a signalling sNaN, and functions can return it,
>>>>>>>> then H needs to process functions that can return it.
>>>>>>>
>>>>>>> Inputs can't throw the sNaP exception as it is private to the
>>>>>>> decider.
>>>>>>
>>>>>> IMPOSSIBLE. Either the "results" of sNaP is a defined behavior of
>>>>>> the computation system or it isn't
>>>>>>
>>>>>> If it is, then ANYONE can throw it.
>>>>>>
>>>>>> If it isn't, then NO ONE can throw it.
>>>>>>
>>>>>> If your computation system isn't complete in this manner, that
>>>>>> Halting can be decidable, as if P can't generate the sNaP result,
>>>>>> it can't be allowed to call T.
>>>>>>
>>>>>> Many non-Turing Complete systems can have Halting deciders if the
>>>>>> decider has powers that the things it is deciding on can't have.
>>>>>>
>>>>>
>>>>> The "program" is that which is being decided by the decider so
>>>>> sNaP is not observable/catchable/throwable by the "program".
>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> These are the sorts of questions you need to think about and
>>>>>>>> answer if you really want to create a new sort of decider to
>>>>>>>> see what it can do.
>>>>>>>
>>>>>>> I have thought about them and I have provided you with answers.
>>>>>>> I did state previously that I don't have to go into
>>>>>>> implementation details of the signaling decider: the high level
>>>>>>> design should be sufficient as long as the reader can apply a
>>>>>>> bit of intelligence when reading it.
>>>>>>
>>>>>> You don't need to necessarily say how H does its job, but you do
>>>>>> need to specify precisely AND COMPLETELY what that job is. That
>>>>>> means you need to think about the corner cases. If only T can
>>>>>> generate the exception, then T is NOT a program in the computaton
>>>>>> system you have defined, as it is doing something "programs"
>>>>>> aren't allowed to do.
>>>>>>
>>>>>> That makes T a not very interesting decider, as the Halting
>>>>>> Problem has other possible solutions when the decider is a more
>>>>>> powerful machine than what it is deciding on.
>>>>>
>>>>> Refuting [Strachey 1965] and associated proofs is quite
>>>>> "interesting".
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Unstopable exceptions (FATAL ERRORS) become very unfriendly
>>>>>>>>>>>> in use, but may be simpler to deal with in theory (but a
>>>>>>>>>>>> lot less useful).
>>>>>>>>>>>
>>>>>>>>>>> In your opinion; again I disagree.
>>>>>>>>>>
>>>>>>>>>> How often does YOUR computer just shut itself down in reponse
>>>>>>>>>> to being given a bad probem?
>>>>>>>>>>
>>>>>>>>>> THAT is the actual effect of a truely unstoppable exception.
>>>>>>>>>>
>>>>>>>>>> BLUE SCREEN OF DEATH time.
>>>>>>>>>
>>>>>>>>> An operating system panic is quite different to a userland
>>>>>>>>> program raising an exception. The sNaP exception is equivalent
>>>>>>>>> to the sNaN exception of IEEE 754 floating point.
>>>>>>>>
>>>>>>>> Nope, that is the result of a exception that can not be caught
>>>>>>>> at all. The only way to keep software from catching the
>>>>>>>> exception is to shut the system down.
>>>>>>>
>>>>>>> The input cannot catch the sNaP exception as it is private to
>>>>>>> the decider.
>>>>>>
>>>>>> Note the "Input" but the CALLER of the decider, that supposedly
>>>>>> you are returning an answer too.
>>>>>
>>>>> The "program" is that which is being decided by the decider so
>>>>> sNaP is not observable/catchable/throwable by the "program".
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Remember, in basic computation theory, there is no such thing
>>>>>>>> as "userland", so no saying that the exception goes through
>>>>>>>> userland to the operating system.
>>>>>>>
>>>>>>> I can choose to present my solution within whatever domain I see
>>>>>>> fit.
>>>>>>
>>>>>> Yes, and it can be a worthless solution if you restrict the
>>>>>> problem domain to somethng uninteresting.
>>>>>
>>>>> Opinion.
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> The sNaN exception is a CATCHABLE exception, that the program
>>>>>>>> can cature and do something with it.
>>>>>>>
>>>>>>> The input cannot catch the sNaP exception as it is private to
>>>>>>> the decider.
>>>>>>
>>>>>> I'm not saying the "INPUT", I'm saying to the CALLER of the
>>>>>> decider.
>>>>>>
>>>>>> A decider that doesn't answer to its caller with its answer is to
>>>>>> computation theory WORTHLESS.
>>>>>
>>>>> The decider does answer to its caller unless the input is
>>>>> pathological in which case sNaP will be signaled.
>>>>>
>>>>
>>>> So your decider is definied to Blue Screen of Death on pathological
>>>> input.
>>>>
>>>> Note, Blue Screen of Death, likeyour sNaP is NOT an "Answer",
>>>> because it is NOT given to the asker.
>>>>
>>>> That means that your sNaP is NOT like sNaN, as the later can, and
>>>> normally IS captured by the program doing the operation, and in
>>>> fact is DESIGNED to be captured by the program in use.
>>>>
>>>> Being signalling rather than quiet says the program MUST do
>>>> something about it (or get aborted).
>>>>
>>>>>>
>>>>>>>
>>>>>>>>>>>> If you can't write a program that does something like, try
>>>>>>>>>>>> to do thing 1, but if that throws a contradiction error, do
>>>>>>>>>>>> thing 2 instead.
>>>>>>>>>>>>
>>>>>>>>>>>> This brings up the interesting question, if the input to T
>>>>>>>>>>>> throws a contradiction error, what should T return? If
>>>>>>>>>>>> contradiction errors are uncatchable, then the only choice
>>>>>>>>>>>> is to return that same contradiction error, EVEN IF THE
>>>>>>>>>>>> OTHER PATH HAD A GOOD ANSWER.
>>>>>>>>>>>
>>>>>>>>>>> You need to re-read my proposal again but this time try to
>>>>>>>>>>> FULLY UNDERSTAND IT and understand the implications.
>>>>>>>>>>
>>>>>>>>>> It says that pathology is detected and reported.
>>>>>>>>>>
>>>>>>>>>> In Computation Theory a function "reports" by returning an
>>>>>>>>>> answer in some way to its caller.
>>>>>>>>>
>>>>>>>>> The sNaP exception is reported by the simulator not by the
>>>>>>>>> function H called by P: I have already told you what that H
>>>>>>>>> does: it returns both true and false to copies of P and then
>>>>>>>>> PROCEEDS WITH THE SIMULATION.
>>>>>>>>
>>>>>>>> Then you H is not the decider you claim. This is the error
>>>>>>>> Peter had years ago when it was pointed out that if x86utm was
>>>>>>>> the actual decider that then P would need to invoke x86utm
>>>>>>>> with the input being itself applied to itself, but x86utm
>>>>>>>> can't handle calls to things like system that would preform
>>>>>>>> that action.
>>>>>>>
>>>>>>> The decider is the decider I claim, it is in fact EXACTLY the
>>>>>>> decider I claim and it bears no resemblance to Peter's efforts.
>>>>>>>
>>>>>>> [snip]
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> You keep on ignoring what the decider is returning to the actual
>>>>>> program that is the CALLER of the decider.
>>>>>>
>>>>>> A decider that can't actually be called is totally uninteresting
>>>>>> to Computation Theory.
>>>>>
>>>>> The "program" is that which is being decided by the decider so
>>>>> sNaP is not observable/catchable/throwable by the "program".
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> No, the "Program" is something that is run.
>>>>
>>>> If I Run P1, and P1 calls T[P2] then P1 is the caller program and
>>>> P2 is the input to T, which happens to represent a Program too.
>>>>
>>>> You seem to want to define your sNaP event as a Blue Screen of
>>>> Death that immediately ends all computations, which makes it NOT a
>>>> "answer" in the computation sense.
>>>>
>>>> Yes, maybe you see it as answering to the User who is operating the
>>>> system, but that is not the normal step goal of a computation, as
>>>> it means it can't be used to build up other operations.
>>>>
>>>> Yes, it is just about as useful as having a program somehow
>>>> intentionally create a BSOD as a way to create an "answer".
>>>
>>> OK, to progress this lets dig down into your most interesting test
>>> case:
>>>
>>> void P(x) {
>>> bool r;
>>> try {
>>> r = H(P,P);
>>> } catch(sNaP) {
>>> // Do something here like:
>>> r = true;
>>> }
>>> while (r) continue;
>>> }
>>>
>>> void main() {
>>> P(P);
>>> }
>>>
>>> It is a basic requirement of my signaling decider that the program
>>> or function being analyzed must be run from within the decider. As
>>> H(P, P) is being called from within P before P has been passed to
>>> the decider the sNaP exception will be signaled. The fact that P
>>> catches this exception and invokes non-halting behavior is
>>> irrelevant as far as my decider is concerned as that particular
>>> *invocation* of P is not being run from within the decider so is in
>>> contravention of a basic requirement of my decider.
>>>
>>> You might now claim that my signaling decider isn't a proper
>>> decider as far as the HP is concerned due to the presence of the
>>> above requirement but I respectfully disagree. You will have to
>>> show WHY such a requirement is in conflict with the definition of a
>>> halting decider.
>>>
>>> /Flibble
>>>
>>
>> And, a fundamental issue is that for a simulation to be "correct" it
>> must match the behavior of the actual program.
>>
>> If the answer tp H(P,P) doesn't match the behavior of P(P), then it
>> is hard to call the answer "correct".
>>
>> Yes, it can make sense to define that some cases will result in H
>> needing to give a "This program is acting contradictory to may
>> prediction so it is impossible to give an answer", but once you
>> define that answer as "throwing an exception", and thus have
>> introduced "throwing an exception" into you list of possible
>> behaviors, you need to define how your decider will handle inputs
>> that do that.
>>
>> If you are going to to make an "useful" answer by adding such an
>> extension to the behaviors of machines, you need to FULLY define how
>> that works.
>
> Except if the input is pathological then it isn't acting contradictory
> to the decider's prediction as the decider is testing both outcomes
> (halting and non-halting) and THEN detects a contradiction which means
> the input is pathological and is signaled as such which is an answer
> (just not an answer of halting or non-halting).
>
> Calling P before invoking the decider means the outcome of that call is
> no business of the decider as doing so is not meeting the usage
> requirements of the decider.
>
> /Flibble
>


Click here to read the complete article
Re: A plea...

<20220720181504.000065d3@reddwarf.jmc.corp>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35858&group=comp.theory#35858

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!news.freedyn.de!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!fx10.ams4.POSTED!not-for-mail
From: flib...@reddwarf.jmc.corp (Mr Flibble)
Newsgroups: comp.theory
Subject: Re: A plea...
Message-ID: <20220720181504.000065d3@reddwarf.jmc.corp>
References: <87k08c79ys.fsf@bsb.me.uk>
<1AZAK.598124$wIO9.69713@fx12.iad>
<20220717205331.0000461e@reddwarf.jmc.corp>
<fc%AK.397559$vAW9.238590@fx10.iad>
<20220717224436.00002c66@reddwarf.jmc.corp>
<qE%AK.514397$ntj.427354@fx15.iad>
<20220717230620.00001532@reddwarf.jmc.corp>
<Um0BK.514846$ntj.83746@fx15.iad>
<20220717235402.00002719@reddwarf.jmc.corp>
<hO0BK.48201$Ae2.4639@fx35.iad>
<20220718002744.00002d25@reddwarf.jmc.corp>
<up2BK.40810$Sf2.38749@fx34.iad>
<20220718021821.000056d2@reddwarf.jmc.corp>
<qN2BK.57711$sZ1.19122@fx07.iad>
<20220718073646.000070ff@reddwarf.jmc.corp>
<GobBK.581682$JVi.394817@fx17.iad>
<20220718172136.000029ad@reddwarf.jmc.corp>
<tXlBK.517864$ntj.364914@fx15.iad>
<20220719083420.00005f0f@reddwarf.jmc.corp>
<vrwBK.33025$8f2.30099@fx38.iad>
<20220719181344.00001568@reddwarf.jmc.corp>
<THGBK.573696$X_i.35184@fx18.iad>
<20220720003151.00000bd7@reddwarf.jmc.corp>
<DuIBK.86909$f81.35526@fx43.iad>
Organization: Jupiter Mining Corporation
X-Newsreader: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Lines: 599
X-Complaints-To: abuse@eweka.nl
NNTP-Posting-Date: Wed, 20 Jul 2022 17:15:05 UTC
Date: Wed, 20 Jul 2022 18:15:04 +0100
X-Received-Bytes: 28650
 by: Mr Flibble - Wed, 20 Jul 2022 17:15 UTC

On Tue, 19 Jul 2022 21:02:25 -0400
Richard Damon <Richard@Damon-Family.org> wrote:

> On 7/19/22 7:31 PM, Mr Flibble wrote:
> > On Tue, 19 Jul 2022 19:00:03 -0400
> > Richard Damon <Richard@Damon-Family.org> wrote:
> >
> >> On 7/19/22 1:13 PM, Mr Flibble wrote:
> >>> On Tue, 19 Jul 2022 07:19:55 -0400
> >>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>
> >>>> On 7/19/22 3:34 AM, Mr Flibble wrote:
> >>>>> On Mon, 18 Jul 2022 19:23:04 -0400
> >>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>
> >>>>>> On 7/18/22 12:21 PM, Mr Flibble wrote:
> >>>>>>> On Mon, 18 Jul 2022 07:23:17 -0400
> >>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>
> >>>>>>>> On 7/18/22 2:36 AM, Mr Flibble wrote:
> >>>>>>>>> On Sun, 17 Jul 2022 21:35:18 -0400
> >>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>
> >>>>>>>>>> On 7/17/22 9:18 PM, Mr Flibble wrote:
> >>>>>>>>>>> On Sun, 17 Jul 2022 21:09:45 -0400
> >>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On 7/17/22 7:27 PM, Mr Flibble wrote:
> >>>>>>>>>>>>> On Sun, 17 Jul 2022 19:19:40 -0400
> >>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 7/17/22 6:54 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>> On Sun, 17 Jul 2022 18:50:28 -0400
> >>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 7/17/22 6:06 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 18:00:54 -0400
> >>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On 7/17/22 5:44 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 17:30:50 -0400
> >>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On 7/17/22 3:53 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 15:39:40 -0400
> >>>>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On 7/17/22 3:05 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 13:36:32 -0500
> >>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> On 7/17/2022 1:00 PM, Gawr Gura wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>> On 7/16/22 19:24, Ben Bacarisse wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>> Please don't respond to Peter Olcott's
> >>>>>>>>>>>>>>>>>>>>>>>>>> posts here. His threads have taken over
> >>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory, but there is no reason that
> >>>>>>>>>>>>>>>>>>>>>>>>>> comp.lang c (or comp.lang.c++) should
> >>>>>>>>>>>>>>>>>>>>>>>>>> suffer the same fate. These two groups
> >>>>>>>>>>>>>>>>>>>>>>>>>> have had many interesting threads over the
> >>>>>>>>>>>>>>>>>>>>>>>>>> years, but they will die if they fill up
> >>>>>>>>>>>>>>>>>>>>>>>>>> with junk.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> If you want to reply to him, just pick any
> >>>>>>>>>>>>>>>>>>>>>>>>>> of the thousands of posts in comp.theory
> >>>>>>>>>>>>>>>>>>>>>>>>>> and he'll be as happy to insult you and
> >>>>>>>>>>>>>>>>>>>>>>>>>> call you ignorant there as he is here.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> I've not made this a head post because I
> >>>>>>>>>>>>>>>>>>>>>>>>>> don't want to single anyone out.  Everyone
> >>>>>>>>>>>>>>>>>>>>>>>>>> who'd got something out of comp.lang.c
> >>>>>>>>>>>>>>>>>>>>>>>>>> should care about its curation...
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Ben, I think the cranks have taken over the
> >>>>>>>>>>>>>>>>>>>>>>>>> asylum.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Flibble is a crank because he created a
> >>>>>>>>>>>>>>>>>>>>>>>> pathological input detector and continues to
> >>>>>>>>>>>>>>>>>>>>>>>> leave out the core piece, the criterion
> >>>>>>>>>>>>>>>>>>>>>>>> measure of detecting a pathological input.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The design of my signaling decider clearly
> >>>>>>>>>>>>>>>>>>>>>>> sets out how pathological input is detected:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> https://github.com/i42output/halting-problem/blob/main/README.txt
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The implementation details of how halting or
> >>>>>>>>>>>>>>>>>>>>>>> non-halting are actually decided are not
> >>>>>>>>>>>>>>>>>>>>>>> described in the design nor need they be for
> >>>>>>>>>>>>>>>>>>>>>>> me to not be a "crank".
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> The one problem with your design is that you
> >>>>>>>>>>>>>>>>>>>>>> have adopted the same faulty simulate the
> >>>>>>>>>>>>>>>>>>>>>> input in the same program memory space as the
> >>>>>>>>>>>>>>>>>>>>>> decider that Peter uses, which means that you
> >>>>>>>>>>>>>>>>>>>>>> won't actually be able to convert the design
> >>>>>>>>>>>>>>>>>>>>>> into two seperate Turing Machines, one for the
> >>>>>>>>>>>>>>>>>>>>>> H that is being asked to decide, and one for P
> >>>>>>>>>>>>>>>>>>>>>> that has its own copy of H, which needs to be
> >>>>>>>>>>>>>>>>>>>>>> run as a machine to see what its answer is and
> >>>>>>>>>>>>>>>>>>>>>> also given to H to see what it decides (though
> >>>>>>>>>>>>>>>>>>>>>> the second might be able to be extracted out
> >>>>>>>>>>>>>>>>>>>>>> of the run of the first).
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> The problem here is that H can't just simply
> >>>>>>>>>>>>>>>>>>>>>> compare "addresses" to detect calls to
> >>>>>>>>>>>>>>>>>>>>>> "itself", but needs to be able to detect a
> >>>>>>>>>>>>>>>>>>>>>> "copy" of itself embedded in another machine.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> In the slightly faulty execution description
> >>>>>>>>>>>>>>>>>>>>>> that Peter uses, which means there are some
> >>>>>>>>>>>>>>>>>>>>>> machines you can not provide to your machine,
> >>>>>>>>>>>>>>>>>>>>>> you system works if the program calls YOU H,
> >>>>>>>>>>>>>>>>>>>>>> and not a copy of it.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> [Strachey 1965] doesn't require two separate
> >>>>>>>>>>>>>>>>>>>>> Turing Machines as far as I can tell:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> rec routine P
> >>>>>>>>>>>>>>>>>>>>> § L : if T[P] goto L
> >>>>>>>>>>>>>>>>>>>>> Return §
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> [Strachey 1965] only talks about functions and
> >>>>>>>>>>>>>>>>>>>>> not Turing Machines: T is defined to be a
> >>>>>>>>>>>>>>>>>>>>> *function returning a boolean*.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I am less familiar with Strachey, if I remember
> >>>>>>>>>>>>>>>>>>>> right, T[P] passes to T the source code of P,
> >>>>>>>>>>>>>>>>>>>> and I guess he allows that source code to
> >>>>>>>>>>>>>>>>>>>> directly reference the decider that it is
> >>>>>>>>>>>>>>>>>>>> confounding.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Maybe you can make the class of deciders you are
> >>>>>>>>>>>>>>>>>>>> working on, with the added paradoxical output for
> >>>>>>>>>>>>>>>>>>>> that form, but it doesn't extend to the classical
> >>>>>>>>>>>>>>>>>>>> problem based on Turing Machines.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Of course, the issue is that T is defined to
> >>>>>>>>>>>>>>>>>>>> return boolean, and not an exception, and it
> >>>>>>>>>>>>>>>>>>>> still doesn't show that you CAN build a Halt
> >>>>>>>>>>>>>>>>>>>> Decider, just that this one simple counter
> >>>>>>>>>>>>>>>>>>>> example can be filtered out.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> T still returns a boolean for my signaling
> >>>>>>>>>>>>>>>>>>> decider; the exception is only thrown later on
> >>>>>>>>>>>>>>>>>>> when pathology is determined.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Which means it has 3 return conditions, returning
> >>>>>>>>>>>>>>>>>> true, returning false, or throwing the pathological
> >>>>>>>>>>>>>>>>>> exception. That is really a form of "return" for a
> >>>>>>>>>>>>>>>>>> function, just with a somewhat different method.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> If you translate into a Turing Machine, it just
> >>>>>>>>>>>>>>>>>> becomes a 3rd final state.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> It only returns true or false to P; the exception is
> >>>>>>>>>>>>>>>>> thrown later, out of band.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> It Can't.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> It can and does.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> HOW. You use T to decide on P by writing T[P] just
> >>>>>>>>>>>>>> like P calls it.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> It returns BOTH true AND false to P as it doesn't YET
> >>>>>>>>>>>>> know if P is pathological and if it isn't whether it
> >>>>>>>>>>>>> halts or not; it will find that out as the simulation
> >>>>>>>>>>>>> continues.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Your confusing what the actual function T does and how T
> >>>>>>>>>>>> simulates recursive calls to T.
> >>>>>>>>>>>>
> >>>>>>>>>>>> If T sees a call to T with the same parameter(s) as a
> >>>>>>>>>>>> previous call to T (or the original call to T) had, you
> >>>>>>>>>>>> replace them with a split where you return true to one
> >>>>>>>>>>>> side and return false to the other and process.
> >>>>>>>>>>>>
> >>>>>>>>>>>> When T is called by an actually running P, it needs to
> >>>>>>>>>>>> return the full decision, including the exception to that
> >>>>>>>>>>>> P, just as it does if directly asked (by main or just
> >>>>>>>>>>>> asked depending on how the language works).
> >>>>>>>>>>>
> >>>>>>>>>>> That is where we disagree: I see no reason why my scheme
> >>>>>>>>>>> is invalid: P doesn't actually care what T does, it acts
> >>>>>>>>>>> on what T returns. T returns both halting decisions to two
> >>>>>>>>>>> copies of P and allows the simulation to proceed with no
> >>>>>>>>>>> recursion.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The question then becomes, what does P do with that third
> >>>>>>>>>>>> answer? What are programs ALLOWED to do with that third
> >>>>>>>>>>>> answer.
> >>>>>>>>>>>
> >>>>>>>>>>> I already told you that P never sees the "third answer"
> >>>>>>>>>>> (exception) as that happens out of band.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> The directly executed P does, at least if T[P] ever
> >>>>>>>>>> generates that third answer as an answer and "reports" it
> >>>>>>>>>> to its caller.
> >>>>>>>>>
> >>>>>>>>> Stop being so obtuse. The exception is not reported to its
> >>>>>>>>> caller (P) as it is not known at the point in the simulation
> >>>>>>>>> if the exceptional condition exits. My solution, unlike
> >>>>>>>>> PO's, is NOT infinitely recursive: think about what that
> >>>>>>>>> actually means and try re-reading my proposal AGAIN but this
> >>>>>>>>> time try to fucking comprehend it. The exception is an out
> >>>>>>>>> of band signal.
> >>>>>>>>
> >>>>>>>> I repeat, I am not talking about in the simulation, but in
> >>>>>>>> the initial call to H.
> >>>>>>>>
> >>>>>>>> What would be the results of:
> >>>>>>>>
> >>>>>>>> void P(x) {
> >>>>>>>> bool r = H(x,x);
> >>>>>>>> while (r) continue;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> void main() {
> >>>>>>>> P(P);
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> I.e. main calls P(P) which calls your H(P,P), what happens
> >>>>>>>> THERE at THAT call site.
> >>>>>>>
> >>>>>>> sNaP exception due to H being passed an input from within the
> >>>>>>> input that has not previously been passed to H from outside
> >>>>>>> the input.
> >>>>>>
> >>>>>> So, you said it was like sNaN, so the program can be configured
> >>>>>> to catch this exception, right? Like show below.
> >>>>>
> >>>>> The "program" is that which is being decided by the decider so
> >>>>> sNaP is not observable/catchable/throwable by the "program".
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> If sNaP is just like sNaN what happens if instead I make P
> >>>>>>>> be:
> >>>>>>>>
> >>>>>>>> void P(x) {
> >>>>>>>> bool r;
> >>>>>>>> try {
> >>>>>>>> r = H(P,P)l
> >>>>>>>> } catch(sNaO) {
> >>>>>>>> // Do something here like:
> >>>>>>>> r = true;
> >>>>>>>> }
> >>>>>>>> while (r) continue;
> >>>>>>>> }
> >>>>>>>
> >>>>>>> Inputs can't observe/catch the sNaP exception as it is
> >>>>>>> private to the decider.
> >>>>>>
> >>>>>> P isn't "Just an input", remember main CALLS P(P) so it is a
> >>>>>> program too.
> >>>>>>
> >>>>>> So, are you saying that the decider doesn't tell anyone about
> >>>>>> the exception, but it just means the whole machine stops?
> >>>>>
> >>>>> sNaP exception will be thrown for same reason given previously.
> >>>>> The "program" is that which is being decided by the decider so
> >>>>> sNaP is not observable/catchable/throwable by the "program".
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> i.e. it is a Blue Screen of Death?
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Also, what happens if I do:
> >>>>>>>>
> >>>>>>>> void P(x) {
> >>>>>>>> throw sNaP;
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> bool T(x) {
> >>>>>>>> return H(x,x);
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> void main() {
> >>>>>>>> Output(T(P,P));
> >>>>>>>> }
> >>>>>>>
> >>>>>>> Inputs can't throw the sNaP exception as it is private to the
> >>>>>>> decider.
> >>>>>>
> >>>>>> But other programs can as T for the computation system to be
> >>>>>> Turing Compllete, T can't be given powers to do things that
> >>>>>> other programs don't have.
> >>>>>>
> >>>>>> Since programs can throw, then inputs can represent programs
> >>>>>> that throw.
> >>>>>
> >>>>> The "program" is that which is being decided by the decider so
> >>>>> sNaP is not observable/catchable/throwable by the "program".
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> i.e. what is the defined answer for an input that throws
> >>>>>>>> sNaP? If sNaP is like a signalling sNaN, and functions can
> >>>>>>>> return it, then H needs to process functions that can return
> >>>>>>>> it.
> >>>>>>>
> >>>>>>> Inputs can't throw the sNaP exception as it is private to the
> >>>>>>> decider.
> >>>>>>
> >>>>>> IMPOSSIBLE. Either the "results" of sNaP is a defined behavior
> >>>>>> of the computation system or it isn't
> >>>>>>
> >>>>>> If it is, then ANYONE can throw it.
> >>>>>>
> >>>>>> If it isn't, then NO ONE can throw it.
> >>>>>>
> >>>>>> If your computation system isn't complete in this manner, that
> >>>>>> Halting can be decidable, as if P can't generate the sNaP
> >>>>>> result, it can't be allowed to call T.
> >>>>>>
> >>>>>> Many non-Turing Complete systems can have Halting deciders if
> >>>>>> the decider has powers that the things it is deciding on can't
> >>>>>> have.
> >>>>>
> >>>>> The "program" is that which is being decided by the decider so
> >>>>> sNaP is not observable/catchable/throwable by the "program".
> >>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> These are the sorts of questions you need to think about and
> >>>>>>>> answer if you really want to create a new sort of decider to
> >>>>>>>> see what it can do.
> >>>>>>>
> >>>>>>> I have thought about them and I have provided you with
> >>>>>>> answers. I did state previously that I don't have to go into
> >>>>>>> implementation details of the signaling decider: the high
> >>>>>>> level design should be sufficient as long as the reader can
> >>>>>>> apply a bit of intelligence when reading it.
> >>>>>>
> >>>>>> You don't need to necessarily say how H does its job, but you
> >>>>>> do need to specify precisely AND COMPLETELY what that job is.
> >>>>>> That means you need to think about the corner cases. If only T
> >>>>>> can generate the exception, then T is NOT a program in the
> >>>>>> computaton system you have defined, as it is doing something
> >>>>>> "programs" aren't allowed to do.
> >>>>>>
> >>>>>> That makes T a not very interesting decider, as the Halting
> >>>>>> Problem has other possible solutions when the decider is a more
> >>>>>> powerful machine than what it is deciding on.
> >>>>>
> >>>>> Refuting [Strachey 1965] and associated proofs is quite
> >>>>> "interesting".
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Unstopable exceptions (FATAL ERRORS) become very
> >>>>>>>>>>>> unfriendly in use, but may be simpler to deal with in
> >>>>>>>>>>>> theory (but a lot less useful).
> >>>>>>>>>>>
> >>>>>>>>>>> In your opinion; again I disagree.
> >>>>>>>>>>
> >>>>>>>>>> How often does YOUR computer just shut itself down in
> >>>>>>>>>> reponse to being given a bad probem?
> >>>>>>>>>>
> >>>>>>>>>> THAT is the actual effect of a truely unstoppable
> >>>>>>>>>> exception.
> >>>>>>>>>>
> >>>>>>>>>> BLUE SCREEN OF DEATH time.
> >>>>>>>>>
> >>>>>>>>> An operating system panic is quite different to a userland
> >>>>>>>>> program raising an exception. The sNaP exception is
> >>>>>>>>> equivalent to the sNaN exception of IEEE 754 floating
> >>>>>>>>> point.
> >>>>>>>>
> >>>>>>>> Nope, that is the result of a exception that can not be
> >>>>>>>> caught at all. The only way to keep software from catching
> >>>>>>>> the exception is to shut the system down.
> >>>>>>>
> >>>>>>> The input cannot catch the sNaP exception as it is private to
> >>>>>>> the decider.
> >>>>>>
> >>>>>> Note the "Input" but the CALLER of the decider, that supposedly
> >>>>>> you are returning an answer too.
> >>>>>
> >>>>> The "program" is that which is being decided by the decider so
> >>>>> sNaP is not observable/catchable/throwable by the "program".
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Remember, in basic computation theory, there is no such thing
> >>>>>>>> as "userland", so no saying that the exception goes through
> >>>>>>>> userland to the operating system.
> >>>>>>>
> >>>>>>> I can choose to present my solution within whatever domain I
> >>>>>>> see fit.
> >>>>>>
> >>>>>> Yes, and it can be a worthless solution if you restrict the
> >>>>>> problem domain to somethng uninteresting.
> >>>>>
> >>>>> Opinion.
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> The sNaN exception is a CATCHABLE exception, that the program
> >>>>>>>> can cature and do something with it.
> >>>>>>>
> >>>>>>> The input cannot catch the sNaP exception as it is private to
> >>>>>>> the decider.
> >>>>>>
> >>>>>> I'm not saying the "INPUT", I'm saying to the CALLER of the
> >>>>>> decider.
> >>>>>>
> >>>>>> A decider that doesn't answer to its caller with its answer is
> >>>>>> to computation theory WORTHLESS.
> >>>>>
> >>>>> The decider does answer to its caller unless the input is
> >>>>> pathological in which case sNaP will be signaled.
> >>>>>
> >>>>
> >>>> So your decider is definied to Blue Screen of Death on
> >>>> pathological input.
> >>>>
> >>>> Note, Blue Screen of Death, likeyour sNaP is NOT an "Answer",
> >>>> because it is NOT given to the asker.
> >>>>
> >>>> That means that your sNaP is NOT like sNaN, as the later can, and
> >>>> normally IS captured by the program doing the operation, and in
> >>>> fact is DESIGNED to be captured by the program in use.
> >>>>
> >>>> Being signalling rather than quiet says the program MUST do
> >>>> something about it (or get aborted).
> >>>>
> >>>>>>
> >>>>>>>
> >>>>>>>>>>>> If you can't write a program that does something like,
> >>>>>>>>>>>> try to do thing 1, but if that throws a contradiction
> >>>>>>>>>>>> error, do thing 2 instead.
> >>>>>>>>>>>>
> >>>>>>>>>>>> This brings up the interesting question, if the input to
> >>>>>>>>>>>> T throws a contradiction error, what should T return? If
> >>>>>>>>>>>> contradiction errors are uncatchable, then the only
> >>>>>>>>>>>> choice is to return that same contradiction error, EVEN
> >>>>>>>>>>>> IF THE OTHER PATH HAD A GOOD ANSWER.
> >>>>>>>>>>>
> >>>>>>>>>>> You need to re-read my proposal again but this time try to
> >>>>>>>>>>> FULLY UNDERSTAND IT and understand the implications.
> >>>>>>>>>>
> >>>>>>>>>> It says that pathology is detected and reported.
> >>>>>>>>>>
> >>>>>>>>>> In Computation Theory a function "reports" by returning an
> >>>>>>>>>> answer in some way to its caller.
> >>>>>>>>>
> >>>>>>>>> The sNaP exception is reported by the simulator not by the
> >>>>>>>>> function H called by P: I have already told you what that H
> >>>>>>>>> does: it returns both true and false to copies of P and then
> >>>>>>>>> PROCEEDS WITH THE SIMULATION.
> >>>>>>>>
> >>>>>>>> Then you H is not the decider you claim. This is the error
> >>>>>>>> Peter had years ago when it was pointed out that if x86utm
> >>>>>>>> was the actual decider that then P would need to invoke
> >>>>>>>> x86utm with the input being itself applied to itself, but
> >>>>>>>> x86utm can't handle calls to things like system that would
> >>>>>>>> preform that action.
> >>>>>>>
> >>>>>>> The decider is the decider I claim, it is in fact EXACTLY the
> >>>>>>> decider I claim and it bears no resemblance to Peter's
> >>>>>>> efforts.
> >>>>>>>
> >>>>>>> [snip]
> >>>>>>>
> >>>>>>> /Flibble
> >>>>>>>
> >>>>>>
> >>>>>> You keep on ignoring what the decider is returning to the
> >>>>>> actual program that is the CALLER of the decider.
> >>>>>>
> >>>>>> A decider that can't actually be called is totally
> >>>>>> uninteresting to Computation Theory.
> >>>>>
> >>>>> The "program" is that which is being decided by the decider so
> >>>>> sNaP is not observable/catchable/throwable by the "program".
> >>>>>
> >>>>> /Flibble
> >>>>>
> >>>>
> >>>> No, the "Program" is something that is run.
> >>>>
> >>>> If I Run P1, and P1 calls T[P2] then P1 is the caller program and
> >>>> P2 is the input to T, which happens to represent a Program too.
> >>>>
> >>>> You seem to want to define your sNaP event as a Blue Screen of
> >>>> Death that immediately ends all computations, which makes it NOT
> >>>> a "answer" in the computation sense.
> >>>>
> >>>> Yes, maybe you see it as answering to the User who is operating
> >>>> the system, but that is not the normal step goal of a
> >>>> computation, as it means it can't be used to build up other
> >>>> operations.
> >>>>
> >>>> Yes, it is just about as useful as having a program somehow
> >>>> intentionally create a BSOD as a way to create an "answer".
> >>>
> >>> OK, to progress this lets dig down into your most interesting test
> >>> case:
> >>>
> >>> void P(x) {
> >>> bool r;
> >>> try {
> >>> r = H(P,P);
> >>> } catch(sNaP) {
> >>> // Do something here like:
> >>> r = true;
> >>> }
> >>> while (r) continue;
> >>> }
> >>>
> >>> void main() {
> >>> P(P);
> >>> }
> >>>
> >>> It is a basic requirement of my signaling decider that the program
> >>> or function being analyzed must be run from within the decider.
> >>> As H(P, P) is being called from within P before P has been passed
> >>> to the decider the sNaP exception will be signaled. The fact that
> >>> P catches this exception and invokes non-halting behavior is
> >>> irrelevant as far as my decider is concerned as that particular
> >>> *invocation* of P is not being run from within the decider so is
> >>> in contravention of a basic requirement of my decider.
> >>>
> >>> You might now claim that my signaling decider isn't a proper
> >>> decider as far as the HP is concerned due to the presence of the
> >>> above requirement but I respectfully disagree. You will have to
> >>> show WHY such a requirement is in conflict with the definition of
> >>> a halting decider.
> >>>
> >>> /Flibble
> >>>
> >>
> >> And, a fundamental issue is that for a simulation to be "correct"
> >> it must match the behavior of the actual program.
> >>
> >> If the answer tp H(P,P) doesn't match the behavior of P(P), then it
> >> is hard to call the answer "correct".
> >>
> >> Yes, it can make sense to define that some cases will result in H
> >> needing to give a "This program is acting contradictory to may
> >> prediction so it is impossible to give an answer", but once you
> >> define that answer as "throwing an exception", and thus have
> >> introduced "throwing an exception" into you list of possible
> >> behaviors, you need to define how your decider will handle inputs
> >> that do that.
> >>
> >> If you are going to to make an "useful" answer by adding such an
> >> extension to the behaviors of machines, you need to FULLY define
> >> how that works.
> >
> > Except if the input is pathological then it isn't acting
> > contradictory to the decider's prediction as the decider is testing
> > both outcomes (halting and non-halting) and THEN detects a
> > contradiction which means the input is pathological and is signaled
> > as such which is an answer (just not an answer of halting or
> > non-halting).
> >
> > Calling P before invoking the decider means the outcome of that
> > call is no business of the decider as doing so is not meeting the
> > usage requirements of the decider.
> >
> > /Flibble
> >
>
> Except that its behavior (if not contradictory because you define
> that as a specific exception) needs to be "correctly" predicted by
> the decider. And thus you need to stop and make sure you have
> actually reasonably defined what all these things mean.
>
> That means defining things like what should H return if its input
> throws sNaP?


Click here to read the complete article
Re: A plea...

<ZD%BK.85973$Me2.46122@fx47.iad>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35859&group=comp.theory#35859

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!feed1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx47.iad.POSTED!not-for-mail
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.11.0
Subject: Re: A plea...
Content-Language: en-US
Newsgroups: comp.theory
References: <87k08c79ys.fsf@bsb.me.uk> <1AZAK.598124$wIO9.69713@fx12.iad>
<20220717205331.0000461e@reddwarf.jmc.corp>
<fc%AK.397559$vAW9.238590@fx10.iad>
<20220717224436.00002c66@reddwarf.jmc.corp>
<qE%AK.514397$ntj.427354@fx15.iad>
<20220717230620.00001532@reddwarf.jmc.corp> <Um0BK.514846$ntj.83746@fx15.iad>
<20220717235402.00002719@reddwarf.jmc.corp> <hO0BK.48201$Ae2.4639@fx35.iad>
<20220718002744.00002d25@reddwarf.jmc.corp> <up2BK.40810$Sf2.38749@fx34.iad>
<20220718021821.000056d2@reddwarf.jmc.corp> <qN2BK.57711$sZ1.19122@fx07.iad>
<20220718073646.000070ff@reddwarf.jmc.corp>
<GobBK.581682$JVi.394817@fx17.iad>
<20220718172136.000029ad@reddwarf.jmc.corp>
<tXlBK.517864$ntj.364914@fx15.iad>
<20220719083420.00005f0f@reddwarf.jmc.corp> <vrwBK.33025$8f2.30099@fx38.iad>
<20220719181344.00001568@reddwarf.jmc.corp> <THGBK.573696$X_i.35184@fx18.iad>
<20220720003151.00000bd7@reddwarf.jmc.corp> <DuIBK.86909$f81.35526@fx43.iad>
<20220720181504.000065d3@reddwarf.jmc.corp>
From: Rich...@Damon-Family.org (Richard Damon)
In-Reply-To: <20220720181504.000065d3@reddwarf.jmc.corp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 609
Message-ID: <ZD%BK.85973$Me2.46122@fx47.iad>
X-Complaints-To: abuse@easynews.com
Organization: Forte - www.forteinc.com
X-Complaints-Info: Please be sure to forward a copy of ALL headers otherwise we will be unable to process your complaint properly.
Date: Wed, 20 Jul 2022 18:49:28 -0400
X-Received-Bytes: 29080
 by: Richard Damon - Wed, 20 Jul 2022 22:49 UTC

On 7/20/22 1:15 PM, Mr Flibble wrote:
> On Tue, 19 Jul 2022 21:02:25 -0400
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 7/19/22 7:31 PM, Mr Flibble wrote:
>>> On Tue, 19 Jul 2022 19:00:03 -0400
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 7/19/22 1:13 PM, Mr Flibble wrote:
>>>>> On Tue, 19 Jul 2022 07:19:55 -0400
>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>
>>>>>> On 7/19/22 3:34 AM, Mr Flibble wrote:
>>>>>>> On Mon, 18 Jul 2022 19:23:04 -0400
>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>
>>>>>>>> On 7/18/22 12:21 PM, Mr Flibble wrote:
>>>>>>>>> On Mon, 18 Jul 2022 07:23:17 -0400
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>
>>>>>>>>>> On 7/18/22 2:36 AM, Mr Flibble wrote:
>>>>>>>>>>> On Sun, 17 Jul 2022 21:35:18 -0400
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 7/17/22 9:18 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Sun, 17 Jul 2022 21:09:45 -0400
>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7/17/22 7:27 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 19:19:40 -0400
>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 7/17/22 6:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 18:50:28 -0400
>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 7/17/22 6:06 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 18:00:54 -0400
>>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 7/17/22 5:44 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 17:30:50 -0400
>>>>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 7/17/22 3:53 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 15:39:40 -0400
>>>>>>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 7/17/22 3:05 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On Sun, 17 Jul 2022 13:36:32 -0500
>>>>>>>>>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/17/2022 1:00 PM, Gawr Gura wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/16/22 19:24, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please don't respond to Peter Olcott's
>>>>>>>>>>>>>>>>>>>>>>>>>>>> posts here. His threads have taken over
>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory, but there is no reason that
>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.lang c (or comp.lang.c++) should
>>>>>>>>>>>>>>>>>>>>>>>>>>>> suffer the same fate. These two groups
>>>>>>>>>>>>>>>>>>>>>>>>>>>> have had many interesting threads over the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> years, but they will die if they fill up
>>>>>>>>>>>>>>>>>>>>>>>>>>>> with junk.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you want to reply to him, just pick any
>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the thousands of posts in comp.theory
>>>>>>>>>>>>>>>>>>>>>>>>>>>> and he'll be as happy to insult you and
>>>>>>>>>>>>>>>>>>>>>>>>>>>> call you ignorant there as he is here.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I've not made this a head post because I
>>>>>>>>>>>>>>>>>>>>>>>>>>>> don't want to single anyone out.  Everyone
>>>>>>>>>>>>>>>>>>>>>>>>>>>> who'd got something out of comp.lang.c
>>>>>>>>>>>>>>>>>>>>>>>>>>>> should care about its curation...
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Ben, I think the cranks have taken over the
>>>>>>>>>>>>>>>>>>>>>>>>>>> asylum.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Flibble is a crank because he created a
>>>>>>>>>>>>>>>>>>>>>>>>>> pathological input detector and continues to
>>>>>>>>>>>>>>>>>>>>>>>>>> leave out the core piece, the criterion
>>>>>>>>>>>>>>>>>>>>>>>>>> measure of detecting a pathological input.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The design of my signaling decider clearly
>>>>>>>>>>>>>>>>>>>>>>>>> sets out how pathological input is detected:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/i42output/halting-problem/blob/main/README.txt
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The implementation details of how halting or
>>>>>>>>>>>>>>>>>>>>>>>>> non-halting are actually decided are not
>>>>>>>>>>>>>>>>>>>>>>>>> described in the design nor need they be for
>>>>>>>>>>>>>>>>>>>>>>>>> me to not be a "crank".
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The one problem with your design is that you
>>>>>>>>>>>>>>>>>>>>>>>> have adopted the same faulty simulate the
>>>>>>>>>>>>>>>>>>>>>>>> input in the same program memory space as the
>>>>>>>>>>>>>>>>>>>>>>>> decider that Peter uses, which means that you
>>>>>>>>>>>>>>>>>>>>>>>> won't actually be able to convert the design
>>>>>>>>>>>>>>>>>>>>>>>> into two seperate Turing Machines, one for the
>>>>>>>>>>>>>>>>>>>>>>>> H that is being asked to decide, and one for P
>>>>>>>>>>>>>>>>>>>>>>>> that has its own copy of H, which needs to be
>>>>>>>>>>>>>>>>>>>>>>>> run as a machine to see what its answer is and
>>>>>>>>>>>>>>>>>>>>>>>> also given to H to see what it decides (though
>>>>>>>>>>>>>>>>>>>>>>>> the second might be able to be extracted out
>>>>>>>>>>>>>>>>>>>>>>>> of the run of the first).
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> The problem here is that H can't just simply
>>>>>>>>>>>>>>>>>>>>>>>> compare "addresses" to detect calls to
>>>>>>>>>>>>>>>>>>>>>>>> "itself", but needs to be able to detect a
>>>>>>>>>>>>>>>>>>>>>>>> "copy" of itself embedded in another machine.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> In the slightly faulty execution description
>>>>>>>>>>>>>>>>>>>>>>>> that Peter uses, which means there are some
>>>>>>>>>>>>>>>>>>>>>>>> machines you can not provide to your machine,
>>>>>>>>>>>>>>>>>>>>>>>> you system works if the program calls YOU H,
>>>>>>>>>>>>>>>>>>>>>>>> and not a copy of it.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> [Strachey 1965] doesn't require two separate
>>>>>>>>>>>>>>>>>>>>>>> Turing Machines as far as I can tell:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> rec routine P
>>>>>>>>>>>>>>>>>>>>>>> § L : if T[P] goto L
>>>>>>>>>>>>>>>>>>>>>>> Return §
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> [Strachey 1965] only talks about functions and
>>>>>>>>>>>>>>>>>>>>>>> not Turing Machines: T is defined to be a
>>>>>>>>>>>>>>>>>>>>>>> *function returning a boolean*.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I am less familiar with Strachey, if I remember
>>>>>>>>>>>>>>>>>>>>>> right, T[P] passes to T the source code of P,
>>>>>>>>>>>>>>>>>>>>>> and I guess he allows that source code to
>>>>>>>>>>>>>>>>>>>>>> directly reference the decider that it is
>>>>>>>>>>>>>>>>>>>>>> confounding.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Maybe you can make the class of deciders you are
>>>>>>>>>>>>>>>>>>>>>> working on, with the added paradoxical output for
>>>>>>>>>>>>>>>>>>>>>> that form, but it doesn't extend to the classical
>>>>>>>>>>>>>>>>>>>>>> problem based on Turing Machines.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Of course, the issue is that T is defined to
>>>>>>>>>>>>>>>>>>>>>> return boolean, and not an exception, and it
>>>>>>>>>>>>>>>>>>>>>> still doesn't show that you CAN build a Halt
>>>>>>>>>>>>>>>>>>>>>> Decider, just that this one simple counter
>>>>>>>>>>>>>>>>>>>>>> example can be filtered out.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> T still returns a boolean for my signaling
>>>>>>>>>>>>>>>>>>>>> decider; the exception is only thrown later on
>>>>>>>>>>>>>>>>>>>>> when pathology is determined.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Which means it has 3 return conditions, returning
>>>>>>>>>>>>>>>>>>>> true, returning false, or throwing the pathological
>>>>>>>>>>>>>>>>>>>> exception. That is really a form of "return" for a
>>>>>>>>>>>>>>>>>>>> function, just with a somewhat different method.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If you translate into a Turing Machine, it just
>>>>>>>>>>>>>>>>>>>> becomes a 3rd final state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It only returns true or false to P; the exception is
>>>>>>>>>>>>>>>>>>> thrown later, out of band.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> It Can't.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It can and does.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> HOW. You use T to decide on P by writing T[P] just
>>>>>>>>>>>>>>>> like P calls it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It returns BOTH true AND false to P as it doesn't YET
>>>>>>>>>>>>>>> know if P is pathological and if it isn't whether it
>>>>>>>>>>>>>>> halts or not; it will find that out as the simulation
>>>>>>>>>>>>>>> continues.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Your confusing what the actual function T does and how T
>>>>>>>>>>>>>> simulates recursive calls to T.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If T sees a call to T with the same parameter(s) as a
>>>>>>>>>>>>>> previous call to T (or the original call to T) had, you
>>>>>>>>>>>>>> replace them with a split where you return true to one
>>>>>>>>>>>>>> side and return false to the other and process.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When T is called by an actually running P, it needs to
>>>>>>>>>>>>>> return the full decision, including the exception to that
>>>>>>>>>>>>>> P, just as it does if directly asked (by main or just
>>>>>>>>>>>>>> asked depending on how the language works).
>>>>>>>>>>>>>
>>>>>>>>>>>>> That is where we disagree: I see no reason why my scheme
>>>>>>>>>>>>> is invalid: P doesn't actually care what T does, it acts
>>>>>>>>>>>>> on what T returns. T returns both halting decisions to two
>>>>>>>>>>>>> copies of P and allows the simulation to proceed with no
>>>>>>>>>>>>> recursion.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The question then becomes, what does P do with that third
>>>>>>>>>>>>>> answer? What are programs ALLOWED to do with that third
>>>>>>>>>>>>>> answer.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I already told you that P never sees the "third answer"
>>>>>>>>>>>>> (exception) as that happens out of band.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The directly executed P does, at least if T[P] ever
>>>>>>>>>>>> generates that third answer as an answer and "reports" it
>>>>>>>>>>>> to its caller.
>>>>>>>>>>>
>>>>>>>>>>> Stop being so obtuse. The exception is not reported to its
>>>>>>>>>>> caller (P) as it is not known at the point in the simulation
>>>>>>>>>>> if the exceptional condition exits. My solution, unlike
>>>>>>>>>>> PO's, is NOT infinitely recursive: think about what that
>>>>>>>>>>> actually means and try re-reading my proposal AGAIN but this
>>>>>>>>>>> time try to fucking comprehend it. The exception is an out
>>>>>>>>>>> of band signal.
>>>>>>>>>>
>>>>>>>>>> I repeat, I am not talking about in the simulation, but in
>>>>>>>>>> the initial call to H.
>>>>>>>>>>
>>>>>>>>>> What would be the results of:
>>>>>>>>>>
>>>>>>>>>> void P(x) {
>>>>>>>>>> bool r = H(x,x);
>>>>>>>>>> while (r) continue;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> void main() {
>>>>>>>>>> P(P);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> I.e. main calls P(P) which calls your H(P,P), what happens
>>>>>>>>>> THERE at THAT call site.
>>>>>>>>>
>>>>>>>>> sNaP exception due to H being passed an input from within the
>>>>>>>>> input that has not previously been passed to H from outside
>>>>>>>>> the input.
>>>>>>>>
>>>>>>>> So, you said it was like sNaN, so the program can be configured
>>>>>>>> to catch this exception, right? Like show below.
>>>>>>>
>>>>>>> The "program" is that which is being decided by the decider so
>>>>>>> sNaP is not observable/catchable/throwable by the "program".
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If sNaP is just like sNaN what happens if instead I make P
>>>>>>>>>> be:
>>>>>>>>>>
>>>>>>>>>> void P(x) {
>>>>>>>>>> bool r;
>>>>>>>>>> try {
>>>>>>>>>> r = H(P,P)l
>>>>>>>>>> } catch(sNaO) {
>>>>>>>>>> // Do something here like:
>>>>>>>>>> r = true;
>>>>>>>>>> }
>>>>>>>>>> while (r) continue;
>>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Inputs can't observe/catch the sNaP exception as it is
>>>>>>>>> private to the decider.
>>>>>>>>
>>>>>>>> P isn't "Just an input", remember main CALLS P(P) so it is a
>>>>>>>> program too.
>>>>>>>>
>>>>>>>> So, are you saying that the decider doesn't tell anyone about
>>>>>>>> the exception, but it just means the whole machine stops?
>>>>>>>
>>>>>>> sNaP exception will be thrown for same reason given previously.
>>>>>>> The "program" is that which is being decided by the decider so
>>>>>>> sNaP is not observable/catchable/throwable by the "program".
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> i.e. it is a Blue Screen of Death?
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Also, what happens if I do:
>>>>>>>>>>
>>>>>>>>>> void P(x) {
>>>>>>>>>> throw sNaP;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> bool T(x) {
>>>>>>>>>> return H(x,x);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> void main() {
>>>>>>>>>> Output(T(P,P));
>>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Inputs can't throw the sNaP exception as it is private to the
>>>>>>>>> decider.
>>>>>>>>
>>>>>>>> But other programs can as T for the computation system to be
>>>>>>>> Turing Compllete, T can't be given powers to do things that
>>>>>>>> other programs don't have.
>>>>>>>>
>>>>>>>> Since programs can throw, then inputs can represent programs
>>>>>>>> that throw.
>>>>>>>
>>>>>>> The "program" is that which is being decided by the decider so
>>>>>>> sNaP is not observable/catchable/throwable by the "program".
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> i.e. what is the defined answer for an input that throws
>>>>>>>>>> sNaP? If sNaP is like a signalling sNaN, and functions can
>>>>>>>>>> return it, then H needs to process functions that can return
>>>>>>>>>> it.
>>>>>>>>>
>>>>>>>>> Inputs can't throw the sNaP exception as it is private to the
>>>>>>>>> decider.
>>>>>>>>
>>>>>>>> IMPOSSIBLE. Either the "results" of sNaP is a defined behavior
>>>>>>>> of the computation system or it isn't
>>>>>>>>
>>>>>>>> If it is, then ANYONE can throw it.
>>>>>>>>
>>>>>>>> If it isn't, then NO ONE can throw it.
>>>>>>>>
>>>>>>>> If your computation system isn't complete in this manner, that
>>>>>>>> Halting can be decidable, as if P can't generate the sNaP
>>>>>>>> result, it can't be allowed to call T.
>>>>>>>>
>>>>>>>> Many non-Turing Complete systems can have Halting deciders if
>>>>>>>> the decider has powers that the things it is deciding on can't
>>>>>>>> have.
>>>>>>>
>>>>>>> The "program" is that which is being decided by the decider so
>>>>>>> sNaP is not observable/catchable/throwable by the "program".
>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> These are the sorts of questions you need to think about and
>>>>>>>>>> answer if you really want to create a new sort of decider to
>>>>>>>>>> see what it can do.
>>>>>>>>>
>>>>>>>>> I have thought about them and I have provided you with
>>>>>>>>> answers. I did state previously that I don't have to go into
>>>>>>>>> implementation details of the signaling decider: the high
>>>>>>>>> level design should be sufficient as long as the reader can
>>>>>>>>> apply a bit of intelligence when reading it.
>>>>>>>>
>>>>>>>> You don't need to necessarily say how H does its job, but you
>>>>>>>> do need to specify precisely AND COMPLETELY what that job is.
>>>>>>>> That means you need to think about the corner cases. If only T
>>>>>>>> can generate the exception, then T is NOT a program in the
>>>>>>>> computaton system you have defined, as it is doing something
>>>>>>>> "programs" aren't allowed to do.
>>>>>>>>
>>>>>>>> That makes T a not very interesting decider, as the Halting
>>>>>>>> Problem has other possible solutions when the decider is a more
>>>>>>>> powerful machine than what it is deciding on.
>>>>>>>
>>>>>>> Refuting [Strachey 1965] and associated proofs is quite
>>>>>>> "interesting".
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Unstopable exceptions (FATAL ERRORS) become very
>>>>>>>>>>>>>> unfriendly in use, but may be simpler to deal with in
>>>>>>>>>>>>>> theory (but a lot less useful).
>>>>>>>>>>>>>
>>>>>>>>>>>>> In your opinion; again I disagree.
>>>>>>>>>>>>
>>>>>>>>>>>> How often does YOUR computer just shut itself down in
>>>>>>>>>>>> reponse to being given a bad probem?
>>>>>>>>>>>>
>>>>>>>>>>>> THAT is the actual effect of a truely unstoppable
>>>>>>>>>>>> exception.
>>>>>>>>>>>>
>>>>>>>>>>>> BLUE SCREEN OF DEATH time.
>>>>>>>>>>>
>>>>>>>>>>> An operating system panic is quite different to a userland
>>>>>>>>>>> program raising an exception. The sNaP exception is
>>>>>>>>>>> equivalent to the sNaN exception of IEEE 754 floating
>>>>>>>>>>> point.
>>>>>>>>>>
>>>>>>>>>> Nope, that is the result of a exception that can not be
>>>>>>>>>> caught at all. The only way to keep software from catching
>>>>>>>>>> the exception is to shut the system down.
>>>>>>>>>
>>>>>>>>> The input cannot catch the sNaP exception as it is private to
>>>>>>>>> the decider.
>>>>>>>>
>>>>>>>> Note the "Input" but the CALLER of the decider, that supposedly
>>>>>>>> you are returning an answer too.
>>>>>>>
>>>>>>> The "program" is that which is being decided by the decider so
>>>>>>> sNaP is not observable/catchable/throwable by the "program".
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Remember, in basic computation theory, there is no such thing
>>>>>>>>>> as "userland", so no saying that the exception goes through
>>>>>>>>>> userland to the operating system.
>>>>>>>>>
>>>>>>>>> I can choose to present my solution within whatever domain I
>>>>>>>>> see fit.
>>>>>>>>
>>>>>>>> Yes, and it can be a worthless solution if you restrict the
>>>>>>>> problem domain to somethng uninteresting.
>>>>>>>
>>>>>>> Opinion.
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The sNaN exception is a CATCHABLE exception, that the program
>>>>>>>>>> can cature and do something with it.
>>>>>>>>>
>>>>>>>>> The input cannot catch the sNaP exception as it is private to
>>>>>>>>> the decider.
>>>>>>>>
>>>>>>>> I'm not saying the "INPUT", I'm saying to the CALLER of the
>>>>>>>> decider.
>>>>>>>>
>>>>>>>> A decider that doesn't answer to its caller with its answer is
>>>>>>>> to computation theory WORTHLESS.
>>>>>>>
>>>>>>> The decider does answer to its caller unless the input is
>>>>>>> pathological in which case sNaP will be signaled.
>>>>>>>
>>>>>>
>>>>>> So your decider is definied to Blue Screen of Death on
>>>>>> pathological input.
>>>>>>
>>>>>> Note, Blue Screen of Death, likeyour sNaP is NOT an "Answer",
>>>>>> because it is NOT given to the asker.
>>>>>>
>>>>>> That means that your sNaP is NOT like sNaN, as the later can, and
>>>>>> normally IS captured by the program doing the operation, and in
>>>>>> fact is DESIGNED to be captured by the program in use.
>>>>>>
>>>>>> Being signalling rather than quiet says the program MUST do
>>>>>> something about it (or get aborted).
>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>> If you can't write a program that does something like,
>>>>>>>>>>>>>> try to do thing 1, but if that throws a contradiction
>>>>>>>>>>>>>> error, do thing 2 instead.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This brings up the interesting question, if the input to
>>>>>>>>>>>>>> T throws a contradiction error, what should T return? If
>>>>>>>>>>>>>> contradiction errors are uncatchable, then the only
>>>>>>>>>>>>>> choice is to return that same contradiction error, EVEN
>>>>>>>>>>>>>> IF THE OTHER PATH HAD A GOOD ANSWER.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You need to re-read my proposal again but this time try to
>>>>>>>>>>>>> FULLY UNDERSTAND IT and understand the implications.
>>>>>>>>>>>>
>>>>>>>>>>>> It says that pathology is detected and reported.
>>>>>>>>>>>>
>>>>>>>>>>>> In Computation Theory a function "reports" by returning an
>>>>>>>>>>>> answer in some way to its caller.
>>>>>>>>>>>
>>>>>>>>>>> The sNaP exception is reported by the simulator not by the
>>>>>>>>>>> function H called by P: I have already told you what that H
>>>>>>>>>>> does: it returns both true and false to copies of P and then
>>>>>>>>>>> PROCEEDS WITH THE SIMULATION.
>>>>>>>>>>
>>>>>>>>>> Then you H is not the decider you claim. This is the error
>>>>>>>>>> Peter had years ago when it was pointed out that if x86utm
>>>>>>>>>> was the actual decider that then P would need to invoke
>>>>>>>>>> x86utm with the input being itself applied to itself, but
>>>>>>>>>> x86utm can't handle calls to things like system that would
>>>>>>>>>> preform that action.
>>>>>>>>>
>>>>>>>>> The decider is the decider I claim, it is in fact EXACTLY the
>>>>>>>>> decider I claim and it bears no resemblance to Peter's
>>>>>>>>> efforts.
>>>>>>>>>
>>>>>>>>> [snip]
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> You keep on ignoring what the decider is returning to the
>>>>>>>> actual program that is the CALLER of the decider.
>>>>>>>>
>>>>>>>> A decider that can't actually be called is totally
>>>>>>>> uninteresting to Computation Theory.
>>>>>>>
>>>>>>> The "program" is that which is being decided by the decider so
>>>>>>> sNaP is not observable/catchable/throwable by the "program".
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> No, the "Program" is something that is run.
>>>>>>
>>>>>> If I Run P1, and P1 calls T[P2] then P1 is the caller program and
>>>>>> P2 is the input to T, which happens to represent a Program too.
>>>>>>
>>>>>> You seem to want to define your sNaP event as a Blue Screen of
>>>>>> Death that immediately ends all computations, which makes it NOT
>>>>>> a "answer" in the computation sense.
>>>>>>
>>>>>> Yes, maybe you see it as answering to the User who is operating
>>>>>> the system, but that is not the normal step goal of a
>>>>>> computation, as it means it can't be used to build up other
>>>>>> operations.
>>>>>>
>>>>>> Yes, it is just about as useful as having a program somehow
>>>>>> intentionally create a BSOD as a way to create an "answer".
>>>>>
>>>>> OK, to progress this lets dig down into your most interesting test
>>>>> case:
>>>>>
>>>>> void P(x) {
>>>>> bool r;
>>>>> try {
>>>>> r = H(P,P);
>>>>> } catch(sNaP) {
>>>>> // Do something here like:
>>>>> r = true;
>>>>> }
>>>>> while (r) continue;
>>>>> }
>>>>>
>>>>> void main() {
>>>>> P(P);
>>>>> }
>>>>>
>>>>> It is a basic requirement of my signaling decider that the program
>>>>> or function being analyzed must be run from within the decider.
>>>>> As H(P, P) is being called from within P before P has been passed
>>>>> to the decider the sNaP exception will be signaled. The fact that
>>>>> P catches this exception and invokes non-halting behavior is
>>>>> irrelevant as far as my decider is concerned as that particular
>>>>> *invocation* of P is not being run from within the decider so is
>>>>> in contravention of a basic requirement of my decider.
>>>>>
>>>>> You might now claim that my signaling decider isn't a proper
>>>>> decider as far as the HP is concerned due to the presence of the
>>>>> above requirement but I respectfully disagree. You will have to
>>>>> show WHY such a requirement is in conflict with the definition of
>>>>> a halting decider.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> And, a fundamental issue is that for a simulation to be "correct"
>>>> it must match the behavior of the actual program.
>>>>
>>>> If the answer tp H(P,P) doesn't match the behavior of P(P), then it
>>>> is hard to call the answer "correct".
>>>>
>>>> Yes, it can make sense to define that some cases will result in H
>>>> needing to give a "This program is acting contradictory to may
>>>> prediction so it is impossible to give an answer", but once you
>>>> define that answer as "throwing an exception", and thus have
>>>> introduced "throwing an exception" into you list of possible
>>>> behaviors, you need to define how your decider will handle inputs
>>>> that do that.
>>>>
>>>> If you are going to to make an "useful" answer by adding such an
>>>> extension to the behaviors of machines, you need to FULLY define
>>>> how that works.
>>>
>>> Except if the input is pathological then it isn't acting
>>> contradictory to the decider's prediction as the decider is testing
>>> both outcomes (halting and non-halting) and THEN detects a
>>> contradiction which means the input is pathological and is signaled
>>> as such which is an answer (just not an answer of halting or
>>> non-halting).
>>>
>>> Calling P before invoking the decider means the outcome of that
>>> call is no business of the decider as doing so is not meeting the
>>> usage requirements of the decider.
>>>
>>> /Flibble
>>>
>>
>> Except that its behavior (if not contradictory because you define
>> that as a specific exception) needs to be "correctly" predicted by
>> the decider. And thus you need to stop and make sure you have
>> actually reasonably defined what all these things mean.
>>
>> That means defining things like what should H return if its input
>> throws sNaP?
>
> Input cannot observe/throw/catch the sNaP exception.
>
> /Flibble
>


Click here to read the complete article
Re: A plea...

<tbbulo$2fmav$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=35863&group=comp.theory#35863

 copy link   Newsgroups: comp.theory
Path: i2pn2.org!i2pn.org!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: richard....@gmail.com (Richard Harnden)
Newsgroups: comp.theory
Subject: Re: A plea...
Date: Thu, 21 Jul 2022 17:25:27 +0100
Organization: A noiseless patient Spider
Lines: 7
Message-ID: <tbbulo$2fmav$1@dont-email.me>
References: <87k08c79ys.fsf@bsb.me.uk>
<20220717205331.0000461e@reddwarf.jmc.corp>
<fc%AK.397559$vAW9.238590@fx10.iad>
<20220717224436.00002c66@reddwarf.jmc.corp>
<qE%AK.514397$ntj.427354@fx15.iad>
<20220717230620.00001532@reddwarf.jmc.corp> <Um0BK.514846$ntj.83746@fx15.iad>
<20220717235402.00002719@reddwarf.jmc.corp> <hO0BK.48201$Ae2.4639@fx35.iad>
<20220718002744.00002d25@reddwarf.jmc.corp> <up2BK.40810$Sf2.38749@fx34.iad>
<20220718021821.000056d2@reddwarf.jmc.corp> <qN2BK.57711$sZ1.19122@fx07.iad>
<20220718073646.000070ff@reddwarf.jmc.corp>
<GobBK.581682$JVi.394817@fx17.iad>
<20220718172136.000029ad@reddwarf.jmc.corp>
<tXlBK.517864$ntj.364914@fx15.iad>
<20220719083420.00005f0f@reddwarf.jmc.corp> <vrwBK.33025$8f2.30099@fx38.iad>
<20220719181344.00001568@reddwarf.jmc.corp> <THGBK.573696$X_i.35184@fx18.iad>
<20220720003151.00000bd7@reddwarf.jmc.corp> <DuIBK.86909$f81.35526@fx43.iad>
<20220720181504.000065d3@reddwarf.jmc.corp> <ZD%BK.85973$Me2.46122@fx47.iad>
Reply-To: nospam.harnden@gmail.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 21 Jul 2022 16:25:28 -0000 (UTC)
Injection-Info: reader01.eternal-september.org; posting-host="d3832b278f562f8690008a6b83fbcce4";
logging-data="2611551"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1//423cNNDY1YwmC/CQvhQX82ejKwHCR9Y="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
Gecko/20100101 Thunderbird/91.11.0
Cancel-Lock: sha1:AQbIE7YsdDaWIo7gK6QuXCv8eyw=
In-Reply-To: <ZD%BK.85973$Me2.46122@fx47.iad>
 by: Richard Harnden - Thu, 21 Jul 2022 16:25 UTC

On 20/07/2022 23:49, Richard Damon wrote:
> On 7/20/22 1:15 PM, Mr Flibble wrote:

Do you really need to quote the previous 2000 lines?

Pages:12
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor