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.

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.

Richard is a crank because he continues to maintain false
assumptions even when they have been corrected hundreds of times.

Mike has clarified two key elements for Paul N and Richard:

On 7/16/2022 10:54 AM, Mike Terry wrote:
> On 16/07/2022 12:23, Paul N wrote:
>> Yes, if the simulation is correct. You've insisted
>> numerous times that your own simulator is incorrect.
>
> PO's simulation is correct at the individual instruction
> level. His H steps the simulation forward a number of steps,
> and each of those steps exactly matches the P(P) calculation
> steps. At some point before the final P RET instruction, his
> H decides to stop stepping (for whatever reason), so H's
> simulation is *incomplete*.
>
> That is the only sense in which P(P) and "the simulated input
> to H(P,P)" differ - H simply stops simulating before P(P)
> terminates.

On 7/16/2022 2:28 PM, Mike Terry wrote:
> On 16/07/2022 17:40, Richard Damon wrote:
>> But "incomplete" is incorrect if your logic assumes that the
>> simulation not reaching the final state PROVES non-halting.
>
> I don't believe PO thinks that, irrespective of how badly he
> explains things. I think he believes that the simulation would
> never halt *because his never-halting-abort test matched*, NOT
> simply as a consequence of aborting. E.g. he seems to understand
> that a simulator that steps 10 steps then stops regardless, does
> not imply that the simulated computation does not halt.

I am not a crank because all of my reasoning is verifiably correct.
Because my earlier work was so terrible most people have already made up
their mind and closed it. New reviewers are not doing this.

--
Copyright 2022 Pete Olcott

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

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

On 7/17/22 2:36 PM, olcott wrote:

> 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.
>
> Richard is a crank because he continues to maintain false
> assumptions even when they have been corrected hundreds of times.
>
> Mike has clarified two key elements for Paul N and Richard:
>

Olcott is a crank because HE continues to maintain false idea even when
they have been corrected hunders of times.

I post statements based on the accepted rules, ones you sometimes even
quote (but don't know the meaning of).

YOU keep on trying to bring up things that are "obvious" or "by the
simple meaning of the words" when such things just aren't correct.

You claim by "Basic Software Engineering Principles" things to be true,
but I am pretty sure you can't actually quote a reference that says all
that you claim. (You do get a few things right, just miss on the ones
you need to twist to make your point).

Now, I suspect, if you haven't been lying about other things, we will
likely stop hearing from you in the no too distant future, and you will
then be remembered in the archives of history as the crank that you are.

Note, Mike misses that you DON'T properly simulate the full effect of
the call H instructions, as if you did, the next point of the simulation
would be of the code of H, or at the very least, the effects of the
return value of H.

The logic used in the determination to halt is functionally part of the
simulation, and that has an error.

The other error is the assumption and claim that you make that the
"behavior" stops when the simulation stops, since the ONLY behavior in
view is the behavior of the machine, or the behavior of the COMPLETE and
correct simulation of the input, that is just FALSE.

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.

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

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.

Of course, one issue is that we should think what should P do if T
returns the confounding result to try to confound that (or is this a
fatal uncatchable result so not usable in another program).

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.

>
> Of course, one issue is that we should think what should P do if T
> returns the confounding result to try to confound that (or is this a
> fatal uncatchable result so not usable in another program).

/Flibble

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.

>
>>
>> Of course, one issue is that we should think what should P do if T
>> returns the confounding result to try to confound that (or is this a
>> fatal uncatchable result so not usable in another program).
>
> /Flibble
>

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

>
> >
> >>
> >> Of course, one issue is that we should think what should P do if T
> >> returns the confounding result to try to confound that (or is this
> >> a fatal uncatchable result so not usable in another program).
> >
> > /Flibble
> >
>

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.

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.

>>
>>>
>>>>
>>>> Of course, one issue is that we should think what should P do if T
>>>> returns the confounding result to try to confound that (or is this
>>>> a fatal uncatchable result so not usable in another program).
>>>
>>> /Flibble
>>>
>>
>
>

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.

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

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.

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.

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

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.

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
>

On Sun, 17 Jul 2022 18:41:13 -0500
olcott <NoOne@NoWhere.com> wrote:

> 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

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

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

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

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.

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.

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.

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.

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.

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