| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 23 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 52:09:14 |
| Calls: | 583 |
| Files: | 1,139 |
| Messages: | 111,532 |
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that computes it. >>
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
On 2025-08-26, olcott <polcott333@gmail.com> wrote:
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that computes it. >>>
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
Turing machines do not have a caller.
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that
computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
Thus HHH(DD) is not supposed to report on the behavior
of its caller because its caller *IS NOT ITS INPUT*
Thus we know that HHH is not a halt decider.
No we know that you can't bake a cake in a blender
because blenders are not made for baking cakes.
Deciders are not made to report on non-inputs.
On 8/26/2025 4:39 PM, Kaz Kylheku wrote:
On 2025-08-26, olcott <polcott333@gmail.com> wrote:
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
Turing machines do not have a caller.
Turing Machine Linz -n applied to its own machine description rf?-nrf-
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR
if rf?-nrf- rf?-nrf- simulated by -n.embedded_H reaches
its simulated final halt state of rf?-n.qnrf-, and
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
Thus HHH(DD) is not supposed to report on the behavior
of its caller because its caller *IS NOT ITS INPUT*
Thus we know that HHH is not a halt decider.
No we know that you can't bake a cake in a blender
because blenders are not made for baking cakes.
Deciders are not made to report on non-inputs.
On 2025-08-26 16:29:41 +0000, olcott said:
No we know that you can't bake a cake in a blender
because blenders are not made for baking cakes.
Deciders are not made to report on non-inputs.
Requirements for a new blender may specify that it must be possible
to bake a cake in that new blender.
On 2025-08-26, olcott <polcott333@gmail.com> wrote:
On 8/26/2025 4:39 PM, Kaz Kylheku wrote:
On 2025-08-26, olcott <polcott333@gmail.com> wrote:
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
Turing machines do not have a caller.
Turing Machine Linz -n applied to its own machine description rf?-nrf-
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR
if rf?-nrf- rf?-nrf- simulated by -n.embedded_H reaches
its simulated final halt state of rf?-n.qnrf-, and
I can't follow this gobbledyook. Or, well, /you/ can't; I merely won't.
Given your track record with the simple version of Halting
based on easy-to-follow functional notation, I'm not confident that you
can work with Linz's version.
But anyway, Turing machines do not have a caller. They just exist. They
are a tape with certain contents, a head mechanism understood to be at
an initial position, and a set of rules governing what the head does.
That's what a Turing Machine /is/. It also /denotes/ something. Some
Turing machines denote a final state in which the tape has certain
different contents; if you follow the rules and simulate the tape
alterations and head movements, you will arrive at that content that the
TM denotes. Other TMs do not denote a final tape content because they
don't halt. They denote a non-halting computation whose tape is
forever changing, but doesn't settle on a final content.
On 2025-08-26 16:29:41 +0000, olcott said:
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that
computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
However, a requirement may define the required mapping in terms of the behaviour (or other properties) of some Turing machine.
Thus HHH(DD) is not supposed to report on the behavior
of its caller because its caller *IS NOT ITS INPUT*
Thus we know that HHH is not a halt decider.
No we know that you can't bake a cake in a blender
because blenders are not made for baking cakes.
Deciders are not made to report on non-inputs.
Requirements for a new blender may specify that it must be possible
to bake a cake in that new blender.
Sure and we can say that TM Y is required
to provide the square-root of a dead squirrel.
On 27/08/2025 16:09, olcott wrote:
<snip>
Sure and we can say that TM Y is required
to provide the square-root of a dead squirrel.
You have failed to make a case for a TM being unable to read and process
a tape. Squirrels are not tapes.
On 8/27/2025 10:30 AM, Richard Heathfield wrote:
On 27/08/2025 16:09, olcott wrote:
<snip>
Sure and we can say that TM Y is required
to provide the square-root of a dead squirrel.
You have failed to make a case for a TM being unable to read
and process a tape. Squirrels are not tapes.
M.q0 rf?Mrf- reo* M.embedded_H rf?Mrf- rf?Mrf- reo* M.reR,
if M applied to rf?Mrf- halts, and
M.q0 rf?Mrf- reo* M.embedded_H rf?Mrf- rf?Mrf- reo* M.qn
if M applied to rf?Mrf- does not halt.
M.embedded_H cannot report on the behavior of its
caller machine M because no TM can take another
actual TM as its input.
M.embedded_H can report on the non-halting
behavior of its input in that rf?Mrf- rf?Mrf- correctly
simulated by M.embedded_H cannot possibly reach
its own simulated final halt state of rf?M.qnrf-
On 27/08/2025 16:40, olcott wrote:
On 8/27/2025 10:30 AM, Richard Heathfield wrote:
On 27/08/2025 16:09, olcott wrote:
<snip>
Sure and we can say that TM Y is required
to provide the square-root of a dead squirrel.
You have failed to make a case for a TM being unable to read and
process a tape. Squirrels are not tapes.
M.q0 rf?Mrf- reo* M.embedded_H rf?Mrf- rf?Mrf- reo* M.reR,
if M applied to rf?Mrf- halts, and
M.q0 rf?Mrf- reo* M.embedded_H rf?Mrf- rf?Mrf- reo* M.qn
if M applied to rf?Mrf- does not halt.
M.embedded_H cannot report on the behavior of its
caller machine M because no TM can take another
actual TM as its input.
M.embedded_H can report on the non-halting
behavior of its input in that rf?Mrf- rf?Mrf- correctly
simulated by M.embedded_H cannot possibly reach
its own simulated final halt state of rf?M.qnrf-
That is not a case for a TM being unable to read and process a tape.
Assume you can write a universal halt decider.
If you can do that, you can use it to construct a program that it cannot decide.
Therefore the assumption (that you can write a universal halt decider)
is wrong, because there is at least one program it can't decide.
QED.
On 8/27/2025 3:05 AM, Mikko wrote:
However, a requirement may define the required mapping in terms of the
behaviour (or other properties) of some Turing machine.
Sure and we can say that TM Y is required
to provide the square-root of a dead squirrel.
On 5/5/2025 4:31 PM, dbush wrote:
Strawman. The square root of a dead rabbit does not exist, but the
question of whether any arbitrary algorithm X with input Y halts when
executed directly has a correct answer in all cases.
It has a correct answer that cannot ever be computed
On 8/27/2025 10:30 AM, Richard Heathfield wrote:
On 27/08/2025 16:09, olcott wrote:
<snip>
Sure and we can say that TM Y is required
to provide the square-root of a dead squirrel.
You have failed to make a case for a TM being unable to read and
process a tape. Squirrels are not tapes.
M.q0 rf?Mrf- reo* M.embedded_H rf?Mrf- rf?Mrf- reo* M.reR,
if M applied to rf?Mrf- halts, and
M.q0 rf?Mrf- reo* M.embedded_H rf?Mrf- rf?Mrf- reo* M.qn
if M applied to rf?Mrf- does not halt.
M.embedded_H cannot report on the behavior of its
caller machine M because no TM can take another
actual TM as its input.
On 8/27/2025 10:50 AM, Richard Heathfield wrote:
On 27/08/2025 16:40, olcott wrote:
On 8/27/2025 10:30 AM, Richard Heathfield wrote:
On 27/08/2025 16:09, olcott wrote:
<snip>
Sure and we can say that TM Y is required
to provide the square-root of a dead squirrel.
You have failed to make a case for a TM being unable to read
and process a tape. Squirrels are not tapes.
M.q0 rf?Mrf- reo* M.embedded_H rf?Mrf- rf?Mrf- reo* M.reR,
if M applied to rf?Mrf- halts, and
M.q0 rf?Mrf- reo* M.embedded_H rf?Mrf- rf?Mrf- reo* M.qn
if M applied to rf?Mrf- does not halt.
M.embedded_H cannot report on the behavior of its
caller machine M because no TM can take another
actual TM as its input.
M.embedded_H can report on the non-halting
behavior of its input in that rf?Mrf- rf?Mrf- correctly
simulated by M.embedded_H cannot possibly reach
its own simulated final halt state of rf?M.qnrf-
That is not a case for a TM being unable to read and process a
tape.
Assume you can write a universal halt decider.
That correctly determines the halt status specified
by its inputs. Then the Linz proof does not show that
such a decider does not exist.
On 27/08/2025 17:07, olcott wrote:
On 8/27/2025 10:50 AM, Richard Heathfield wrote:
On 27/08/2025 16:40, olcott wrote:
On 8/27/2025 10:30 AM, Richard Heathfield wrote:
On 27/08/2025 16:09, olcott wrote:
<snip>
Sure and we can say that TM Y is required
to provide the square-root of a dead squirrel.
You have failed to make a case for a TM being unable to read and
process a tape. Squirrels are not tapes.
M.q0 rf?Mrf- reo* M.embedded_H rf?Mrf- rf?Mrf- reo* M.reR,
if M applied to rf?Mrf- halts, and
M.q0 rf?Mrf- reo* M.embedded_H rf?Mrf- rf?Mrf- reo* M.qn
if M applied to rf?Mrf- does not halt.
M.embedded_H cannot report on the behavior of its
caller machine M because no TM can take another
actual TM as its input.
M.embedded_H can report on the non-halting
behavior of its input in that rf?Mrf- rf?Mrf- correctly
simulated by M.embedded_H cannot possibly reach
its own simulated final halt state of rf?M.qnrf-
That is not a case for a TM being unable to read and process a tape.
Assume you can write a universal halt decider.
That correctly determines the halt status specified
by its inputs. Then the Linz proof does not show that
such a decider does not exist.
Yes it does, and on the way he scuppers simulation. No wonder you don't
like him.
On 8/27/2025 10:50 AM, Richard Heathfield wrote:It can still compute what it would do when executed.
On 27/08/2025 16:40, olcott wrote:
On 8/27/2025 10:30 AM, Richard Heathfield wrote:
On 27/08/2025 16:09, olcott wrote:
You have failed to make a case for a TM being unable to read and
process a tape.
M.embedded_H cannot report on the behavior of its caller machine M
because no TM can take another actual TM as its input.
A string does not behave. Inside the simulation DD halts; only HHHM.embedded_H can report on the non-halting behavior of its input in
That correctly determines the halt status specified by its inputs. ThenIt shows that no decider can report on the direct execution of at least
the Linz proof does not show that such a decider does not exist.
On 8/27/2025 12:25 PM, Richard Heathfield wrote:
On 27/08/2025 17:07, olcott wrote:
On 8/27/2025 10:50 AM, Richard Heathfield wrote:
Assume you can write a universal halt decider.
That correctly determines the halt status specified
by its inputs. Then the Linz proof does not show that
such a decider does not exist.
Yes it does, and on the way he scuppers simulation. No wonder
you don't like him.
WTF does scuppers mean?
Am Wed, 27 Aug 2025 11:07:03 -0500 schrieb olcott:
On 8/27/2025 10:50 AM, Richard Heathfield wrote:
On 27/08/2025 16:40, olcott wrote:
On 8/27/2025 10:30 AM, Richard Heathfield wrote:
On 27/08/2025 16:09, olcott wrote:
You have failed to make a case for a TM being unable to read and
process a tape.
It can still compute what it would do when executed.M.embedded_H cannot report on the behavior of its caller machine M
because no TM can take another actual TM as its input.
On 27/08/2025 18:48, olcott wrote:
On 8/27/2025 12:25 PM, Richard Heathfield wrote:
On 27/08/2025 17:07, olcott wrote:
On 8/27/2025 10:50 AM, Richard Heathfield wrote:
<snip>
Assume you can write a universal halt decider.
That correctly determines the halt status specified
by its inputs. Then the Linz proof does not show that
such a decider does not exist.
Yes it does, and on the way he scuppers simulation. No wonder you
don't like him.
WTF does scuppers mean?
https://en.wiktionary.org/wiki/scupper#Verb
To thwart or destroy, especially something belonging or pertaining to another.
In other words, Linz explains why simulation doesn't work.
No HHH cannot report on the behavior of its caller.
DD correctly simulated by HHH cannot possibly halt.
On 27/08/2025 19:43, olcott wrote:
<snip>
DD correctly simulated by HHH cannot possibly halt.
And yet it halts, as you yourself have conceded.
On 27/08/2025 19:42, olcott wrote:
<snip>
No HHH cannot report on the behavior of its caller.
Then it's not fit for purpose,
On 8/27/2025 1:18 PM, joes wrote:
Am Wed, 27 Aug 2025 11:07:03 -0500 schrieb olcott:
On 8/27/2025 10:50 AM, Richard Heathfield wrote:It can still compute what it would do when executed.
On 27/08/2025 16:40, olcott wrote:
On 8/27/2025 10:30 AM, Richard Heathfield wrote:
On 27/08/2025 16:09, olcott wrote:
You have failed to make a case for a TM being unable to read and
process a tape.
M.embedded_H cannot report on the behavior of its caller machine M
because no TM can take another actual TM as its input.
No HHH cannot report on the behavior of its caller.
No Turing machine halt decider can ever report
on the behavior of its caller.
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
-a-a if -n applied to rf?-nrf- halts, and
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
-a-a if -n applied to rf?-nrf- does not halt.
Thus -n.embedded_H cannot report on the behavior
of its caller: -n.q0 rf?-nrf-
On 8/27/2025 1:27 PM, Richard Heathfield wrote:
On 27/08/2025 18:48, olcott wrote:
On 8/27/2025 12:25 PM, Richard Heathfield wrote:
On 27/08/2025 17:07, olcott wrote:
On 8/27/2025 10:50 AM, Richard Heathfield wrote:
<snip>
Assume you can write a universal halt decider.
That correctly determines the halt status specified
by its inputs. Then the Linz proof does not show that
such a decider does not exist.
Yes it does, and on the way he scuppers simulation. No wonder you
don't like him.
WTF does scuppers mean?
https://en.wiktionary.org/wiki/scupper#Verb
To thwart or destroy, especially something belonging or pertaining to
another.
In other words, Linz explains why simulation doesn't work.
No he takes a guess that it won't work.
On 8/27/2025 1:48 PM, Richard Heathfield wrote:
On 27/08/2025 19:43, olcott wrote:
<snip>
DD correctly simulated by HHH cannot possibly halt.
And yet it halts, as you yourself have conceded.
Is the same as Bill's identical twin brother
John robbed a liquor store thus making Bill guilty.
On 8/27/2025 1:47 PM, Richard Heathfield wrote:
On 27/08/2025 19:42, olcott wrote:
<snip>
No HHH cannot report on the behavior of its caller.
Then it's not fit for purpose,
In the same way that no blender is fit for the
purpose of baking a cake.
On 8/27/2025 1:48 PM, Richard Heathfield wrote:
On 27/08/2025 19:43, olcott wrote:
<snip>
DD correctly simulated by HHH cannot possibly halt.
And yet it halts, as you yourself have conceded.
Is the same as Bill's identical twin brother
John robbed a liquor store thus making Bill guilty.
On 8/27/2025 1:47 PM, Richard Heathfield wrote:
On 27/08/2025 19:42, olcott wrote:
<snip>
No HHH cannot report on the behavior of its caller.
Then it's not fit for purpose,
In the same way that no blender is fit for the
purpose of baking a cake.
On 27/08/2025 19:54, olcott wrote:
On 8/27/2025 1:47 PM, Richard Heathfield wrote:
On 27/08/2025 19:42, olcott wrote:
<snip>
No HHH cannot report on the behavior of its caller.
Then it's not fit for purpose,
In the same way that no blender is fit for the
purpose of baking a cake.
No, in the same way that no blender is fit for purpose if it can't blend.
On 8/27/2025 2:10 PM, Richard Heathfield wrote:
On 27/08/2025 19:54, olcott wrote:
On 8/27/2025 1:47 PM, Richard Heathfield wrote:
On 27/08/2025 19:42, olcott wrote:
<snip>
No HHH cannot report on the behavior of its caller.
Then it's not fit for purpose,
In the same way that no blender is fit for the
purpose of baking a cake.
No, in the same way that no blender is fit for purpose if it can't blend.
No it the same as a Turing machine halt decider
cannot bake you a cake even if it is required to.\
On 27/08/2025 19:53, olcott wrote:
On 8/27/2025 1:48 PM, Richard Heathfield wrote:
On 27/08/2025 19:43, olcott wrote:
<snip>
DD correctly simulated by HHH cannot possibly halt.
And yet it halts, as you yourself have conceded.
Is the same as Bill's identical twin brother
John robbed a liquor store thus making Bill guilty.
No, it's the same as John robbing a liquor store thus making John guilty.
John is the same person as John. [Discuss. 3 marks.]
DD is the same function as DD. C guarantees it.
On 27/08/2025 19:53, olcott wrote:
On 8/27/2025 1:48 PM, Richard Heathfield wrote:
On 27/08/2025 19:43, olcott wrote:
<snip>
DD correctly simulated by HHH cannot possibly halt.
And yet it halts, as you yourself have conceded.
Is the same as Bill's identical twin brother
John robbed a liquor store thus making Bill guilty.
No, it's the same as John robbing a liquor store thus making John guilty.
On 8/27/2025 2:10 PM, Richard Heathfield wrote:
On 27/08/2025 19:54, olcott wrote:
On 8/27/2025 1:47 PM, Richard Heathfield wrote:
On 27/08/2025 19:42, olcott wrote:
<snip>
No HHH cannot report on the behavior of its caller.
Then it's not fit for purpose,
In the same way that no blender is fit for the
purpose of baking a cake.
No, in the same way that no blender is fit for purpose if it
can't blend.
No it the same as a Turing machine halt decider
cannot bake you a cake even if it is required to.
On 8/27/2025 2:03 PM, Richard Heathfield wrote:
On 27/08/2025 19:53, olcott wrote:
On 8/27/2025 1:48 PM, Richard Heathfield wrote:
On 27/08/2025 19:43, olcott wrote:
<snip>
DD correctly simulated by HHH cannot possibly halt.
And yet it halts, as you yourself have conceded.
Is the same as Bill's identical twin brother
John robbed a liquor store thus making Bill guilty.
No, it's the same as John robbing a liquor store thus making
John guilty.
Not at all You said that HHH is wrong because something
that looks like (yet is not) its input halts.
On 27/08/2025 20:16, olcott wrote:
On 8/27/2025 2:10 PM, Richard Heathfield wrote:
On 27/08/2025 19:54, olcott wrote:
On 8/27/2025 1:47 PM, Richard Heathfield wrote:
On 27/08/2025 19:42, olcott wrote:
<snip>
No HHH cannot report on the behavior of its caller.
Then it's not fit for purpose,
In the same way that no blender is fit for the
purpose of baking a cake.
No, in the same way that no blender is fit for purpose if it can't
blend.
No it the same as a Turing machine halt decider
cannot bake you a cake even if it is required to.
This really is a rubbish analogy.
On 27/08/2025 20:24, olcott wrote:
On 8/27/2025 2:03 PM, Richard Heathfield wrote:
On 27/08/2025 19:53, olcott wrote:
On 8/27/2025 1:48 PM, Richard Heathfield wrote:
On 27/08/2025 19:43, olcott wrote:
<snip>
DD correctly simulated by HHH cannot possibly halt.
And yet it halts, as you yourself have conceded.
Is the same as Bill's identical twin brother
John robbed a liquor store thus making Bill guilty.
No, it's the same as John robbing a liquor store thus making John
guilty.
Not at all You said that HHH is wrong because something
that looks like (yet is not) its input halts.
Citation needed. I don't recall saying those words.
On 8/27/2025 2:36 PM, Richard Heathfield wrote:
On 27/08/2025 20:24, olcott wrote:
On 8/27/2025 2:03 PM, Richard Heathfield wrote:
On 27/08/2025 19:53, olcott wrote:
On 8/27/2025 1:48 PM, Richard Heathfield wrote:
On 27/08/2025 19:43, olcott wrote:
<snip>
DD correctly simulated by HHH cannot possibly halt.
And yet it halts, as you yourself have conceded.
Is the same as Bill's identical twin brother
John robbed a liquor store thus making Bill guilty.
No, it's the same as John robbing a liquor store thus making John
guilty.
Not at all You said that HHH is wrong because something
that looks like (yet is not) its input halts.
Citation needed. I don't recall saying those words.
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
On 8/27/2025 2:03 PM, Richard Heathfield wrote:
On 27/08/2025 19:53, olcott wrote:
On 8/27/2025 1:48 PM, Richard Heathfield wrote:
On 27/08/2025 19:43, olcott wrote:
<snip>
DD correctly simulated by HHH cannot possibly halt.
And yet it halts, as you yourself have conceded.
Is the same as Bill's identical twin brother
John robbed a liquor store thus making Bill guilty.
No, it's the same as John robbing a liquor store thus making
John guilty.
As Kaz said (paraphrase) DD.executed has a different
name than DD.simulated_by_HHH.
On 8/27/2025 2:30 PM, Richard Heathfield wrote:
On 27/08/2025 20:16, olcott wrote:
On 8/27/2025 2:10 PM, Richard Heathfield wrote:
On 27/08/2025 19:54, olcott wrote:
On 8/27/2025 1:47 PM, Richard Heathfield wrote:
On 27/08/2025 19:42, olcott wrote:
<snip>
No HHH cannot report on the behavior of its caller.
Then it's not fit for purpose,
In the same way that no blender is fit for the
purpose of baking a cake.
No, in the same way that no blender is fit for purpose if it
can't blend.
No it the same as a Turing machine halt decider
cannot bake you a cake even if it is required to.
This really is a rubbish analogy.
It is the same as requiring a halt decider
to report on the behavior of its caller.
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
On 27/08/2025 20:42, olcott wrote:
On 8/27/2025 2:30 PM, Richard Heathfield wrote:
On 27/08/2025 20:16, olcott wrote:
On 8/27/2025 2:10 PM, Richard Heathfield wrote:
On 27/08/2025 19:54, olcott wrote:
On 8/27/2025 1:47 PM, Richard Heathfield wrote:
On 27/08/2025 19:42, olcott wrote:
<snip>
No HHH cannot report on the behavior of its caller.
Then it's not fit for purpose,
In the same way that no blender is fit for the
purpose of baking a cake.
No, in the same way that no blender is fit for purpose if it can't
blend.
No it the same as a Turing machine halt decider
cannot bake you a cake even if it is required to.
This really is a rubbish analogy.
It is the same as requiring a halt decider
to report on the behavior of its caller.
Then why do you ask it of what you like to think of as a halt decider?
If a universal TM halt decider existed (which it doesn't), to qualify to
be one it would have to be able to decide on *any* TM. It's not allowed
to be finicky.
On 8/27/2025 2:52 PM, Richard Heathfield wrote:Maps the halting function:
On 27/08/2025 20:42, olcott wrote:
On 8/27/2025 2:30 PM, Richard Heathfield wrote:
On 27/08/2025 20:16, olcott wrote:
On 8/27/2025 2:10 PM, Richard Heathfield wrote:
On 27/08/2025 19:54, olcott wrote:
On 8/27/2025 1:47 PM, Richard Heathfield wrote:
On 27/08/2025 19:42, olcott wrote:
<snip>
No HHH cannot report on the behavior of its caller.
Then it's not fit for purpose,
In the same way that no blender is fit for the
purpose of baking a cake.
No, in the same way that no blender is fit for purpose if it can't >>>>>> blend.
No it the same as a Turing machine halt decider
cannot bake you a cake even if it is required to.
This really is a rubbish analogy.
It is the same as requiring a halt decider
to report on the behavior of its caller.
Then why do you ask it of what you like to think of as a halt decider?
A halt decider
On 27/08/2025 20:44, olcott wrote:
<snip>
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
They're constraint violations requiring diagnostic messages from your implementation.
On 8/27/2025 3:44 PM, olcott wrote:
On 8/27/2025 2:36 PM, Richard Heathfield wrote:
On 27/08/2025 20:24, olcott wrote:
On 8/27/2025 2:03 PM, Richard Heathfield wrote:
On 27/08/2025 19:53, olcott wrote:
On 8/27/2025 1:48 PM, Richard Heathfield wrote:
On 27/08/2025 19:43, olcott wrote:
<snip>
DD correctly simulated by HHH cannot possibly halt.
And yet it halts, as you yourself have conceded.
Is the same as Bill's identical twin brother
John robbed a liquor store thus making Bill guilty.
No, it's the same as John robbing a liquor store thus making
John guilty.
Not at all You said that HHH is wrong because something
that looks like (yet is not) its input halts.
Citation needed. I don't recall saying those words.
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
In other words, the directly executed DD calls HHH with an empty
stack trace, and that is what is given to the directly executed
HHH(DD), but HHH then simulates DD calling HHH with a non-empty
stack trace.
A halt decider correctly reports on the behavior
that its input specifies
On 8/27/2025 2:54 PM, Richard Heathfield wrote:
On 27/08/2025 20:44, olcott wrote:
<snip>
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
They're constraint violations requiring diagnostic messages
from your implementation.
DD() does not halt
, it looks like it halts because
the infinite recursion that it specifies
On 27/08/2025 21:01, olcott wrote:
<snip>
A halt decider correctly reports on the behavior
that its input specifies
Then you don't have one, because it doesn't.
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
On 27/08/2025 21:04, olcott wrote:
On 8/27/2025 2:54 PM, Richard Heathfield wrote:
On 27/08/2025 20:44, olcott wrote:
<snip>
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
They're constraint violations requiring diagnostic messages from your
implementation.
DD() does not halt
Yeah, it does.
, it looks like it halts because
the infinite recursion that it specifies
But it specifies no such thing. It specifies a call to a function that
plays silly buggers and then returns a value.
Over and over and over you have said that HHH returns a value --- which indeed it must in order to report its decision.
Since it returns a value, there is clearly no infinite recursion.
On 8/27/2025 3:43 PM, Richard Heathfield wrote:
On 27/08/2025 21:04, olcott wrote:
On 8/27/2025 2:54 PM, Richard Heathfield wrote:
On 27/08/2025 20:44, olcott wrote:
<snip>
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
They're constraint violations requiring diagnostic messages from
your implementation.
DD() does not halt
Yeah, it does.
, it looks like it halts because
the infinite recursion that it specifies
But it specifies no such thing. It specifies a call to a function that
plays silly buggers and then returns a value.
Over and over and over you have said that HHH returns a value ---
which indeed it must in order to report its decision.
Since it returns a value, there is clearly no infinite recursion.
It returns a value indicating that DD correctly
simulated by HHH cannot possibly reach its own
halt state.
On 8/27/2025 3:39 PM, Richard Heathfield wrote:
On 27/08/2025 21:01, olcott wrote:
<snip>
A halt decider correctly reports on the behavior
that its input specifies
Then you don't have one, because it doesn't.
*Thats not what you said*
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
On 8/27/2025 3:43 PM, Richard Heathfield wrote:
On 27/08/2025 21:04, olcott wrote:
On 8/27/2025 2:54 PM, Richard Heathfield wrote:
On 27/08/2025 20:44, olcott wrote:
<snip>
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
They're constraint violations requiring diagnostic messages
from your implementation.
DD() does not halt
Yeah, it does.
, it looks like it halts because
the infinite recursion that it specifies
But it specifies no such thing. It specifies a call to a
function that plays silly buggers and then returns a value.
Over and over and over you have said that HHH returns a value
--- which indeed it must in order to report its decision.
Since it returns a value, there is clearly no infinite recursion.
It returns a value indicating that DD correctly
simulated by HHH cannot possibly reach its own
halt state.
On 27/08/2025 22:15, olcott wrote:
On 8/27/2025 3:39 PM, Richard Heathfield wrote:
On 27/08/2025 21:01, olcott wrote:
<snip>
A halt decider correctly reports on the behavior
that its input specifies
Then you don't have one, because it doesn't.
*Thats not what you said*
Yeah, it is.
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
Yup. HHH has to report, right? So it has to pull the plug on what it
thinks is unhalting behaviour. Now it can report. But what? Well, the simulator didn't reach a halt state, so it can't report 1, but that only leaves 0.
On 27/08/2025 22:17, olcott wrote:
On 8/27/2025 3:43 PM, Richard Heathfield wrote:
On 27/08/2025 21:04, olcott wrote:
On 8/27/2025 2:54 PM, Richard Heathfield wrote:
On 27/08/2025 20:44, olcott wrote:
<snip>
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
They're constraint violations requiring diagnostic messages from
your implementation.
DD() does not halt
Yeah, it does.
, it looks like it halts because
the infinite recursion that it specifies
But it specifies no such thing. It specifies a call to a function
that plays silly buggers and then returns a value.
Over and over and over you have said that HHH returns a value ---
which indeed it must in order to report its decision.
Since it returns a value, there is clearly no infinite recursion.
It returns a value indicating that DD correctly
simulated by HHH cannot possibly reach its own
halt state.
"Correctly simulated" would surely entail getting the answer right.
Besides, HHH /could/ simulate DD better than it does, by *not* canning
the simulation when it detects running away recursion.
It could say "okay, that's going off down the rabbit hole, so instead of chasing it or killing it let's /imagine/ we killed it, and plug in a 0 return from... er... *that* HHH call, and continue simulating from there."
That way, at least you'd /reach/ the Turing Twist. Got to be an
improvement, surely?
If you're curious, see Theorem 12.1 in AN INTRODUCTION TO FORMAL
LANGUAGES AND AUTOMATA.
<https://[SNIP]>
On 8/27/2025 4:43 PM, Richard Heathfield wrote:V--- returns 0
On 27/08/2025 22:15, olcott wrote:
On 8/27/2025 3:39 PM, Richard Heathfield wrote:
On 27/08/2025 21:01, olcott wrote:
<snip>
A halt decider correctly reports on the behavior
that its input specifies
Then you don't have one, because it doesn't.
*Thats not what you said*
Yeah, it is.
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
Yup. HHH has to report, right? So it has to pull the plug on
what it thinks is unhalting behaviour. Now it can report. But
what? Well, the simulator didn't reach a halt state, so it
can't report 1, but that only leaves 0.
HHH that reports in the same behavior as five chat bots
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern:
-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
-a int Halt_Status = HHH(DD);receives 0--^
-a if (Halt_Status)
-a-a-a HERE: goto HERE;
-a return Halt_Status;
}
What value should HHH(DD) correctly return?
<Input to LLM systems>
returns 0 on the basis of the above static text.
On 8/27/2025 4:49 PM, Richard Heathfield wrote:
On 27/08/2025 22:17, olcott wrote:
On 8/27/2025 3:43 PM, Richard Heathfield wrote:
On 27/08/2025 21:04, olcott wrote:
On 8/27/2025 2:54 PM, Richard Heathfield wrote:
On 27/08/2025 20:44, olcott wrote:
<snip>
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
They're constraint violations requiring diagnostic messages
from your implementation.
DD() does not halt
Yeah, it does.
, it looks like it halts because
the infinite recursion that it specifies
But it specifies no such thing. It specifies a call to a
function that plays silly buggers and then returns a value.
Over and over and over you have said that HHH returns a value
--- which indeed it must in order to report its decision.
Since it returns a value, there is clearly no infinite
recursion.
It returns a value indicating that DD correctly
simulated by HHH cannot possibly reach its own
halt state.
"Correctly simulated" would surely entail getting the answer
right.
Besides, HHH /could/ simulate DD better than it does, by *not*
canning the simulation when it detects running away recursion.
It could say "okay, that's going off down the rabbit hole, so
instead of chasing it or killing it let's /imagine/ we killed
it, and plug in a 0 return from... er... *that* HHH call, and
continue simulating from there."
That way, at least you'd /reach/ the Turing Twist. Got to be an
improvement, surely?
I am going to stop responding to posts as dumb as this one too.
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
If you're curious, see Theorem 12.1 in AN INTRODUCTION TO FORMAL
LANGUAGES AND AUTOMATA.
<https://[SNIP]>
That's a PDF copy of the 6th edition of Peter Linz's book, provided
on the personal website of a computer science student. Page 3
includes a clear copyright statement, dated 2017. I don't believe
the copyright holder has given permission to freely distribute
the book.
On 27/08/2025 22:59, olcott wrote:
On 8/27/2025 4:43 PM, Richard Heathfield wrote:-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a V--- returns 0
On 27/08/2025 22:15, olcott wrote:
On 8/27/2025 3:39 PM, Richard Heathfield wrote:
On 27/08/2025 21:01, olcott wrote:
<snip>
A halt decider correctly reports on the behavior
that its input specifies
Then you don't have one, because it doesn't.
*Thats not what you said*
Yeah, it is.
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
Yup. HHH has to report, right? So it has to pull the plug on what it
thinks is unhalting behaviour. Now it can report. But what? Well, the
simulator didn't reach a halt state, so it can't report 1, but that
only leaves 0.
HHH that reports in the same behavior as five chat bots
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
-a-a int Halt_Status = HHH(DD);-a-a-a-a-a-a receives 0--^
-a-a-a-a VVVVVVVVVVVVVVVV if(0) is false
-a-a if (Halt_Status)
-a-a-a-a-a-a VVVVVVVVVVVVVVV doesn't happen
-a-a-a-a HERE: goto HERE;
-a-a-a-a V---- reaches return statement and halts
-a-a return Halt_Status;
}
What value should HHH(DD) correctly return?
<Input to LLM systems>
returns 0 on the basis of the above static text.
0 means "non-halting". Nice try. Wrong, but nice try.
If it's any consolation, 1 is wrong as well.
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
On 27/08/2025 23:03, olcott wrote:
On 8/27/2025 4:49 PM, Richard Heathfield wrote:
On 27/08/2025 22:17, olcott wrote:
On 8/27/2025 3:43 PM, Richard Heathfield wrote:
On 27/08/2025 21:04, olcott wrote:
On 8/27/2025 2:54 PM, Richard Heathfield wrote:
On 27/08/2025 20:44, olcott wrote:
<snip>
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
They're constraint violations requiring diagnostic messages from >>>>>>> your implementation.
DD() does not halt
Yeah, it does.
, it looks like it halts because
the infinite recursion that it specifies
But it specifies no such thing. It specifies a call to a function
that plays silly buggers and then returns a value.
Over and over and over you have said that HHH returns a value ---
which indeed it must in order to report its decision.
Since it returns a value, there is clearly no infinite recursion.
It returns a value indicating that DD correctly
simulated by HHH cannot possibly reach its own
halt state.
"Correctly simulated" would surely entail getting the answer right.
Besides, HHH /could/ simulate DD better than it does, by *not*
canning the simulation when it detects running away recursion.
It could say "okay, that's going off down the rabbit hole, so instead
of chasing it or killing it let's /imagine/ we killed it, and plug in
a 0 return from... er... *that* HHH call, and continue simulating
from there."
That way, at least you'd /reach/ the Turing Twist. Got to be an
improvement, surely?
I am going to stop responding to posts as dumb as this one too.
Since olcott is too "dumb" (as he puts it) to figure out what I'm
getting at, perhaps someone else would be good enough to comment on my suggestion for improving HHH's coverage of DD's code.
On 27/08/2025 23:06, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
If you're curious, see Theorem 12.1 in AN INTRODUCTION TO FORMAL
LANGUAGES AND AUTOMATA.
<https://[SNIP]>
That's a PDF copy of the 6th edition of Peter Linz's book, provided
on the personal website of a computer science student.-a Page 3
includes a clear copyright statement, dated 2017.-a I don't believe
the copyright holder has given permission to freely distribute
the book.
Oops. I was foolish enough to take it at face value. My apologies to Mr Linz's estate.
On 8/27/2025 5:07 PM, Richard Heathfield wrote:
On 27/08/2025 22:59, olcott wrote:
On 8/27/2025 4:43 PM, Richard Heathfield wrote:-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a V--- returns 0
On 27/08/2025 22:15, olcott wrote:
On 8/27/2025 3:39 PM, Richard Heathfield wrote:
On 27/08/2025 21:01, olcott wrote:
<snip>
A halt decider correctly reports on the behavior
that its input specifies
Then you don't have one, because it doesn't.
*Thats not what you said*
Yeah, it is.
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
Yup. HHH has to report, right? So it has to pull the plug on
what it thinks is unhalting behaviour. Now it can report. But
what? Well, the simulator didn't reach a halt state, so it
can't report 1, but that only leaves 0.
HHH that reports in the same behavior as five chat bots
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its
input until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
-a-a int Halt_Status = HHH(DD);-a-a-a-a-a-a-a receives 0--^
-a-a-a-a-a VVVVVVVVVVVVVVVV if(0) is false
-a-a if (Halt_Status)
-a-a-a-a-a-a-a VVVVVVVVVVVVVVV doesn't happen
-a-a-a-a HERE: goto HERE;
-a-a-a-a-a V---- reaches return statement and halts
-a-a return Halt_Status;
}
What value should HHH(DD) correctly return?
<Input to LLM systems>
returns 0 on the basis of the above static text.
0 means "non-halting". Nice try. Wrong, but nice try.
If it's any consolation, 1 is wrong as well.
No the problem is that in 89 years no one noticed
that the short-hand notion of M halts in input P
does not always correspond to the input to H(rf?Mrf-,P)
specifies a halting computation.
I have proven this and you acknowledged this
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
On 8/27/2025 5:11 PM, Richard Heathfield wrote:
On 27/08/2025 23:03, olcott wrote:
On 8/27/2025 4:49 PM, Richard Heathfield wrote:
On 27/08/2025 22:17, olcott wrote:
On 8/27/2025 3:43 PM, Richard Heathfield wrote:
On 27/08/2025 21:04, olcott wrote:
On 8/27/2025 2:54 PM, Richard Heathfield wrote:
On 27/08/2025 20:44, olcott wrote:
<snip>
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
They're constraint violations requiring diagnostic
messages from your implementation.
DD() does not halt
Yeah, it does.
, it looks like it halts because
the infinite recursion that it specifies
But it specifies no such thing. It specifies a call to a
function that plays silly buggers and then returns a value.
Over and over and over you have said that HHH returns a
value --- which indeed it must in order to report its
decision.
Since it returns a value, there is clearly no infinite
recursion.
It returns a value indicating that DD correctly
simulated by HHH cannot possibly reach its own
halt state.
"Correctly simulated" would surely entail getting the answer
right.
Besides, HHH /could/ simulate DD better than it does, by
*not* canning the simulation when it detects running away
recursion.
It could say "okay, that's going off down the rabbit hole, so
instead of chasing it or killing it let's /imagine/ we killed
it, and plug in a 0 return from... er... *that* HHH call, and
continue simulating from there."
That way, at least you'd /reach/ the Turing Twist. Got to be
an improvement, surely?
I am going to stop responding to posts as dumb as this one too.
Since olcott is too "dumb" (as he puts it) to figure out what
I'm getting at, perhaps someone else would be good enough to
comment on my suggestion for improving HHH's coverage of DD's
code.
You know that your idea was ridiculously stupid.
On 27/08/2025 23:24, olcott wrote:
On 8/27/2025 5:07 PM, Richard Heathfield wrote:
On 27/08/2025 22:59, olcott wrote:
On 8/27/2025 4:43 PM, Richard Heathfield wrote:-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a V--- returns 0
On 27/08/2025 22:15, olcott wrote:
On 8/27/2025 3:39 PM, Richard Heathfield wrote:
On 27/08/2025 21:01, olcott wrote:
<snip>
A halt decider correctly reports on the behavior
that its input specifies
Then you don't have one, because it doesn't.
*Thats not what you said*
Yeah, it is.
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
Yup. HHH has to report, right? So it has to pull the plug on what
it thinks is unhalting behaviour. Now it can report. But what?
Well, the simulator didn't reach a halt state, so it can't report
1, but that only leaves 0.
HHH that reports in the same behavior as five chat bots
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
-a-a int Halt_Status = HHH(DD);-a-a-a-a-a-a-a receives 0--^
-a-a-a-a-a VVVVVVVVVVVVVVVV if(0) is false
-a-a if (Halt_Status)
-a-a-a-a-a-a-a VVVVVVVVVVVVVVV doesn't happen
-a-a-a-a HERE: goto HERE;
-a-a-a-a-a V---- reaches return statement and halts
-a-a return Halt_Status;
}
What value should HHH(DD) correctly return?
<Input to LLM systems>
returns 0 on the basis of the above static text.
0 means "non-halting". Nice try. Wrong, but nice try.
If it's any consolation, 1 is wrong as well.
No the problem is that in 89 years no one noticed
that the short-hand notion of M halts in input P
does not always correspond to the input to H(rf?Mrf-,P)
specifies a halting computation.
I have proven this and you acknowledged this
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
I literally just answered that point
See above. You *cannot* be this stupid!
On 27/08/2025 23:27, olcott wrote:
On 8/27/2025 5:11 PM, Richard Heathfield wrote:
On 27/08/2025 23:03, olcott wrote:
On 8/27/2025 4:49 PM, Richard Heathfield wrote:
On 27/08/2025 22:17, olcott wrote:
On 8/27/2025 3:43 PM, Richard Heathfield wrote:
On 27/08/2025 21:04, olcott wrote:
On 8/27/2025 2:54 PM, Richard Heathfield wrote:
On 27/08/2025 20:44, olcott wrote:
<snip>
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
They're constraint violations requiring diagnostic messages >>>>>>>>> from your implementation.
DD() does not halt
Yeah, it does.
, it looks like it halts because
the infinite recursion that it specifies
But it specifies no such thing. It specifies a call to a function >>>>>>> that plays silly buggers and then returns a value.
Over and over and over you have said that HHH returns a value --- >>>>>>> which indeed it must in order to report its decision.
Since it returns a value, there is clearly no infinite recursion. >>>>>>>
It returns a value indicating that DD correctly
simulated by HHH cannot possibly reach its own
halt state.
"Correctly simulated" would surely entail getting the answer right.
Besides, HHH /could/ simulate DD better than it does, by *not*
canning the simulation when it detects running away recursion.
It could say "okay, that's going off down the rabbit hole, so
instead of chasing it or killing it let's /imagine/ we killed it,
and plug in a 0 return from... er... *that* HHH call, and continue
simulating from there."
That way, at least you'd /reach/ the Turing Twist. Got to be an
improvement, surely?
I am going to stop responding to posts as dumb as this one too.
Since olcott is too "dumb" (as he puts it) to figure out what I'm
getting at, perhaps someone else would be good enough to comment on
my suggestion for improving HHH's coverage of DD's code.
You know that your idea was ridiculously stupid.
No stupider than trying to overturn a self-evident proof.
(1) When HHH(DD) would return 0 THIS WOULD BE CORRECT
(2) Halt decider ONLY report on the behavior that
actual their input actually specifies
and the input
to HHH(DD) SPECIFIES NON-HALTING.
On 28/08/2025 03:59, olcott wrote:
(1) When HHH(DD) would return 0 THIS WOULD BE CORRECT
Only until it isn't.
(2) Halt decider ONLY report on the behavior that
actual their input actually specifies
The input is DD.
and the input
to HHH(DD) SPECIFIES NON-HALTING.
And so HHH(DD)'s output to DD is non-halting, which DD uses to halt,
making HHH's answer wrong.
You seem to think it matters whether HHH "ONLY report on the behavior
that actual their input actually specifies". Well, in a way it does
because it should at least /try/ to get the answer right, which it does
a bit but not very hard. But whatever it does, it's doomed, because DD
has HHH completely figured out.
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
On 8/12/2025 12:31 PM, dbush wrote:--- Synchronet 3.21a-Linux NewsLink 1.2
On 8/12/2025 1:18 PM, olcott wrote:
On 8/12/2025 12:14 PM, dbush wrote:
Mathematical induction doesn't allow changing the input, which is
what you're doing.
Changing the input is not allowed.
Mathematical induction simultaneously tests
every input of an infinite set of inputs.
So you admit to changing the input.
Changing the input is not allowed.
Changing the input in this way is REQUIRED.
On 8/27/2025 10:30 PM, Richard Heathfield wrote:
On 28/08/2025 03:59, olcott wrote:
(1) When HHH(DD) would return 0 THIS WOULD BE CORRECT
Only until it isn't.
(2) Halt decider ONLY report on the behavior that
actual their input actually specifies
The input is DD.
and the input
to HHH(DD) SPECIFIES NON-HALTING.
And so HHH(DD)'s output to DD is non-halting, which DD uses to
halt, making HHH's answer wrong.
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
On 28/08/2025 04:46, olcott wrote:
On 8/27/2025 10:30 PM, Richard Heathfield wrote:
On 28/08/2025 03:59, olcott wrote:
(1) When HHH(DD) would return 0 THIS WOULD BE CORRECT
Only until it isn't.
(2) Halt decider ONLY report on the behavior that
actual their input actually specifies
The input is DD.
and the input
to HHH(DD) SPECIFIES NON-HALTING.
And so HHH(DD)'s output to DD is non-halting, which DD uses to halt,
making HHH's answer wrong.
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
All that matters is
whether it halts in the real world, being executed directly on the
hardware and not through a grossly inefficient simulation layer that
halts the simulation on a whim.
The question is not "does DD halt under simulation?" but "does DD halt?"
You say it doesn't, by returning 0 from HHH.
In the real world of hardware, DD responds to your answer by stopping on
a sixpence. HHH gets it wrong, and so it isn't a decider after all.
You seem to think it matters whether HHH "ONLY report on the
behavior that actual their input actually specifies". Well, in
a way it does because it should at least /try/ to get the
answer right, which it does a bit but not very hard. But
whatever it does, it's doomed, because DD has HHH completely
figured out.
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that
nobody gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
On 8/27/2025 11:46 PM, olcott wrote:
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
Yet you claim they must report on non-inputs (see below):
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
On 8/27/2025 3:05 AM, Mikko wrote:
On 2025-08-26 16:29:41 +0000, olcott said:
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
However, a requirement may define the required mapping in terms of the
behaviour (or other properties) of some Turing machine.
Sure and we can say that TM Y is required
to provide the square-root of a dead squirrel.
On 8/27/2025 9:45 PM, Richard Heathfield wrote:
On 27/08/2025 23:27, olcott wrote:
On 8/27/2025 5:11 PM, Richard Heathfield wrote:
On 27/08/2025 23:03, olcott wrote:
On 8/27/2025 4:49 PM, Richard Heathfield wrote:
On 27/08/2025 22:17, olcott wrote:
On 8/27/2025 3:43 PM, Richard Heathfield wrote:
On 27/08/2025 21:04, olcott wrote:
On 8/27/2025 2:54 PM, Richard Heathfield wrote:
On 27/08/2025 20:44, olcott wrote:
<snip>
DD.executed looks like DD.simulated_by_HHH yet
because they specify a different sequence of steps
(that you already acknowledged) they are not the same.
They're constraint violations requiring diagnostic messages >>>>>>>>>> from your implementation.
DD() does not halt
Yeah, it does.
, it looks like it halts because
the infinite recursion that it specifies
But it specifies no such thing. It specifies a call to a
function that plays silly buggers and then returns a value.
Over and over and over you have said that HHH returns a value >>>>>>>> --- which indeed it must in order to report its decision.
Since it returns a value, there is clearly no infinite recursion. >>>>>>>>
It returns a value indicating that DD correctly
simulated by HHH cannot possibly reach its own
halt state.
"Correctly simulated" would surely entail getting the answer right. >>>>>>
Besides, HHH /could/ simulate DD better than it does, by *not*
canning the simulation when it detects running away recursion.
It could say "okay, that's going off down the rabbit hole, so
instead of chasing it or killing it let's /imagine/ we killed it, >>>>>> and plug in a 0 return from... er... *that* HHH call, and continue >>>>>> simulating from there."
That way, at least you'd /reach/ the Turing Twist. Got to be an
improvement, surely?
I am going to stop responding to posts as dumb as this one too.
Since olcott is too "dumb" (as he puts it) to figure out what I'm
getting at, perhaps someone else would be good enough to comment on
my suggestion for improving HHH's coverage of DD's code.
You know that your idea was ridiculously stupid.
No stupider than trying to overturn a self-evident proof.
What I just said in my prior reply to you is:
PROVEN TOTALLY TRUE ENTIRELY ON THE BASIS OF THE MEANING OF ITS WORDS (SELF-EVIDENTLY TRUE)
On 27/08/2025 23:24, olcott wrote:
On 8/27/2025 5:07 PM, Richard Heathfield wrote:
On 27/08/2025 22:59, olcott wrote:
On 8/27/2025 4:43 PM, Richard Heathfield wrote:-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a V--- returns 0
On 27/08/2025 22:15, olcott wrote:
On 8/27/2025 3:39 PM, Richard Heathfield wrote:
On 27/08/2025 21:01, olcott wrote:
<snip>
A halt decider correctly reports on the behavior
that its input specifies
Then you don't have one, because it doesn't.
*Thats not what you said*
Yeah, it is.
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
Yup. HHH has to report, right? So it has to pull the plug on what
it thinks is unhalting behaviour. Now it can report. But what?
Well, the simulator didn't reach a halt state, so it can't report
1, but that only leaves 0.
HHH that reports in the same behavior as five chat bots
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
-a-a int Halt_Status = HHH(DD);-a-a-a-a-a-a-a receives 0--^
-a-a-a-a-a VVVVVVVVVVVVVVVV if(0) is false
-a-a if (Halt_Status)
-a-a-a-a-a-a-a VVVVVVVVVVVVVVV doesn't happen
-a-a-a-a HERE: goto HERE;
-a-a-a-a-a V---- reaches return statement and halts
-a-a return Halt_Status;
}
What value should HHH(DD) correctly return?
<Input to LLM systems>
returns 0 on the basis of the above static text.
0 means "non-halting". Nice try. Wrong, but nice try.
If it's any consolation, 1 is wrong as well.
No the problem is that in 89 years no one noticed
that the short-hand notion of M halts in input P
does not always correspond to the input to H(rf?Mrf-,P)
specifies a halting computation.
I have proven this and you acknowledged this
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
I literally just answered that point
See above. You *cannot* be this stupid!
On 8/27/2025 9:42 PM, Richard Heathfield wrote:
On 27/08/2025 23:24, olcott wrote:
On 8/27/2025 5:07 PM, Richard Heathfield wrote:
On 27/08/2025 22:59, olcott wrote:
On 8/27/2025 4:43 PM, Richard Heathfield wrote:-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a-a V--- returns 0
On 27/08/2025 22:15, olcott wrote:
On 8/27/2025 3:39 PM, Richard Heathfield wrote:
On 27/08/2025 21:01, olcott wrote:
<snip>
A halt decider correctly reports on the behavior
that its input specifies
Then you don't have one, because it doesn't.
*Thats not what you said*
Yeah, it is.
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
Yup. HHH has to report, right? So it has to pull the plug on what >>>>>> it thinks is unhalting behaviour. Now it can report. But what?
Well, the simulator didn't reach a halt state, so it can't report >>>>>> 1, but that only leaves 0.
HHH that reports in the same behavior as five chat bots
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern:
-a-a-a-a abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
-a-a-a-a return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
-a-a int Halt_Status = HHH(DD);-a-a-a-a-a-a-a receives 0--^
-a-a-a-a-a VVVVVVVVVVVVVVVV if(0) is false
-a-a if (Halt_Status)
-a-a-a-a-a-a-a VVVVVVVVVVVVVVV doesn't happen
-a-a-a-a HERE: goto HERE;
-a-a-a-a-a V---- reaches return statement and halts
-a-a return Halt_Status;
}
What value should HHH(DD) correctly return?
<Input to LLM systems>
returns 0 on the basis of the above static text.
0 means "non-halting". Nice try. Wrong, but nice try.
If it's any consolation, 1 is wrong as well.
No the problem is that in 89 years no one noticed
that the short-hand notion of M halts in input P
does not always correspond to the input to H(rf?Mrf-,P)
specifies a halting computation.
I have proven this and you acknowledged this
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
I literally just answered that point
See above. You *cannot* be this stupid!
(1) When HHH(DD) would return 0 THIS WOULD BE CORRECT
(2) Halt decider ONLY report on the behavior that
actual their input actually specifies and the input
to HHH(DD) SPECIFIES NON-HALTING.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
On 28/08/2025 05:21, olcott wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
<snip>
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
No, it isn't. It's the key that proves you don't get the question. Your "decider" demonstrates very neatly that HHH cannot correctly analyse DD.
It can't even /see/ DD!
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
Well, you forgot the last three lines of DD. Careless.
The question is not "does DD halt under simulation?" but "does
DD halt?" And you have to include the whole function.
You seem to think it matters whether HHH "ONLY report on the
behavior that actual their input actually specifies". Well, in
a way it does because it should at least /try/ to get the
answer right, which it does a bit but not very hard. But
whatever it does, it's doomed, because DD has HHH completely
figured out.
On 28/08/2025 04:50, dbush wrote:
On 8/27/2025 11:46 PM, olcott wrote:
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
Yet you claim they must report on non-inputs (see below):
He does. And yet he is content to discard actual input.
if (Halt_Status)
-a-a-a HERE: goto HERE;
-a return Halt_Status;
}
is never simulated by HHH.
On 8/27/2025 11:34 PM, Richard Heathfield wrote:
On 28/08/2025 05:21, olcott wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
<snip>
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
No, it isn't. It's the key that proves you don't get the question.
Your "decider" demonstrates very neatly that HHH cannot correctly
analyse DD. It can't even /see/ DD!
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
Well, you forgot the last three lines of DD. Careless.
The question is not "does DD halt under simulation?" but "does
DD halt?" And you have to include the whole function.
The question is: Does DD correctly simulated by HHH halt?
You seem to think it matters whether HHH "ONLY report on the
behavior that actual their input actually specifies". Well, in
a way it does because it should at least /try/ to get the
answer right, which it does a bit but not very hard. But
whatever it does, it's doomed, because DD has HHH completely
figured out.
You keep ignoring that halt deciders
only
COMPUTE THE MAPPING FROM THEIR INPUTS
On 8/27/2025 11:34 PM, Richard Heathfield wrote:
The question is not "does DD halt under simulation?" but "does
DD halt?" And you have to include the whole function.
The question is: Does DD correctly simulated by HHH halt?
You keep ignoring that halt deciders only
COMPUTE THE MAPPING FROM THEIR INPUTS
On 8/27/2025 11:44 PM, Richard Heathfield wrote:
On 28/08/2025 04:50, dbush wrote:
On 8/27/2025 11:46 PM, olcott wrote:
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
Yet you claim they must report on non-inputs (see below):
He does. And yet he is content to discard actual input.
if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
is never simulated by HHH.
Certainly you understand unreachable code?
On 2025-08-26 16:29:41 +0000, olcott said:
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that
computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
A Turing machine never refuses to compute from their the behaviour of
its caller because it doesn't know that it has a caller, let alone the identity of the caller.
On 28/08/2025 15:10, olcott wrote:
On 8/27/2025 11:44 PM, Richard Heathfield wrote:
On 28/08/2025 04:50, dbush wrote:
On 8/27/2025 11:46 PM, olcott wrote:
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
Yet you claim they must report on non-inputs (see below):
He does. And yet he is content to discard actual input.
if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
is never simulated by HHH.
Certainly you understand unreachable code?
What unreachable code?
On 28/08/2025 15:08, olcott wrote:
On 8/27/2025 11:34 PM, Richard Heathfield wrote:
<snip>
The question is not "does DD halt under simulation?" but "does
DD halt?" And you have to include the whole function.
The question is: Does DD correctly simulated by HHH halt?
No, that's the question you want to answer. It's not the question the Halting Problem poses.
You keep ignoring that halt deciders only
COMPUTE THE MAPPING FROM THEIR INPUTS
Your input is (a pointer to)
int DD()
{
-a int Halt_Status = HHH(DD);
-a if (Halt_Status)
-a-a-a HERE: goto HERE;
-a return Halt_Status;
}
The only bit you bother with is
int DD()
{
-a HHH(DD);
You seem to think that you can pick and choose which behaviour you model.
Pathetic.
On 8/28/2025 9:39 AM, Richard Heathfield wrote:
On 28/08/2025 15:10, olcott wrote:
On 8/27/2025 11:44 PM, Richard Heathfield wrote:
On 28/08/2025 04:50, dbush wrote:
On 8/27/2025 11:46 PM, olcott wrote:
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
Yet you claim they must report on non-inputs (see below):
He does. And yet he is content to discard actual input.
if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
is never simulated by HHH.
Certainly you understand unreachable code?
What unreachable code?
You know that you are cheating Jackass.
On 8/28/2025 2:46 AM, Mikko wrote:
On 2025-08-26 16:29:41 +0000, olcott said:
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that
computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
A Turing machine never refuses to compute from their the behaviour of
its caller because it doesn't know that it has a caller, let alone the
identity of the caller.
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
if -n applied to rf?-nrf- halts, and
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if -n applied to rf?-nrf- does not halt.
Yet Linz requires -n.embedded_H rf?-nrf- rf?-nrf- to report
on the behavior of its caller: -n applied to rf?-nrf-
On 8/28/2025 9:32 AM, Richard Heathfield wrote:
On 28/08/2025 15:08, olcott wrote:
On 8/27/2025 11:34 PM, Richard Heathfield wrote:
<snip>
The question is not "does DD halt under simulation?" but "does
DD halt?" And you have to include the whole function.
The question is: Does DD correctly simulated by HHH halt?
No, that's the question you want to answer. It's not the
question the Halting Problem poses.
You keep ignoring that halt deciders only
COMPUTE THE MAPPING FROM THEIR INPUTS
Your input is (a pointer to)
int DD()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
The only bit you bother with is
int DD()
{
-a-a HHH(DD);
You seem to think that you can pick and choose which behaviour
you model.
Pathetic.
You know that you are lying.
_DD()
[00002162] 55-a-a-a-a-a-a-a-a push ebp
[00002163] 8bec-a-a-a-a-a-a mov ebp,esp
[00002165] 51-a-a-a-a-a-a-a-a push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
On 28/08/2025 15:58, olcott wrote:
On 8/28/2025 9:32 AM, Richard Heathfield wrote:
On 28/08/2025 15:08, olcott wrote:
On 8/27/2025 11:34 PM, Richard Heathfield wrote:
<snip>
The question is not "does DD halt under simulation?" but "does
DD halt?" And you have to include the whole function.
The question is: Does DD correctly simulated by HHH halt?
No, that's the question you want to answer. It's not the question the
Halting Problem poses.
You keep ignoring that halt deciders only
COMPUTE THE MAPPING FROM THEIR INPUTS
Your input is (a pointer to)
int DD()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
The only bit you bother with is
int DD()
{
-a-a HHH(DD);
You seem to think that you can pick and choose which behaviour you
model.
Pathetic.
You know that you are lying.
Are you now claiming that you can reach the code you said was unreachable?
_DD()
[00002162] 55-a-a-a-a-a-a-a-a push ebp
[00002163] 8bec-a-a-a-a-a-a mov ebp,esp
[00002165] 51-a-a-a-a-a-a-a-a push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
*****************************************************
Presumably this is where you halt your simulation (when you do halt it).
Instead of halting, why not replace the push and the call 000015d2 with
a mov of 0 into Halt_Status (because you know HHH would return 0) and
then keep simulating?
Bingo! Unreachable code becomes reachable.
Or explain why you don't.
*****************************************************
On 8/28/2025 10:45 AM, Richard Heathfield wrote:
On 28/08/2025 15:58, olcott wrote:
On 8/28/2025 9:32 AM, Richard Heathfield wrote:
On 28/08/2025 15:08, olcott wrote:
On 8/27/2025 11:34 PM, Richard Heathfield wrote:
<snip>
The question is not "does DD halt under simulation?" but "does
DD halt?" And you have to include the whole function.
The question is: Does DD correctly simulated by HHH halt?
No, that's the question you want to answer. It's not the
question the Halting Problem poses.
You keep ignoring that halt deciders only
COMPUTE THE MAPPING FROM THEIR INPUTS
Your input is (a pointer to)
int DD()
{
-a-a int Halt_Status = HHH(DD);
-a-a if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
The only bit you bother with is
int DD()
{
-a-a HHH(DD);
You seem to think that you can pick and choose which
behaviour you model.
Pathetic.
You know that you are lying.
Are you now claiming that you can reach the code you said was
unreachable?
_DD()
[00002162] 55-a-a-a-a-a-a-a-a push ebp
[00002163] 8bec-a-a-a-a-a-a mov ebp,esp
[00002165] 51-a-a-a-a-a-a-a-a push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
*****************************************************
Presumably this is where you halt your simulation (when you do
halt it).
Instead of halting, why not replace the push and the call
000015d2 with a mov of 0 into Halt_Status (because you know HHH
would return 0) and then keep simulating?
Bingo! Unreachable code becomes reachable.
Or explain why you don't.
*****************************************************
You and most everyone else here (besides Fred) knows
that is cheating. Mike would know this is cheating.
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
When we Unit Test DD(), we find that it halts.
When we Unit Test HHH(DD), we find that it returns 0.
Unit Testing establishes the ground truths.
The meaning of "HHH(DD)" is this: "does the Unit Test of DD halt?"
Unit Testing means probing the behavior of an expression, isolated into
its own program, run under prisitine initial condition so that there are
no interactions with previously run Unit Tests.
A Unit Test of an expression like DD() is this: a test case is created
with a main() which calls that expression before doing anything else,
and this is executed by a brand new instance of the x86utm which has not previously loaded and executed anything else.
All claims of yours that are refer to and are based on the behavior of
your apparatus, in which you are not using the Unit Test interpretation
of the expression terms being discussed, are simply incorrect.
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
That Turing machine halt deciders
only compute
the mapping from their inputs does entail that
HHH must report on the behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES*
This *is* correctly measured by DD correctly
simulated by HHH.
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
DD correctly simulated by HHH
makes sure that it
includes the changes to the behavior of DD that are
caused by the fact that DD is calling its own simulator
in recursive simulation.
For three years now everyone here has essentially said
that the correct thing to do is to ignore the fact that
DD calls HHH(DD) in recursive simulation and just make
pretend that it does not do this.
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping from their
inputs does entail that HHH must report on the behavior that *ITS ACTUAL INPUT ACTUALLY SPECIFIES*
When we Unit Test DD(), we find that it halts.I carefully studied all of this and my original comment still applies.
When we Unit Test HHH(DD), we find that it returns 0.
Unit Testing establishes the ground truths.
The meaning of "HHH(DD)" is this: "does the Unit Test of DD halt?"
Unit Testing means probing the behavior of an expression, isolated into
its own program, run under prisitine initial condition so that there
are no interactions with previously run Unit Tests.
A Unit Test of an expression like DD() is this: a test case is created
with a main() which calls that expression before doing anything else,
and this is executed by a brand new instance of the x86utm which has
not previously loaded and executed anything else.
All claims of yours that are refer to and are based on the behavior of
your apparatus, in which you are not using the Unit Test interpretation
of the expression terms being discussed, are simply incorrect.
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping from their
inputs does entail that HHH must report on the behavior that *ITS ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. Nothing
is stopping from computing its direct execution.
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping
from their
inputs does entail that HHH must report on the behavior that
*ITS ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD.
Nothing
is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping from their
inputs does entail that HHH must report on the behavior that *ITS
ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. Nothing
is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping
from their
inputs does entail that HHH must report on the behavior that
*ITS ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of
DD. Nothing
is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
-a Infinite_Recursion();
-a return;
}
Yet HHH(Infinite_Recursion) does report
because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
On 28/08/2025 22:04, olcott wrote:
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping from their >>>>>> inputs does entail that HHH must report on the behavior that *ITS >>>>>> ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. Nothing >>>>> is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
-a-a Infinite_Recursion();
-a-a return;
}
Yet HHH(Infinite_Recursion) does report
So it halts the simulation. Has to.
because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
Right. So it *has* to halt the simulation, so calling HHH(DD) is one way
to guarantee that the simulation halts.
Therefore, DD (correctly simulated) halts.
On 8/28/2025 4:11 PM, Richard Heathfield wrote:
On 28/08/2025 22:04, olcott wrote:
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping
from their
inputs does entail that HHH must report on the behavior
that *ITS ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of
DD. Nothing
is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
-a-a Infinite_Recursion();
-a-a return;
}
Yet HHH(Infinite_Recursion) does report
So it halts the simulation. Has to.
because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
Right. So it *has* to halt the simulation, so calling HHH(DD)
is one way to guarantee that the simulation halts.
Therefore, DD (correctly simulated) halts.
Not when Halting is properly defined as reaching a
final halt state. DD simulated by HHH never does that.
On 28/08/2025 22:32, olcott wrote:
On 8/28/2025 4:11 PM, Richard Heathfield wrote:
On 28/08/2025 22:04, olcott wrote:
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping from >>>>>>>> their
inputs does entail that HHH must report on the behavior that
*ITS ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD.
Nothing
is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
-a-a Infinite_Recursion();
-a-a return;
}
Yet HHH(Infinite_Recursion) does report
So it halts the simulation. Has to.
because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
Right. So it *has* to halt the simulation, so calling HHH(DD) is one
way to guarantee that the simulation halts.
Therefore, DD (correctly simulated) halts.
Not when Halting is properly defined as reaching a
final halt state. DD simulated by HHH never does that.
DD simulated by HHH is guaranteed to reach a final halt state because
HHH guarantees to halt it.
Either you halt it or you don't. You can't have it both ways.
I don't think that is the shell game. PO really /has/ an H--
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
On 8/28/2025 4:47 PM, Richard Heathfield wrote:
On 28/08/2025 22:32, olcott wrote:
On 8/28/2025 4:11 PM, Richard Heathfield wrote:
On 28/08/2025 22:04, olcott wrote:
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means! >>>>>>>>>>That Turing machine halt deciders only compute the
mapping from their
inputs does entail that HHH must report on the behavior
that *ITS ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code
of DD. Nothing
is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
-a-a Infinite_Recursion();
-a-a return;
}
Yet HHH(Infinite_Recursion) does report
So it halts the simulation. Has to.
because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
Right. So it *has* to halt the simulation, so calling HHH(DD)
is one way to guarantee that the simulation halts.
Therefore, DD (correctly simulated) halts.
Not when Halting is properly defined as reaching a
final halt state. DD simulated by HHH never does that.
DD simulated by HHH is guaranteed to reach a final halt state
because HHH guarantees to halt it.
Either you halt it or you don't. You can't have it both ways.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
On 28/08/2025 22:52, olcott wrote:
On 8/28/2025 4:47 PM, Richard Heathfield wrote:
On 28/08/2025 22:32, olcott wrote:
On 8/28/2025 4:11 PM, Richard Heathfield wrote:
On 28/08/2025 22:04, olcott wrote:
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means! >>>>>>>>>>>That Turing machine halt deciders only compute the mapping >>>>>>>>>> from their
inputs does entail that HHH must report on the behavior that >>>>>>>>>> *ITS ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. >>>>>>>>> Nothing
is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
-a-a Infinite_Recursion();
-a-a return;
}
Yet HHH(Infinite_Recursion) does report
So it halts the simulation. Has to.
because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
Right. So it *has* to halt the simulation, so calling HHH(DD) is
one way to guarantee that the simulation halts.
Therefore, DD (correctly simulated) halts.
Not when Halting is properly defined as reaching a
final halt state. DD simulated by HHH never does that.
DD simulated by HHH is guaranteed to reach a final halt state because
HHH guarantees to halt it.
Either you halt it or you don't. You can't have it both ways.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
Ben is rarely wrong. I think he's wrong here.
HHH claims to be a decider. *Therefore* it must halt. *Therefore* any function calling it can rely on the fact that it will return.
*Therefore* there can be no risk of infinite descent.
By calling HHH(DD), DD assures its own demise at the hands of its own
return statement.
*Therefore*, properly simulated, HHH(DD) should detect terminating behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach its own return statement, and so requiring HHH to return 0 after all, and so we
rock back and forth over the two choices, and it's literally impossible
to choose between them, *exactly* as Turing predicted.
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 8/28/2025 4:47 PM, Richard Heathfield wrote:
On 28/08/2025 22:32, olcott wrote:
On 8/28/2025 4:11 PM, Richard Heathfield wrote:
On 28/08/2025 22:04, olcott wrote:
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means! >>>>>>>>>>>>That Turing machine halt deciders only compute the mapping >>>>>>>>>>> from their
inputs does entail that HHH must report on the behavior that >>>>>>>>>>> *ITS ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. >>>>>>>>>> Nothing
is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
-a-a Infinite_Recursion();
-a-a return;
}
Yet HHH(Infinite_Recursion) does report
So it halts the simulation. Has to.
because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
Right. So it *has* to halt the simulation, so calling HHH(DD) is
one way to guarantee that the simulation halts.
Therefore, DD (correctly simulated) halts.
Not when Halting is properly defined as reaching a
final halt state. DD simulated by HHH never does that.
DD simulated by HHH is guaranteed to reach a final halt state
because HHH guarantees to halt it.
Either you halt it or you don't. You can't have it both ways.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
Ben is rarely wrong. I think he's wrong here.
HHH claims to be a decider. *Therefore* it must halt. *Therefore* any
function calling it can rely on the fact that it will return.
*Therefore* there can be no risk of infinite descent.
By calling HHH(DD), DD assures its own demise at the hands of its own
return statement.
*Therefore*, properly simulated, HHH(DD) should detect terminating
behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach its own
return statement, and so requiring HHH to return 0 after all, and so
we rock back and forth over the two choices, and it's literally
impossible to choose between them, *exactly* as Turing predicted.
Yes that is the way that cheaters think.
HHH(DD) has always correctly reported that DD
would never stop running unless aborted.
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 8/28/2025 4:47 PM, Richard Heathfield wrote:
Either you halt it or you don't. You can't have it both ways.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an Hdetermines
(it's trivial to do for this one case) that correctly
that P(P) *would* never stop running *unless* aborted.
Ben is rarely wrong. I think he's wrong here.
HHH claims to be a decider. *Therefore* it must halt.
*Therefore* any function calling it can rely on the fact that
it will return. *Therefore* there can be no risk of infinite
descent.
By calling HHH(DD), DD assures its own demise at the hands of
its own return statement.
*Therefore*, properly simulated, HHH(DD) should detect
terminating behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach
its own return statement, and so requiring HHH to return 0
after all, and so we rock back and forth over the two choices,
and it's literally impossible to choose between them, *exactly*
as Turing predicted.
Yes that is the way that cheaters think.
HHH(DD) has always correctly reported that DD
would never stop running unless aborted.
On 8/28/2025 6:13 PM, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
*Therefore*, properly simulated, HHH(DD) should detect
terminating behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach
its own return statement, and so requiring HHH to return 0
after all, and so we rock back and forth over the two choices,
and it's literally impossible to choose between them,
*exactly* as Turing predicted.
Yes that is the way that cheaters think.
HHH(DD) has always correctly reported that DD
would never stop running unless aborted.
In other words, if DD was changed into something that is no
longer DD.
Changing the input and reporting on that changed input is not
allowed.
On 28/08/2025 23:13, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 8/28/2025 4:47 PM, Richard Heathfield wrote:
<snip>
Either you halt it or you don't. You can't have it both ways.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
Ben is rarely wrong. I think he's wrong here.
HHH claims to be a decider. *Therefore* it must halt. *Therefore* any
function calling it can rely on the fact that it will return.
*Therefore* there can be no risk of infinite descent.
By calling HHH(DD), DD assures its own demise at the hands of its own
return statement.
*Therefore*, properly simulated, HHH(DD) should detect terminating
behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach its
own return statement, and so requiring HHH to return 0 after all, and
so we rock back and forth over the two choices, and it's literally
impossible to choose between them, *exactly* as Turing predicted.
Yes that is the way that cheaters think.
No, cheaters think they can ignore most of the code in a function and
still claim to "correctly simulate".
On 28/08/2025 23:24, dbush wrote:
On 8/28/2025 6:13 PM, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
<snip>
*Therefore*, properly simulated, HHH(DD) should detect terminating
behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach its
own return statement, and so requiring HHH to return 0 after all,
and so we rock back and forth over the two choices, and it's
literally impossible to choose between them, *exactly* as Turing
predicted.
Yes that is the way that cheaters think.
HHH(DD) has always correctly reported that DD
would never stop running unless aborted.
In other words, if DD was changed into something that is no longer DD.
Changing the input and reporting on that changed input is not allowed.
It hardly matters. Whatever he returns, he's screwed.
Even when he cheats, he loses.
On 8/28/2025 6:31 PM, Richard Heathfield wrote:
On 28/08/2025 23:24, dbush wrote:
Changing the input and reporting on that changed input is not
allowed.
It hardly matters. Whatever he returns, he's screwed.
Even when he cheats, he loses.
He attempts to sidestep things by claiming that the question to
be answered isn't the actual question to be answered.
He thinks the simulation *must* be correct because replacing HHH
with a pure simulator results in a DD that doesn't halt, not
understanding that he's changing the input by doing so.
And by that logic, since the simulation *must* be correct, the
answer of non-halting *must* be correct, therefore the question
that was asked was actually a different question.
This is faulty because:
* An aborted simulation by definition is not a correct simulation
* It's changing the entity to be decided on and reporting on what
was changed
* HHH is dead before it starts because of the execution_trace
variable in the static code area.-a This is an extra input to the
algorithm, and the spec for a halt decider takes *only* a
description of an algorithm (and that algorithm's input) as
input, so based on that alone HHH is not a halt decider.
On 28/08/2025 23:52, dbush wrote:
On 8/28/2025 6:31 PM, Richard Heathfield wrote:
On 28/08/2025 23:24, dbush wrote:
<snip>
Changing the input and reporting on that changed input is not allowed.
It hardly matters. Whatever he returns, he's screwed.
Even when he cheats, he loses.
He attempts to sidestep things by claiming that the question to be
answered isn't the actual question to be answered.
I sometimes think the question he's really asking is how long he can
keep this gag running. I am genuinely torn between "nobody can be this dense" and "just maybe they can".
If you make sure to put 100% of ALL of your
concentration into not hearing a word that
I say then you would get that view AND BE DISHONEST.
Turing machines that satisfy these requirements:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
DO NOT REPORT ON THE BEHAVIOR OF THEIR CALLER
THEY REPORT ON THE (in this case) RECURSIVE
SIMULATION BEHAVIOR OF THEIR INPUT !!!
Turing machine halt deciders
DO NOT REPORT ON THE BEHAVIOR OF THEIR CALLER
THEY REPORT ON THE (in this case) RECURSIVE
SIMULATION BEHAVIOR OF THEIR INPUT !!!
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
That Turing machine halt deciders only compute
the mapping from their inputs does entail that
HHH must report on the behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES*
This *is* correctly measured by DD correctly
simulated by HHH.
*Here is is again in terms of the Linz proof*
On 29/08/2025 00:20, olcott wrote:I AM SAYING THAT THIS APPLIES TO 100% OF ALL
<snip>
Turing machine halt deciders
DO NOT REPORT ON THE BEHAVIOR OF THEIR CALLER
THEY REPORT ON THE (in this case) RECURSIVE
SIMULATION BEHAVIOR OF THEIR INPUT !!!
No. A universal Turing machine halt decider,
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping from their
inputs does entail that HHH must report on the behavior that *ITS ACTUAL >>> INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. Nothing
is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping from their >>>>> inputs does entail that HHH must report on the behavior that *ITS
ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. Nothing >>>> is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
Infinite_Recursion();
return;
}
Yet HHH(Infinite_Recursion) does report because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
On 8/28/2025 6:45 PM, Richard Heathfield wrote:
On 29/08/2025 00:20, olcott wrote:I AM SAYING THAT THIS APPLIES TO 100% OF ALL
<snip>
Turing machine halt deciders
DO NOT REPORT ON THE BEHAVIOR OF THEIR CALLER
THEY REPORT ON THE (in this case) RECURSIVE
SIMULATION BEHAVIOR OF THEIR INPUT !!!
No. A universal Turing machine halt decider,
HALT DECIDERS INCLDUING THOSE THAT HAVE A
SINGLE ELEMENT IN THEIR ENTIRE DOMAIN.
On 8/28/2025 4:11 PM, Richard Heathfield wrote:
On 28/08/2025 22:04, olcott wrote:
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping from their >>>>>>> inputs does entail that HHH must report on the behavior that *ITS >>>>>>> ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. Nothing >>>>>> is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
-a-a Infinite_Recursion();
-a-a return;
}
Yet HHH(Infinite_Recursion) does report
So it halts the simulation. Has to.
because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
Right. So it *has* to halt the simulation, so calling HHH(DD) is one way
to guarantee that the simulation halts.
Therefore, DD (correctly simulated) halts.
Not when Halting is properly defined as reaching a
final halt state. DD simulated by HHH never does that.
On 8/28/2025 6:45 PM, Richard Heathfield wrote:
On 29/08/2025 00:20, olcott wrote:I AM SAYING THAT THIS APPLIES TO 100% OF ALL
<snip>
Turing machine halt deciders
DO NOT REPORT ON THE BEHAVIOR OF THEIR CALLER
THEY REPORT ON THE (in this case) RECURSIVE
SIMULATION BEHAVIOR OF THEIR INPUT !!!
No. A universal Turing machine halt decider,
HALT DECIDERS INCLDUING THOSE THAT HAVE A
SINGLE ELEMENT IN THEIR ENTIRE DOMAIN.
On 8/28/2025 6:13 PM, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 8/28/2025 4:47 PM, Richard Heathfield wrote:
On 28/08/2025 22:32, olcott wrote:
On 8/28/2025 4:11 PM, Richard Heathfield wrote:
On 28/08/2025 22:04, olcott wrote:
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>> On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means! >>>>>>>>>>>>>That Turing machine halt deciders only compute the mapping >>>>>>>>>>>> from their
inputs does entail that HHH must report on the behavior that >>>>>>>>>>>> *ITS ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. >>>>>>>>>>> Nothing
is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
-a-a Infinite_Recursion();
-a-a return;
}
Yet HHH(Infinite_Recursion) does report
So it halts the simulation. Has to.
because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
Right. So it *has* to halt the simulation, so calling HHH(DD) is >>>>>>> one way to guarantee that the simulation halts.
Therefore, DD (correctly simulated) halts.
Not when Halting is properly defined as reaching a
final halt state. DD simulated by HHH never does that.
DD simulated by HHH is guaranteed to reach a final halt state
because HHH guarantees to halt it.
Either you halt it or you don't. You can't have it both ways.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
Ben is rarely wrong. I think he's wrong here.
HHH claims to be a decider. *Therefore* it must halt. *Therefore* any
function calling it can rely on the fact that it will return.
*Therefore* there can be no risk of infinite descent.
By calling HHH(DD), DD assures its own demise at the hands of its own
return statement.
*Therefore*, properly simulated, HHH(DD) should detect terminating
behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach its own
return statement, and so requiring HHH to return 0 after all, and so
we rock back and forth over the two choices, and it's literally
impossible to choose between them, *exactly* as Turing predicted.
Yes that is the way that cheaters think.
HHH(DD) has always correctly reported that DD
would never stop running unless aborted.
In other words, if DD was changed into something that is no longer DD.
Changing the input and reporting on that changed input is not allowed.
He thinks the simulation *must* be correct because replacing HHH with a
pure simulator results in a DD that doesn't halt, not understanding that he's changing the input by doing so.
On 8/28/2025 6:14 PM, Richard Heathfield wrote:
On 28/08/2025 23:52, dbush wrote:
On 8/28/2025 6:31 PM, Richard Heathfield wrote:
On 28/08/2025 23:24, dbush wrote:
<snip>
Changing the input and reporting on that changed input is not allowed. >>>>It hardly matters. Whatever he returns, he's screwed.
Even when he cheats, he loses.
He attempts to sidestep things by claiming that the question to be
answered isn't the actual question to be answered.
I sometimes think the question he's really asking is how long he can
keep this gag running. I am genuinely torn between "nobody can be this
dense" and "just maybe they can".
If you make sure to put 100% of ALL of your
concentration into not hearing a word that
I say then you would get that view AND BE DISHONEST.
Turing machine halt deciders
DO NOT REPORT ON THE BEHAVIOR OF THEIR CALLER
THEY REPORT ON THE (in this case) RECURSIVE
SIMULATION BEHAVIOR OF THEIR INPUT !!!
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
DD correctly simulated by HHH makes sure that it
includes the changes to the behavior of DD that are
caused by the fact that DD is calling its own simulator
in recursive simulation.
For three years now everyone here has essentially said
that the correct thing to do is to ignore the fact that
DD calls HHH(DD) in recursive simulation and just make
pretend that it does not do this.
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
That Turing machine halt deciders only compute
the mapping from their inputs does entail that
HHH must report on the behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES*
If there is any difference between a top-level being executed other than
by HHH, and the DD which is processed by the HHH(DD) expression inside
DD itself, then you have a problem.
But, never mind, we sidestep dealing with such a problem by insisting on
the Unit Test interpretation: HHH(DD) must decide what is the halting behavior of DD in an isolated Unit Test in which nothing but DD is
executed. Whatever HHH(DD) return is interpreted as a comment on the Unit-Tested DD, and not the nonsensical interpretation that it is a
comment on the modified DD that was simulated by the second HHH call
that takes place /in/ DD.
Let us make the change that x86utm stands for "unit test machine".
This *is* correctly measured by DD correctly
simulated by HHH.
DD isn't correctly simulated because it behaves differently from its
Unit Test semantics.
The simulator /per se/ (interpreter of x86 instructions) is functioning correctly enough; the problem is that DD was diddled before being
presented to the simulator.
That doesn't matter, as long as we insist that all expressions denote
their their Unit Test semantics, HHH can edit its own code or that of DD
all it wants.
*Here is is again in terms of the Linz proof*
Linz has something even better "Unit Test semantics" in his work;
everything he describes exists in isolation and has fixed semantics.
It doesn't behave differently in this or that context.
On 8/28/2025 7:06 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody >>>>>> gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
That Turing machine halt deciders only compute
the mapping from their inputs does entail that
HHH must report on the behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES*
If there is any difference between a top-level being executed other than
by HHH, and the DD which is processed by the HHH(DD) expression inside
DD itself, then you have a problem.
First you must understand that the measure of the behavior
of the input to HHH(DD) is only DD correctly simulated by
HHH that takes into account rather than ignores that DD
does call HHH in recursive simulation.
Second you must understand that HHH(DD) is only responsible
for reporting on the above behavior that its actual input
actually specifies. This means that the behavior of the
caller of HHH(DD) (that can be an executed DD) has nothing
to do with the correctness of HHH rejecting its input.
But, never mind, we sidestep dealing with such a problem by insisting on
the Unit Test interpretation: HHH(DD) must decide what is the halting
behavior of DD in an isolated Unit Test in which nothing but DD is
executed. Whatever HHH(DD) return is interpreted as a comment on the
Unit-Tested DD, and not the nonsensical interpretation that it is a
comment on the modified DD that was simulated by the second HHH call
that takes place /in/ DD.
Let us make the change that x86utm stands for "unit test machine".
This *is* correctly measured by DD correctly
simulated by HHH.
DD isn't correctly simulated because it behaves differently from its
Unit Test semantics.
When you measure this by the semantics of the
x86 language then this overrules everything else.
DD correctly emulated by HHH cannot possibly ever
get past its own [0000216b] machine address.
I am just saying that the actual execution trace
cannot by truthfully denied.
DD correctly simulated
by HHH cannot possibly reach its own final state.
On 2025-08-29, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 7:06 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody >>>>>>> gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
That Turing machine halt deciders only compute
the mapping from their inputs does entail that
HHH must report on the behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES*
If there is any difference between a top-level being executed other than >>> by HHH, and the DD which is processed by the HHH(DD) expression inside
DD itself, then you have a problem.
First you must understand that the measure of the behavior
of the input to HHH(DD) is only DD correctly simulated by
HHH that takes into account rather than ignores that DD
does call HHH in recursive simulation.
No, I don't understand taht; it is complete nonsense.
The symbol DD refers to the Unit Test semantics of the computation DD()
executed in a freshly instantiated x86utm (x86 Unit Test Machine),
regardless of the existence of any derived DD' embroiled in
a nested simulation which has different semantics from DD.
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines
that P(P) *would* never stop running *unless* aborted.
If we correctly use apostrophes to label the different procedures
we find these truths:
- DD() halts
- DD'() does not halt
- DD() calls HHH(DD), which returns 0. That's why DD() halts.
- The first call to HHH(DD) creates HHH' by mutating itself, thereby creating DD'.
After this, any subsequent call to HHH or DD is actually HHH' and DD'.
- HHH'(DD') enters into recursive simulation.
- The top-level HHH(DD) returns 0 due to simulating and analyzing DD'
which calls HHH'(DD'). This 0 return value is true if interpreted
as a statement about DD'
However:
- HHH(DD) is required to make a statement about the halting of DD,
not the halting of DD', and therefore its return value is
correctly interpreted as a remark about DD and not DD',
and that remark is incorrect.
Any disagreement of yours with the above arises from deliberately
conflating DD and DD' and HHH and HHH'.
It's all about the statements you are making and the interpretation
of the symbols in them, not about the correctness of the execution
traces by themselves. The traces are what they are; your inference
from them is completely invalid.
Second you must understand that HHH(DD) is only responsible
for reporting on the above behavior that its actual input
actually specifies. This means that the behavior of the
caller of HHH(DD) (that can be an executed DD) has nothing
to do with the correctness of HHH rejecting its input.
But, never mind, we sidestep dealing with such a problem by insisting on >>> the Unit Test interpretation: HHH(DD) must decide what is the halting
behavior of DD in an isolated Unit Test in which nothing but DD is
executed. Whatever HHH(DD) return is interpreted as a comment on the
Unit-Tested DD, and not the nonsensical interpretation that it is a
comment on the modified DD that was simulated by the second HHH call
that takes place /in/ DD.
Let us make the change that x86utm stands for "unit test machine".
This *is* correctly measured by DD correctly
simulated by HHH.
DD isn't correctly simulated because it behaves differently from its
Unit Test semantics.
When you measure this by the semantics of the
x86 language then this overrules everything else.
No, it doesn't overrule. You need the x86 language /and/ a clean initial power up state of that x86 machine.
DD correctly emulated by HHH cannot possibly ever
get past its own [0000216b] machine address.
Yet, in a clean x86utm machine, if the first thing we do is call DD(),
it terminates, cheerfully getting past that machine address.
That establishes the ground truth for what DD() is.
What does not get past that address is DD'() not DD().
You have superimposed DD' over DD by self-modifyiing code
(or, equivalently, static variables, in an earlier incarnation).
I am just saying that the actual execution trace
cannot by truthfully denied.
What can be denied is its interpretation, in which
you talk about DD and DD' as if they were one and the same.
They have the same name in the C code. DD is the
Unit Test semantics of the call DD(). DD' is the
altered semantics in the recursive simulation.
One halts, the other doesn't; how the hell can they
be the same?
DD correctly simulated
by HHH cannot possibly reach its own final state.
DD' correctly simualted by HHH' cannot reach its own final state.
Changing HHH to HHH' and DD to DD' and then saying DD cannot reach its
final state is a horrible equivocation over symbols.
On 29/08/2025 01:07, olcott wrote:
On 8/28/2025 6:45 PM, Richard Heathfield wrote:
On 29/08/2025 00:20, olcott wrote:I AM SAYING THAT THIS APPLIES TO 100% OF ALL
<snip>
Turing machine halt deciders
DO NOT REPORT ON THE BEHAVIOR OF THEIR CALLER
THEY REPORT ON THE (in this case) RECURSIVE
SIMULATION BEHAVIOR OF THEIR INPUT !!!
No. A universal Turing machine halt decider,
HALT DECIDERS INCLDUING THOSE THAT HAVE A
SINGLE ELEMENT IN THEIR ENTIRE DOMAIN.
Yeah, I get that. Thing is, though - and I realise this may come as a
shock - you saying it doesn't necessarily make it so.
On 8/28/2025 8:12 PM, Kaz Kylheku wrote:FALSE!!!
You have superimposed DD' over DD by self-modifyiing code
(or, equivalently, static variables, in an earlier incarnation).
No self modifying code.
On 8/28/2025 7:22 PM, Richard Heathfield wrote:
On 29/08/2025 01:07, olcott wrote:
On 8/28/2025 6:45 PM, Richard Heathfield wrote:
On 29/08/2025 00:20, olcott wrote:I AM SAYING THAT THIS APPLIES TO 100% OF ALL
<snip>
Turing machine halt deciders
DO NOT REPORT ON THE BEHAVIOR OF THEIR CALLER
THEY REPORT ON THE (in this case) RECURSIVE
SIMULATION BEHAVIOR OF THEIR INPUT !!!
No. A universal Turing machine halt decider,
HALT DECIDERS INCLDUING THOSE THAT HAVE A
SINGLE ELEMENT IN THEIR ENTIRE DOMAIN.
Yeah, I get that. Thing is, though - and I realise this may
come as a shock - you saying it doesn't necessarily make it so.
The definition of deciders makes it so.
No Turing machine halt decider can ever
report in the behavior of its own caller.
On 8/28/2025 8:12 PM, Kaz Kylheku wrote:
On 2025-08-29, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 7:06 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody >>>>>>>> gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
That Turing machine halt deciders only compute
the mapping from their inputs does entail that
HHH must report on the behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES*
If there is any difference between a top-level being executed other than >>>> by HHH, and the DD which is processed by the HHH(DD) expression inside >>>> DD itself, then you have a problem.
First you must understand that the measure of the behavior
of the input to HHH(DD) is only DD correctly simulated by
HHH that takes into account rather than ignores that DD
does call HHH in recursive simulation.
No, I don't understand taht; it is complete nonsense.
The symbol DD refers to the Unit Test semantics of the computation DD()
Not really. DD as the actual input to HHH is a
finite string of machine code.
As the actual
input to HHH it does specify that DD does call
its own simulator in recursive simulation.
Everyone on this forum has been trying to get
away with denying that for three years.
Changing HHH to HHH' and DD to DD' and then saying DD cannot reach its
final state is a horrible equivocation over symbols.
DD and HHH simulated by HHH cannot possibly reach
their final halt state.
On 29/08/2025 02:56, olcott wrote:
On 8/28/2025 7:22 PM, Richard Heathfield wrote:
On 29/08/2025 01:07, olcott wrote:
On 8/28/2025 6:45 PM, Richard Heathfield wrote:
On 29/08/2025 00:20, olcott wrote:I AM SAYING THAT THIS APPLIES TO 100% OF ALL
<snip>
Turing machine halt deciders
DO NOT REPORT ON THE BEHAVIOR OF THEIR CALLER
THEY REPORT ON THE (in this case) RECURSIVE
SIMULATION BEHAVIOR OF THEIR INPUT !!!
No. A universal Turing machine halt decider,
HALT DECIDERS INCLDUING THOSE THAT HAVE A
SINGLE ELEMENT IN THEIR ENTIRE DOMAIN.
Yeah, I get that. Thing is, though - and I realise this may come as a
shock - you saying it doesn't necessarily make it so.
The definition of deciders makes it so.
No, it doesn't.
No Turing machine halt decider can ever
report in the behavior of its own caller.
A TM decider, should one exist, would be required to report on the TM specified on the tape.
The whole tape, not just the first five minutes.
No Turing machine halt decider can ever
report in the behavior of its own caller.
On 2025-08-29, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 8:12 PM, Kaz Kylheku wrote:
On 2025-08-29, olcott <polcott333@gmail.com> wrote:
First you must understand that the measure of the behavior
of the input to HHH(DD) is only DD correctly simulated by
HHH that takes into account rather than ignores that DD
does call HHH in recursive simulation.
No, I don't understand taht; it is complete nonsense.
The symbol DD refers to the Unit Test semantics of the computation DD()
Not really. DD as the actual input to HHH is a
finite string of machine code.
No, it isn't. It is several strings of machine code, one of which
is self-modifying, which splits DD into two functions.
It is an easily verified fact, as you love to say,
that if *DD calls HHH (as it does) and HHH calls DD*
(as, *through simulation, it effectively does) that*
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
The strings of machine code that make up DD are:
- the string of machine code from the compiled DD definition
- the string of machine code from HHH.
- the strings of machine code in all subroutines called by HHH,
and their transitive closure: the entire call graph.
- that includes the x86 simulator code.
The string of machine code HHH changes when HHH is called for the first
time, which we can interpret as giving rise to alternative functionw
HHH' and DD'.
For that reason, we must insist on the Unit Test semantics.
DD refers only to the top-level DD() invoked in isolation in a new,
fresh instance of the x86utm, in which HHH has not been called and not modified the static data.
As the actual
input to HHH it does specify that DD does call
its own simulator in recursive simulation.
In a new instance of the x86utm in which the first thing that
is called is HHH(DD), DD clearly refers to the original DD.
And it is the input to HHH. However, as you say, it is not the input HHH under simulation.
But HHH changes itself to HHH' which creates DD'. By the time DD
is simulated, it has become DD' and the expression HHH(DD) that
it calls is actually HHH'(DD').
There is a modified HHH' being simulated and its input is DD'.
DD' is not DD.
Everyone on this forum has been trying to get
away with denying that for three years.
Nobody is going to agree with you for as long as you keep insisting
that two entities with /different properties/ are the /same object/.
Do you see?
Because that is complete idiocy.
In Philosophy if A and B are the same object, it means that
A and B cannot differ in any property whatsoever.
(The dummy variable names by which they are referenced, A and B, are not properties; if objects being referenced by the variables A and B have a "name" property and A and B are the same object, then they have the same
name property. E.g. A.name == B.name == "Bob".)
You are making a deep mistake which strikes at your credibility
as a basic critical thinker.
Changing HHH to HHH' and DD to DD' and then saying DD cannot reach its
final state is a horrible equivocation over symbols.
DD and HHH simulated by HHH cannot possibly reach
their final halt state.
DD is never simulated by HHH in your apparatus while you
apparatus makes use of static fuses. Rather, something
we can call DD' is simulated by HHH'.
When you remove all references to the static data from the
source code, then there is only one HHH and one DD. Then it is
true that DD is simulated by HHH and cannot reach its return
statement.
But, in that situation, the Unit Test semantics of HHH(DD)
is that HHH(DD) never returns. It no longer returns 0.
Correctly, the Unit Test semantics of HHH(DD) (that expression
being run on the host processor in a fresh instance of the x86utm,
as the first action) is then identical to the simulated semantics:
both denote a non-halting computation.
While you have the static stuff in the code, you have DD',
which you'are wrongly calling DD even though it has different
properties.
On 2025-08-29, olcott <polcott333@gmail.com> wrote:
No Turing machine halt decider can ever
report in the behavior of its own caller.
Only in the sense that there is no such thing.
"Caller" is not among the properties of a Turing Machine object.
It's a set of symbols, a tape with initial contents, and so on.
If some discussion identifies something called "its caller"
that a Turing Machine can report on, that discussion must
be using the term "its caller" for something represented among
the initial symbols stored on the tape.
On 2025-08-28, dbush <dbush.mobile@gmail.com> wrote:
On 8/28/2025 6:13 PM, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 8/28/2025 4:47 PM, Richard Heathfield wrote:
On 28/08/2025 22:32, olcott wrote:
On 8/28/2025 4:11 PM, Richard Heathfield wrote:
On 28/08/2025 22:04, olcott wrote:
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>>> On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means! >>>>>>>>>>>>>>That Turing machine halt deciders only compute the mapping >>>>>>>>>>>>> from their
inputs does entail that HHH must report on the behavior that >>>>>>>>>>>>> *ITS ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. >>>>>>>>>>>> Nothing
is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
-a-a Infinite_Recursion();
-a-a return;
}
Yet HHH(Infinite_Recursion) does report
So it halts the simulation. Has to.
because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
Right. So it *has* to halt the simulation, so calling HHH(DD) is >>>>>>>> one way to guarantee that the simulation halts.
Therefore, DD (correctly simulated) halts.
Not when Halting is properly defined as reaching a
final halt state. DD simulated by HHH never does that.
DD simulated by HHH is guaranteed to reach a final halt state
because HHH guarantees to halt it.
Either you halt it or you don't. You can't have it both ways.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>> -a> that P(P) *would* never stop running *unless* aborted.
Ben is rarely wrong. I think he's wrong here.
HHH claims to be a decider. *Therefore* it must halt. *Therefore* any
function calling it can rely on the fact that it will return.
*Therefore* there can be no risk of infinite descent.
By calling HHH(DD), DD assures its own demise at the hands of its own
return statement.
*Therefore*, properly simulated, HHH(DD) should detect terminating
behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach its own >>>> return statement, and so requiring HHH to return 0 after all, and so
we rock back and forth over the two choices, and it's literally
impossible to choose between them, *exactly* as Turing predicted.
Yes that is the way that cheaters think.
HHH(DD) has always correctly reported that DD
would never stop running unless aborted.
In other words, if DD was changed into something that is no longer DD.
Changing the input and reporting on that changed input is not allowed.
Sure it is allowed; and any literal Turing Machine based on a head
and tape works by constantly making alterations to the tape,
after all. Any representation of an input to a Turing Machine solving
any problem whatsoever will likely get destructively clobbered.
What's not allowed is taking DD, deriving a different procedure DD'
(whether purely or by mutating DD), analyzing the derived DD' instead of
DD and then *dishonestly* insisting that statements which are true
about DD' are actually talking about the original DD.
DD always refers to the original DD, which in the present Halt7.c is
defined such that DD() is a halting computation according to its Unit
Test semantics.
This means that when DD() is executed in isolation in a
brand new x86utm_exe instance, without any other test case code run
before it that could sneakily modify static state, that's the behavior
which is the source of truth about whether DD is halting or not. If it
so happens that DD() launches some recursive simulations of DD which
behave differently, those are irrelevant; those do not have the Unit
Test semantics. They are allowed to exist, but we do not allow
them being talked about as if they were DD.
On 8/28/2025 11:07 PM, Kaz Kylheku wrote:
On 2025-08-29, olcott <polcott333@gmail.com> wrote:
No Turing machine halt decider can ever
report in the behavior of its own caller.
Only in the sense that there is no such thing.
When I say decider I also include a decider with a domain
of one single finite string. When I use the proper term
partial halt decider most people here get confused.
M.H rf?Mrf- rf?Mrf- cannot report M rf?Mrf- because no TM
can take another TM as its actual input.
On 8/28/2025 7:26 PM, Kaz Kylheku wrote:
DD always refers to the original DD, which in the present Halt7.c is
defined such that DD() is a halting computation according to its Unit
Test semantics.
Not when you get rid of the static data DD() never halts.
I dropped the use of the static data in my
reference to HHH when you first mentioned it.
Now we either have an HHH(DD) that cannot
recognize the repeating state of its input
that never stops running
OR
We have an HHH that by some other means
detects the repeating state of its input
and it somehow does this as a pure function
of its input.
As the actual
input to HHH it does specify that DD does call
its own simulator in recursive simulation.
In a new instance of the x86utm in which the first thing that
is called is HHH(DD), DD clearly refers to the original DD.
HHH never has its own caller as its input.
The HHH(DD) refers only to a finite string
of x86 machine code.
On 8/28/2025 9:06 PM, Richard Heathfield wrote:
On 29/08/2025 02:56, olcott wrote:
On 8/28/2025 7:22 PM, Richard Heathfield wrote:
On 29/08/2025 01:07, olcott wrote:
On 8/28/2025 6:45 PM, Richard Heathfield wrote:
On 29/08/2025 00:20, olcott wrote:I AM SAYING THAT THIS APPLIES TO 100% OF ALL
<snip>
Turing machine halt deciders
DO NOT REPORT ON THE BEHAVIOR OF THEIR CALLER
THEY REPORT ON THE (in this case) RECURSIVE
SIMULATION BEHAVIOR OF THEIR INPUT !!!
No. A universal Turing machine halt decider,
HALT DECIDERS INCLDUING THOSE THAT HAVE A
SINGLE ELEMENT IN THEIR ENTIRE DOMAIN.
Yeah, I get that. Thing is, though - and I realise this may come as
a shock - you saying it doesn't necessarily make it so.
The definition of deciders makes it so.
No, it doesn't.
No Turing machine halt decider can ever
report in the behavior of its own caller.
A TM decider, should one exist, would be required to report on the TM
specified on the tape.
The whole tape, not just the first five minutes.
Only the initial input that is on the tape.
On 8/28/2025 5:29 PM, Richard Heathfield wrote:
On 28/08/2025 23:13, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 8/28/2025 4:47 PM, Richard Heathfield wrote:
<snip>
Either you halt it or you don't. You can't have it both ways.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>> -a> that P(P) *would* never stop running *unless* aborted.
Ben is rarely wrong. I think he's wrong here.
HHH claims to be a decider. *Therefore* it must halt. *Therefore*
any function calling it can rely on the fact that it will return.
*Therefore* there can be no risk of infinite descent.
By calling HHH(DD), DD assures its own demise at the hands of its
own return statement.
*Therefore*, properly simulated, HHH(DD) should detect terminating
behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach its
own return statement, and so requiring HHH to return 0 after all,
and so we rock back and forth over the two choices, and it's
literally impossible to choose between them, *exactly* as Turing
predicted.
Yes that is the way that cheaters think.
No, cheaters think they can ignore most of the code in a function and
still claim to "correctly simulate".
void Infinite_Recursion()
{
-a Infinite_Recursion();
-a printf("Never gets here without cheating!\n");
-a return;
}
On 8/28/2025 7:26 PM, Kaz Kylheku wrote:More like olcott is misunderstanding him. Note the rCRunlessrCY: it is a counterfactual, since DD *is* in fact aborted.
On 2025-08-28, dbush <dbush.mobile@gmail.com> wrote:
On 8/28/2025 6:13 PM, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:Ben is rarely wrong. I think he's wrong here.
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly
determines that P(P) *would* never stop running *unless*
aborted.
Of course. A bounded loop doesnrCOt halt either when you take out the termination check. That is neither here nor there.What's not allowed is taking DD, deriving a different procedure DD'Not when you get rid of the static data DD() never halts.
(whether purely or by mutating DD), analyzing the derived DD' instead
of DD and then *dishonestly* insisting that statements which are true
about DD' are actually talking about the original DD.
DD always refers to the original DD, which in the present Halt7.c is
defined such that DD() is a halting computation according to its Unit
Test semantics.
Ah, but HHH doesnrCOt report on the direct execution, but on itself ;-)This means that when DD() is executed in isolation in a
brand new x86utm_exe instance, without any other test case code run
before it that could sneakily modify static state, that's the behavior
which is the source of truth about whether DD is halting or not. If it
so happens that DD() launches some recursive simulations of DD which
behave differently, those are irrelevant; those do not have the Unit
Test semantics. They are allowed to exist, but we do not allow them
being talked about as if they were DD.
On 8/27/2025 11:44 PM, Richard Heathfield wrote:
On 28/08/2025 04:50, dbush wrote:
On 8/27/2025 11:46 PM, olcott wrote:
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
Yet you claim they must report on non-inputs (see below):
He does. And yet he is content to discard actual input.
if (Halt_Status)
-a-a-a HERE: goto HERE;
-a return Halt_Status;
}
is never simulated by HHH.
Certainly you understand unreachable code?
void Infinite_Loop()
{
HERE: goto HERE;
printf("I never get here you dumb bunny!\n");
return;
}
On 8/27/2025 11:34 PM, Richard Heathfield wrote:
On 28/08/2025 05:21, olcott wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
<snip>
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
No, it isn't. It's the key that proves you don't get the question. Your
"decider" demonstrates very neatly that HHH cannot correctly analyse
DD. It can't even /see/ DD!
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
Well, you forgot the last three lines of DD. Careless.
The question is not "does DD halt under simulation?" but "does
DD halt?" And you have to include the whole function.
The question is: Does DD correctly simulated by HHH halt?
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
That Turing machine halt deciders only compute
the mapping from their inputs does entail that
HHH must report on the behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES*
On 8/28/2025 2:46 AM, Mikko wrote:
On 2025-08-26 16:29:41 +0000, olcott said:
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
A Turing machine never refuses to compute from their the behaviour of
its caller because it doesn't know that it has a caller, let alone the
identity of the caller.
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
if -n applied to rf?-nrf- halts, and
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if -n applied to rf?-nrf- does not halt.
Yet Linz requires -n.embedded_H rf?-nrf- rf?-nrf- to report
on the behavior of its caller: -n applied to rf?-nrf-
On 2025-08-29, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 7:26 PM, Kaz Kylheku wrote:
DD always refers to the original DD, which in the present Halt7.c is
defined such that DD() is a halting computation according to its Unit
Test semantics.
Not when you get rid of the static data DD() never halts.
Yes; but then all instances of the expression HHH(DD) do not halt; you
never get your HHH(DD) -> 0 result.
You will never get a HHH(DD) -> 0 for a non-halting DD other than
by faking the appearance of the result with the help of
invalid communication between simulation levels equivalent
to the current static data.
On 2025-08-29, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 11:07 PM, Kaz Kylheku wrote:
On 2025-08-29, olcott <polcott333@gmail.com> wrote:
No Turing machine halt decider can ever
report in the behavior of its own caller.
Only in the sense that there is no such thing.
When I say decider I also include a decider with a domain
of one single finite string. When I use the proper term
partial halt decider most people here get confused.
When you use the term partial halt decider, it means "not a total
decider". I.e. the only kind of decider that the Halting
Theorem says you we can have.
M.H rf?Mrf- rf?Mrf- cannot report M rf?Mrf- because no TM
can take another TM as its actual input.
What? Of course it can.
Part of the initial tape content of a TM can be (some representation of)
the content of some other TM's tape.
The TM can then somehow try calculate whether that representation is
the initial tape contents of a halting TM or a of non-halting TM.
On 2025-08-29, olcott <polcott333@gmail.com> wrote:
I dropped the use of the static data in my
reference to HHH when you first mentioned it.
Great. So what does HHH(DD) return now?
Now we either have an HHH(DD) that cannot
recognize the repeating state of its input
that never stops running
OR
We have an HHH that by some other means
detects the repeating state of its input
and it somehow does this as a pure function
of its input.
If we "have" it we wrote the code. If so, why the "somehow"?
It's a logical impossibility. If HHH is pure, then every instance of
HHH(DD) denotes the same computation and result, by the definition of
what it means to be pure.
Every instance including the one in DD.
As the actual
input to HHH it does specify that DD does call
its own simulator in recursive simulation.
In a new instance of the x86utm in which the first thing that
is called is HHH(DD), DD clearly refers to the original DD.
HHH never has its own caller as its input.
The HHH(DD) refers only to a finite string
of x86 machine code.
Without the mutating static data, you do not have anything to
equivocate on. The DD() simulated by HHH is starkly identical
to a DD() called as a isolated Unit Test.
Since that DD() calls HHH, HHH(DD) has its own caller as input.
The DD that can be called in isolation as a Unit Test is exactly the
same item as the DD in the HHH(DD) expression found in the body of DD.
You cannot switch to pure functions, yet keep these
impossible distinctions like DD that is serving as input to HHH
versus DD that isn't.
int Pseudo_HHH(ptr x)
{
-a x();
-a return 1;
}
int DD()
{
-a int Halt_Status = Pseudo_HHH(DD);
-a if (Halt_Status)
-a-a-a HERE: goto HERE;
-a return Halt_Status;
}
HHH(DD)==0 as a pure function of its input.
All five LLM systems abstracted away the
extraneous details and performed a similar
analysis.
Am Thu, 28 Aug 2025 23:19:31 -0500 schrieb olcott:
On 8/28/2025 7:26 PM, Kaz Kylheku wrote:
On 2025-08-28, dbush <dbush.mobile@gmail.com> wrote:
On 8/28/2025 6:13 PM, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:Ben is rarely wrong. I think he's wrong here.
-a> I don't think that is the shell game. PO really /has/ an H >>>>>>> -a> (it's trivial to do for this one case) that correctly
-a> determines that P(P) *would* never stop running *unless*
-a> aborted.
More like olcott is misunderstanding him. Note the rCRunlessrCY: it is a counterfactual, since DD *is* in fact aborted.
Of course. A bounded loop doesnrCOt halt either when you take out the termination check. That is neither here nor there.What's not allowed is taking DD, deriving a different procedure DD'Not when you get rid of the static data DD() never halts.
(whether purely or by mutating DD), analyzing the derived DD' instead
of DD and then *dishonestly* insisting that statements which are true
about DD' are actually talking about the original DD.
DD always refers to the original DD, which in the present Halt7.c is
defined such that DD() is a halting computation according to its Unit
Test semantics.
This means that when DD() is executed in isolation in a
brand new x86utm_exe instance, without any other test case code run
before it that could sneakily modify static state, that's the behavior
which is the source of truth about whether DD is halting or not. If it
so happens that DD() launches some recursive simulations of DD which
behave differently, those are irrelevant; those do not have the Unit
Test semantics. They are allowed to exist, but we do not allow them
being talked about as if they were DD.
Ah, but HHH doesnrCOt report on the direct execution, but on itself ;-)--
Op 29.aug.2025 om 00:49 schreef olcott:
On 8/28/2025 5:29 PM, Richard Heathfield wrote:
On 28/08/2025 23:13, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 8/28/2025 4:47 PM, Richard Heathfield wrote:
<snip>
Either you halt it or you don't. You can't have it both ways.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>>> -a> that P(P) *would* never stop running *unless* aborted.
Ben is rarely wrong. I think he's wrong here.
HHH claims to be a decider. *Therefore* it must halt. *Therefore*
any function calling it can rely on the fact that it will return.
*Therefore* there can be no risk of infinite descent.
By calling HHH(DD), DD assures its own demise at the hands of its
own return statement.
*Therefore*, properly simulated, HHH(DD) should detect terminating
behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach its
own return statement, and so requiring HHH to return 0 after all,
and so we rock back and forth over the two choices, and it's
literally impossible to choose between them, *exactly* as Turing
predicted.
Yes that is the way that cheaters think.
No, cheaters think they can ignore most of the code in a function and
still claim to "correctly simulate".
void Infinite_Recursion()
{
-a-a Infinite_Recursion();
-a-a printf("Never gets here without cheating!\n");
-a-a return;
}
As usual irrelevant. Nobody said that Infinite_Recursion halts.
But the input specifying a DD based on an aborting HHH specifies only a finite recursion.
void Finite_Recursion () {
-a static int N = 5;
-a if (N > 0) Finite_Recursion ();
-a printf ("Olcott thinks this is never printed.\n");
}
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping from their >>>>>> inputs does entail that HHH must report on the behavior that *ITS
ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. Nothing >>>>> is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
Infinite_Recursion();
return;
}
Yet HHH(Infinite_Recursion) does report because
it can see the repeating pattern.
HHH can correctly decide this Infinite_Recursion procedure because that procedure isn't the instance (DD) of the Diagonal (D) test case template which embeds the decider and behaves in a contradictory m anner.
DD correctly simulated by HHH has this exact same
repeating pattern.
If HHH(DD) returns 0, and the simulated DD still has this pattern,
it means that something is seriously wrong, because HHH(DD) returning
zero requires DD to halt.
The simulated DD is a decoy which doesn't conform to the Unit Test
semantics of DD, defined by the behavior of DD started in complete
isolation in a brand new x86utm_exe instance.
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 4:11 PM, Richard Heathfield wrote:
On 28/08/2025 22:04, olcott wrote:
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping from their >>>>>>>> inputs does entail that HHH must report on the behavior that *ITS >>>>>>>> ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. Nothing >>>>>>> is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
-a-a Infinite_Recursion();
-a-a return;
}
Yet HHH(Infinite_Recursion) does report
So it halts the simulation. Has to.
because
it can see the repeating pattern.
DD correctly simulated by HHH has this exact same
repeating pattern.
Right. So it *has* to halt the simulation, so calling HHH(DD) is one way >>> to guarantee that the simulation halts.
Therefore, DD (correctly simulated) halts.
Not when Halting is properly defined as reaching a
final halt state. DD simulated by HHH never does that.
"DD simulated by HHH" is a decoy that HHH produced by tampering with DD.
The procedure HHH didn't tamper with the instructions of the C
procedure DD directly. Rather, it tampered with itself.
DD is built on HHH, so tampering with HHH changes the behavior of DD;
it becomes a different procedure such that DD() no longer has the
Unit Test semantics of DD() (which is all that matters, the only
rationally permissible source of truth).
On 2025-08-28, dbush <dbush.mobile@gmail.com> wrote:
He thinks the simulation *must* be correct because replacing HHH with a
pure simulator results in a DD that doesn't halt, not understanding that
he's changing the input by doing so.
Anyone who doesn't understand that if we have:
extern void g(void);
void f(void) { g(); }
then the function g is a part of f, such that changing the definition/behavior of g changes the definition/behavior of f ...
... is not even remotely a competent software engineer or computer scientist.
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 6:14 PM, Richard Heathfield wrote:
On 28/08/2025 23:52, dbush wrote:
On 8/28/2025 6:31 PM, Richard Heathfield wrote:
On 28/08/2025 23:24, dbush wrote:
<snip>
Changing the input and reporting on that changed input is not allowed. >>>>>It hardly matters. Whatever he returns, he's screwed.
Even when he cheats, he loses.
He attempts to sidestep things by claiming that the question to be
answered isn't the actual question to be answered.
I sometimes think the question he's really asking is how long he can
keep this gag running. I am genuinely torn between "nobody can be this
dense" and "just maybe they can".
If you make sure to put 100% of ALL of your
concentration into not hearing a word that
I say then you would get that view AND BE DISHONEST.
Turing machine halt deciders
DO NOT REPORT ON THE BEHAVIOR OF THEIR CALLER
THEY REPORT ON THE (in this case) RECURSIVE
SIMULATION BEHAVIOR OF THEIR INPUT !!!
While that is true,
In your apparatus, the x86utm_exe and its Halt7.o test case,
this is not the case.
The behavior of HHH and DD is being informed of the calling context
due to examining and mutating a static variable that is shared
between instances of HHH.
The HHH that is invoked by DD is precisely doing that which
you are above saying halt deciders do not do! It is reporting
on a behavior of its caller, because its caller (HHH grandparent two
levels up) diddled a static variable, which is observed by
the HHH grandchild.
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
DD correctly simulated by HHH makes sure that it
includes the changes to the behavior of DD that are
caused by the fact that DD is calling its own simulator
in recursive simulation.
No because, a wise man once said:
Turing machine halt deciders
DO NOT REPORT ON THE BEHAVIOR OF THEIR CALLER
THEY REPORT ON THE (in this case) RECURSIVE
SIMULATION BEHAVIOR OF THEIR INPUT !!!
Including changes which are perpetrated by a caller amounts to reporting
on the behavior of the caller.
For three years now everyone here has essentially said
that the correct thing to do is to ignore the fact that
DD calls HHH(DD) in recursive simulation and just make
pretend that it does not do this.
The correct thing is for HHH not to mutate itself into
something else which changes it into HHH', which then changes
DD into DD'.
Failing that, if there must be DD', then stop insisting that statements
which are true of DD' (DD' is in an infinite, nonterminating
simulation) are actually true of DD (which isn't and cheerfully
terminates).
Use apostrophes to correctly denote the versions of the procedures that
exist and make sure the correct statements are applied to the symbols
with correct numbers of apostrophes which match those statements.
On 2025-08-28 14:48:35 +0000, olcott said:
On 8/28/2025 2:46 AM, Mikko wrote:
On 2025-08-26 16:29:41 +0000, olcott said:
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing
machines.
If the mapping is uncomputable there is no Turing machine that
computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
A Turing machine never refuses to compute from their the behaviour of
its caller because it doesn't know that it has a caller, let alone the
identity of the caller.
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
if -n applied to rf?-nrf- halts, and
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if -n applied to rf?-nrf- does not halt.
Yet Linz requires -n.embedded_H rf?-nrf- rf?-nrf- to report
on the behavior of its caller: -n applied to rf?-nrf-
Linz does not require anything about -n.embedded_H rf?-nrf- rf?-nrf-. He only infers from the construction what it might do and evaluates the
consequences of every possibility that can't be excluded.
On 2025-08-28 19:24:56 +0000, olcott said:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody
gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
That Turing machine halt deciders only compute
the mapping from their inputs does entail that
HHH must report on the behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES*
No, there is no such entailment. Never heard of Hume's guillotine? https://en.wikipedia.org/wiki/Is%E2%80%93ought_problem
On 2025-08-28 14:08:09 +0000, olcott said:
On 8/27/2025 11:34 PM, Richard Heathfield wrote:
On 28/08/2025 05:21, olcott wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
<snip>
If you really understood the question you would realise that nobody >>>>> gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
No, it isn't. It's the key that proves you don't get the question.
Your "decider" demonstrates very neatly that HHH cannot correctly
analyse DD. It can't even /see/ DD!
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
Well, you forgot the last three lines of DD. Careless.
The question is not "does DD halt under simulation?" but "does
DD halt?" And you have to include the whole function.
The question is: Does DD correctly simulated by HHH halt?
That is your question. Others ask other questions.
On 8/28/2025 7:15 PM, Kaz Kylheku wrote:
The simulated DD is a decoy which doesn't conform to the Unit Test
semantics of DD, defined by the behavior of DD started in complete
isolation in a brand new x86utm_exe instance.
It is an easily verified fact that DD correctly
simulated by HHH cannot possibly reach its "return"
statement final halt state because the input to
HHH(DD) specifies recursive simulation that is
equivalent to mutual recursion.
When people deny easily verified facts they are
not telling the truth.
*DD simulated by HHH as a pure function of its input*
cannot possibly reach its "return" statement
On 8/29/2025 3:25 AM, Mikko wrote:
On 2025-08-28 14:08:09 +0000, olcott said:
On 8/27/2025 11:34 PM, Richard Heathfield wrote:
On 28/08/2025 05:21, olcott wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
<snip>
If you really understood the question you would realise that nobody >>>>>> gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
No, it isn't. It's the key that proves you don't get the question. Your >>>> "decider" demonstrates very neatly that HHH cannot correctly analyse
DD. It can't even /see/ DD!
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
Well, you forgot the last three lines of DD. Careless.
The question is not "does DD halt under simulation?" but "does
DD halt?" And you have to include the whole function.
The question is: Does DD correctly simulated by HHH halt?
That is your question. Others ask other questions.
That is the only question that takes into
account the fact that DD does call HHH in
recursive simulation, thus provides the
actual behavior that the input to HHH(DD)
actually specifies.
On 8/29/2025 2:41 AM, Fred. Zwarts wrote:
Op 29.aug.2025 om 00:49 schreef olcott:
On 8/28/2025 5:29 PM, Richard Heathfield wrote:
On 28/08/2025 23:13, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 8/28/2025 4:47 PM, Richard Heathfield wrote:
<snip>
Either you halt it or you don't. You can't have it both ways.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>>>> -a> that P(P) *would* never stop running *unless* aborted.
Ben is rarely wrong. I think he's wrong here.
HHH claims to be a decider. *Therefore* it must halt. *Therefore* >>>>>> any function calling it can rely on the fact that it will return. >>>>>> *Therefore* there can be no risk of infinite descent.
By calling HHH(DD), DD assures its own demise at the hands of its >>>>>> own return statement.
*Therefore*, properly simulated, HHH(DD) should detect terminating >>>>>> behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach its >>>>>> own return statement, and so requiring HHH to return 0 after all, >>>>>> and so we rock back and forth over the two choices, and it's
literally impossible to choose between them, *exactly* as Turing
predicted.
Yes that is the way that cheaters think.
No, cheaters think they can ignore most of the code in a function
and still claim to "correctly simulate".
void Infinite_Recursion()
{
-a-a Infinite_Recursion();
-a-a printf("Never gets here without cheating!\n");
-a-a return;
}
As usual irrelevant. Nobody said that Infinite_Recursion halts.
It is the same thing with recursive simulation,
yet simply too difficult for you to understand.
When HHH(DD) reaches its abort criteria (if it can)
then it aborts its simulation of DD such that no
DD can possibly have any behavior at all such as
stack unwinding.
But the input specifying a DD based on an aborting HHH specifies only
a finite recursion.
void Infinite_Recursion()
{
-a Infinite_Recursion();
-a return;
}
HHH(Infinite_Recursion) also only has finite
recursion so the measure is:
Can Infinite_Recursion correctly simulated by
HHH possibly reach its own "return" statement
final halt state?
void Finite_Recursion () {
-a-a static int N = 5;
-a-a if (N > 0) Finite_Recursion ();
-a-a printf ("Olcott thinks this is never printed.\n");
}
On 8/29/2025 12:07 AM, Kaz Kylheku wrote:
On 2025-08-29, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 7:26 PM, Kaz Kylheku wrote:
DD always refers to the original DD, which in the present Halt7.c is
defined such that DD() is a halting computation according to its Unit
Test semantics.
Not when you get rid of the static data DD() never halts.
Yes; but then all instances of the expression HHH(DD) do not halt; you
never get your HHH(DD) -> 0 result.
You will never get a HHH(DD) -> 0 for a non-halting DD other than
by faking the appearance of the result with the help of
invalid communication between simulation levels equivalent
to the current static data.
So we hypothesize two cases:
(a) HHH(DD) never halts
(b) HHH(DD) sees the repeating state as a pure function of its input.
On 8/29/2025 3:33 AM, Mikko wrote:Requiring HHH(DD) to report on a DD based on another hypothetical HHH
On 2025-08-28 19:24:56 +0000, olcott said:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody >>>>>> gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
That Turing machine halt deciders only compute
the mapping from their inputs does entail that
HHH must report on the behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES*
No, there is no such entailment. Never heard of Hume's guillotine?
https://en.wikipedia.org/wiki/Is%E2%80%93ought_problem
int sum(int x, int y){return x + y;}
requiring sum(3,5) to report on the sum of 5 + 7
is an incorrect requirement.
On 8/29/2025 2:53 AM, joes wrote:
Am Thu, 28 Aug 2025 23:19:31 -0500 schrieb olcott:
On 8/28/2025 7:26 PM, Kaz Kylheku wrote:
On 2025-08-28, dbush <dbush.mobile@gmail.com> wrote:
On 8/28/2025 6:13 PM, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:Ben is rarely wrong. I think he's wrong here.
I don't think that is the shell game. PO really /has/ an H >>>>>>>> -a> (it's trivial to do for this one case) that correctly
determines that P(P) *would* never stop running *unless*
aborted.
More like olcott is misunderstanding him. Note the rCRunlessrCY: it is a
counterfactual, since DD *is* in fact aborted.
*This is the full context*
*Best selling author of theory of computation textbooks*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 8/29/2025 2:41 AM, Fred. Zwarts wrote:
Op 29.aug.2025 om 00:49 schreef olcott:
On 8/28/2025 5:29 PM, Richard Heathfield wrote:
On 28/08/2025 23:13, olcott wrote:
On 8/28/2025 5:09 PM, Richard Heathfield wrote:
On 28/08/2025 22:52, olcott wrote:
On 8/28/2025 4:47 PM, Richard Heathfield wrote:
<snip>
Either you halt it or you don't. You can't have it both ways.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
I don't think that is the shell game. PO really /has/ an H
(it's trivial to do for this one case) that correctly determines >>>>>>> -a> that P(P) *would* never stop running *unless* aborted.
Ben is rarely wrong. I think he's wrong here.
HHH claims to be a decider. *Therefore* it must halt. *Therefore* any >>>>>> function calling it can rely on the fact that it will return.
*Therefore* there can be no risk of infinite descent.
By calling HHH(DD), DD assures its own demise at the hands of its own >>>>>> return statement.
*Therefore*, properly simulated, HHH(DD) should detect terminating behaviour...
...and return 1, thereby guaranteeing that DD will *not* reach its own >>>>>> return statement, and so requiring HHH to return 0 after all, and so we >>>>>> rock back and forth over the two choices, and it's literally impossible >>>>>> to choose between them, *exactly* as Turing predicted.
Yes that is the way that cheaters think.
No, cheaters think they can ignore most of the code in a function and >>>> still claim to "correctly simulate".
void Infinite_Recursion()
{
-a-a Infinite_Recursion();
-a-a printf("Never gets here without cheating!\n");
-a-a return;
}
As usual irrelevant. Nobody said that Infinite_Recursion halts.
It is the same thing with recursive simulation,
yet simply too difficult for you to understand.
When HHH(DD) reaches its abort criteria (if it can)
then it aborts its simulation of DD such that no
DD can possibly have any behavior at all such as
stack unwinding.
But the input specifying a DD based on an aborting HHH specifies only a
finite recursion.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
HHH(Infinite_Recursion) also only has finite
recursion so the measure is:
Can Infinite_Recursion correctly simulated by
HHH possibly reach its own "return" statement
final halt state?
On 8/28/2025 7:15 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/28/2025 4:00 PM, Richard Heathfield wrote:
On 28/08/2025 21:40, olcott wrote:void Infinite_Recursion()
On 8/28/2025 3:35 PM, joes wrote:
Am Thu, 28 Aug 2025 14:24:56 -0500 schrieb olcott:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
No, it isn't. You don't get to dictate what HHH(DD) means!That Turing machine halt deciders only compute the mapping from their >>>>>>> inputs does entail that HHH must report on the behavior that *ITS >>>>>>> ACTUAL
INPUT ACTUALLY SPECIFIES*
No, it must compute *from* the input, which is the code of DD. Nothing >>>>>> is stopping from computing its direct execution.
The call from DD to HHH(DD) (its own simulator)
prevents this DD (not some other DD somewhere else)
from ever halting.
But if that's true, HHH never reports.
{
Infinite_Recursion();
return;
}
Yet HHH(Infinite_Recursion) does report because
it can see the repeating pattern.
HHH can correctly decide this Infinite_Recursion procedure because that
procedure isn't the instance (DD) of the Diagonal (D) test case template
which embeds the decider and behaves in a contradictory m anner.
DD correctly simulated by HHH has this exact same
repeating pattern.
If HHH(DD) returns 0, and the simulated DD still has this pattern,
it means that something is seriously wrong, because HHH(DD) returning
zero requires DD to halt.
The simulated DD is a decoy which doesn't conform to the Unit Test
semantics of DD, defined by the behavior of DD started in complete
isolation in a brand new x86utm_exe instance.
It is an easily verified fact that DD correctly
simulated by HHH cannot possibly reach its "return"
statement final halt state because the input to
HHH(DD) specifies recursive simulation that is
equivalent to mutual recursion.
When people deny easily verified facts they are
not telling the truth.
On 8/29/2025 3:33 AM, Mikko wrote:
On 2025-08-28 19:24:56 +0000, olcott said:
On 8/28/2025 12:28 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
On 8/27/2025 11:12 PM, Richard Heathfield wrote:
If you really understood the question you would realise that nobody >>>>>> gives a damn whether DD halts when being simulated.
This is the key that proves the HP proofs are incorrect.
DD simulated by HHH is a correct measure the behavior
that the input to HHH(DD) specifies.
No, it isn't.
You don't get to dictate what HHH(DD) means!
That Turing machine halt deciders only compute
the mapping from their inputs does entail that
HHH must report on the behavior that
*ITS ACTUAL INPUT ACTUALLY SPECIFIES*
No, there is no such entailment. Never heard of Hume's guillotine?
https://en.wikipedia.org/wiki/Is%E2%80%93ought_problem
int sum(int x, int y){return x + y;}
requiring sum(3,5) to report on the sum of 5 + 7
is an incorrect requirement.
Requiring HHH(DD) to report on the behavior of
its caller is this same mistake.
On 8/28/2025 7:35 PM, Kaz Kylheku wrote:If only! Instead it descends into infinitely recursive simulation.
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
That only effects the means of reporting and does not have any effect onTuring machine halt deciders DO NOT REPORT ON THE BEHAVIOR OF THEIR
CALLER THEY REPORT ON THE (in this case) RECURSIVE SIMULATION BEHAVIOR
OF THEIR INPUT !!!
While that is true,
In your apparatus, the x86utm_exe and its Halt7.o test case,
this is not the case.
The behavior of HHH and DD is being informed of the calling context due
to examining and mutating a static variable that is shared between
instances of HHH.
the behavior. An LLM system is smart enough to determine that the
behavior of mutual recursion is equivalent to DD correctly simulated by
HHH. If HHH was this smart then it could perform this pseudo execution
trace and return 0 on this basis.
rCain the way that it chooses to manipulate it, which isnrCOt much ofThe HHH that is invoked by DD is precisely doing that which you areFactually incorrect. The directly executed outermost HHH is only
above saying halt deciders do not do! It is reporting on a behavior of
its caller, because its caller (HHH grandparent two levels up) diddled
a static variable, which is observed by the HHH grandchild.
reporting on the behavior of its input data that it manipulates.
On 8/29/2025 3:38 AM, Mikko wrote:
On 2025-08-28 14:48:35 +0000, olcott said:
On 8/28/2025 2:46 AM, Mikko wrote:
On 2025-08-26 16:29:41 +0000, olcott said:
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing >>>>>> machines.
If the mapping is uncomputable there is no Turing machine that computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
A Turing machine never refuses to compute from their the behaviour of
its caller because it doesn't know that it has a caller, let alone the >>>> identity of the caller.
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
if -n applied to rf?-nrf- halts, and
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if -n applied to rf?-nrf- does not halt.
Yet Linz requires -n.embedded_H rf?-nrf- rf?-nrf- to report
on the behavior of its caller: -n applied to rf?-nrf-
Linz does not require anything about -n.embedded_H rf?-nrf- rf?-nrf-. He only
infers from the construction what it might do and evaluates the
consequences of every possibility that can't be excluded.
*Quoted from above and the requirement that I referred to*
if -n applied to rf?-nrf- does not halt.
if -n applied to rf?-nrf- does not halt.
-n.embedded_H rf?-nrf- rf?-nrf- is required to report on the
behavior of its caller -n rf?-nrf-.
On 8/27/2025 11:44 PM, Richard Heathfield wrote:
On 28/08/2025 04:50, dbush wrote:
On 8/27/2025 11:46 PM, olcott wrote:
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
Yet you claim they must report on non-inputs (see below):
He does. And yet he is content to discard actual input.
if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
is never simulated by HHH.
Certainly you understand unreachable code?
void Infinite_Loop()
{
-a HERE: goto HERE;
-a printf("I never get here you dumb bunny!\n");
-a return;
}
On 8/28/25 10:10 AM, olcott wrote:
On 8/27/2025 11:44 PM, Richard Heathfield wrote:
On 28/08/2025 04:50, dbush wrote:
On 8/27/2025 11:46 PM, olcott wrote:
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
Yet you claim they must report on non-inputs (see below):
He does. And yet he is content to discard actual input.
if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
is never simulated by HHH.
Certainly you understand unreachable code?
void Infinite_Loop()
{
-a-a HERE: goto HERE;
-a-a printf("I never get here you dumb bunny!\n");
-a-a return;
}
But the code in DD isn't unreachable, at least if HHH meets its
requirement to be a decider.
It is just not reachable in the simulation done by HHH because it
doesn't do a correct simulation of it.
On 30/08/2025 13:37, Richard Damon wrote:
On 8/28/25 10:10 AM, olcott wrote:
On 8/27/2025 11:44 PM, Richard Heathfield wrote:
On 28/08/2025 04:50, dbush wrote:
On 8/27/2025 11:46 PM, olcott wrote:
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
Yet you claim they must report on non-inputs (see below):
He does. And yet he is content to discard actual input.
if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
is never simulated by HHH.
Certainly you understand unreachable code?
void Infinite_Loop()
{
-a-a HERE: goto HERE;
-a-a printf("I never get here you dumb bunny!\n");
-a-a return;
}
But the code in DD isn't unreachable, at least if HHH meets its
requirement to be a decider.
It is just not reachable in the simulation done by HHH because it
doesn't do a correct simulation of it.
I've already explained to him how he could fix it, but he clearly isn't interested in correct simulation.
As usual incorrect and irrelevant claims.
I perfectly understand that a finite recursion is different from an
infinite recursion.
Am Fri, 29 Aug 2025 12:06:42 -0500 schrieb olcott:
On 8/28/2025 7:35 PM, Kaz Kylheku wrote:
On 2025-08-28, olcott <polcott333@gmail.com> wrote:
If only! Instead it descends into infinitely recursive simulation.That only effects the means of reporting and does not have any effect onTuring machine halt deciders DO NOT REPORT ON THE BEHAVIOR OF THEIR
CALLER THEY REPORT ON THE (in this case) RECURSIVE SIMULATION BEHAVIOR >>>> OF THEIR INPUT !!!
While that is true,
In your apparatus, the x86utm_exe and its Halt7.o test case,
this is not the case.
The behavior of HHH and DD is being informed of the calling context due
to examining and mutating a static variable that is shared between
instances of HHH.
the behavior. An LLM system is smart enough to determine that the
behavior of mutual recursion is equivalent to DD correctly simulated by
HHH. If HHH was this smart then it could perform this pseudo execution
trace and return 0 on this basis.
The static variable directly affects the abort decision by making it unconditional.
rCain the way that it chooses to manipulate it, which isnrCOt much ofThe HHH that is invoked by DD is precisely doing that which you areFactually incorrect. The directly executed outermost HHH is only
above saying halt deciders do not do! It is reporting on a behavior of
its caller, because its caller (HHH grandparent two levels up) diddled
a static variable, which is observed by the HHH grandchild.
reporting on the behavior of its input data that it manipulates.
a statement at all.
On 30/08/2025 13:37, Richard Damon wrote:
On 8/28/25 10:10 AM, olcott wrote:
On 8/27/2025 11:44 PM, Richard Heathfield wrote:
On 28/08/2025 04:50, dbush wrote:
On 8/27/2025 11:46 PM, olcott wrote:
If you really understood Turing machine deciders you
would already know that they only compute the mapping
from their actual input finite strings.
Yet you claim they must report on non-inputs (see below):
He does. And yet he is content to discard actual input.
if (Halt_Status)
-a-a-a-a HERE: goto HERE;
-a-a return Halt_Status;
}
is never simulated by HHH.
Certainly you understand unreachable code?
void Infinite_Loop()
{
-a-a HERE: goto HERE;
-a-a printf("I never get here you dumb bunny!\n");
-a-a return;
}
But the code in DD isn't unreachable, at least if HHH meets its
requirement to be a decider.
It is just not reachable in the simulation done by HHH because it
doesn't do a correct simulation of it.
I've already explained to him how he could fix it, but he clearly isn't interested in correct simulation.
On 29/08/2025 17:46, olcott wrote:
On 8/28/2025 7:15 PM, Kaz Kylheku wrote:
<snip>
The simulated DD is a decoy which doesn't conform to the Unit Test
semantics of DD, defined by the behavior of DD started in complete
isolation in a brand new x86utm_exe instance.
It is an easily verified fact that DD correctly
simulated by HHH cannot possibly reach its "return"
statement final halt state because the input to
HHH(DD) specifies recursive simulation that is
equivalent to mutual recursion.
It is an easily verified fact that
int main(void)
{
-a DD();
-a return 0;
}
halts. Several of us /have/ verified that fact (easily).
When people deny easily verified facts they are
not telling the truth.
Er... quite so.
A halting decider that can't figure out the same easily verified fact is
not doing its job.
On 29/08/2025 17:46, olcott wrote:
On 8/28/2025 7:15 PM, Kaz Kylheku wrote:
<snip>
The simulated DD is a decoy which doesn't conform to the Unit Test
semantics of DD, defined by the behavior of DD started in complete
isolation in a brand new x86utm_exe instance.
It is an easily verified fact that DD correctly
simulated by HHH cannot possibly reach its "return"
statement final halt state because the input to
HHH(DD) specifies recursive simulation that is
equivalent to mutual recursion.
It is an easily verified fact that
int main(void)
{
-a DD();
-a return 0;
}
halts. Several of us /have/ verified that fact (easily).
On 29/08/2025 17:49, olcott wrote:
*DD simulated by HHH as a pure function of its input*
cannot possibly reach its "return" statement
So what you're saying is that HHH is incapable of correctly analysing
the halting behaviour of DD (which is known to halt).
On 8/29/2025 2:23 PM, Richard Heathfield wrote:
It is an easily verified fact that
int main(void)
{
-a-a DD();
-a-a return 0;
}
halts. Several of us /have/ verified that fact (easily).
DD.exe is executed.
DD.exe calls HHH(DD).exe
HHH.exe simulates DD.sim1
DD.sim1 calls HHH(DD).sim1
HHH.sim1 simulates DD.sim2
DD.sim2 calls HHH(DD).sim2 ... This would repeat unless aborted
On 2025-08-29 17:19:32 +0000, olcott said:
On 8/29/2025 3:38 AM, Mikko wrote:
On 2025-08-28 14:48:35 +0000, olcott said:
On 8/28/2025 2:46 AM, Mikko wrote:
On 2025-08-26 16:29:41 +0000, olcott said:
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing >>>>>>> machines.
If the mapping is uncomputable there is no Turing machine that
computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
A Turing machine never refuses to compute from their the behaviour of >>>>> its caller because it doesn't know that it has a caller, let alone the >>>>> identity of the caller.
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
if -n applied to rf?-nrf- halts, and
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if -n applied to rf?-nrf- does not halt.
Yet Linz requires -n.embedded_H rf?-nrf- rf?-nrf- to report
on the behavior of its caller: -n applied to rf?-nrf-
Linz does not require anything about -n.embedded_H rf?-nrf- rf?-nrf-. He only
infers from the construction what it might do and evaluates the
consequences of every possibility that can't be excluded.
*Quoted from above and the requirement that I referred to*
if -n applied to rf?-nrf- does not halt.
if -n applied to rf?-nrf- does not halt.
That is not neither a requirement nor a condition but a condition.
-n.embedded_H rf?-nrf- rf?-nrf- is required to report on the
behavior of its caller -n rf?-nrf-.
Linz does not specify any requirements on -n or any part of it. Instead
-n is fully specified with a construction from H.
On 30/08/2025 16:52, olcott wrote:
On 8/29/2025 2:23 PM, Richard Heathfield wrote:
<snip>
It is an easily verified fact that
int main(void)
{
-a-a DD();
-a-a return 0;
}
halts. Several of us /have/ verified that fact (easily).
DD.exe is executed.
DD.exe calls HHH(DD).exe
HHH.exe simulates DD.sim1
DD.sim1 calls HHH(DD).sim1
HHH.sim1 simulates DD.sim2
DD.sim2 calls HHH(DD).sim2 ... This would repeat unless aborted
Nonsense. It can't. HHH *must* return and *does* return.
On 8/30/2025 10:55 AM, Richard Heathfield wrote:
On 30/08/2025 16:52, olcott wrote:
On 8/29/2025 2:23 PM, Richard Heathfield wrote:
<snip>
It is an easily verified fact that
int main(void)
{
-a-a DD();
-a-a return 0;
}
halts. Several of us /have/ verified that fact (easily).
DD.exe is executed.
DD.exe calls HHH(DD).exe
HHH.exe simulates DD.sim1
DD.sim1 calls HHH(DD).sim1
HHH.sim1 simulates DD.sim2
DD.sim2 calls HHH(DD).sim2 ... This would repeat unless aborted
Nonsense. It can't. HHH *must* return and *does* return.
HHH.exe is required to return.
HHH.sim1 cannot possibly return any requirement
to the contrary is simply counter-factual.
On 8/30/2025 10:55 AM, Richard Heathfield wrote:
On 30/08/2025 16:52, olcott wrote:
On 8/29/2025 2:23 PM, Richard Heathfield wrote:
<snip>
It is an easily verified fact that
int main(void)
{
-a-a DD();
-a-a return 0;
}
halts. Several of us /have/ verified that fact (easily).
DD.exe is executed.
DD.exe calls HHH(DD).exe
HHH.exe simulates DD.sim1
DD.sim1 calls HHH(DD).sim1
HHH.sim1 simulates DD.sim2
DD.sim2 calls HHH(DD).sim2 ... This would repeat unless aborted
Nonsense. It can't. HHH *must* return and *does* return.
HHH.exe is required to return.
On 8/29/2025 2:24 PM, Richard Heathfield wrote:
On 29/08/2025 17:49, olcott wrote:
*DD simulated by HHH as a pure function of its input*
cannot possibly reach its "return" statement
So what you're saying is that HHH is incapable of correctly
analysing the halting behaviour of DD (which is known to halt).
DD.exe is executed.
DD.exe calls HHH(DD).exe
HHH.exe simulates DD.sim1
DD.sim1 calls HHH(DD).sim1
HHH.sim1 simulates DD.sim2
DD.sim2 calls HHH(DD).sim2 ... This would repeat unless aborted
if aborted then DD.exe halts
HHH(DD).exe is only being asked about DD.sim1.
On 8/29/2025 2:24 PM, Richard Heathfield wrote:
On 29/08/2025 17:49, olcott wrote:
*DD simulated by HHH as a pure function of its input*
cannot possibly reach its "return" statement
So what you're saying is that HHH is incapable of correctly analysing
the halting behaviour of DD (which is known to halt).
DD.exe is executed.
DD.exe calls HHH(DD).exe
HHH.exe simulates DD.sim1
DD.sim1 calls HHH(DD).sim1
HHH.sim1 simulates DD.sim2
DD.sim2 calls HHH(DD).sim2 ... This would repeat unless aborted
if aborted then DD.exe halts
HHH(DD).exe is only being asked about DD.sim1.
On 8/30/2025 10:55 AM, Richard Heathfield wrote:That is to say, it doesn't repeat because it is aborted.
On 30/08/2025 16:52, olcott wrote:
On 8/29/2025 2:23 PM, Richard Heathfield wrote:
It is an easily verified fact thatDD.exe is executed.
int main(void) {
-a-a DD();
return 0;
}
halts. Several of us /have/ verified that fact (easily).
DD.exe calls HHH(DD).exe
HHH.exe simulates DD.sim1
DD.sim1 calls HHH(DD).sim1
HHH.sim1 simulates DD.sim2
DD.sim2 calls HHH(DD).sim2 ...
This would repeat unless aborted
Nonsense. It can't. HHH *must* return and *does* return.
HHH.exe is required to return.Requirements aren't factual or not, they are fulfilled or not.
HHH.sim1 cannot possibly return any requirement to the contrary is
simply counter-factual.
On 8/29/2025 2:24 PM, Richard Heathfield wrote:
On 29/08/2025 17:49, olcott wrote:
*DD simulated by HHH as a pure function of its input*
cannot possibly reach its "return" statement
So what you're saying is that HHH is incapable of correctly analysing
the halting behaviour of DD (which is known to halt).
DD.exe is executed.
DD.exe calls HHH(DD).exe
HHH.exe simulates DD.sim1
DD.sim1 calls HHH(DD).sim1
HHH.sim1 simulates DD.sim2
DD.sim2 calls HHH(DD).sim2 ... This would repeat unless aborted
if aborted then DD.exe halts
HHH(DD).exe is only being asked about DD.sim1.
On 8/30/2025 5:42 AM, Mikko wrote:
On 2025-08-29 17:19:32 +0000, olcott said:
On 8/29/2025 3:38 AM, Mikko wrote:
On 2025-08-28 14:48:35 +0000, olcott said:
On 8/28/2025 2:46 AM, Mikko wrote:
On 2025-08-26 16:29:41 +0000, olcott said:
On 8/26/2025 4:29 AM, Mikko wrote:
On 2025-08-20 16:20:21 +0000, olcott said:
Turing machine deciders only compute the mapping
from their inputs...
Not the mapping but some computable mapping. And so do other Turing >>>>>>>> machines.
If the mapping is uncomputable there is no Turing machine that computes it.
Turing machines never compute the mapping
from their own behavior or the behavior
of their caller.
A Turing machine never refuses to compute from their the behaviour of >>>>>> its caller because it doesn't know that it has a caller, let alone the >>>>>> identity of the caller.
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.reR,
if -n applied to rf?-nrf- halts, and
-n.q0 rf?-nrf- reo* -n.embedded_H rf?-nrf- rf?-nrf- reo* -n.qn
if -n applied to rf?-nrf- does not halt.
Yet Linz requires -n.embedded_H rf?-nrf- rf?-nrf- to report
on the behavior of its caller: -n applied to rf?-nrf-
Linz does not require anything about -n.embedded_H rf?-nrf- rf?-nrf-. He only
infers from the construction what it might do and evaluates the
consequences of every possibility that can't be excluded.
*Quoted from above and the requirement that I referred to*
if -n applied to rf?-nrf- does not halt.
if -n applied to rf?-nrf- does not halt.
That is not neither a requirement nor a condition but a condition.
It is not a condition because it is a condition?
As Dennis Bush keeps saying *it is a requirement*
Original Linz Turing Machine H
H.q0 rf?Mrf- w reo* H.qy
if M applied to w halts, and
H.q0 rf?Mrf- w reo* H.qn
if M applied to w does not halt
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
-n.embedded_H rf?-nrf- rf?-nrf- is required to report on the
behavior of its caller -n rf?-nrf-.
Linz does not specify any requirements on -n or any part of it. Instead
-n is fully specified with a construction from H.
That you can't pay attention is not a rebuttal.
On 8/30/2025 3:25 AM, Fred. Zwarts wrote:
As usual incorrect and irrelevant claims.
I perfectly understand that a finite recursion is different from an
infinite recursion.
void Infinite_Recursion()
{
-a Infinite_Recursion();
-a return;
}
HHH(Infinite_Recursion); // is finite recursion
when measured by the screwy incorrect way that
you measure it.
Am Sat, 30 Aug 2025 11:28:52 -0500 schrieb olcott:
On 8/30/2025 10:55 AM, Richard Heathfield wrote:That is to say, it doesn't repeat because it is aborted.
On 30/08/2025 16:52, olcott wrote:
On 8/29/2025 2:23 PM, Richard Heathfield wrote:
It is an easily verified fact thatDD.exe is executed.
int main(void) {
-a-a DD();
return 0;
}
halts. Several of us /have/ verified that fact (easily).
DD.exe calls HHH(DD).exe
HHH.exe simulates DD.sim1
DD.sim1 calls HHH(DD).sim1
HHH.sim1 simulates DD.sim2
DD.sim2 calls HHH(DD).sim2 ...
This would repeat unless aborted
Nonsense. It can't. HHH *must* return and *does* return.
HHH.exe is required to return.Requirements aren't factual or not, they are fulfilled or not.
HHH.sim1 cannot possibly return any requirement to the contrary is
simply counter-factual.
Op 30.aug.2025 om 17:12 schreef olcott:
On 8/30/2025 3:25 AM, Fred. Zwarts wrote:
As usual incorrect and irrelevant claims.
I perfectly understand that a finite recursion is different from an
infinite recursion.
void Infinite_Recursion()
{
-a-a Infinite_Recursion();
-a-a return;
}
HHH(Infinite_Recursion); // is finite recursion
when measured by the screwy incorrect way that
you measure it.
As usual irrelevant claims.
The DD based on the HHH that aborts does in no way compare to Infinite_Recursion.
The problem is that HHH (and probably olcott, as well) does not
understand the difference between finite recursion and non-termination.
The programmer of HHH ignores conditional branch instructions--
encountered during the simulation. Then it aborts, but odes not prove
that these alternative branches will not be followed in a correct continuation of the simulation. So, it does not prove non-termination behaviour.
That is his attitude: he assumes that it is correct and uses that as a
proof that it is correct. An invalid circular reasoning.
Halting *IS NOT* stopping running. Halting is only reaching a final
halt state.
----
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
On 8/30/2025 3:55 PM, joes wrote:
Am Sat, 30 Aug 2025 11:28:52 -0500 schrieb olcott:
On 8/30/2025 10:55 AM, Richard Heathfield wrote:That is to say, it doesn't repeat because it is aborted.
On 30/08/2025 16:52, olcott wrote:
On 8/29/2025 2:23 PM, Richard Heathfield wrote:
It is an easily verified fact thatDD.exe is executed.
int main(void) {
-a-a-a DD();
-a-a-a return 0;
}
halts. Several of us /have/ verified that fact (easily).
DD.exe calls HHH(DD).exe
HHH.exe simulates DD.sim1
DD.sim1 calls HHH(DD).sim1
HHH.sim1 simulates DD.sim2
DD.sim2 calls HHH(DD).sim2 ...
This would repeat unless aborted
Nonsense. It can't. HHH *must* return and *does* return.
You haven't been paying attention to the static data issue.
The requirement that a TM compute the square root ofHHH.exe is required to return.Requirements aren't factual or not, they are fulfilled or not.
HHH.sim1 cannot possibly return any requirement to the
contrary is
simply counter-factual.
a dead rabbit is an incorrect requirement.
Likewise a requirement that HHH(DD) report
in the behavior of its DD() caller is also incorrect.
On 8/30/2025 3:55 PM, joes wrote:
Am Sat, 30 Aug 2025 11:28:52 -0500 schrieb olcott:
On 8/30/2025 10:55 AM, Richard Heathfield wrote:That is to say, it doesn't repeat because it is aborted.
On 30/08/2025 16:52, olcott wrote:
On 8/29/2025 2:23 PM, Richard Heathfield wrote:
It is an easily verified fact thatDD.exe is executed.
int main(void) {
-a-a-a DD();
-a-a-a return 0;
}
halts. Several of us /have/ verified that fact (easily).
DD.exe calls HHH(DD).exe
HHH.exe simulates DD.sim1
DD.sim1 calls HHH(DD).sim1
HHH.sim1 simulates DD.sim2
DD.sim2 calls HHH(DD).sim2 ...
This would repeat unless aborted
Nonsense. It can't. HHH *must* return and *does* return.
You haven't been paying attention to the static data issue.
The requirement that a TM compute the square root ofHHH.exe is required to return.Requirements aren't factual or not, they are fulfilled or not.
HHH.sim1 cannot possibly return any requirement to the contrary is
simply counter-factual.
a dead rabbit is an incorrect requirement.
On 5/5/2025 4:31 PM, dbush wrote:
Strawman. The square root of a dead rabbit does not exist, but the
question of whether any arbitrary algorithm X with input Y halts when
executed directly has a correct answer in all cases.
It has a correct answer that cannot ever be computed
Likewise a requirement that HHH(DD) report
in the behavior of its DD() caller is also incorrect.
On 8/31/2025 5:58 AM, Fred. Zwarts wrote:
Op 30.aug.2025 om 17:12 schreef olcott:
On 8/30/2025 3:25 AM, Fred. Zwarts wrote:
As usual incorrect and irrelevant claims.
I perfectly understand that a finite recursion is different
from an infinite recursion.
void Infinite_Recursion()
{
-a-a Infinite_Recursion();
-a-a return;
}
HHH(Infinite_Recursion); // is finite recursion
when measured by the screwy incorrect way that
you measure it.
As usual irrelevant claims.
The DD based on the HHH that aborts does in no way compare to
Infinite_Recursion.
The problem is that HHH (and probably olcott, as well) does not
understand the difference between finite recursion and
non-termination.
This problem is all your mistake. Halting *IS NOT* stopping running.
Halting is only reaching a final halt state.
On 8/31/2025 5:58 AM, Fred. Zwarts wrote:
Op 30.aug.2025 om 17:12 schreef olcott:
On 8/30/2025 3:25 AM, Fred. Zwarts wrote:
As usual incorrect and irrelevant claims.
I perfectly understand that a finite recursion is different from an
infinite recursion.
void Infinite_Recursion()
{
-a-a Infinite_Recursion();
-a-a return;
}
HHH(Infinite_Recursion); // is finite recursion
when measured by the screwy incorrect way that
you measure it.
As usual irrelevant claims.
The DD based on the HHH that aborts does in no way compare to
Infinite_Recursion.
The problem is that HHH (and probably olcott, as well) does not
understand the difference between finite recursion and non-termination.
This problem is all your mistake. Halting *IS NOT* stopping running.
Halting is only reaching a final halt state.
The programmer of HHH ignores conditional branch instructions
encountered during the simulation. Then it aborts, but odes not prove
that these alternative branches will not be followed in a correct
continuation of the simulation. So, it does not prove non-termination
behaviour.
That is his attitude: he assumes that it is correct and uses that as a
proof that it is correct. An invalid circular reasoning.
On 8/30/2025 3:55 PM, joes wrote:
Am Sat, 30 Aug 2025 11:28:52 -0500 schrieb olcott:
On 8/30/2025 10:55 AM, Richard Heathfield wrote:That is to say, it doesn't repeat because it is aborted.
On 30/08/2025 16:52, olcott wrote:
On 8/29/2025 2:23 PM, Richard Heathfield wrote:
It is an easily verified fact thatDD.exe is executed.
int main(void) {
-a-a-a DD();
-a-a-a return 0;
}
halts. Several of us /have/ verified that fact (easily).
DD.exe calls HHH(DD).exe
HHH.exe simulates DD.sim1
DD.sim1 calls HHH(DD).sim1
HHH.sim1 simulates DD.sim2
DD.sim2 calls HHH(DD).sim2 ...
This would repeat unless aborted
Nonsense. It can't. HHH *must* return and *does* return.
You haven't been paying attention to the static data issue.
The requirement that a TM compute the square root ofHHH.exe is required to return.Requirements aren't factual or not, they are fulfilled or not.
HHH.sim1 cannot possibly return any requirement to the contrary is
simply counter-factual.
a dead rabbit is an incorrect requirement.
Likewise a requirement that HHH(DD) report
in the behavior of its DD() caller is also incorrect.
olcott <polcott333@gmail.com> wrote:
[ .... ]
Halting *IS NOT* stopping running. Halting is only reaching a final
halt state.
How can a turing machine stop running without reaching a final halt
state?
[ .... ]
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
An adapted UTM would not be required to simulate
all of the steps of its input Turing machine description.
On 8/31/2025 5:58 AM, Fred. Zwarts wrote:
Op 30.aug.2025 om 17:12 schreef olcott:
On 8/30/2025 3:25 AM, Fred. Zwarts wrote:
As usual incorrect and irrelevant claims.
I perfectly understand that a finite recursion is different from an
infinite recursion.
void Infinite_Recursion()
{
-a-a Infinite_Recursion();
-a-a return;
}
HHH(Infinite_Recursion); // is finite recursion
when measured by the screwy incorrect way that
you measure it.
As usual irrelevant claims.
The DD based on the HHH that aborts does in no way compare to
Infinite_Recursion.
The problem is that HHH (and probably olcott, as well) does not
understand the difference between finite recursion and non-termination.
This problem is all your mistake. Halting *IS NOT* stopping running.
Halting is only reaching a final halt state.
The programmer of HHH ignores conditional branch instructions
encountered during the simulation. Then it aborts, but odes not prove
that these alternative branches will not be followed in a correct
continuation of the simulation. So, it does not prove non-termination
behaviour.
That is his attitude: he assumes that it is correct and uses that as a
proof that it is correct. An invalid circular reasoning.