Hi!

I have an idea for a signaling simulating halt decider that forks the
simulation into two branches if the input calls the halt decider as
per [Strachey 1965]'s "Impossible Program":

void P(void (*x)())
{ if (H(x, x))
infinite_loop: goto infinite_loop;
return;
}

int main()
{ std::cout << "Input halts: " << H(P, P) << std::endl;
}

When the simulator detects the call to H in P it forks the simulation
into a non-halting branch (returning 0 to P) and a halting branch
(returning 1 to P) and continues the simulation of these two branches
in parallel.

If the non-halting branch is determined to halt AND the halting branch
is determined to not halt then pathology is detected and reported via
a sNaP (signaling Not a Program) signal (analogous to IEEE 754's
sNaN (signaling Not a Number) signal)

If EITHER branch is determined to be correctly decided then that will
be the decision of the halting decider.

Crucially this scheme will handle (and correctly decide) the
following case whereby the result of H is discarded by the input:

void Px(void (*x)())
{ (void) H(x, x);
return;
}

Obviously my idea necessitates extending the definition of a halt
decider:

1) Decider decision is HALTS if input halts.
2) Decider decision is NON-HALTING if input does not halt.
3) Decider rejects pathological input as invalid by signaling sNaP.

Thoughts? I am probably missing something obvious as my idea
appears to refute [Strachey 1965] and associated HP proofs which
great minds have mulled over for decades.

/Flibble

Mr Flibble <flibble@reddwarf.jmc.corp> writes:

> Obviously my idea necessitates extending the definition of a halt
> decider:

And, indeed, the term 'decider' since a decider is defined to be an
algorithm that always either accepts or rejects an input!

> 1) Decider decision is HALTS if input halts.
> 2) Decider decision is NON-HALTING if input does not halt.
> 3) Decider rejects pathological input as invalid by signaling sNaP.
>
> Thoughts?

So what? Every computation in category 3 either halts or does not halt,
so you might as well call this category "the inputs the 'decider' gets
wrong". There is no better definition of it.

(See any of the dozens of replies to PO when he was pushing this line
many years ago.)

> I am probably missing something obvious as my idea
> appears to refute [Strachey 1965] and associated HP proofs which
> great minds have mulled over for decades.

The obvious thing you are missing is that you can't refute an argument
about a decider by talking about something else.

--
Ben.

Op 18.sep..2022 om 12:20 schreef Mr Flibble:
> Hi!
>
> I have an idea for a signaling simulating halt decider that forks the
> simulation into two branches if the input calls the halt decider as
> per [Strachey 1965]'s "Impossible Program":
>
> void P(void (*x)())
> {
> if (H(x, x))
> infinite_loop: goto infinite_loop;
> return;
> }
>
> int main()
> {
> std::cout << "Input halts: " << H(P, P) << std::endl;
> }
>
> When the simulator detects the call to H in P it forks the simulation
> into a non-halting branch (returning 0 to P) and a halting branch
> (returning 1 to P) and continues the simulation of these two branches
> in parallel.
>
> If the non-halting branch is determined to halt AND the halting branch
> is determined to not halt then pathology is detected and reported via
> a sNaP (signaling Not a Program) signal (analogous to IEEE 754's
> sNaN (signaling Not a Number) signal)
>
> If EITHER branch is determined to be correctly decided then that will
> be the decision of the halting decider.
>
> Crucially this scheme will handle (and correctly decide) the
> following case whereby the result of H is discarded by the input:
>
> void Px(void (*x)())
> {
> (void) H(x, x);
> return;
> }
>
> Obviously my idea necessitates extending the definition of a halt
> decider:
>
> 1) Decider decision is HALTS if input halts.
> 2) Decider decision is NON-HALTING if input does not halt.
> 3) Decider rejects pathological input as invalid by signaling sNaP.
>
> Thoughts? I am probably missing something obvious as my idea
> appears to refute [Strachey 1965] and associated HP proofs which
> great minds have mulled over for decades.
>
> /Flibble

Ben said already that this is not the solution of the halting problem,
but something else.

But even then I see a few problems with your ideas:

1) The definition of "pathological input" is unclear. So, is there a way
to verify that the sNaP signal is always correct or incorrect?
2) If the sNaP signal can be used by a program to decide whether a
program is pathological, then also a pathological program can use the
signal to make the signal invalid. If the sNaP signal cannot be used by
the main program, then it has no value.
3) It seems crucial for your idea, that H detects a call to itself. But
a pathological program could hide this, e.g. by copying the code of H to
somewhere else and call the copy instead of the original H, maybe after
making a few irrelevant changes to the code of the copy to make it more
difficult to recognize. I wonder whether H will always be able to detect
such tricks.

On 18/09/2022 16:04, Ben Bacarisse wrote:
> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>
>> Obviously my idea necessitates extending the definition of a halt
>> decider:
>
> And, indeed, the term 'decider' since a decider is defined to be an
> algorithm that always either accepts or rejects an input!
>
>> 1) Decider decision is HALTS if input halts.
>> 2) Decider decision is NON-HALTING if input does not halt.
>> 3) Decider rejects pathological input as invalid by signaling sNaP.
>>
>> Thoughts?
>
> So what? Every computation in category 3 either halts or does not halt,
> so you might as well call this category "the inputs the 'decider' gets
> wrong". There is no better definition of it.
>
> (See any of the dozens of replies to PO when he was pushing this line
> many years ago.)
>
>> I am probably missing something obvious as my idea
>> appears to refute [Strachey 1965] and associated HP proofs which
>> great minds have mulled over for decades.
>
> The obvious thing you are missing is that you can't refute an argument
> about a decider by talking about something else.
>

MF's post is an exact copy of a thread he started 11/08/2022, which in turn is a (nearly) exact copy
of an earlier thread he started 31/07/2022. Perhaps he's conducting an experiment to see how many
times people will give sensible replies to the same post?

Mike.

Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:

> On 18/09/2022 16:04, Ben Bacarisse wrote:
>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>
>>> Obviously my idea necessitates extending the definition of a halt
>>> decider:
>> And, indeed, the term 'decider' since a decider is defined to be an
>> algorithm that always either accepts or rejects an input!
>>
>>> 1) Decider decision is HALTS if input halts.
>>> 2) Decider decision is NON-HALTING if input does not halt.
>>> 3) Decider rejects pathological input as invalid by signaling sNaP.
>>>
>>> Thoughts?
>> So what? Every computation in category 3 either halts or does not halt,
>> so you might as well call this category "the inputs the 'decider' gets
>> wrong". There is no better definition of it.
>> (See any of the dozens of replies to PO when he was pushing this line
>> many years ago.)
>>
>>> I am probably missing something obvious as my idea
>>> appears to refute [Strachey 1965] and associated HP proofs which
>>> great minds have mulled over for decades.
>> The obvious thing you are missing is that you can't refute an argument
>> about a decider by talking about something else.
>
> MF's post is an exact copy of a thread he started 11/08/2022, which in
> turn is a (nearly) exact copy of an earlier thread he started
> 31/07/2022. Perhaps he's conducting an experiment to see how many
> times people will give sensible replies to the same post?

Yes, I was aware of the similarity. If his real purpose is trolling, I
doubt it will work (though PO sometimes gets into it with him). And if
it is pure boasting, then I hope a short reply will burst the bubble.

--
Ben.

On Sun, 18 Sep 2022 16:04:03 +0100
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>
> > Obviously my idea necessitates extending the definition of a halt
> > decider:
>
> And, indeed, the term 'decider' since a decider is defined to be an
> algorithm that always either accepts or rejects an input!
>
> > 1) Decider decision is HALTS if input halts.
> > 2) Decider decision is NON-HALTING if input does not halt.
> > 3) Decider rejects pathological input as invalid by signaling sNaP.
> >
> > Thoughts?
>
> So what? Every computation in category 3 either halts or does not
> halt, so you might as well call this category "the inputs the
> 'decider' gets wrong". There is no better definition of it.

Wrong. Every computation in category 3 BOTH halts AND doesn't halt which
is obviously invalid hence the need to signal such pathological input
as invalid.

>
> (See any of the dozens of replies to PO when he was pushing this line
> many years ago.)

Olcott is a sub-par troll; I like to think my trolling is of better
quality.

/Flibble

On 9/18/2022 10:25 AM, Fred. Zwarts wrote:
> Op 18.sep..2022 om 12:20 schreef Mr Flibble:
>> Hi!
>>
>> I have an idea for a signaling simulating halt decider that forks the
>> simulation into two branches if the input calls the halt decider as
>> per [Strachey 1965]'s "Impossible Program":
>>
>> void P(void (*x)())
>> {
>>     if (H(x, x))
>>         infinite_loop: goto infinite_loop;
>>     return;
>> }
>>
>> int main()
>> {
>>     std::cout << "Input halts: " << H(P, P) << std::endl;
>> }
>>
>> When the simulator detects the call to H in P it forks the simulation
>> into a non-halting branch (returning 0 to P) and a halting branch
>> (returning 1 to P) and continues the simulation of these two branches
>> in parallel.
>>
>> If the non-halting branch is determined to halt AND the halting branch
>> is determined to not halt then pathology is detected and reported via
>> a sNaP (signaling Not a Program) signal (analogous to IEEE 754's
>> sNaN (signaling Not a Number) signal)
>>
>> If EITHER branch is determined to be correctly decided then that will
>> be the decision of the halting decider.
>>
>> Crucially this scheme will handle (and correctly decide) the
>> following case whereby the result of H is discarded by the input:
>>
>> void Px(void (*x)())
>> {
>>     (void) H(x, x);
>>     return;
>> }
>>
>> Obviously my idea necessitates extending the definition of a halt
>> decider:
>>
>> 1) Decider decision is HALTS if input halts.
>> 2) Decider decision is NON-HALTING if input does not halt.
>> 3) Decider rejects pathological input as invalid by signaling sNaP.
>>
>> Thoughts?  I am probably missing something obvious as my idea
>> appears to refute [Strachey 1965] and associated HP proofs which
>> great minds have mulled over for decades.
>>
>> /Flibble
>
> Ben said already that this is not the solution of the halting problem,
> but something else.
>
> But even then I see a few problems with your ideas:
>
> 1) The definition of "pathological input" is unclear. So, is there a way
> to verify that the sNaP signal is always correct or incorrect?
> 2) If the sNaP signal can be used by a program to decide whether a
> program is pathological, then also a pathological program can use the
> signal to make the signal invalid. If the sNaP signal cannot be used by
> the main program, then it has no value.
> 3) It seems crucial for your idea, that H detects a call to itself. But
> a pathological program could hide this, e.g. by copying the code of H to
> somewhere else and call the copy instead of the original H, maybe after
> making a few irrelevant changes to the code of the copy to make it more
> difficult to recognize. I wonder whether H will always be able to detect
> such tricks.
>

// P does the opposite of whatever H decides
void P(ptr x)
{ int Halt_Status = H(x, x);
if (Halt_Status) // if H(P,P) reports that its input halts
HERE: goto HERE; // P loops and never halts
return; // else P halts
}

int main()
{ Output("Input_Halts = ", H(P, P));
}

The standard template of the "impossible" input used by the halting
problem proofs can be determined to be non-halting on the basis that the
correct and complete simulation of P by H never reaches the return value
from H. This refutes all of the standard proofs.

*This also applies to the direct execution of P(P) by H*

int H(ptr x, ptr y)
{ x(y); // H(P,P) specifies the direct execution of P(P);
}

--
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 9/18/2022 10:04 AM, Ben Bacarisse wrote:
> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>
>> Obviously my idea necessitates extending the definition of a halt
>> decider:
>
> And, indeed, the term 'decider' since a decider is defined to be an
> algorithm that always either accepts or rejects an input!
>
>> 1) Decider decision is HALTS if input halts.
>> 2) Decider decision is NON-HALTING if input does not halt.
>> 3) Decider rejects pathological input as invalid by signaling sNaP.
>>
>> Thoughts?
>
> So what? Every computation in category 3 either halts or does not halt,

The correct UTM simulation of a valid Turing machine description either
halts or does not halt. When we apply a UTM to an English poem we have a
case of neither halting nor not halting.

Years ago I was thinking that a syntactically valid machine description
that is semantically invalid may neither halt nor not halt, I was
incorrect about this.

The idea that I was basing this in is that the Liar Paradox is neither
true nor false because it is not a truth bearer.

--
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, 18 Sep 2022 17:25:48 +0200
"Fred. Zwarts" <F.Zwarts@KVI.nl> wrote:

> Op 18.sep..2022 om 12:20 schreef Mr Flibble:
> > Hi!
> >
> > I have an idea for a signaling simulating halt decider that forks
> > the simulation into two branches if the input calls the halt
> > decider as per [Strachey 1965]'s "Impossible Program":
> >
> > void P(void (*x)())
> > {
> > if (H(x, x))
> > infinite_loop: goto infinite_loop;
> > return;
> > }
> >
> > int main()
> > {
> > std::cout << "Input halts: " << H(P, P) << std::endl;
> > }
> >
> > When the simulator detects the call to H in P it forks the
> > simulation into a non-halting branch (returning 0 to P) and a
> > halting branch (returning 1 to P) and continues the simulation of
> > these two branches in parallel.
> >
> > If the non-halting branch is determined to halt AND the halting
> > branch is determined to not halt then pathology is detected and
> > reported via a sNaP (signaling Not a Program) signal (analogous to
> > IEEE 754's sNaN (signaling Not a Number) signal)
> >
> > If EITHER branch is determined to be correctly decided then that
> > will be the decision of the halting decider.
> >
> > Crucially this scheme will handle (and correctly decide) the
> > following case whereby the result of H is discarded by the input:
> >
> > void Px(void (*x)())
> > {
> > (void) H(x, x);
> > return;
> > }
> >
> > Obviously my idea necessitates extending the definition of a halt
> > decider:
> >
> > 1) Decider decision is HALTS if input halts.
> > 2) Decider decision is NON-HALTING if input does not halt.
> > 3) Decider rejects pathological input as invalid by signaling sNaP.
> >
> > Thoughts? I am probably missing something obvious as my idea
> > appears to refute [Strachey 1965] and associated HP proofs which
> > great minds have mulled over for decades.
> >
> > /Flibble
>
> Ben said already that this is not the solution of the halting
> problem, but something else.
>
> But even then I see a few problems with your ideas:
>
> 1) The definition of "pathological input" is unclear. So, is there a
> way to verify that the sNaP signal is always correct or incorrect?

The pathological input is an input that replicates the [Strachey 1965]
"Impossible Program) pattern.

> 2) If the sNaP signal can be used by a program to decide whether a
> program is pathological, then also a pathological program can use the
> signal to make the signal invalid. If the sNaP signal cannot be used
> by the main program, then it has no value.

The sNaP signal is unavailable (catching or raising) to the input being
simulated; it is only available to the code which is invoking the
decider (i.e. from outside the simulation).

> 3) It seems crucial for your idea, that H detects a call to itself.
> But a pathological program could hide this, e.g. by copying the code
> of H to somewhere else and call the copy instead of the original H,
> maybe after making a few irrelevant changes to the code of the copy
> to make it more difficult to recognize. I wonder whether H will
> always be able to detect such tricks.

Use of the Flibble Signaling Decider necessitates use of the "neos"
virtual machine and compiler which will be configured to prohibit the
copying and/or modification you describe.

/Flibble

On Sun, 18 Sep 2022 11:09:44 -0500
olcott <polcott2@gmail.com> wrote:

> On 9/18/2022 10:25 AM, Fred. Zwarts wrote:
> > Op 18.sep..2022 om 12:20 schreef Mr Flibble:
> >> Hi!
> >>
> >> I have an idea for a signaling simulating halt decider that forks
> >> the simulation into two branches if the input calls the halt
> >> decider as per [Strachey 1965]'s "Impossible Program":
> >>
> >> void P(void (*x)())
> >> {
> >>     if (H(x, x))
> >>         infinite_loop: goto infinite_loop;
> >>     return;
> >> }
> >>
> >> int main()
> >> {
> >>     std::cout << "Input halts: " << H(P, P) << std::endl;
> >> }
> >>
> >> When the simulator detects the call to H in P it forks the
> >> simulation into a non-halting branch (returning 0 to P) and a
> >> halting branch (returning 1 to P) and continues the simulation of
> >> these two branches in parallel.
> >>
> >> If the non-halting branch is determined to halt AND the halting
> >> branch is determined to not halt then pathology is detected and
> >> reported via a sNaP (signaling Not a Program) signal (analogous to
> >> IEEE 754's sNaN (signaling Not a Number) signal)
> >>
> >> If EITHER branch is determined to be correctly decided then that
> >> will be the decision of the halting decider.
> >>
> >> Crucially this scheme will handle (and correctly decide) the
> >> following case whereby the result of H is discarded by the input:
> >>
> >> void Px(void (*x)())
> >> {
> >>     (void) H(x, x);
> >>     return;
> >> }
> >>
> >> Obviously my idea necessitates extending the definition of a halt
> >> decider:
> >>
> >> 1) Decider decision is HALTS if input halts.
> >> 2) Decider decision is NON-HALTING if input does not halt.
> >> 3) Decider rejects pathological input as invalid by signaling sNaP.
> >>
> >> Thoughts?  I am probably missing something obvious as my idea
> >> appears to refute [Strachey 1965] and associated HP proofs which
> >> great minds have mulled over for decades.
> >>
> >> /Flibble
> >
> > Ben said already that this is not the solution of the halting
> > problem, but something else.
> >
> > But even then I see a few problems with your ideas:
> >
> > 1) The definition of "pathological input" is unclear. So, is there
> > a way to verify that the sNaP signal is always correct or incorrect?
> > 2) If the sNaP signal can be used by a program to decide whether a
> > program is pathological, then also a pathological program can use
> > the signal to make the signal invalid. If the sNaP signal cannot be
> > used by the main program, then it has no value.
> > 3) It seems crucial for your idea, that H detects a call to itself.
> > But a pathological program could hide this, e.g. by copying the
> > code of H to somewhere else and call the copy instead of the
> > original H, maybe after making a few irrelevant changes to the code
> > of the copy to make it more difficult to recognize. I wonder
> > whether H will always be able to detect such tricks.
> >
>
> // P does the opposite of whatever H decides
> void P(ptr x)
> {
> int Halt_Status = H(x, x);
> if (Halt_Status) // if H(P,P) reports that its input halts
> HERE: goto HERE; // P loops and never halts
> return; // else P halts
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }
>
> The standard template of the "impossible" input used by the halting
> problem proofs can be determined to be non-halting on the basis that
> the correct and complete simulation of P by H never reaches the
> return value from H. This refutes all of the standard proofs.
>
> *This also applies to the direct execution of P(P) by H*
>
> int H(ptr x, ptr y)
> {
> x(y); // H(P,P) specifies the direct execution of P(P);
> }

Wrong. A halt decider must return a value to its caller ergo a
recursive halt decider is not a valid halt decider ergo your halt
decider is not a valid halt decider.

/Flibble

On 9/18/2022 11:33 AM, Mr Flibble wrote:
> On Sun, 18 Sep 2022 11:09:44 -0500
> olcott <polcott2@gmail.com> wrote:
>
>> On 9/18/2022 10:25 AM, Fred. Zwarts wrote:
>>> Op 18.sep..2022 om 12:20 schreef Mr Flibble:
>>>> Hi!
>>>>
>>>> I have an idea for a signaling simulating halt decider that forks
>>>> the simulation into two branches if the input calls the halt
>>>> decider as per [Strachey 1965]'s "Impossible Program":
>>>>
>>>> void P(void (*x)())
>>>> {
>>>>     if (H(x, x))
>>>>         infinite_loop: goto infinite_loop;
>>>>     return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>     std::cout << "Input halts: " << H(P, P) << std::endl;
>>>> }
>>>>
>>>> When the simulator detects the call to H in P it forks the
>>>> simulation into a non-halting branch (returning 0 to P) and a
>>>> halting branch (returning 1 to P) and continues the simulation of
>>>> these two branches in parallel.
>>>>
>>>> If the non-halting branch is determined to halt AND the halting
>>>> branch is determined to not halt then pathology is detected and
>>>> reported via a sNaP (signaling Not a Program) signal (analogous to
>>>> IEEE 754's sNaN (signaling Not a Number) signal)
>>>>
>>>> If EITHER branch is determined to be correctly decided then that
>>>> will be the decision of the halting decider.
>>>>
>>>> Crucially this scheme will handle (and correctly decide) the
>>>> following case whereby the result of H is discarded by the input:
>>>>
>>>> void Px(void (*x)())
>>>> {
>>>>     (void) H(x, x);
>>>>     return;
>>>> }
>>>>
>>>> Obviously my idea necessitates extending the definition of a halt
>>>> decider:
>>>>
>>>> 1) Decider decision is HALTS if input halts.
>>>> 2) Decider decision is NON-HALTING if input does not halt.
>>>> 3) Decider rejects pathological input as invalid by signaling sNaP.
>>>>
>>>> Thoughts?  I am probably missing something obvious as my idea
>>>> appears to refute [Strachey 1965] and associated HP proofs which
>>>> great minds have mulled over for decades.
>>>>
>>>> /Flibble
>>>
>>> Ben said already that this is not the solution of the halting
>>> problem, but something else.
>>>
>>> But even then I see a few problems with your ideas:
>>>
>>> 1) The definition of "pathological input" is unclear. So, is there
>>> a way to verify that the sNaP signal is always correct or incorrect?
>>> 2) If the sNaP signal can be used by a program to decide whether a
>>> program is pathological, then also a pathological program can use
>>> the signal to make the signal invalid. If the sNaP signal cannot be
>>> used by the main program, then it has no value.
>>> 3) It seems crucial for your idea, that H detects a call to itself.
>>> But a pathological program could hide this, e.g. by copying the
>>> code of H to somewhere else and call the copy instead of the
>>> original H, maybe after making a few irrelevant changes to the code
>>> of the copy to make it more difficult to recognize. I wonder
>>> whether H will always be able to detect such tricks.
>>>
>>
>> // P does the opposite of whatever H decides
>> void P(ptr x)
>> {
>> int Halt_Status = H(x, x);
>> if (Halt_Status) // if H(P,P) reports that its input halts
>> HERE: goto HERE; // P loops and never halts
>> return; // else P halts
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H(P, P));
>> }
>>
>> The standard template of the "impossible" input used by the halting
>> problem proofs can be determined to be non-halting on the basis that
>> the correct and complete simulation of P by H never reaches the
>> return value from H. This refutes all of the standard proofs.
>>
>> *This also applies to the direct execution of P(P) by H*
>>
>> int H(ptr x, ptr y)
>> {
>> x(y); // H(P,P) specifies the direct execution of P(P);
>> }
>
> Wrong. A halt decider must return a value to its caller ergo a
> recursive halt decider is not a valid halt decider ergo your halt
> decider is not a valid halt decider.
>
> /Flibble
>
>

Computer science is not allowed to contradict software engineering, when
a function called in infinite recursion returns to its caller
*IT IS WRONG*.

On the other hand a decider must return that same result for the same
arguments to every caller whenever it is actually invoked.

This makes HH(PP,PP) not conform to the requirements of a decider within
computer science so spent several months rewriting the original H(P,P)
to meet these requirements.

--
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 9/18/22 1:09 PM, olcott wrote:
> On 9/18/2022 11:33 AM, Mr Flibble wrote:
>> On Sun, 18 Sep 2022 11:09:44 -0500
>> olcott <polcott2@gmail.com> wrote:
>>
>>> On 9/18/2022 10:25 AM, Fred. Zwarts wrote:
>>>> Op 18.sep..2022 om 12:20 schreef Mr Flibble:
>>>>> Hi!
>>>>>
>>>>> I have an idea for a signaling simulating halt decider that forks
>>>>> the simulation into two branches if the input calls the halt
>>>>> decider as per [Strachey 1965]'s "Impossible Program":
>>>>>
>>>>> void P(void (*x)())
>>>>> {
>>>>>      if (H(x, x))
>>>>>          infinite_loop: goto infinite_loop;
>>>>>      return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>      std::cout << "Input halts: " << H(P, P) << std::endl;
>>>>> }
>>>>>
>>>>> When the simulator detects the call to H in P it forks the
>>>>> simulation into a non-halting branch (returning 0 to P) and a
>>>>> halting branch (returning 1 to P) and continues the simulation of
>>>>> these two branches in parallel.
>>>>>
>>>>> If the non-halting branch is determined to halt AND the halting
>>>>> branch is determined to not halt then pathology is detected and
>>>>> reported via a sNaP (signaling Not a Program) signal (analogous to
>>>>> IEEE 754's sNaN (signaling Not a Number) signal)
>>>>>
>>>>> If EITHER branch is determined to be correctly decided then that
>>>>> will be the decision of the halting decider.
>>>>>
>>>>> Crucially this scheme will handle (and correctly decide) the
>>>>> following case whereby the result of H is discarded by the input:
>>>>>
>>>>> void Px(void (*x)())
>>>>> {
>>>>>      (void) H(x, x);
>>>>>      return;
>>>>> }
>>>>>
>>>>> Obviously my idea necessitates extending the definition of a halt
>>>>> decider:
>>>>>
>>>>> 1) Decider decision is HALTS if input halts.
>>>>> 2) Decider decision is NON-HALTING if input does not halt.
>>>>> 3) Decider rejects pathological input as invalid by signaling sNaP.
>>>>>
>>>>> Thoughts?  I am probably missing something obvious as my idea
>>>>> appears to refute [Strachey 1965] and associated HP proofs which
>>>>> great minds have mulled over for decades.
>>>>>
>>>>> /Flibble
>>>>
>>>> Ben said already that this is not the solution of the halting
>>>> problem, but something else.
>>>>
>>>> But even then I see a few problems with your ideas:
>>>>
>>>> 1) The definition of "pathological input" is unclear. So, is there
>>>> a way to verify that the sNaP signal is always correct or incorrect?
>>>> 2) If the sNaP signal can be used by a program to decide whether a
>>>> program is pathological, then also a pathological program can use
>>>> the signal to make the signal invalid. If the sNaP signal cannot be
>>>> used by the main program, then it has no value.
>>>> 3) It seems crucial for your idea, that H detects a call to itself.
>>>> But a pathological program could hide this, e.g. by copying the
>>>> code of H to somewhere else and call the copy instead of the
>>>> original H, maybe after making a few irrelevant changes to the code
>>>> of the copy to make it more difficult to recognize. I wonder
>>>> whether H will always be able to detect such tricks.
>>>
>>> // P does the opposite of whatever H decides
>>> void P(ptr x)
>>> {
>>>     int Halt_Status = H(x, x);
>>>     if (Halt_Status)    // if H(P,P) reports that its input halts
>>>       HERE: goto HERE;  // P loops and never halts
>>>     return;             // else P halts
>>> }
>>>
>>> int main()
>>> {
>>>     Output("Input_Halts = ", H(P, P));
>>> }
>>>
>>> The standard template of the "impossible" input used by the halting
>>> problem proofs can be determined to be non-halting on the basis that
>>> the correct and complete simulation of P by H never reaches the
>>> return value from H. This refutes all of the standard proofs.
>>>
>>> *This also applies to the direct execution of P(P) by H*
>>>
>>> int H(ptr x, ptr y)
>>> {
>>>     x(y); // H(P,P) specifies the direct execution of P(P);
>>> }
>>
>> Wrong.  A halt decider must return a value to its caller ergo a
>> recursive halt decider is not a valid halt decider ergo your halt
>> decider is not a valid halt decider.
>>
>> /Flibble
>>
>>
>
> Computer science is not allowed to contradict software engineering, when
> a function called in infinite recursion returns to its caller
> *IT IS WRONG*.
>

No, Engineering is not allowed to contradict Science. Engineering it the
art of putting the Scientific principles into practice, and needs to do
so understanding the limitations imposed by the Science.

If Science says a given support can only hold 1000 lbs, Engineering
can't decider to put 2000 lbs on it.

You don't seem to understand even that fact.

> On the other hand a decider must return that same result for the same
> arguments to every caller whenever it is actually invoked.
>
> This makes HH(PP,PP) not conform to the requirements of a decider within
> computer science so spent several months rewriting the original H(P,P)
> to meet these requirements.
>

Mr Flibble <flibble@reddwarf.jmc.corp> writes:

> On Sun, 18 Sep 2022 16:04:03 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>
>> > Obviously my idea necessitates extending the definition of a halt
>> > decider:
>>
>> And, indeed, the term 'decider' since a decider is defined to be an
>> algorithm that always either accepts or rejects an input!
>>
>> > 1) Decider decision is HALTS if input halts.
>> > 2) Decider decision is NON-HALTING if input does not halt.
>> > 3) Decider rejects pathological input as invalid by signaling sNaP.
>> >
>> > Thoughts?
>>
>> So what? Every computation in category 3 either halts or does not
>> halt, so you might as well call this category "the inputs the
>> 'decider' gets wrong". There is no better definition of it.
>
> Wrong. Every computation in category 3 BOTH halts AND doesn't halt which
> is obviously invalid

If a computation has to have both P /and/ not P for some property P (in
this case "halting") to be in some category, then that category is
empty.

--
Ben.

On 9/18/2022 2:54 PM, Ben Bacarisse wrote:
> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>
>> On Sun, 18 Sep 2022 16:04:03 +0100
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>>
>>>> Obviously my idea necessitates extending the definition of a halt
>>>> decider:
>>>
>>> And, indeed, the term 'decider' since a decider is defined to be an
>>> algorithm that always either accepts or rejects an input!
>>>
>>>> 1) Decider decision is HALTS if input halts.
>>>> 2) Decider decision is NON-HALTING if input does not halt.
>>>> 3) Decider rejects pathological input as invalid by signaling sNaP.
>>>>
>>>> Thoughts?
>>>
>>> So what? Every computation in category 3 either halts or does not
>>> halt, so you might as well call this category "the inputs the
>>> 'decider' gets wrong". There is no better definition of it.
>>
>> Wrong. Every computation in category 3 BOTH halts AND doesn't halt which
>> is obviously invalid
>
> If a computation has to have both P /and/ not P for some property P (in
> this case "halting") to be in some category, then that category is
> empty.
>

More aptly put as: "obviously invalid"

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

Op 18.sep..2022 om 18:27 schreef Mr Flibble:
> On Sun, 18 Sep 2022 17:25:48 +0200
> "Fred. Zwarts" <F.Zwarts@KVI.nl> wrote:
>
>> Op 18.sep..2022 om 12:20 schreef Mr Flibble:
>>> Hi!
>>>
>>> I have an idea for a signaling simulating halt decider that forks
>>> the simulation into two branches if the input calls the halt
>>> decider as per [Strachey 1965]'s "Impossible Program":
>>>
>>> void P(void (*x)())
>>> {
>>> if (H(x, x))
>>> infinite_loop: goto infinite_loop;
>>> return;
>>> }
>>>
>>> int main()
>>> {
>>> std::cout << "Input halts: " << H(P, P) << std::endl;
>>> }
>>>
>>> When the simulator detects the call to H in P it forks the
>>> simulation into a non-halting branch (returning 0 to P) and a
>>> halting branch (returning 1 to P) and continues the simulation of
>>> these two branches in parallel.
>>>
>>> If the non-halting branch is determined to halt AND the halting
>>> branch is determined to not halt then pathology is detected and
>>> reported via a sNaP (signaling Not a Program) signal (analogous to
>>> IEEE 754's sNaN (signaling Not a Number) signal)
>>>
>>> If EITHER branch is determined to be correctly decided then that
>>> will be the decision of the halting decider.
>>>
>>> Crucially this scheme will handle (and correctly decide) the
>>> following case whereby the result of H is discarded by the input:
>>>
>>> void Px(void (*x)())
>>> {
>>> (void) H(x, x);
>>> return;
>>> }
>>>
>>> Obviously my idea necessitates extending the definition of a halt
>>> decider:
>>>
>>> 1) Decider decision is HALTS if input halts.
>>> 2) Decider decision is NON-HALTING if input does not halt.
>>> 3) Decider rejects pathological input as invalid by signaling sNaP.
>>>
>>> Thoughts? I am probably missing something obvious as my idea
>>> appears to refute [Strachey 1965] and associated HP proofs which
>>> great minds have mulled over for decades.
>>>
>>> /Flibble
>>
>> Ben said already that this is not the solution of the halting
>> problem, but something else.
>>
>> But even then I see a few problems with your ideas:
>>
>> 1) The definition of "pathological input" is unclear. So, is there a
>> way to verify that the sNaP signal is always correct or incorrect?
>
> The pathological input is an input that replicates the [Strachey 1965]
> "Impossible Program) pattern.
>
>> 2) If the sNaP signal can be used by a program to decide whether a
>> program is pathological, then also a pathological program can use the
>> signal to make the signal invalid. If the sNaP signal cannot be used
>> by the main program, then it has no value.
>
> The sNaP signal is unavailable (catching or raising) to the input being
> simulated; it is only available to the code which is invoking the
> decider (i.e. from outside the simulation).
>
>> 3) It seems crucial for your idea, that H detects a call to itself.
>> But a pathological program could hide this, e.g. by copying the code
>> of H to somewhere else and call the copy instead of the original H,
>> maybe after making a few irrelevant changes to the code of the copy
>> to make it more difficult to recognize. I wonder whether H will
>> always be able to detect such tricks.
>
> Use of the Flibble Signaling Decider necessitates use of the "neos"
> virtual machine and compiler which will be configured to prohibit the
> copying and/or modification you describe.

Do the restrictions for 2) and 3) imply that the Flibble Signaling
Decider can only be used for a limited set of programs?

On 9/18/22 12:27 PM, Mr Flibble wrote:
> On Sun, 18 Sep 2022 17:25:48 +0200
> "Fred. Zwarts" <F.Zwarts@KVI.nl> wrote:
>
>> Op 18.sep..2022 om 12:20 schreef Mr Flibble:
>>> Hi!
>>>
>>> I have an idea for a signaling simulating halt decider that forks
>>> the simulation into two branches if the input calls the halt
>>> decider as per [Strachey 1965]'s "Impossible Program":
>>>
>>> void P(void (*x)())
>>> {
>>> if (H(x, x))
>>> infinite_loop: goto infinite_loop;
>>> return;
>>> }
>>>
>>> int main()
>>> {
>>> std::cout << "Input halts: " << H(P, P) << std::endl;
>>> }
>>>
>>> When the simulator detects the call to H in P it forks the
>>> simulation into a non-halting branch (returning 0 to P) and a
>>> halting branch (returning 1 to P) and continues the simulation of
>>> these two branches in parallel.
>>>
>>> If the non-halting branch is determined to halt AND the halting
>>> branch is determined to not halt then pathology is detected and
>>> reported via a sNaP (signaling Not a Program) signal (analogous to
>>> IEEE 754's sNaN (signaling Not a Number) signal)
>>>
>>> If EITHER branch is determined to be correctly decided then that
>>> will be the decision of the halting decider.
>>>
>>> Crucially this scheme will handle (and correctly decide) the
>>> following case whereby the result of H is discarded by the input:
>>>
>>> void Px(void (*x)())
>>> {
>>> (void) H(x, x);
>>> return;
>>> }
>>>
>>> Obviously my idea necessitates extending the definition of a halt
>>> decider:
>>>
>>> 1) Decider decision is HALTS if input halts.
>>> 2) Decider decision is NON-HALTING if input does not halt.
>>> 3) Decider rejects pathological input as invalid by signaling sNaP.
>>>
>>> Thoughts? I am probably missing something obvious as my idea
>>> appears to refute [Strachey 1965] and associated HP proofs which
>>> great minds have mulled over for decades.
>>>
>>> /Flibble
>>
>> Ben said already that this is not the solution of the halting
>> problem, but something else.
>>
>> But even then I see a few problems with your ideas:
>>
>> 1) The definition of "pathological input" is unclear. So, is there a
>> way to verify that the sNaP signal is always correct or incorrect?
>
> The pathological input is an input that replicates the [Strachey 1965]
> "Impossible Program) pattern.

Which the detection of is impossible for a Turing machine, or anything
equivalent to a Turing Machine.

Note, Olcott's (and your) method of deciding on the recursion by address
matching is flawed because it says that BY STRUCTURE, the decider
absolutely can not take as an input "All Programs", as it constrains the
definition of the program it is deciding on.

>
>> 2) If the sNaP signal can be used by a program to decide whether a
>> program is pathological, then also a pathological program can use the
>> signal to make the signal invalid. If the sNaP signal cannot be used
>> by the main program, then it has no value.
>
> The sNaP signal is unavailable (catching or raising) to the input being
> simulated; it is only available to the code which is invoking the
> decider (i.e. from outside the simulation).

Which means it isn't deciding on the actual behavior of the input program.

Since the actual execution of the input program invokes the decider, it
can get the sNAP return value, and thus since the decider doesn't
consider what happens with a sNAP return, which is what it will claim t
happen, it doesn't actually look at what the actual behavior of the
input is.

You need to better analyize the effect of converting a binary logic to
trinary.

>
>> 3) It seems crucial for your idea, that H detects a call to itself.
>> But a pathological program could hide this, e.g. by copying the code
>> of H to somewhere else and call the copy instead of the original H,
>> maybe after making a few irrelevant changes to the code of the copy
>> to make it more difficult to recognize. I wonder whether H will
>> always be able to detect such tricks.
>
> Use of the Flibble Signaling Decider necessitates use of the "neos"
> virtual machine and compiler which will be configured to prohibit the
> copying and/or modification you describe.
>
> /Flibble
>

And thus doesn't process ALL inputs, and fails to be the universal
decider that the problem asks about.

All you have done is CONFIRM that you can't make a Universal Halt
Decider, not even one that is allowed to answer "sNAP".

On Mon, 19 Sep 2022 07:40:11 -0400
Richard Damon <Richard@Damon-Family.org> wrote:

> On 9/18/22 12:27 PM, Mr Flibble wrote:
> > On Sun, 18 Sep 2022 17:25:48 +0200
> > "Fred. Zwarts" <F.Zwarts@KVI.nl> wrote:
> >
> >> Op 18.sep..2022 om 12:20 schreef Mr Flibble:
> >>> Hi!
> >>>
> >>> I have an idea for a signaling simulating halt decider that forks
> >>> the simulation into two branches if the input calls the halt
> >>> decider as per [Strachey 1965]'s "Impossible Program":
> >>>
> >>> void P(void (*x)())
> >>> {
> >>> if (H(x, x))
> >>> infinite_loop: goto infinite_loop;
> >>> return;
> >>> }
> >>>
> >>> int main()
> >>> {
> >>> std::cout << "Input halts: " << H(P, P) << std::endl;
> >>> }
> >>>
> >>> When the simulator detects the call to H in P it forks the
> >>> simulation into a non-halting branch (returning 0 to P) and a
> >>> halting branch (returning 1 to P) and continues the simulation of
> >>> these two branches in parallel.
> >>>
> >>> If the non-halting branch is determined to halt AND the halting
> >>> branch is determined to not halt then pathology is detected and
> >>> reported via a sNaP (signaling Not a Program) signal (analogous to
> >>> IEEE 754's sNaN (signaling Not a Number) signal)
> >>>
> >>> If EITHER branch is determined to be correctly decided then that
> >>> will be the decision of the halting decider.
> >>>
> >>> Crucially this scheme will handle (and correctly decide) the
> >>> following case whereby the result of H is discarded by the input:
> >>>
> >>> void Px(void (*x)())
> >>> {
> >>> (void) H(x, x);
> >>> return;
> >>> }
> >>>
> >>> Obviously my idea necessitates extending the definition of a halt
> >>> decider:
> >>>
> >>> 1) Decider decision is HALTS if input halts.
> >>> 2) Decider decision is NON-HALTING if input does not halt.
> >>> 3) Decider rejects pathological input as invalid by signaling
> >>> sNaP.
> >>>
> >>> Thoughts? I am probably missing something obvious as my idea
> >>> appears to refute [Strachey 1965] and associated HP proofs which
> >>> great minds have mulled over for decades.
> >>>
> >>> /Flibble
> >>
> >> Ben said already that this is not the solution of the halting
> >> problem, but something else.
> >>
> >> But even then I see a few problems with your ideas:
> >>
> >> 1) The definition of "pathological input" is unclear. So, is there
> >> a way to verify that the sNaP signal is always correct or
> >> incorrect?
> >
> > The pathological input is an input that replicates the [Strachey
> > 1965] "Impossible Program) pattern.
>
> Which the detection of is impossible for a Turing machine, or
> anything equivalent to a Turing Machine.
>
> Note, Olcott's (and your) method of deciding on the recursion by
> address matching is flawed because it says that BY STRUCTURE, the
> decider absolutely can not take as an input "All Programs", as it
> constrains the definition of the program it is deciding on.
>
> >
> >> 2) If the sNaP signal can be used by a program to decide whether a
> >> program is pathological, then also a pathological program can use
> >> the signal to make the signal invalid. If the sNaP signal cannot
> >> be used by the main program, then it has no value.
> >
> > The sNaP signal is unavailable (catching or raising) to the input
> > being simulated; it is only available to the code which is invoking
> > the decider (i.e. from outside the simulation).
>
> Which means it isn't deciding on the actual behavior of the input
> program.

Yes it is.

>
> Since the actual execution of the input program invokes the decider,
> it can get the sNAP return value, and thus since the decider doesn't
> consider what happens with a sNAP return, which is what it will claim
> t happen, it doesn't actually look at what the actual behavior of the
> input is.

Nope. The driver program that calls the decider IS NOT THE INPUT; the
driver program passes the input to the decider and then the input is
simulated.

>
> You need to better analyize the effect of converting a binary logic
> to trinary.

Bullshit.

>
> >
> >> 3) It seems crucial for your idea, that H detects a call to itself.
> >> But a pathological program could hide this, e.g. by copying the
> >> code of H to somewhere else and call the copy instead of the
> >> original H, maybe after making a few irrelevant changes to the
> >> code of the copy to make it more difficult to recognize. I wonder
> >> whether H will always be able to detect such tricks.
> >
> > Use of the Flibble Signaling Decider necessitates use of the "neos"
> > virtual machine and compiler which will be configured to prohibit
> > the copying and/or modification you describe.
> >
> > /Flibble
> >
>
> And thus doesn't process ALL inputs, and fails to be the universal
> decider that the problem asks about.

Yes it does process all inputs so you are wrong again. How? Consider
Turing Completeness: any input can be reformulated into an equivalent
input that is properly constrained by the halting decider framework.

>
> All you have done is CONFIRM that you can't make a Universal Halt
> Decider, not even one that is allowed to answer "sNAP".

Of course the decider can answer sNaP, externally to the simulation.
You appear to have gone full retard due to your endless back and forth
with Olcott messing with your head.

My halting decider just works; I have refuted the halting problem
proofs.

/Flibble

On Mon, 19 Sep 2022 13:18:09 +0200
"Fred. Zwarts" <F.Zwarts@KVI.nl> wrote:

> Op 18.sep..2022 om 18:27 schreef Mr Flibble:
> > On Sun, 18 Sep 2022 17:25:48 +0200
> > "Fred. Zwarts" <F.Zwarts@KVI.nl> wrote:
> >
> >> Op 18.sep..2022 om 12:20 schreef Mr Flibble:
> >>> Hi!
> >>>
> >>> I have an idea for a signaling simulating halt decider that forks
> >>> the simulation into two branches if the input calls the halt
> >>> decider as per [Strachey 1965]'s "Impossible Program":
> >>>
> >>> void P(void (*x)())
> >>> {
> >>> if (H(x, x))
> >>> infinite_loop: goto infinite_loop;
> >>> return;
> >>> }
> >>>
> >>> int main()
> >>> {
> >>> std::cout << "Input halts: " << H(P, P) << std::endl;
> >>> }
> >>>
> >>> When the simulator detects the call to H in P it forks the
> >>> simulation into a non-halting branch (returning 0 to P) and a
> >>> halting branch (returning 1 to P) and continues the simulation of
> >>> these two branches in parallel.
> >>>
> >>> If the non-halting branch is determined to halt AND the halting
> >>> branch is determined to not halt then pathology is detected and
> >>> reported via a sNaP (signaling Not a Program) signal (analogous to
> >>> IEEE 754's sNaN (signaling Not a Number) signal)
> >>>
> >>> If EITHER branch is determined to be correctly decided then that
> >>> will be the decision of the halting decider.
> >>>
> >>> Crucially this scheme will handle (and correctly decide) the
> >>> following case whereby the result of H is discarded by the input:
> >>>
> >>> void Px(void (*x)())
> >>> {
> >>> (void) H(x, x);
> >>> return;
> >>> }
> >>>
> >>> Obviously my idea necessitates extending the definition of a halt
> >>> decider:
> >>>
> >>> 1) Decider decision is HALTS if input halts.
> >>> 2) Decider decision is NON-HALTING if input does not halt.
> >>> 3) Decider rejects pathological input as invalid by signaling
> >>> sNaP.
> >>>
> >>> Thoughts? I am probably missing something obvious as my idea
> >>> appears to refute [Strachey 1965] and associated HP proofs which
> >>> great minds have mulled over for decades.
> >>>
> >>> /Flibble
> >>
> >> Ben said already that this is not the solution of the halting
> >> problem, but something else.
> >>
> >> But even then I see a few problems with your ideas:
> >>
> >> 1) The definition of "pathological input" is unclear. So, is there
> >> a way to verify that the sNaP signal is always correct or
> >> incorrect?
> >
> > The pathological input is an input that replicates the [Strachey
> > 1965] "Impossible Program) pattern.
> >
> >> 2) If the sNaP signal can be used by a program to decide whether a
> >> program is pathological, then also a pathological program can use
> >> the signal to make the signal invalid. If the sNaP signal cannot
> >> be used by the main program, then it has no value.
> >
> > The sNaP signal is unavailable (catching or raising) to the input
> > being simulated; it is only available to the code which is invoking
> > the decider (i.e. from outside the simulation).
> >
> >> 3) It seems crucial for your idea, that H detects a call to itself.
> >> But a pathological program could hide this, e.g. by copying the
> >> code of H to somewhere else and call the copy instead of the
> >> original H, maybe after making a few irrelevant changes to the
> >> code of the copy to make it more difficult to recognize. I wonder
> >> whether H will always be able to detect such tricks.
> >
> > Use of the Flibble Signaling Decider necessitates use of the "neos"
> > virtual machine and compiler which will be configured to prohibit
> > the copying and/or modification you describe.
>
> Do the restrictions for 2) and 3) imply that the Flibble Signaling
> Decider can only be used for a limited set of programs?

No, it can be used for any input that can be reformulated to be
simulated within the decider's framework. Any Turing Complete language
can be used to formulate the input.

/Flibble

On Sunday, September 18, 2022 at 4:55:42 PM UTC+1, Mr Flibble wrote:
> On Sun, 18 Sep 2022 16:04:03 +0100
> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> > (See any of the dozens of replies to PO when he was pushing this line
> > many years ago.)
> Olcott is a sub-par troll; I like to think my trolling is of better
> quality.

I beg to differ. Olcott manages to get us to believe he actually believes all his nonsense, despite him occasionally showing that he knows exactly which points he has to turn the conversation away from. And also, every so often, he makes us think the conversation is actually getting somewhere, we think "just one more post and he'll see sense" - which of course never happens.

On 9/19/2022 8:44 AM, Paul N wrote:
> On Sunday, September 18, 2022 at 4:55:42 PM UTC+1, Mr Flibble wrote:
>> On Sun, 18 Sep 2022 16:04:03 +0100
>> Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>>> (See any of the dozens of replies to PO when he was pushing this line
>>> many years ago.)
>> Olcott is a sub-par troll; I like to think my trolling is of better
>> quality.
>
> I beg to differ. Olcott manages to get us to believe he actually believes all his nonsense, despite him occasionally showing that he knows exactly which points he has to turn the conversation away from. And also, every so often, he makes us think the conversation is actually getting somewhere, we think "just one more post and he'll see sense" - which of course never happens.

int Hx(ptr x, ptr y)
{ x(y); // the direct execution of the input to Hx(Px,Px)
}

*Richard has understood and agreed to one of my key points*

On 9/17/2022 9:38 PM, Richard Damon wrote:
> If Hx DOES directly execute its input, then it
> will NEVER report non-halting, and yes, then the
> input Px built from THAT Hx will be non-halting.

I count this as progress.

*A halt decider always only predicts the behavior of its input*, the
above behavior is what Hx must predict. By using an adapted version of
the infinite recursion behavior pattern a simulating halt decider does
correctly predict the above behavior in a finite number of steps and as
a pure function of its inputs.

--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

Op 19.sep..2022 om 15:22 schreef Mr Flibble:
> On Mon, 19 Sep 2022 13:18:09 +0200
> "Fred. Zwarts" <F.Zwarts@KVI.nl> wrote:
>
>> Op 18.sep..2022 om 18:27 schreef Mr Flibble:
>>> On Sun, 18 Sep 2022 17:25:48 +0200
>>> "Fred. Zwarts" <F.Zwarts@KVI.nl> wrote:
>>>
>>>> Op 18.sep..2022 om 12:20 schreef Mr Flibble:
>>>>> Hi!
>>>>>
>>>>> I have an idea for a signaling simulating halt decider that forks
>>>>> the simulation into two branches if the input calls the halt
>>>>> decider as per [Strachey 1965]'s "Impossible Program":
>>>>>
>>>>> void P(void (*x)())
>>>>> {
>>>>> if (H(x, x))
>>>>> infinite_loop: goto infinite_loop;
>>>>> return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>> std::cout << "Input halts: " << H(P, P) << std::endl;
>>>>> }
>>>>>
>>>>> When the simulator detects the call to H in P it forks the
>>>>> simulation into a non-halting branch (returning 0 to P) and a
>>>>> halting branch (returning 1 to P) and continues the simulation of
>>>>> these two branches in parallel.
>>>>>
>>>>> If the non-halting branch is determined to halt AND the halting
>>>>> branch is determined to not halt then pathology is detected and
>>>>> reported via a sNaP (signaling Not a Program) signal (analogous to
>>>>> IEEE 754's sNaN (signaling Not a Number) signal)
>>>>>
>>>>> If EITHER branch is determined to be correctly decided then that
>>>>> will be the decision of the halting decider.
>>>>>
>>>>> Crucially this scheme will handle (and correctly decide) the
>>>>> following case whereby the result of H is discarded by the input:
>>>>>
>>>>> void Px(void (*x)())
>>>>> {
>>>>> (void) H(x, x);
>>>>> return;
>>>>> }
>>>>>
>>>>> Obviously my idea necessitates extending the definition of a halt
>>>>> decider:
>>>>>
>>>>> 1) Decider decision is HALTS if input halts.
>>>>> 2) Decider decision is NON-HALTING if input does not halt.
>>>>> 3) Decider rejects pathological input as invalid by signaling
>>>>> sNaP.
>>>>>
>>>>> Thoughts? I am probably missing something obvious as my idea
>>>>> appears to refute [Strachey 1965] and associated HP proofs which
>>>>> great minds have mulled over for decades.
>>>>>
>>>>> /Flibble
>>>>
>>>> Ben said already that this is not the solution of the halting
>>>> problem, but something else.
>>>>
>>>> But even then I see a few problems with your ideas:
>>>>
>>>> 1) The definition of "pathological input" is unclear. So, is there
>>>> a way to verify that the sNaP signal is always correct or
>>>> incorrect?
>>>
>>> The pathological input is an input that replicates the [Strachey
>>> 1965] "Impossible Program) pattern.
>>>
>>>> 2) If the sNaP signal can be used by a program to decide whether a
>>>> program is pathological, then also a pathological program can use
>>>> the signal to make the signal invalid. If the sNaP signal cannot
>>>> be used by the main program, then it has no value.
>>>
>>> The sNaP signal is unavailable (catching or raising) to the input
>>> being simulated; it is only available to the code which is invoking
>>> the decider (i.e. from outside the simulation).
>>>
>>>> 3) It seems crucial for your idea, that H detects a call to itself.
>>>> But a pathological program could hide this, e.g. by copying the
>>>> code of H to somewhere else and call the copy instead of the
>>>> original H, maybe after making a few irrelevant changes to the
>>>> code of the copy to make it more difficult to recognize. I wonder
>>>> whether H will always be able to detect such tricks.
>>>
>>> Use of the Flibble Signaling Decider necessitates use of the "neos"
>>> virtual machine and compiler which will be configured to prohibit
>>> the copying and/or modification you describe.
>>
>> Do the restrictions for 2) and 3) imply that the Flibble Signaling
>> Decider can only be used for a limited set of programs?
>
> No, it can be used for any input that can be reformulated to be
> simulated within the decider's framework. Any Turing Complete language
> can be used to formulate the input.
Even if P does not use a direct execution of H to determine its
behaviour, but it simulates H in its own simulator, similar (but not
equal) to how P is simulated by H?