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.

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

>
>>
>> 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 big problem is that H may not know HOW its report is supposed to be
given. That is the problem with fatal execeptions.

>
>>
>>>>
>>>> T doesn't know how it was called, so were is the "Out of Band" that
>>>> meets the requirement to be an answer.
>>>>
>>>> Do you mean that deciding a pathological machine is a FATAL error
>>>> and the whole program is aborted? That isn't "Reporting" in the
>>>> sense of a Function.
>>>
>>> Once pathological input is detected it is a FATAL error in the form
>>> of a signaled exception -- sNaP (signaling Not a Program) -- hence
>>> why I call it a signaling halt decider.
>>
>> Is that an uncatchable signal, so a program can't ask the decider
>> about one input, and if that is contradictory, try another? (in
>> essence it is a call exit operation)
>
> /Flibble
>