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.



--
meet ever shorter deadlines, known as "beat the clock"

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

On 8/24/25 6:14 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.

Which fails as the input isn't "invalid", just one that this decider
can't determine, and thus while perhaps an "allowed" return value, its
"THE correct" return value, which, by definition, must be an objective
value which is the same for all deciders. Since other deciders can
determine this value, at least once you define what it means for the
decider to "reject" as opposed to returning a value, and how that
affects a machine being halting or not.

Note, The standard terminology for a decider is that it accepts inputs
that meet the requirements (in this case represent a haltng machine
halts) and rejects inputs that don't. So, you need to first define some
new terminology for you system.

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

On Sun, 24 Aug 2025 18:21:14 -0400, Richard Damon wrote:

On 8/24/25 6:14 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.

Which fails as the input isn't "invalid", just one that this decider
can't determine, and thus while perhaps an "allowed" return value, its
"THE correct" return value, which, by definition, must be an objective
value which is the same for all deciders. Since other deciders can
determine this value, at least once you define what it means for the
decider to "reject" as opposed to returning a value, and how that
affects a machine being halting or not.

Note, The standard terminology for a decider is that it accepts inputs
that meet the requirements (in this case represent a haltng machine
halts) and rejects inputs that don't. So, you need to first define some
new terminology for you system.

You can think of my SSHD as a "DD", a "Diagonalization Detector". :D

/Flibble



--
meet ever shorter deadlines, known as "beat the clock"

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

On 8/24/25 6:36 PM, Mr Flibble wrote:

On Sun, 24 Aug 2025 18:21:14 -0400, Richard Damon wrote:

On 8/24/25 6:14 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.

Which fails as the input isn't "invalid", just one that this decider
can't determine, and thus while perhaps an "allowed" return value, its
"THE correct" return value, which, by definition, must be an objective
value which is the same for all deciders. Since other deciders can
determine this value, at least once you define what it means for the
decider to "reject" as opposed to returning a value, and how that
affects a machine being halting or not.

Note, The standard terminology for a decider is that it accepts inputs
that meet the requirements (in this case represent a haltng machine
halts) and rejects inputs that don't. So, you need to first define some
new terminology for you system.

You can think of my SSHD as a "DD", a "Diagonalization Detector". :D

/Flibble

So, how do you define how it answers?

It seems you don't understand the question.

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

On Sun, 24 Aug 2025 18:57:58 -0400, Richard Damon wrote:

On 8/24/25 6:36 PM, Mr Flibble wrote:

On Sun, 24 Aug 2025 18:21:14 -0400, Richard Damon wrote:

On 8/24/25 6:14 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.

Which fails as the input isn't "invalid", just one that this decider
can't determine, and thus while perhaps an "allowed" return value, its
"THE correct" return value, which, by definition, must be an objective
value which is the same for all deciders. Since other deciders can
determine this value, at least once you define what it means for the
decider to "reject" as opposed to returning a value, and how that
affects a machine being halting or not.

Note, The standard terminology for a decider is that it accepts inputs
that meet the requirements (in this case represent a haltng machine
halts) and rejects inputs that don't. So, you need to first define
some new terminology for you system.

You can think of my SSHD as a "DD", a "Diagonalization Detector". :D

/Flibble

So, how do you define how it answers?

It seems you don't understand the question.

Your shtick is becoming rather monotonous, mate.

/Flibble



--
meet ever shorter deadlines, known as "beat the clock"

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

On 8/24/25 7:03 PM, Mr Flibble wrote:

On Sun, 24 Aug 2025 18:57:58 -0400, Richard Damon wrote:

On 8/24/25 6:36 PM, Mr Flibble wrote:

On Sun, 24 Aug 2025 18:21:14 -0400, Richard Damon wrote:

On 8/24/25 6:14 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.

Which fails as the input isn't "invalid", just one that this decider
can't determine, and thus while perhaps an "allowed" return value, its >>>> "THE correct" return value, which, by definition, must be an objective >>>> value which is the same for all deciders. Since other deciders can
determine this value, at least once you define what it means for the
decider to "reject" as opposed to returning a value, and how that
affects a machine being halting or not.

Note, The standard terminology for a decider is that it accepts inputs >>>> that meet the requirements (in this case represent a haltng machine
halts) and rejects inputs that don't. So, you need to first define
some new terminology for you system.

You can think of my SSHD as a "DD", a "Diagonalization Detector". :D

/Flibble

So, how do you define how it answers?

It seems you don't understand the question.

Your shtick is becoming rather monotonous, mate.

/Flibble

Truth sometimes is.

There are requirements to meet to define a new system, and if you don't
them, you can't define a new thing,

Your concept has the same problem as Olcott's in that it seems to need non-compuations as things its works on, and thus isn't part of
Computability Theory, which works in the domain of Computations.

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

On 2025-08-24 22:14:26 +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.

That is a partial halt simulator. It probably gets stuck in a loop if
the computation does not halt and does not repeat any pattern.

--
Mikko

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