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>When we make HHH an integral part of the operating system that checks
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 failure of a simulator to reach the final halt state is not a
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.
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.
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.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,090 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 63:14:19 |
| Calls: | 13,949 |
| Calls today: | 2 |
| Files: | 187,035 |
| D/L today: |
3,464 files (1,014M bytes) |
| Messages: | 2,461,403 |