On 7/17/2022 6: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.
>
>>
>> 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.
>
>>
>>>
>>>>
>>>> H is a funciton, it doesn't know who is calling it and needs to
>>>> give the answer to its caller.
>>>>
>>>> You can run either
>>>>
>>>> T[P] to ask P its answer, or
>>>> P to see what P does and ompare it.
>>>
>>> Try reading the following again:
>>>
>>> https://github.com/i42output/halting-problem/blob/main/README.txt
>>>
>>> /Flibble
>>>
>>
>> That is about a H(M,x) not the T[P].
>>
>> It doesn't say a thing about sending an "Out of Band" answer, just
>> that it reports the pathological case.
>>
>> And yes, given the execution model that is the answer I suggested to
>> PO over a year ago I think as one way to handle the non-pathological
>> recursions and be a better decider than his that just got any
>> recursive case that ends up actually halting after gettting the
>> answer wrong.
>
> We can both agree that PO is barking up the wrong tree.
>
> /Flibble
>

Prior to Pythagoras everyone agreed that the Earth was flat.
https://starchild.gsfc.nasa.gov/docs/StarChild/questions/question54.html

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer