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?