A valid halt decider must conform to the following requirements (as
test case assertions):

void P1(ptr x)
{ return;
}

void P2(ptr x)
{ for(;;);
}

void P3(ptr x)
{ if (H(x, x))
for(;;);
return;
}

void P4(ptr x)
{ (void)H(x, x);
return;
}

int main()
{ EXPECT_EQ(H(P1, P1), 1);
EXPECT_EQ(H(P2, P2), 0);
EXPECT_THROW(H(P3, P3), sNaP); // sNaP exception = pathological input
EXPECT_EQ(H(P4, P4), 1);
}

Olcott's simulating halt decider does not meet the above requrements so
is not a valid halt decider.
Flibble's signaling halt decider does meet the above requirements so is
a valid halt decider.

/Flibble

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

> A valid halt decider must conform to the following requirements (as

You mean a valid "Flibble-decider". The meaning of halt decider is
already established and re-using it that term for something else is poor
communication.

> test case assertions):
>
> void P1(ptr x)
> {
> return;
> }
>
> void P2(ptr x)
> {
> for(;;);idl
> }
>
> void P3(ptr x)
> {
> if (H(x, x))
> for(;;);
> return;
> }
>
> void P4(ptr x)
> {
> (void)H(x, x);
> return;
> }
>
> int main()
> {
> EXPECT_EQ(H(P1, P1), 1);
> EXPECT_EQ(H(P2, P2), 0);
> EXPECT_THROW(H(P3, P3), sNaP); // sNaP exception = pathological input

All computations (in the formal sense) either halt or they don't halt.
Therefore there is always a correct 0/1 result for every computation.

But don't despair. Provided your so-called pathological inputs are
rare, Flibble-deciders are interesting in themselves.

Unfortunately, the post's subject it a bit deceptive because these are
only a tiny part of the formal requirements for a Flibble-decider. If
you could actually specify what "pathological input" really is (by which
I don't mean give another example or two) then you would have gone
further than any of the other cranks who have used this three-way answer
pattern. None of them can ever say exactly what is pathological.

> EXPECT_EQ(H(P4, P4), 1);
> }
>
> Olcott's simulating halt decider does not meet the above requrements so
> is not a valid halt decider.

It's not a Flibble-decider, no. But PO is aiming for an actual "two
answers only" decider but he's now just stuck trying to explain away the
wrong answer.

--
Ben.

On Mon, 29 Aug 2022 22:07:00 +0100
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:

> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>
> > A valid halt decider must conform to the following requirements (as
> >
>
> You mean a valid "Flibble-decider". The meaning of halt decider is
> already established and re-using it that term for something else is
> poor communication.
>
> > test case assertions):
> >
> > void P1(ptr x)
> > {
> > return;
> > }
> >
> > void P2(ptr x)
> > {
> > for(;;);idl
> > }
> >
> > void P3(ptr x)
> > {
> > if (H(x, x))
> > for(;;);
> > return;
> > }
> >
> > void P4(ptr x)
> > {
> > (void)H(x, x);
> > return;
> > }
> >
> > int main()
> > {
> > EXPECT_EQ(H(P1, P1), 1);
> > EXPECT_EQ(H(P2, P2), 0);
> > EXPECT_THROW(H(P3, P3), sNaP); // sNaP exception = pathological
> > input
>
> All computations (in the formal sense) either halt or they don't halt.
> Therefore there is always a correct 0/1 result for every computation.

WRONG. A pathological input neither halts nor doesn't halt.

/Flibble

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

> On Mon, 29 Aug 2022 22:07:00 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>
>> Mr Flibble <flibble@reddwarf.jmc.corp> writes:
>>
>> > A valid halt decider must conform to the following requirements (as
>>
>> You mean a valid "Flibble-decider". The meaning of halt decider is
>> already established and re-using it that term for something else is
>> poor communication.
>>
>> > test case assertions):
>> >
>> > void P1(ptr x)
>> > {
>> > return;
>> > }
>> >
>> > void P2(ptr x)
>> > {
>> > for(;;);idl
>> > }
>> >
>> > void P3(ptr x)
>> > {
>> > if (H(x, x))
>> > for(;;);
>> > return;
>> > }
>> >
>> > void P4(ptr x)
>> > {
>> > (void)H(x, x);
>> > return;
>> > }
>> >
>> > int main()
>> > {
>> > EXPECT_EQ(H(P1, P1), 1);
>> > EXPECT_EQ(H(P2, P2), 0);
>> > EXPECT_THROW(H(P3, P3), sNaP); // sNaP exception = pathological
>> > input
>>
>> All computations (in the formal sense) either halt or they don't halt.
>> Therefore there is always a correct 0/1 result for every computation.
>
> WRONG. A pathological input neither halts nor doesn't halt.

Well no input halts (and no input does not halt) because halting is not
a property of inputs but of the computations represented by the those
inputs. The "inputs" P2, P2 represent the computation P2(P2) which does
not halt. What computation is represented by the inputs P3, P3?

--
Ben.