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.

>
> >
> >>>>>> 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