Here is 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 this necessitates extending the definition of a halt
decider to return three rather than the tradition two results:

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.

This approach is valid if we recognise the presence of a category error
at the heart of the halting problem's "Impossible Program" definition:
a circular self referential infinitely recursive conflation between a
decider and its input: the sNaP signal being the result of the category
error manifesting.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/30/25 7:42 PM, olcott wrote:

On 7/30/2025 6:00 PM, Mr Flibble wrote:

Here is 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 this necessitates extending the definition of a halt
decider to return three rather than the tradition two results:

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.

This approach is valid if we recognise the presence of a category error
at the heart of the halting problem's "Impossible Program" definition:
a circular self referential infinitely recursive conflation between a
decider and its input: the sNaP signal being the result of the category
error manifesting.

/Flibble

Alternatively halt deciders never were accountable
for the direct execution of their inputs because
no Turing machine can take a directly executing
Turing machine as an input.

Sure they are, you are just proving you don't know what you are talking
about.

Halt deciders are only accountable for the behavior
that their input finite string Turing machine
description specifies.

Which is DEFINED to be the behavior of the directly executed machine
they describe.

This is only different than the direct execution
of the underlying machine when the input calls
its own decider (in recursive simulation).

Nope, no exceptions. Just proves you are liar that think it is ok to
change the defintions of the words you are using.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-07-30 23:00:21 +0000, Mr Flibble said:

Here is 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 this necessitates extending the definition of a halt
decider to return three rather than the tradition two results:

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.

This approach is valid if we recognise the presence of a category error
at the heart of the halting problem's "Impossible Program" definition:
a circular self referential infinitely recursive conflation between a
decider and its input: the sNaP signal being the result of the category
error manifesting.

This method depends on the possibility of identifying a call to H. If
the input has a copy of H that is functionally equivalent but encoded differently the identification of the pathology may fail and H may
fail to return.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 31 Jul 2025 11:46:55 +0300, Mikko wrote:

On 2025-07-30 23:00:21 +0000, Mr Flibble said:

Here is 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 this necessitates extending the definition of a halt decider
to return three rather than the tradition two results:

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.

This approach is valid if we recognise the presence of a category error
at the heart of the halting problem's "Impossible Program" definition:
a circular self referential infinitely recursive conflation between a
decider and its input: the sNaP signal being the result of the category
error manifesting.

This method depends on the possibility of identifying a call to H. If
the input has a copy of H that is functionally equivalent but encoded differently the identification of the pathology may fail and H may fail
to return.

There is no copy.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/31/25 12:19 PM, Mr Flibble wrote:

On Thu, 31 Jul 2025 11:46:55 +0300, Mikko wrote:

On 2025-07-30 23:00:21 +0000, Mr Flibble said:

Here is 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 this necessitates extending the definition of a halt decider
to return three rather than the tradition two results:

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.

This approach is valid if we recognise the presence of a category error
at the heart of the halting problem's "Impossible Program" definition:
a circular self referential infinitely recursive conflation between a
decider and its input: the sNaP signal being the result of the category
error manifesting.

This method depends on the possibility of identifying a call to H. If
the input has a copy of H that is functionally equivalent but encoded
differently the identification of the pathology may fail and H may fail
to return.

There is no copy.

/Flibble

There is SUPPOSED to be one. Olcott misses it because he admits his
system isn't Turing Complete because he claims you can't make a copy of
his decider, even though he then does so to make HHH1.

That just shows he is just a pathological liar.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-07-31 16:19:37 +0000, Mr Flibble said:

On Thu, 31 Jul 2025 11:46:55 +0300, Mikko wrote:

On 2025-07-30 23:00:21 +0000, Mr Flibble said:

Here is 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 this necessitates extending the definition of a halt decider
to return three rather than the tradition two results:

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.

This approach is valid if we recognise the presence of a category error
at the heart of the halting problem's "Impossible Program" definition:
a circular self referential infinitely recursive conflation between a
decider and its input: the sNaP signal being the result of the category
error manifesting.

This method depends on the possibility of identifying a call to H. If
the input has a copy of H that is functionally equivalent but encoded
differently the identification of the pathology may fail and H may fail
to return.

There is no copy.

There is when the code is copied.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 31 Jul 2025 19:19:00 -0400, Richard Damon wrote:

On 7/31/25 12:19 PM, Mr Flibble wrote:

On Thu, 31 Jul 2025 11:46:55 +0300, Mikko wrote:

On 2025-07-30 23:00:21 +0000, Mr Flibble said:

Here is 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 this necessitates extending the definition of a halt
decider to return three rather than the tradition two results:

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.

This approach is valid if we recognise the presence of a category
error at the heart of the halting problem's "Impossible Program"
definition: a circular self referential infinitely recursive
conflation between a decider and its input: the sNaP signal being the
result of the category error manifesting.

This method depends on the possibility of identifying a call to H. If
the input has a copy of H that is functionally equivalent but encoded
differently the identification of the pathology may fail and H may
fail to return.

There is no copy.

/Flibble

There is SUPPOSED to be one. Olcott misses it because he admits his
system isn't Turing Complete because he claims you can't make a copy of
his decider, even though he then does so to make HHH1.

That just shows he is just a pathological liar.

The type stratification as highlighted by the category error prevents a
copy of H being made and used by P.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 01 Aug 2025 09:48:35 +0300, Mikko wrote:

On 2025-07-31 16:19:37 +0000, Mr Flibble said:

On Thu, 31 Jul 2025 11:46:55 +0300, Mikko wrote:

On 2025-07-30 23:00:21 +0000, Mr Flibble said:

Here is 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 this necessitates extending the definition of a halt
decider to return three rather than the tradition two results:

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.

This approach is valid if we recognise the presence of a category
error at the heart of the halting problem's "Impossible Program"
definition: a circular self referential infinitely recursive
conflation between a decider and its input: the sNaP signal being the
result of the category error manifesting.

This method depends on the possibility of identifying a call to H. If
the input has a copy of H that is functionally equivalent but encoded
differently the identification of the pathology may fail and H may
fail to return.

There is no copy.

There is when the code is copied.

The code of H cannot be copied and used by P due to type stratification as highlighted by the category error.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/1/25 8:00 AM, Mr Flibble wrote:

On Thu, 31 Jul 2025 19:19:00 -0400, Richard Damon wrote:

On 7/31/25 12:19 PM, Mr Flibble wrote:

On Thu, 31 Jul 2025 11:46:55 +0300, Mikko wrote:

On 2025-07-30 23:00:21 +0000, Mr Flibble said:

Here is 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 this necessitates extending the definition of a halt
decider to return three rather than the tradition two results:

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.

This approach is valid if we recognise the presence of a category
error at the heart of the halting problem's "Impossible Program"
definition: a circular self referential infinitely recursive
conflation between a decider and its input: the sNaP signal being the >>>>> result of the category error manifesting.

This method depends on the possibility of identifying a call to H. If
the input has a copy of H that is functionally equivalent but encoded
differently the identification of the pathology may fail and H may
fail to return.

There is no copy.

/Flibble

There is SUPPOSED to be one. Olcott misses it because he admits his
system isn't Turing Complete because he claims you can't make a copy of
his decider, even though he then does so to make HHH1.

That just shows he is just a pathological liar.

The type stratification as highlighted by the category error prevents a
copy of H being made and used by P.

/Flibble

But it isn't a category error, because you can't actually define the
categories in a usable manner, and they don't actually exist.

Rememver, Olcott is claiming to be working in a system equivalent to
Turing Machines, There is no restrictions in systems equivalent of
Turing Machines about making a copy of any given program.

So, all you are doing is admitting that you want to work in a system
weaker that Turing Machines, for which the halting problem has been
shown in many systems to be solvable, so your ideas aren't really
interesting until you show something new about them.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

olcott <polcott333@gmail.com> wrote:

[ .... ]

Alternatively halt deciders never were accountable
for the direct execution of their inputs because
no Turing machine can take a directly executing
Turing machine as an input.

It's not clear what you mean by a "directly executing turing machine".
Turing machines are abstract constructs which only secondarily can be physically instantiated. What does it mean for a TM to be "directly executing", and how does that differ from "indirectly executing"?

Halt deciders are only accountable for the behavior
that their input finite string Turing machine
description specifies.

If the initial state of the TM's tape can be construed as a string, then
yes.

This is only different than the direct execution
of the underlying machine when the input calls
its own decider (in recursive simulation).

Again, you haven't defined "direct execution".

It is unclear what you mean by "its own decider". What, for example, is
the decider of a program which adds two integers? I think you're getting confused between a purported decider "having" a program which breaks it
(which they all do), and an arbitrary program "having" a decider (which
is non-sensical).

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

--
Alan Mackenzie (Nuremberg, Germany).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 01 Aug 2025 08:27:39 -0400, Richard Damon wrote:

On 8/1/25 8:00 AM, Mr Flibble wrote:

On Thu, 31 Jul 2025 19:19:00 -0400, Richard Damon wrote:

On 7/31/25 12:19 PM, Mr Flibble wrote:

On Thu, 31 Jul 2025 11:46:55 +0300, Mikko wrote:

On 2025-07-30 23:00:21 +0000, Mr Flibble said:

Here is 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 this necessitates extending the definition of a halt
decider to return three rather than the tradition two results:

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. >>>>>>
This approach is valid if we recognise the presence of a category
error at the heart of the halting problem's "Impossible Program"
definition: a circular self referential infinitely recursive
conflation between a decider and its input: the sNaP signal being
the result of the category error manifesting.

This method depends on the possibility of identifying a call to H.
If the input has a copy of H that is functionally equivalent but
encoded differently the identification of the pathology may fail and >>>>> H may fail to return.

There is no copy.

/Flibble

There is SUPPOSED to be one. Olcott misses it because he admits his
system isn't Turing Complete because he claims you can't make a copy
of his decider, even though he then does so to make HHH1.

That just shows he is just a pathological liar.

The type stratification as highlighted by the category error prevents a
copy of H being made and used by P.

/Flibble

But it isn't a category error, because you can't actually define the categories in a usable manner, and they don't actually exist.

Rememver, Olcott is claiming to be working in a system equivalent to
Turing Machines, There is no restrictions in systems equivalent of
Turing Machines about making a copy of any given program.

So, all you are doing is admitting that you want to work in a system
weaker that Turing Machines, for which the halting problem has been
shown in many systems to be solvable, so your ideas aren't really
interesting until you show something new about them.

No, I am working in a STRONGER system than the system espoused by the
Halting Problem as my system actually enables rather than inhibits program verification.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:

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

How's it going to do that? It would need to detect anything which has
the same functionality as H, and I think this is a provably insoluble
task.

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

That's misleading. P _is_ a program. The fact that your simulators may
have trouble with it is a property of the simulators, not of P.

Also, what happens in the general case, where neither branch can be
determined to halt or not to halt? You seem to be begging the question
as to whether halting deciders can exist, assuming (wrongly) the answer
to be yes as part of your "proof".

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 this necessitates extending the definition of a halt
decider to return three rather than the tradition two results:

That's not "exending it", that's defining something entirely different
and less useful.

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.

What you've constructed (assuming it's possible) is a partial halting
decider. It's a machine which can return either yes, no, or don't know.
Or it might run for ever and never return an answer.

This approach is valid if we recognise the presence of a category error
at the heart of the halting problem's "Impossible Program" definition:
a circular self referential infinitely recursive conflation between a
decider and its input: the sNaP signal being the result of the category
error manifesting.

There is no category error in the halting problem. It's a simple
question "does this program halt or does it not halt?". The halting
problem has no "impossible program", and doesn't define one.

It is only in one of several approaches to proving the HP that the
badly named notion of "impossible program" comes up. Again, this
program is just an ordinary program, and there's nothing impossible
about it. It has a particular relationship with some purported halt
decider, but remains a program. This relationship is enough to show
that the purported decider isn't a decider at all.

/Flibble

--
Alan Mackenzie (Nuremberg, Germany).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 01 Aug 2025 13:14:11 +0000, Alan Mackenzie wrote:

There is no category error in the halting problem. It's a simple
question "does this program halt or does it not halt?". The halting
problem has no "impossible program", and doesn't define one.

That is not true so you are either:
(a) a liar;
(b) delusional;
(c) stupid;
(d) ignorant of the facts for some reason.

It is multiple choice however more than one answer may be correct.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:

On Fri, 01 Aug 2025 13:14:11 +0000, Alan Mackenzie wrote:

There is no category error in the halting problem. It's a simple
question "does this program halt or does it not halt?". The halting
problem has no "impossible program", and doesn't define one.

I note how you've snipped pertinent context.

That is not true so you are either:
(a) a liar;
(b) delusional;
(c) stupid;
(d) ignorant of the facts for some reason.

It is multiple choice however more than one answer may be correct.

Now who's descended to ad hominem attacks?

/Flibble

--
Alan Mackenzie (Nuremberg, Germany).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 01 Aug 2025 13:14:11 +0000, Alan Mackenzie wrote:

Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:

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

How's it going to do that? It would need to detect anything which has
the same functionality as H, and I think this is a provably insoluble
task.

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

That's misleading. P _is_ a program. The fact that your simulators may
have trouble with it is a property of the simulators, not of P.

Also, what happens in the general case, where neither branch can be determined to halt or not to halt? You seem to be begging the question
as to whether halting deciders can exist, assuming (wrongly) the answer
to be yes as part of your "proof".

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 this necessitates extending the definition of a halt decider
to return three rather than the tradition two results:

That's not "exending it", that's defining something entirely different
and less useful.

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.

What you've constructed (assuming it's possible) is a partial halting decider. It's a machine which can return either yes, no, or don't know.
Or it might run for ever and never return an answer.

This approach is valid if we recognise the presence of a category error
at the heart of the halting problem's "Impossible Program" definition:
a circular self referential infinitely recursive conflation between a
decider and its input: the sNaP signal being the result of the category
error manifesting.

There is no category error in the halting problem. It's a simple
question "does this program halt or does it not halt?". The halting
problem has no "impossible program", and doesn't define one.

It is only in one of several approaches to proving the HP that the badly named notion of "impossible program" comes up. Again, this program is
just an ordinary program, and there's nothing impossible about it. It
has a particular relationship with some purported halt decider, but
remains a program. This relationship is enough to show that the
purported decider isn't a decider at all.

/Flibble

I am not begging the question at all: partial deciders exist.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/1/25 8:44 AM, Mr Flibble wrote:

On Fri, 01 Aug 2025 08:27:39 -0400, Richard Damon wrote:

On 8/1/25 8:00 AM, Mr Flibble wrote:

On Thu, 31 Jul 2025 19:19:00 -0400, Richard Damon wrote:

On 7/31/25 12:19 PM, Mr Flibble wrote:

On Thu, 31 Jul 2025 11:46:55 +0300, Mikko wrote:

On 2025-07-30 23:00:21 +0000, Mr Flibble said:

Here is 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 this necessitates extending the definition of a halt
decider to return three rather than the tradition two results:

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. >>>>>>>
This approach is valid if we recognise the presence of a category >>>>>>> error at the heart of the halting problem's "Impossible Program" >>>>>>> definition: a circular self referential infinitely recursive
conflation between a decider and its input: the sNaP signal being >>>>>>> the result of the category error manifesting.

This method depends on the possibility of identifying a call to H. >>>>>> If the input has a copy of H that is functionally equivalent but
encoded differently the identification of the pathology may fail and >>>>>> H may fail to return.

There is no copy.

/Flibble

There is SUPPOSED to be one. Olcott misses it because he admits his
system isn't Turing Complete because he claims you can't make a copy
of his decider, even though he then does so to make HHH1.

That just shows he is just a pathological liar.

The type stratification as highlighted by the category error prevents a
copy of H being made and used by P.

/Flibble

But it isn't a category error, because you can't actually define the
categories in a usable manner, and they don't actually exist.

Rememver, Olcott is claiming to be working in a system equivalent to
Turing Machines, There is no restrictions in systems equivalent of
Turing Machines about making a copy of any given program.

So, all you are doing is admitting that you want to work in a system
weaker that Turing Machines, for which the halting problem has been
shown in many systems to be solvable, so your ideas aren't really
interesting until you show something new about them.

No, I am working in a STRONGER system than the system espoused by the
Halting Problem as my system actually enables rather than inhibits program verification.

/Flibble

No, it is WEAKER, as you are restricting what a "program" can do.

You are trying to make program verification easier by limiting what a
program can do, that makes programs WEAKER.

It may make knowledge about them better, but their capabilities are less.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/1/25 9:24 AM, Mr Flibble wrote:

On Fri, 01 Aug 2025 13:14:11 +0000, Alan Mackenzie wrote:

There is no category error in the halting problem. It's a simple
question "does this program halt or does it not halt?". The halting
problem has no "impossible program", and doesn't define one.

That is not true so you are either:
(a) a liar;
(b) delusional;
(c) stupid;
(d) ignorant of the facts for some reason.

It is multiple choice however more than one answer may be correct.

/Flibble

The problem is a wrong definition of the "impossible program".

It's impossibility isn't in its existance, but its ability for the
decider to answer about it.

You are trying to make it impossible to define the program, but that
just means your system is weaker, as programs that could be defined in
the basic system can't be in yours.

That you can't see that make YOU the one that is eitehr:
(a) a liar;
(b) delusional;
(c) stupid;
(d) ignorant of the facts for some reason.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 01 Aug 2025 09:54:18 -0400, Richard Damon wrote:

On 8/1/25 8:44 AM, Mr Flibble wrote:

On Fri, 01 Aug 2025 08:27:39 -0400, Richard Damon wrote:

On 8/1/25 8:00 AM, Mr Flibble wrote:

On Thu, 31 Jul 2025 19:19:00 -0400, Richard Damon wrote:

On 7/31/25 12:19 PM, Mr Flibble wrote:

On Thu, 31 Jul 2025 11:46:55 +0300, Mikko wrote:

On 2025-07-30 23:00:21 +0000, Mr Flibble said:

Here is 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 this necessitates extending the definition of a halt >>>>>>>> decider to return three rather than the tradition two results: >>>>>>>>
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.

This approach is valid if we recognise the presence of a category >>>>>>>> error at the heart of the halting problem's "Impossible Program" >>>>>>>> definition: a circular self referential infinitely recursive
conflation between a decider and its input: the sNaP signal being >>>>>>>> the result of the category error manifesting.

This method depends on the possibility of identifying a call to H. >>>>>>> If the input has a copy of H that is functionally equivalent but >>>>>>> encoded differently the identification of the pathology may fail >>>>>>> and H may fail to return.

There is no copy.

/Flibble

There is SUPPOSED to be one. Olcott misses it because he admits his
system isn't Turing Complete because he claims you can't make a copy >>>>> of his decider, even though he then does so to make HHH1.

That just shows he is just a pathological liar.

The type stratification as highlighted by the category error prevents
a copy of H being made and used by P.

/Flibble

But it isn't a category error, because you can't actually define the
categories in a usable manner, and they don't actually exist.

Rememver, Olcott is claiming to be working in a system equivalent to
Turing Machines, There is no restrictions in systems equivalent of
Turing Machines about making a copy of any given program.

So, all you are doing is admitting that you want to work in a system
weaker that Turing Machines, for which the halting problem has been
shown in many systems to be solvable, so your ideas aren't really
interesting until you show something new about them.

No, I am working in a STRONGER system than the system espoused by the
Halting Problem as my system actually enables rather than inhibits
program verification.

/Flibble

No, it is WEAKER, as you are restricting what a "program" can do.

You are trying to make program verification easier by limiting what a
program can do, that makes programs WEAKER.

It may make knowledge about them better, but their capabilities are
less.

A system which allows verification of programs is stronger than a system
which does not.

/Flibble

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 8/1/25 10:00 AM, Mr Flibble wrote:

On Fri, 01 Aug 2025 09:54:18 -0400, Richard Damon wrote:

On 8/1/25 8:44 AM, Mr Flibble wrote:

On Fri, 01 Aug 2025 08:27:39 -0400, Richard Damon wrote:

On 8/1/25 8:00 AM, Mr Flibble wrote:

On Thu, 31 Jul 2025 19:19:00 -0400, Richard Damon wrote:

On 7/31/25 12:19 PM, Mr Flibble wrote:

On Thu, 31 Jul 2025 11:46:55 +0300, Mikko wrote:

On 2025-07-30 23:00:21 +0000, Mr Flibble said:

Here is 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 this necessitates extending the definition of a halt >>>>>>>>> decider to return three rather than the tradition two results: >>>>>>>>>
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.

This approach is valid if we recognise the presence of a category >>>>>>>>> error at the heart of the halting problem's "Impossible Program" >>>>>>>>> definition: a circular self referential infinitely recursive >>>>>>>>> conflation between a decider and its input: the sNaP signal being >>>>>>>>> the result of the category error manifesting.

This method depends on the possibility of identifying a call to H. >>>>>>>> If the input has a copy of H that is functionally equivalent but >>>>>>>> encoded differently the identification of the pathology may fail >>>>>>>> and H may fail to return.

There is no copy.

/Flibble

There is SUPPOSED to be one. Olcott misses it because he admits his >>>>>> system isn't Turing Complete because he claims you can't make a copy >>>>>> of his decider, even though he then does so to make HHH1.

That just shows he is just a pathological liar.

The type stratification as highlighted by the category error prevents >>>>> a copy of H being made and used by P.

/Flibble

But it isn't a category error, because you can't actually define the
categories in a usable manner, and they don't actually exist.

Rememver, Olcott is claiming to be working in a system equivalent to
Turing Machines, There is no restrictions in systems equivalent of
Turing Machines about making a copy of any given program.

So, all you are doing is admitting that you want to work in a system
weaker that Turing Machines, for which the halting problem has been
shown in many systems to be solvable, so your ideas aren't really
interesting until you show something new about them.

No, I am working in a STRONGER system than the system espoused by the
Halting Problem as my system actually enables rather than inhibits
program verification.

/Flibble

No, it is WEAKER, as you are restricting what a "program" can do.

You are trying to make program verification easier by limiting what a
program can do, that makes programs WEAKER.

It may make knowledge about them better, but their capabilities are
less.

A system which allows verification of programs is stronger than a system which does not.

/Flibble

Yes, but weaker than the system that allows the creation of programs
that your system doesn't allow to be created because you couldn't
"verify" them with a program.

Sorry, but you just don't have a workable definition of the "power" of a system.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-08-01 11:42:35 +0000, Mr Flibble said:

On Fri, 01 Aug 2025 09:48:35 +0300, Mikko wrote:

On 2025-07-31 16:19:37 +0000, Mr Flibble said:

On Thu, 31 Jul 2025 11:46:55 +0300, Mikko wrote:

On 2025-07-30 23:00:21 +0000, Mr Flibble said:

Here is 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 this necessitates extending the definition of a halt
decider to return three rather than the tradition two results:

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.

This approach is valid if we recognise the presence of a category
error at the heart of the halting problem's "Impossible Program"
definition: a circular self referential infinitely recursive
conflation between a decider and its input: the sNaP signal being the >>>>> result of the category error manifesting.

This method depends on the possibility of identifying a call to H. If
the input has a copy of H that is functionally equivalent but encoded
differently the identification of the pathology may fail and H may
fail to return.

There is no copy.

There is when the code is copied.

The code of H cannot be copied and used by P due to type stratification as highlighted by the category error.

Text editors do not understand type stratification or category error and therefore do not prevent copying H.

--
Mikko

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)