From Newsgroup: comp.theory

On 9/19/2025 8:22 PM, vallor wrote:

On Fri, 19 Sep 2025 10:02:58 -0500, olcott <polcott333@gmail.com> wrote in <10ajrb4$ik2f$1@dont-email.me>:

On 9/19/2025 5:31 AM, vallor wrote:

On Fri, 19 Sep 2025 10:49:15 +0200, "Fred. Zwarts" <F.Zwarts@HetNet.nl>
wrote in <10aj5ea$cf6i$5@dont-email.me>:

Op 19.sep.2025 om 03:51 schreef olcott:

On 9/18/2025 8:38 PM, Kaz Kylheku wrote:
The pattern that you outlined is exactly the same as the recursion
depth of mutual recursion.

It is easy to cheat and come to some other fake conclusion. No other >>>>> correct conclusion exists.

The failure of a simulator to reach the final halt state is not a
proof for non-termination behaviour.

In particular when other simulators have proven that the exact same
input specifies a program for which the final halt state can be
reached.
That is true for the HHH that aborts after two cycles of recursion.
What we see is that 1) If HHH does not abort, it does not provide any
answer,
so it fails. 2) If HHH does abort, it aborts prematurely, because the
input has changed. A correct simulation would reach the final halt
state one cycle later. It is incorrect for HHH to report on another
hypothetical input with a different finite string that include the HHH >>>> that does not abort.
It mus abort on the input that includes the HHH that aborts.

You confuse your self by not clearly separating the input and the code >>>> of the decider. But a TM cannot report about another TM, so the full
program, DDD including all functions called by it directly or
indirectly, in particular including the HHH called by DDD, must be
part of the input.

By George, I think this is the crux of Olcott's confusion. I know you
all understand this, but I don't think Peter does:

Ignoring for a second that the "machine string" he's passing to HHH()
is a pointer, consider the string to which the pointer points: it is a
function that includes a call to HHH(). So a good chunk of HHH() is
part of the input string, including the parts that cause the actual
paradox: DD() halts, because it has "decided" (incorrectly) that it
doesn't halt. But it does, because it includes the code from HHH.

Peter, If you run DD() by itself, it halts -- and let's not hear
anymore of this talk about HHH() and DD() being none of each other's
business, because the code for DD() includes the code for HHH(),
standalone or otherwise.

When we make HHH an integral part of the operating system that checks
every function called from main() then yet again main-->DD() is rejected
as non-halting.
main-->DD() has always specified the equivalent of infinite recursion.

But DD() includes the specification of HHH(DD) (by reference) -- ignoring
the results of HHH(DD) isn't allowed.

Consider the call to HHH() if it were inlined. You have a considerable
chunk of your halt decider guts as part of the DD input string. You
can't ignore that and hand-wave it away -- and that is the crux of the matter: you continue to ignore a very large chunk of the input string.

When HHH sees it right away it says it right away. When HHH does not see
it until the second recursive call then it makes it looks like
main-->DD() halted on its own without intervention.

It did halt on its own, because DD() calls HHH(), which points to a considerable amount of code that you seem to be hand-waving away.

Everyone here knows that intervention was required or main-->DD() would
have never halted yet ignore this so that they can remain in
disagreement mode.

Actually, everyone can see (even me) that that-which-is-referred-to-by
HHH is part of the input string DD. You can't ignore that.

What I did figure out (by putting myself in your shoes) is that you apparently don't consider that-which-is-referred-to by HHH as part
of (that-which-is-referred-to-by) DD.

Crudely, the input string DD contains the contents of HHH. You
can't ignore that.

int P()
{
int Halt_Status = H(P);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}

int main()
{
H(P);
return 0;
}

While DD is simulated by HHH according to the
semantics of the C programing language the
simulated DD cannot possibly reach its own
simulated "return" statement final halt state.
--
Copyright 2025 Olcott<br><br>

My 28 year goal has been to make <br>
"true on the basis of meaning expressed in language"<br>
reliably computable.<br><br>

This required establishing a new foundation<br>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 12/18/25 3:02 AM, olcott wrote:

On 9/19/2025 8:22 PM, vallor wrote:

On Fri, 19 Sep 2025 10:02:58 -0500, olcott <polcott333@gmail.com>
wrote in
<10ajrb4$ik2f$1@dont-email.me>:

On 9/19/2025 5:31 AM, vallor wrote:

On Fri, 19 Sep 2025 10:49:15 +0200, "Fred. Zwarts" <F.Zwarts@HetNet.nl> >>>> wrote in <10aj5ea$cf6i$5@dont-email.me>:

Op 19.sep.2025 om 03:51 schreef olcott:

On 9/18/2025 8:38 PM, Kaz Kylheku wrote:
The pattern that you outlined is exactly the same as the recursion >>>>>> depth of mutual recursion.

It is easy to cheat and come to some other fake conclusion. No other >>>>>> correct conclusion exists.

The failure of a simulator to reach the final halt state is not a
proof for non-termination behaviour.

In particular when other simulators have proven that the exact same
input specifies a program for which the final halt state can be
reached.
That is true for the HHH that aborts after two cycles of recursion.
What we see is that 1) If HHH does not abort, it does not provide any >>>>> answer,
so it fails. 2) If HHH does abort, it aborts prematurely, because the >>>>> input has changed. A correct simulation would reach the final halt
state one cycle later. It is incorrect for HHH to report on another
hypothetical input with a different finite string that include the HHH >>>>> that does not abort.
It mus abort on the input that includes the HHH that aborts.

You confuse your self by not clearly separating the input and the code >>>>> of the decider. But a TM cannot report about another TM, so the full >>>>> program, DDD including all functions called by it directly or
indirectly, in particular including the HHH called by DDD, must be
part of the input.

By George, I think this is the crux of Olcott's confusion.  I know you >>>> all understand this, but I don't think Peter does:

Ignoring for a second that the "machine string" he's passing to HHH()
is a pointer, consider the string to which the pointer points:  it is a >>>> function that includes a call to HHH().  So a good chunk of HHH() is
part of the input string, including the parts that cause the actual
paradox:  DD() halts, because it has "decided" (incorrectly) that it
doesn't halt.  But it does, because it includes the code from HHH.

Peter, If you run DD() by itself, it halts -- and let's not hear
anymore of this talk about HHH() and DD() being none of each other's
business, because the code for DD() includes the code for HHH(),
standalone or otherwise.

When we make HHH an integral part of the operating system that checks
every function called from main() then yet again main-->DD() is rejected >>> as non-halting.
main-->DD() has always specified the equivalent of infinite recursion.

But DD() includes the specification of HHH(DD) (by reference) -- ignoring
the results of HHH(DD) isn't allowed.

Consider the call to HHH() if it were inlined.  You have a considerable
chunk of your halt decider guts as part of the DD input string.  You
can't ignore that and hand-wave it away -- and that is the crux of the
matter:  you continue to ignore a very large chunk of the input string.

When HHH sees it right away it says it right away. When HHH does not see >>> it until the second recursive call then it makes it looks like
main-->DD() halted on its own without intervention.

It did halt on its own, because DD() calls HHH(), which points to a
considerable amount of code that you seem to be hand-waving away.

Everyone here knows that intervention was required or main-->DD() would
have never halted yet ignore this so that they can remain in
disagreement mode.

Actually, everyone can see (even me) that that-which-is-referred-to-by
HHH is part of the input string DD.  You can't ignore that.

What I did figure out (by putting myself in your shoes) is that you
apparently don't consider that-which-is-referred-to by HHH as part
of (that-which-is-referred-to-by) DD.

Crudely, the input string DD contains the contents of HHH.  You
can't ignore that.

int P()
{
  int Halt_Status = H(P);
  if (Halt_Status)
    HERE: goto HERE;
  return Halt_Status;
}

int main()
{
  H(P);
  return 0;
}

While DD is simulated by HHH according to the
semantics of the C programing language the
simulated DD cannot possibly reach its own
simulated "return" statement final halt state.

But your P doesn't have a defined behavior by the C programming
langugae, as it is missing the C definition of H. and thus your are just showing you are a liar.

Your problem is you have two different meaning for your words, and thus
you are just lying by equivocation.

Either your H/HHH is just a simultor, at which point it fails to be the
halt decider you claim, or it isn't a UTM equivalent, so its failure to
reach a final state isn't determination for the halting property of its
input.

Your claim is isomoprhic to claiming a road is infinitely long, because
you drove on it a mile then got off, and you never saw the other end.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 12/18/2025 6:22 AM, Richard Damon wrote:

On 12/18/25 3:02 AM, olcott wrote:

On 9/19/2025 8:22 PM, vallor wrote:

On Fri, 19 Sep 2025 10:02:58 -0500, olcott <polcott333@gmail.com>
wrote in
<10ajrb4$ik2f$1@dont-email.me>:

On 9/19/2025 5:31 AM, vallor wrote:

On Fri, 19 Sep 2025 10:49:15 +0200, "Fred. Zwarts"
<F.Zwarts@HetNet.nl>
wrote in <10aj5ea$cf6i$5@dont-email.me>:

Op 19.sep.2025 om 03:51 schreef olcott:

On 9/18/2025 8:38 PM, Kaz Kylheku wrote:
The pattern that you outlined is exactly the same as the recursion >>>>>>> depth of mutual recursion.

It is easy to cheat and come to some other fake conclusion. No other >>>>>>> correct conclusion exists.

The failure of a simulator to reach the final halt state is not a
proof for non-termination behaviour.

In particular when other simulators have proven that the exact same >>>>>> input specifies a program for which the final halt state can be
reached.
That is true for the HHH that aborts after two cycles of recursion. >>>>>> What we see is that 1) If HHH does not abort, it does not provide any >>>>>> answer,
so it fails. 2) If HHH does abort, it aborts prematurely, because the >>>>>> input has changed. A correct simulation would reach the final halt >>>>>> state one cycle later. It is incorrect for HHH to report on another >>>>>> hypothetical input with a different finite string that include the >>>>>> HHH
that does not abort.
It mus abort on the input that includes the HHH that aborts.

You confuse your self by not clearly separating the input and the >>>>>> code
of the decider. But a TM cannot report about another TM, so the full >>>>>> program, DDD including all functions called by it directly or
indirectly, in particular including the HHH called by DDD, must be >>>>>> part of the input.

By George, I think this is the crux of Olcott's confusion.  I know you >>>>> all understand this, but I don't think Peter does:

Ignoring for a second that the "machine string" he's passing to HHH() >>>>> is a pointer, consider the string to which the pointer points:  it >>>>> is a
function that includes a call to HHH().  So a good chunk of HHH() is >>>>> part of the input string, including the parts that cause the actual
paradox:  DD() halts, because it has "decided" (incorrectly) that it >>>>> doesn't halt.  But it does, because it includes the code from HHH.

Peter, If you run DD() by itself, it halts -- and let's not hear
anymore of this talk about HHH() and DD() being none of each other's >>>>> business, because the code for DD() includes the code for HHH(),
standalone or otherwise.

When we make HHH an integral part of the operating system that checks
every function called from main() then yet again main-->DD() is
rejected
as non-halting.
main-->DD() has always specified the equivalent of infinite recursion.

But DD() includes the specification of HHH(DD) (by reference) --
ignoring
the results of HHH(DD) isn't allowed.

Consider the call to HHH() if it were inlined.  You have a considerable >>> chunk of your halt decider guts as part of the DD input string.  You
can't ignore that and hand-wave it away -- and that is the crux of the
matter:  you continue to ignore a very large chunk of the input string. >>>

When HHH sees it right away it says it right away. When HHH does not
see
it until the second recursive call then it makes it looks like
main-->DD() halted on its own without intervention.

It did halt on its own, because DD() calls HHH(), which points to a
considerable amount of code that you seem to be hand-waving away.

Everyone here knows that intervention was required or main-->DD() would >>>> have never halted yet ignore this so that they can remain in
disagreement mode.

Actually, everyone can see (even me) that that-which-is-referred-to-by
HHH is part of the input string DD.  You can't ignore that.

What I did figure out (by putting myself in your shoes) is that you
apparently don't consider that-which-is-referred-to by HHH as part
of (that-which-is-referred-to-by) DD.

Crudely, the input string DD contains the contents of HHH.  You
can't ignore that.

int P()
{
   int Halt_Status = H(P);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

int main()
{
   H(P);
   return 0;
}

While DD is simulated by HHH according to the
semantics of the C programing language the
simulated DD cannot possibly reach its own
simulated "return" statement final halt state.

But your P doesn't have a defined behavior by the C programming
langugae, as it is missing the C definition of H. and thus your are just showing you are a liar.

While P is simulated by H according to the
semantics of the C programing language the
simulated D cannot possibly reach its own
simulated "return" statement final halt state.

All that we need to know about H is that
it simulates P according to the semantics
of the C programing language.

Your problem is you have two different meaning for your words, and thus
you are just lying by equivocation.

Either your H/HHH is just a simultor, at which point it fails to be the
halt decider you claim, or it isn't a UTM equivalent, so its failure to reach a final state isn't determination for the halting property of its input.

Your claim is isomoprhic to claiming a road is infinitely long, because
you drove on it a mile then got off, and you never saw the other end.

--
Copyright 2025 Olcott<br><br>

My 28 year goal has been to make <br>
"true on the basis of meaning expressed in language"<br>
reliably computable.<br><br>

This required establishing a new foundation<br>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 12/18/25 7:48 AM, olcott wrote:

On 12/18/2025 6:22 AM, Richard Damon wrote:

On 12/18/25 3:02 AM, olcott wrote:

On 9/19/2025 8:22 PM, vallor wrote:

On Fri, 19 Sep 2025 10:02:58 -0500, olcott <polcott333@gmail.com>
wrote in
<10ajrb4$ik2f$1@dont-email.me>:

On 9/19/2025 5:31 AM, vallor wrote:

On Fri, 19 Sep 2025 10:49:15 +0200, "Fred. Zwarts"
<F.Zwarts@HetNet.nl>
wrote in <10aj5ea$cf6i$5@dont-email.me>:

Op 19.sep.2025 om 03:51 schreef olcott:

On 9/18/2025 8:38 PM, Kaz Kylheku wrote:
The pattern that you outlined is exactly the same as the recursion >>>>>>>> depth of mutual recursion.

It is easy to cheat and come to some other fake conclusion. No >>>>>>>> other
correct conclusion exists.

The failure of a simulator to reach the final halt state is not a >>>>>>> proof for non-termination behaviour.

In particular when other simulators have proven that the exact same >>>>>>> input specifies a program for which the final halt state can be
reached.
That is true for the HHH that aborts after two cycles of recursion. >>>>>>> What we see is that 1) If HHH does not abort, it does not provide >>>>>>> any
answer,
so it fails. 2) If HHH does abort, it aborts prematurely, because >>>>>>> the
input has changed. A correct simulation would reach the final halt >>>>>>> state one cycle later. It is incorrect for HHH to report on another >>>>>>> hypothetical input with a different finite string that include
the HHH
that does not abort.
It mus abort on the input that includes the HHH that aborts.

You confuse your self by not clearly separating the input and the >>>>>>> code
of the decider. But a TM cannot report about another TM, so the full >>>>>>> program, DDD including all functions called by it directly or
indirectly, in particular including the HHH called by DDD, must be >>>>>>> part of the input.

By George, I think this is the crux of Olcott's confusion.  I know >>>>>> you
all understand this, but I don't think Peter does:

Ignoring for a second that the "machine string" he's passing to HHH() >>>>>> is a pointer, consider the string to which the pointer points:  it >>>>>> is a
function that includes a call to HHH().  So a good chunk of HHH() is >>>>>> part of the input string, including the parts that cause the actual >>>>>> paradox:  DD() halts, because it has "decided" (incorrectly) that it >>>>>> doesn't halt.  But it does, because it includes the code from HHH. >>>>>>
Peter, If you run DD() by itself, it halts -- and let's not hear
anymore of this talk about HHH() and DD() being none of each other's >>>>>> business, because the code for DD() includes the code for HHH(),
standalone or otherwise.

When we make HHH an integral part of the operating system that checks >>>>> every function called from main() then yet again main-->DD() is
rejected
as non-halting.
main-->DD() has always specified the equivalent of infinite recursion. >>>>

But DD() includes the specification of HHH(DD) (by reference) --
ignoring
the results of HHH(DD) isn't allowed.

Consider the call to HHH() if it were inlined.  You have a considerable >>>> chunk of your halt decider guts as part of the DD input string.  You
can't ignore that and hand-wave it away -- and that is the crux of the >>>> matter:  you continue to ignore a very large chunk of the input string. >>>>

When HHH sees it right away it says it right away. When HHH does
not see
it until the second recursive call then it makes it looks like
main-->DD() halted on its own without intervention.

It did halt on its own, because DD() calls HHH(), which points to a
considerable amount of code that you seem to be hand-waving away.

Everyone here knows that intervention was required or main-->DD()
would
have never halted yet ignore this so that they can remain in
disagreement mode.

Actually, everyone can see (even me) that that-which-is-referred-to-by >>>> HHH is part of the input string DD.  You can't ignore that.

What I did figure out (by putting myself in your shoes) is that you
apparently don't consider that-which-is-referred-to by HHH as part
of (that-which-is-referred-to-by) DD.

Crudely, the input string DD contains the contents of HHH.  You
can't ignore that.

int P()
{
   int Halt_Status = H(P);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

int main()
{
   H(P);
   return 0;
}

While DD is simulated by HHH according to the
semantics of the C programing language the
simulated DD cannot possibly reach its own
simulated "return" statement final halt state.

But your P doesn't have a defined behavior by the C programming
langugae, as it is missing the C definition of H. and thus your are
just showing you are a liar.

While P is simulated by H according to the
semantics of the C programing language the
simulated D cannot possibly reach its own
simulated "return" statement final halt state.

But your H doesn't do that. All you are doing is proving you lie and
don't know what you are talking about.

All that we need to know about H is that
it simulates P according to the semantics
of the C programing language.

And thus that *IS* what it is, and thus your H can never answer, and
thus isn't a decider.

You can not have two different definitions for your H, one that is the
correct simulator, and another that is a decider that uses the other to
decide to abort.

It seems that in your logic, two DIFFERENT things are also the SAME, and
thus your logic is just a great big lie.

Your problem is you have two different meaning for your words, and
thus you are just lying by equivocation.

Either your H/HHH is just a simultor, at which point it fails to be
the halt decider you claim, or it isn't a UTM equivalent, so its
failure to reach a final state isn't determination for the halting
property of its input.

Your claim is isomoprhic to claiming a road is infinitely long,
because you drove on it a mile then got off, and you never saw the
other end.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 12/18/25 7:48 AM, olcott wrote:

On 12/18/2025 6:22 AM, Richard Damon wrote:

On 12/18/25 3:02 AM, olcott wrote:

On 9/19/2025 8:22 PM, vallor wrote:

On Fri, 19 Sep 2025 10:02:58 -0500, olcott <polcott333@gmail.com>
wrote in
<10ajrb4$ik2f$1@dont-email.me>:

On 9/19/2025 5:31 AM, vallor wrote:

On Fri, 19 Sep 2025 10:49:15 +0200, "Fred. Zwarts"
<F.Zwarts@HetNet.nl>
wrote in <10aj5ea$cf6i$5@dont-email.me>:

Op 19.sep.2025 om 03:51 schreef olcott:

On 9/18/2025 8:38 PM, Kaz Kylheku wrote:
The pattern that you outlined is exactly the same as the recursion >>>>>>>> depth of mutual recursion.

It is easy to cheat and come to some other fake conclusion. No >>>>>>>> other
correct conclusion exists.

The failure of a simulator to reach the final halt state is not a >>>>>>> proof for non-termination behaviour.

In particular when other simulators have proven that the exact same >>>>>>> input specifies a program for which the final halt state can be
reached.
That is true for the HHH that aborts after two cycles of recursion. >>>>>>> What we see is that 1) If HHH does not abort, it does not provide >>>>>>> any
answer,
so it fails. 2) If HHH does abort, it aborts prematurely, because >>>>>>> the
input has changed. A correct simulation would reach the final halt >>>>>>> state one cycle later. It is incorrect for HHH to report on another >>>>>>> hypothetical input with a different finite string that include
the HHH
that does not abort.
It mus abort on the input that includes the HHH that aborts.

You confuse your self by not clearly separating the input and the >>>>>>> code
of the decider. But a TM cannot report about another TM, so the full >>>>>>> program, DDD including all functions called by it directly or
indirectly, in particular including the HHH called by DDD, must be >>>>>>> part of the input.

By George, I think this is the crux of Olcott's confusion.  I know >>>>>> you
all understand this, but I don't think Peter does:

Ignoring for a second that the "machine string" he's passing to HHH() >>>>>> is a pointer, consider the string to which the pointer points:  it >>>>>> is a
function that includes a call to HHH().  So a good chunk of HHH() is >>>>>> part of the input string, including the parts that cause the actual >>>>>> paradox:  DD() halts, because it has "decided" (incorrectly) that it >>>>>> doesn't halt.  But it does, because it includes the code from HHH. >>>>>>
Peter, If you run DD() by itself, it halts -- and let's not hear
anymore of this talk about HHH() and DD() being none of each other's >>>>>> business, because the code for DD() includes the code for HHH(),
standalone or otherwise.

When we make HHH an integral part of the operating system that checks >>>>> every function called from main() then yet again main-->DD() is
rejected
as non-halting.
main-->DD() has always specified the equivalent of infinite recursion. >>>>

But DD() includes the specification of HHH(DD) (by reference) --
ignoring
the results of HHH(DD) isn't allowed.

Consider the call to HHH() if it were inlined.  You have a considerable >>>> chunk of your halt decider guts as part of the DD input string.  You
can't ignore that and hand-wave it away -- and that is the crux of the >>>> matter:  you continue to ignore a very large chunk of the input string. >>>>

When HHH sees it right away it says it right away. When HHH does
not see
it until the second recursive call then it makes it looks like
main-->DD() halted on its own without intervention.

It did halt on its own, because DD() calls HHH(), which points to a
considerable amount of code that you seem to be hand-waving away.

Everyone here knows that intervention was required or main-->DD()
would
have never halted yet ignore this so that they can remain in
disagreement mode.

Actually, everyone can see (even me) that that-which-is-referred-to-by >>>> HHH is part of the input string DD.  You can't ignore that.

What I did figure out (by putting myself in your shoes) is that you
apparently don't consider that-which-is-referred-to by HHH as part
of (that-which-is-referred-to-by) DD.

Crudely, the input string DD contains the contents of HHH.  You
can't ignore that.

int P()
{
   int Halt_Status = H(P);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

int main()
{
   H(P);
   return 0;
}

While DD is simulated by HHH according to the
semantics of the C programing language the
simulated DD cannot possibly reach its own
simulated "return" statement final halt state.

But your P doesn't have a defined behavior by the C programming
langugae, as it is missing the C definition of H. and thus your are
just showing you are a liar.

While P is simulated by H according to the
semantics of the C programing language the
simulated D cannot possibly reach its own
simulated "return" statement final halt state.

All that we need to know about H is that
it simulates P according to the semantics
of the C programing language.

And thus that your H can't be a halt decider as it didn't answer for
this input.

You can't change H, or you are changing the input, as the input contains
the exact specification of what H is. If you change that, then you no
longer have the needed input for your final H.

Sorry, you are just showing that you are a liar.

Your problem is you have two different meaning for your words, and
thus you are just lying by equivocation.

Either your H/HHH is just a simultor, at which point it fails to be
the halt decider you claim, or it isn't a UTM equivalent, so its
failure to reach a final state isn't determination for the halting
property of its input.

Your claim is isomoprhic to claiming a road is infinitely long,
because you drove on it a mile then got off, and you never saw the
other end.

--- Synchronet 3.21a-Linux NewsLink 1.2