On 9/10/2025 7:41 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 7:11 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:The diagonal test case never could ever actually exist.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates itsThat is positively true ... provided that D is not the diagonal
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> >>>>
test case aimed against H!
So it's okay not to mention that to Sipser, who, unlike you, obviously
does believe that diagonal test cases can actually exist?
I just discovered this when I was spending
December to May getting chemo therapy, radiation
therapy and CAR-T cell therapy in Minnesota.
There never has been any ACTUAL INPUT that does
the opposite of whatever its decider decides.
This has always been the error of conflating
the behavior that the ACTUAL INPUT ACTUALLY
SPECIFIES with other behavior somewhere else.
Without the execution trace that a simulating
termination analyzer provides this conflation
error remained invisible.
On 9/10/2025 2:57 AM, Mikko wrote:
On 2025-09-10 03:41:32 +0000, olcott said:
Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.
That does not define halting as the term "final halt state" is undefined.
When we are in a comp.theory forum we expect people
to know the terms of the art.
Eventually, the whole process may terminate,
which we achieve in a Turing machine by putting
it into a halt state. A Turing machine is said
to halt whenever it reaches a configuration for
which δ is not defined; this is possible because
δ is a partial function. In fact, we will assume
that no transitions are defined for any final
state, so the Turing machine will halt whenever
it enters a final state. page 1990:234 Linz
Besides, many authors define halting as reacheng any configuration
where the execution cannot be continued.
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 7:57 PM, Mike Terry wrote:
On 11/09/2025 01:11, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates itsThat is positively true ... provided that D is not the diagonal
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> >>>>
test case aimed against H!
Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.
Separately from that, if Sisper really did say that, he might not have >>>> been aware that D is supposed to be the diagonal test case targeting H, >>>> such that D is built on top of H, and D's behavior depends on H's
decision. Had that been pointed out, a corection would have swiftly
followed.
My explanation is Sipser is considering a general H and a general input
D. When he says "...its simulated D would never stop running unless
aborted..." he is naturally talking about criteria that can be applied
to determine non-halting *OF INPUT D*, and no other input.
Yet input D can be anything it is an arbitrary placeholder.
(However, you should not use the letter D when not intending to symbolize
a diagonal test case. Maybe something else like P.)
But anyway, I wanted to add that, I can also agree with your verbatim
words above from 10/13/2022.
Paraphrase:
If a halt decider /correctly/ determine, by /correctly/ simulating its
input that the input doesn't halt, then a halt decicer
can stop the simulation and reject the input.
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 7:41 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 7:11 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:The diagonal test case never could ever actually exist.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>> If simulating halt decider H correctly simulates itsThat is positively true ... provided that D is not the diagonal
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> >>>>>
test case aimed against H!
So it's okay not to mention that to Sipser, who, unlike you, obviously
does believe that diagonal test cases can actually exist?
I just discovered this when I was spending
December to May getting chemo therapy, radiation
therapy and CAR-T cell therapy in Minnesota.
There never has been any ACTUAL INPUT that does
the opposite of whatever its decider decides.
This has always been the error of conflating
the behavior that the ACTUAL INPUT ACTUALLY
SPECIFIES with other behavior somewhere else.
Nope; the input, such as DD, fully encapsulates the
entire decider HHH in its description.
In effect, it's as if DD has a copy of that decider.
The actual input to the decider; has the decider in its body.
It is built on it.
There is no "trompe d'oeil", like a hand reaching out
of the picture to hold a pen which draws the picture.
Programs can easily have themselves as input.
For instance your Unix program /bin/cp
can copy itself: "/bin/cp /bin/cp copy-of-cp"
/bin/cp is a string of bits which is the actual input
to /bin/cp.
Without the execution trace that a simulating
termination analyzer provides this conflation
error remained invisible.
Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.
You say you disagree: that it wouldn't happen that way.
I suspect you understand the explanations very well, and
are just too scared to try it.
On 9/10/2025 10:43 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
You still do not understand that as soon as HHH(DD) matches thisWithout the execution trace that a simulating termination analyzer
provides this conflation error remained invisible.
Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.
recursive simulation non halting behavior pattern:
that it has answered the only question that it was asking: Does my input
DD specify behavior reach reaches its own final halt state?
At that point it is required to stop simulating anything.
There'd be no need to recheck if you had already convinced yourself.You say you disagree: that it wouldn't happen that way.I have been over these same points hundreds of more times than you have.
I suspect you understand the explanations very well, and are just too
scared to try it.
Each time I check and recheck. My IQ really is the same as an average
MD. By checking and rechecking my work I put a transmission on my mind
such the more time spent raises my effective IQ.
When I spend 12 hours per day 7 days per week for ten years sharply
focused on a problem I beat anyone with a 180 IQ that only spent six
months at 40 hours per week. True greatness can only be achieved by a
very abnormally high focus of concentration. Most people are simply not
wired that way.
Am Thu, 11 Sep 2025 10:30:40 -0500 schrieb olcott:
On 9/10/2025 10:43 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
You still do not understand that as soon as HHH(DD) matches thisWithout the execution trace that a simulating termination analyzer
provides this conflation error remained invisible.
Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.
recursive simulation non halting behavior pattern:
that it has answered the only question that it was asking: Does my input
DD specify behavior reach reaches its own final halt state?
At that point it is required to stop simulating anything.
Not really. It could simulate further, as long is still halts and
returns this value, although there would be no point.
You say you disagree: that it wouldn't happen that way.I have been over these same points hundreds of more times than you have.
I suspect you understand the explanations very well, and are just too
scared to try it.
Each time I check and recheck. My IQ really is the same as an average
MD. By checking and rechecking my work I put a transmission on my mind
such the more time spent raises my effective IQ.
When I spend 12 hours per day 7 days per week for ten years sharply
focused on a problem I beat anyone with a 180 IQ that only spent six
months at 40 hours per week. True greatness can only be achieved by a
very abnormally high focus of concentration. Most people are simply not
wired that way.
There'd be no need to recheck if you had already convinced yourself.
You basically can't change your IQ; people with an IQ of 180 don't exist
and intelligence isn't the same as knowledge. The HP also isn't that deep.
On 9/11/2025 10:52 AM, joes wrote:
Am Thu, 11 Sep 2025 10:30:40 -0500 schrieb olcott:It could simulate until just before the heat death of the universe and
On 9/10/2025 10:43 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
You still do not understand that as soon as HHH(DD) matches thisWithout the execution trace that a simulating termination analyzer
provides this conflation error remained invisible.
Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.
recursive simulation non halting behavior pattern:
that it has answered the only question that it was asking: Does my
input DD specify behavior reach reaches its own final halt state?
At that point it is required to stop simulating anything.
Not really. It could simulate further, as long is still halts and
returns this value, although there would be no point.
then finally report that DD does not halt.
I merely coded it to report as soon as it can do this correctly.
On Thu, 11 Sep 2025 11:38:22 -0500, olcott wrote:
On 9/11/2025 10:52 AM, joes wrote:
Am Thu, 11 Sep 2025 10:30:40 -0500 schrieb olcott:It could simulate until just before the heat death of the universe and
On 9/10/2025 10:43 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
You still do not understand that as soon as HHH(DD) matches thisWithout the execution trace that a simulating termination analyzer >>>>>> provides this conflation error remained invisible.
Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.
recursive simulation non halting behavior pattern:
that it has answered the only question that it was asking: Does my
input DD specify behavior reach reaches its own final halt state?
At that point it is required to stop simulating anything.
Not really. It could simulate further, as long is still halts and
returns this value, although there would be no point.
then finally report that DD does not halt.
I merely coded it to report as soon as it can do this correctly.
But DD halts so it didn't report correctly.
/Flibble
On 9/11/2025 11:45 AM, Mr Flibble wrote:
On Thu, 11 Sep 2025 11:38:22 -0500, olcott wrote:That is the very subtle fallacy of equivocation error that has been perpetuated by every textbook on the subject.
On 9/11/2025 10:52 AM, joes wrote:
Am Thu, 11 Sep 2025 10:30:40 -0500 schrieb olcott:It could simulate until just before the heat death of the universe and
On 9/10/2025 10:43 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
You still do not understand that as soon as HHH(DD) matches thisWithout the execution trace that a simulating termination analyzer >>>>>>> provides this conflation error remained invisible.
Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.
recursive simulation non halting behavior pattern:
that it has answered the only question that it was asking: Does my
input DD specify behavior reach reaches its own final halt state? At >>>>> that point it is required to stop simulating anything.
Not really. It could simulate further, as long is still halts and
returns this value, although there would be no point.
then finally report that DD does not halt.
I merely coded it to report as soon as it can do this correctly.
But DD halts so it didn't report correctly.
/Flibble
All deciders only compute the mapping from their input finite strings...
It is not the behavior of some machine somewhere else that is
"represented" by the finite string.
It is the behavior that the finite string INPUT SPECIFIES to its
decider.
When simulating halt deciders are considered then we see that DD does
call HHH(DD) in recursive simulation that cannot possibly reach its own simulated final halt state. The same applies to the Linz Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩.
To expound on some notions in Rice's theorem deciders accept or reject
input finite strings on the basis of a semantic or syntactic property
[of their input].
[HHH] could simulate until just before the heat death of
the universe and then finally report that DD does not halt.
I merely coded it to report as soon as it can do this correctly.
There never has been any ACTUAL INPUT that does
the opposite of whatever its decider decides.
This has always been the error of conflating
the behavior that the ACTUAL INPUT ACTUALLY
SPECIFIES with other behavior somewhere else.
Without the execution trace that a simulating
termination analyzer provides this conflation
error remained invisible.
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 7:57 PM, Mike Terry wrote:
On 11/09/2025 01:11, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>> If simulating halt decider H correctly simulates itsThat is positively true ... provided that D is not the diagonal
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> >>>>
test case aimed against H!
Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.
Separately from that, if Sisper really did say that, he might not have >>>> been aware that D is supposed to be the diagonal test case targeting H, >>>> such that D is built on top of H, and D's behavior depends on H's
decision. Had that been pointed out, a corection would have swiftly
followed.
My explanation is Sipser is considering a general H and a general input
D. When he says "...its simulated D would never stop running unless
aborted..." he is naturally talking about criteria that can be applied
to determine non-halting *OF INPUT D*, and no other input.
Yet input D can be anything it is an arbitrary placeholder.
(However, you should not use the letter D when not intending to symbolize
a diagonal test case. Maybe something else like P.)
But anyway, I wanted to add that, I can also agree with your verbatim
words above from 10/13/2022.
Paraphrase:
If a halt decider /correctly/ determine, by /correctly/ simulating its
input that the input doesn't halt, then a halt decicer
can stop the simulation and reject the input.
We have an logical if here:
"If it can correctly simulate ... determine, ... THEN it can reject"
IF P THEN Q
P -> Q
Now P -> Q has a truth table such that P -> Q is only false when
P is true and Q is false.
P Q P -> Q
F F T
F T T
T F F
T T T
In the diagonal test case D that is aligned against H, H /cannot/
correctly determine the halting status of D, and therefore doesn't.
Thus P is false.
If P is false then P -> Q is true.
Therefore, it is reasonable to agree with P -> Q.
"If unicorns exist, then pigs fly" --- I don't disagree!
However, there are some reasons to believe we can hit the "T F"
case of the truth table.
Suppose that H correctly determines the halting status of D. H cannot
report that. It has to keep it to itself and not return. In that case,
H can stop the simulation of D, but just cannot itself terminate; if it returns anything to D, it is automatically wrong.
In that situation P is true (H has correctly simulated and determined,
but Q is false: it is not true that H can correctly report anything)
It hinges around the philosophical question of: if H doesn't report
anything, is it deemed to have determined anything?
If we deny this: H is not deemed to determine anything until it
terminates and reports it, then P is necessarily false for the diagonal
case, and your verbatim "Sipser agree text" can be easily agreed with.
If we admit the possiblity that H can internally determine something,
but keep it to itself, so as not to provoke contradictory behavior that proves it wrong, then it's not easy to agree with your text. H has
determined that D doesn't halt, and H is refraining from reporting this
fact in order to keep it true: for as long as H doesn't return, D
doesn't return and the fact remains true.
The problem is that functions are blackboxes. A result that is secret
within a function effectively doesn't exist; only the return value is observable, or the fact that the function is not returning. Therefore
the former camp is more on the correct side (H is not deemed to have correctly determined anything until it returns) and can agree with
your verbatim text.
On 9/10/2025 10:43 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 7:41 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 7:11 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:The diagonal test case never could ever actually exist.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>> If simulating halt decider H correctly simulates itsThat is positively true ... provided that D is not the diagonal
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> >>>>>>
test case aimed against H!
So it's okay not to mention that to Sipser, who, unlike you, obviously >>>> does believe that diagonal test cases can actually exist?
I just discovered this when I was spending
December to May getting chemo therapy, radiation
therapy and CAR-T cell therapy in Minnesota.
There never has been any ACTUAL INPUT that does
the opposite of whatever its decider decides.
This has always been the error of conflating
the behavior that the ACTUAL INPUT ACTUALLY
SPECIFIES with other behavior somewhere else.
Nope; the input, such as DD, fully encapsulates the
entire decider HHH in its description.
In effect, it's as if DD has a copy of that decider.
The actual input to the decider; has the decider in its body.
It is built on it.
There is no "trompe d'oeil", like a hand reaching out
of the picture to hold a pen which draws the picture.
Programs can easily have themselves as input.
For instance your Unix program /bin/cp
can copy itself: "/bin/cp /bin/cp copy-of-cp"
/bin/cp is a string of bits which is the actual input
to /bin/cp.
Without the execution trace that a simulating
termination analyzer provides this conflation
error remained invisible.
Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.
You still do not understand that as soon as HHH(DD)
matches this recursive simulation non halting behavior
pattern:
Lines 996 through 1006 matches the
*recursive simulation non-halting behavior pattern* https://github.com/plolcott/x86utm/blob/master/Halt7.c
My IQ really is the same as an average MD.
By checking
and rechecking my work I put a transmission on my mind
such the more time spent raises my effective IQ.
When I spend 12 hours per day 7 days per week for
ten years sharply focused on a problem I beat anyone
with a 180 IQ that only spent six months at 40 hours
per week.
True greatness can only be achieved by a
very abnormally high focus of concentration.
Lines 996 through 1006 matches the
*recursive simulation non-halting behavior pattern* https://github.com/plolcott/x86utm/blob/master/Halt7.c
On 11/09/2025 04:17, Kaz Kylheku wrote:Even an approach like the one you sketch here is unlikely to be
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 7:57 PM, Mike Terry wrote:
On 11/09/2025 01:11, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:
<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>
That is positively true ... provided that D is not the diagonal
test case aimed against H!
Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.
Separately from that, if Sisper really did say that, he might not have >>>>> been aware that D is supposed to be the diagonal test case
targeting H,
such that D is built on top of H, and D's behavior depends on H's
decision. Had that been pointed out, a corection would have swiftly >>>>> followed.
My explanation is Sipser is considering a general H and a general input >>>> D. When he says "...its simulated D would never stop running unless
aborted..." he is naturally talking about criteria that can be applied >>>> to determine non-halting *OF INPUT D*, and no other input.
Yet input D can be anything it is an arbitrary placeholder.
(However, you should not use the letter D when not intending to symbolize
a diagonal test case. Maybe something else like P.)
But anyway, I wanted to add that, I can also agree with your verbatim
words above from 10/13/2022.
Paraphrase:
If a halt decider /correctly/ determine, by /correctly/ simulating its >> input that the input doesn't halt, then a halt decicer
can stop the simulation and reject the input.
We have an logical if here:
"If it can correctly simulate ... determine, ... THEN it can reject" >>
IF P THEN Q
P -> Q
Now P -> Q has a truth table such that P -> Q is only false when
P is true and Q is false.
P Q P -> Q
F F T
F T T
T F F
T T T
In the diagonal test case D that is aligned against H, H /cannot/
correctly determine the halting status of D, and therefore doesn't.
Thus P is false.
If P is false then P -> Q is true.
Therefore, it is reasonable to agree with P -> Q.
"If unicorns exist, then pigs fly" --- I don't disagree!
However, there are some reasons to believe we can hit the "T F"
case of the truth table.
Suppose that H correctly determines the halting status of D. H cannot
report that. It has to keep it to itself and not return. In that case,
H can stop the simulation of D, but just cannot itself terminate; if it
returns anything to D, it is automatically wrong.
In that situation P is true (H has correctly simulated and determined,
but Q is false: it is not true that H can correctly report anything)
It hinges around the philosophical question of: if H doesn't report
anything, is it deemed to have determined anything?
If we deny this: H is not deemed to determine anything until it
terminates and reports it, then P is necessarily false for the diagonal
case, and your verbatim "Sipser agree text" can be easily agreed with.
If we admit the possiblity that H can internally determine something,
but keep it to itself, so as not to provoke contradictory behavior that
proves it wrong, then it's not easy to agree with your text. H has
determined that D doesn't halt, and H is refraining from reporting this
fact in order to keep it true: for as long as H doesn't return, D
doesn't return and the fact remains true.
The problem is that functions are blackboxes. A result that is secret
within a function effectively doesn't exist; only the return value is
observable, or the fact that the function is not returning. Therefore
the former camp is more on the correct side (H is not deemed to have
correctly determined anything until it returns) and can agree with
your verbatim text.
I think I'm on safe grounds predicting that Sipser is considering
deciding to mean reporting the decision and halting. And of course an H which never returns is not a halt decider in the sense of the HP.
But your idea of internally determining something made me think: is it
easy to actually do that in practice? It seems so to me.
H can be coded to examine its input computation. If it sees that it has
no reachable code path that leads to any final state, it can be said to "know" (or have "determined") at that point that its input is non-
halting - if we like we could say it must pass through a designated
"I've worked out the input doesn't halt" state to "register" its discovery. Regardless of the previous test succeeding, H then loops.
So now we construct the diagonal machine D, which embeds H algorithm.
H(D) never halts, and so D never halts. Moreover, D() has no reachable code path that returns, and that fact can be correctly ascertained by
code in H, so H (coded appropriately) can "determine" that D() never
halts and register this, before continuing with its infinite loop.
Conclusion: H has correctly proved (internally) that D() does not halt,
and registered that by passing through its designated state. And indeed D() never halts as proved (internally) by H.
For comparison we could imaging an H that (regardless of input) just "registers" that the input never halts, then enters an infinite loop. That's much simpler! But... while this H /correctly/ registers that its associated diagonal D() never halts, it can't be said to have "seen"/"determined" that it halts, as you required(??), because there
are alternative inputs which H will also register as never halting but
will in fact halt.
[OK, I'm not sure if you used the word "determined" in the stronger
sense I interpreted it, or in the weaker sense of H simply being
"correct for the case being considered" without any justification. My H which looks for reachable terminating code paths works with the stronger "determined" interpretation.]
On 11/09/2025 04:17, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 7:57 PM, Mike Terry wrote:
On 11/09/2025 01:11, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>> If simulating halt decider H correctly simulates itsThat is positively true ... provided that D is not the diagonal
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> >>>>>
test case aimed against H!
Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.
Separately from that, if Sisper really did say that, he might not have >>>>> been aware that D is supposed to be the diagonal test case targeting H, >>>>> such that D is built on top of H, and D's behavior depends on H's
decision. Had that been pointed out, a corection would have swiftly >>>>> followed.
My explanation is Sipser is considering a general H and a general input >>>> D. When he says "...its simulated D would never stop running unless
aborted..." he is naturally talking about criteria that can be applied >>>> to determine non-halting *OF INPUT D*, and no other input.
Yet input D can be anything it is an arbitrary placeholder.
(However, you should not use the letter D when not intending to symbolize
a diagonal test case. Maybe something else like P.)
But anyway, I wanted to add that, I can also agree with your verbatim
words above from 10/13/2022.
Paraphrase:
If a halt decider /correctly/ determine, by /correctly/ simulating its
input that the input doesn't halt, then a halt decicer
can stop the simulation and reject the input.
We have an logical if here:
"If it can correctly simulate ... determine, ... THEN it can reject"
IF P THEN Q
P -> Q
Now P -> Q has a truth table such that P -> Q is only false when
P is true and Q is false.
P Q P -> Q
F F T
F T T
T F F
T T T
In the diagonal test case D that is aligned against H, H /cannot/
correctly determine the halting status of D, and therefore doesn't.
Thus P is false.
If P is false then P -> Q is true.
Therefore, it is reasonable to agree with P -> Q.
"If unicorns exist, then pigs fly" --- I don't disagree!
However, there are some reasons to believe we can hit the "T F"
case of the truth table.
Suppose that H correctly determines the halting status of D. H cannot
report that. It has to keep it to itself and not return. In that case,
H can stop the simulation of D, but just cannot itself terminate; if it
returns anything to D, it is automatically wrong.
In that situation P is true (H has correctly simulated and determined,
but Q is false: it is not true that H can correctly report anything)
It hinges around the philosophical question of: if H doesn't report
anything, is it deemed to have determined anything?
If we deny this: H is not deemed to determine anything until it
terminates and reports it, then P is necessarily false for the diagonal
case, and your verbatim "Sipser agree text" can be easily agreed with.
If we admit the possiblity that H can internally determine something,
but keep it to itself, so as not to provoke contradictory behavior that
proves it wrong, then it's not easy to agree with your text. H has
determined that D doesn't halt, and H is refraining from reporting this
fact in order to keep it true: for as long as H doesn't return, D
doesn't return and the fact remains true.
The problem is that functions are blackboxes. A result that is secret
within a function effectively doesn't exist; only the return value is
observable, or the fact that the function is not returning. Therefore
the former camp is more on the correct side (H is not deemed to have
correctly determined anything until it returns) and can agree with
your verbatim text.
I think I'm on safe grounds predicting that Sipser is considering deciding to mean reporting the
decision and halting. And of course an H which never returns is not a halt decider in the sense of
the HP.
But your idea of internally determining something made me think: is it easy to actually do that in
practice? It seems so to me.
Conclusion: H has correctly proved (internally) that D() does not halt, and registered that by
passing through its designated state. And indeed D() never halts as proved (internally) by H.
On 2025-09-10, olcott <polcott333@gmail.com> wrote:
<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>
That is positively true ... provided that D is not the diagonal
test case aimed against H!
Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.
Separately from that, if Sisper really did say that, he might not have
been aware that D is supposed to be the diagonal test case targeting H,
such that D is built on top of H, and D's behavior depends on H's
decision. Had that been pointed out, a corection would have swiftly followed.
So you think that professor Sipser is stupid?
No, just you, sorry.
I'd like not to, but you're trying incredibly hard to remain in such a regard.
Its the exact same thing with Infinite_Recursion()
when we do not stupidly conflate stopping running
with halting.
We must likewise not stupidly conflate stopping running
with non-halting, as I said.
You cannot get this just half right; the full truth
is that "stopping running" (simulation is suspended
indefinitely) has no bearing on whether the subject
is halting or non-halting.
If a correctly simulated function
cannot possibly reach its own simulated final halt
state
... due to stopping running ...
then as soon as we see this non-halting behavior
... then as soon as we see "stopping running" as a "non-halting
behavior" we are a bleeping idiot who conflates "stopping running" with
"non halting".
How can you call someone stupid for conflating "sopping running" with "halting", which at least "smell" similar, but then yourself conflate "stopping running" with "NON-halting", which superficially look like
outright opposites!
Like, wow ...
Do you want an honest dialogue?
Do you mean actually honest dialogue, or just the same old
HHHonest DDialogue?
Do you think that professor Sipser is stupid?
Well, everyone who engages you, including myself, is obviously
stupid to some extent.
Now P -> Q has a truth table such that P -> Q is only false when
P is true and Q is false.
P Q P -> Q
F F T
F T T
T F F
T T T
On 2025-09-10 21:17, Kaz Kylheku wrote:
Now P -> Q has a truth table such that P -> Q is only false when
P is true and Q is false.
P Q P -> Q
F F T
F T T
T F F
T T T
Just to warn you, you're venturing into dangerous territory here. Among Olcott's many peculiarities is the fact that in the past he has rejectedAnd latter, I found olcott does not even understand X&~X (olcott can copy,
the above truth table (though it's never been clear what he wants to
replace it with).
André
On 11/09/2025 17:38, olcott wrote:
<snip>
[HHH] could simulate until just before the heat death of
the universe and then finally report that DD does not halt.
It would still be wrong. DD halts.
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 10:43 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 7:41 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 7:11 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:The diagonal test case never could ever actually exist.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022> >>>>>>>> If simulating halt decider H correctly simulates itsThat is positively true ... provided that D is not the diagonal
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> >>>>>>>
test case aimed against H!
So it's okay not to mention that to Sipser, who, unlike you, obviously >>>>> does believe that diagonal test cases can actually exist?
I just discovered this when I was spending
December to May getting chemo therapy, radiation
therapy and CAR-T cell therapy in Minnesota.
There never has been any ACTUAL INPUT that does
the opposite of whatever its decider decides.
This has always been the error of conflating
the behavior that the ACTUAL INPUT ACTUALLY
SPECIFIES with other behavior somewhere else.
Nope; the input, such as DD, fully encapsulates the
entire decider HHH in its description.
In effect, it's as if DD has a copy of that decider.
The actual input to the decider; has the decider in its body.
It is built on it.
There is no "trompe d'oeil", like a hand reaching out
of the picture to hold a pen which draws the picture.
Programs can easily have themselves as input.
For instance your Unix program /bin/cp
can copy itself: "/bin/cp /bin/cp copy-of-cp"
/bin/cp is a string of bits which is the actual input
to /bin/cp.
Without the execution trace that a simulating
termination analyzer provides this conflation
error remained invisible.
Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.
You still do not understand that as soon as HHH(DD)
matches this recursive simulation non halting behavior
pattern:
Lines 996 through 1006 matches the
*recursive simulation non-halting behavior pattern*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Here is what you don't understand. In every recursive
simulation level. your HHH(DD) returns 0.
Each recursive simulation level has a *parent* HHH(DD)
which is simualting it.
On 9/11/2025 12:12 PM, Richard Heathfield wrote:
On 11/09/2025 17:38, olcott wrote:
<snip>
[HHH] could simulate until just before the heat death of
the universe and then finally report that DD does not halt.
It would still be wrong. DD halts.
I carefully explain all of the details of how
this is incorrect
Presuming that I must be wrong without finding a
single error in the reasoning of my basis counts
as less then no rebuttal at all.
On 9/11/2025 2:04 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:I spent 10,000 hours on this an you only spent a few minutes, you are
On 9/10/2025 10:43 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:You still do not understand that as soon as HHH(DD) matches this
On 9/10/2025 7:41 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:I just discovered this when I was spending December to May getting
On 9/10/2025 7:11 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:The diagonal test case never could ever actually exist.
<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>
That is positively true ... provided that D is not the diagonal >>>>>>>> test case aimed against H!
So it's okay not to mention that to Sipser, who, unlike you,
obviously does believe that diagonal test cases can actually exist? >>>>>>
chemo therapy, radiation therapy and CAR-T cell therapy in
Minnesota.
There never has been any ACTUAL INPUT that does the opposite of
whatever its decider decides.
This has always been the error of conflating the behavior that the
ACTUAL INPUT ACTUALLY SPECIFIES with other behavior somewhere else.
Nope; the input, such as DD, fully encapsulates the entire decider
HHH in its description.
In effect, it's as if DD has a copy of that decider.
The actual input to the decider; has the decider in its body.
It is built on it.
There is no "trompe d'oeil", like a hand reaching out of the picture
to hold a pen which draws the picture.
Programs can easily have themselves as input.
For instance your Unix program /bin/cp can copy itself: "/bin/cp
/bin/cp copy-of-cp"
/bin/cp is a string of bits which is the actual input to /bin/cp.
Without the execution trace that a simulating termination analyzer
provides this conflation error remained invisible.
Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.
recursive simulation non halting behavior pattern:
Lines 996 through 1006 matches the *recursive simulation non-halting
behavior pattern*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Here is what you don't understand. In every recursive simulation level.
your HHH(DD) returns 0.
simply wrong and I will explain why and how.
An instance of HHH correctly determines that DD simulated by HHH matches
the infinite recursion behavior pattern as soon as it simulates DD
twice, thus is one step ahead of all of the others.
It sees that DD calls HHH(DD) twice in sequence with no conditional code between the invocation of DD and its call to HHH(DD). This entails non-halting behavior for DD.
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
Lines 996 through 1006 matches the
*recursive simulation non-halting behavior pattern*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Not correctly though. Once that condition fires, and the
simulation is abandoned, it is failing to see that if the
simulation were continued, the simulated HHH(DD) would
return and proceed to the conditional instruction.
You know this is true, but you would rather look brutally
stupid than to admit being wrong.
Like I said, someone will come along and demonstrate what
I'm talking about using your own code, and you will have
your ass handed to you at that point.
On 11/09/2025 04:17, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 7:57 PM, Mike Terry wrote:
On 11/09/2025 01:11, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:
<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>
That is positively true ... provided that D is not the diagonal
test case aimed against H!
Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.
Separately from that, if Sisper really did say that, he might not have >>>>> been aware that D is supposed to be the diagonal test case
targeting H,
such that D is built on top of H, and D's behavior depends on H's
decision. Had that been pointed out, a corection would have swiftly >>>>> followed.
My explanation is Sipser is considering a general H and a general input >>>> D. When he says "...its simulated D would never stop running unless
aborted..." he is naturally talking about criteria that can be applied >>>> to determine non-halting *OF INPUT D*, and no other input.
Yet input D can be anything it is an arbitrary placeholder.
(However, you should not use the letter D when not intending to symbolize
a diagonal test case. Maybe something else like P.)
But anyway, I wanted to add that, I can also agree with your verbatim
words above from 10/13/2022.
Paraphrase:
If a halt decider /correctly/ determine, by /correctly/ simulating its >> input that the input doesn't halt, then a halt decicer
can stop the simulation and reject the input.
We have an logical if here:
"If it can correctly simulate ... determine, ... THEN it can reject" >>
IF P THEN Q
P -> Q
Now P -> Q has a truth table such that P -> Q is only false when
P is true and Q is false.
P Q P -> Q
F F T
F T T
T F F
T T T
In the diagonal test case D that is aligned against H, H /cannot/
correctly determine the halting status of D, and therefore doesn't.
Thus P is false.
If P is false then P -> Q is true.
Therefore, it is reasonable to agree with P -> Q.
"If unicorns exist, then pigs fly" --- I don't disagree!
However, there are some reasons to believe we can hit the "T F"
case of the truth table.
Suppose that H correctly determines the halting status of D. H cannot
report that. It has to keep it to itself and not return. In that case,
H can stop the simulation of D, but just cannot itself terminate; if it
returns anything to D, it is automatically wrong.
In that situation P is true (H has correctly simulated and determined,
but Q is false: it is not true that H can correctly report anything)
It hinges around the philosophical question of: if H doesn't report
anything, is it deemed to have determined anything?
If we deny this: H is not deemed to determine anything until it
terminates and reports it, then P is necessarily false for the diagonal
case, and your verbatim "Sipser agree text" can be easily agreed with.
If we admit the possiblity that H can internally determine something,
but keep it to itself, so as not to provoke contradictory behavior that
proves it wrong, then it's not easy to agree with your text. H has
determined that D doesn't halt, and H is refraining from reporting this
fact in order to keep it true: for as long as H doesn't return, D
doesn't return and the fact remains true.
The problem is that functions are blackboxes. A result that is secret
within a function effectively doesn't exist; only the return value is
observable, or the fact that the function is not returning. Therefore
the former camp is more on the correct side (H is not deemed to have
correctly determined anything until it returns) and can agree with
your verbatim text.
I think I'm on safe grounds predicting that Sipser is considering
deciding to mean reporting the decision and halting. And of course an H which never returns is not a halt decider in the sense of the HP.
But your idea of internally determining something made me think: is it
easy to actually do that in practice? It seems so to me.
H can be coded to examine its input computation. If it sees that it has
no reachable code path that leads to any final state, it can be said to "know" (or have "determined") at that point that its input is non-
halting - if we like we could say it must pass through a designated
"I've worked out the input doesn't halt" state to "register" its discovery. Regardless of the previous test succeeding, H then loops.
So now we construct the diagonal machine D, which embeds H algorithm.
H(D) never halts, and so D never halts. Moreover, D() has no reachable code path that returns, and that fact can be correctly ascertained by
code in H, so H (coded appropriately) can "determine" that D() never
halts and register this, before continuing with its infinite loop.
Conclusion: H has correctly proved (internally) that D() does not halt,
and registered that by passing through its designated state. And indeed D() never halts as proved (internally) by H.
For comparison we could imaging an H that (regardless of input) just "registers" that the input never halts, then enters an infinite loop. That's much simpler! But... while this H /correctly/ registers that its associated diagonal D() never halts, it can't be said to have "seen"/"determined" that it halts, as you required(??), because there
are alternative inputs which H will also register as never halting but
will in fact halt.
[OK, I'm not sure if you used the word "determined" in the stronger
sense I interpreted it, or in the weaker sense of H simply being
"correct for the case being considered" without any justification. My H which looks for reachable terminating code paths works with the stronger "determined" interpretation.]
Mike.
On 2025-09-11, Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote:
I think I'm on safe grounds predicting that Sipser is considering deciding to mean reporting the
decision and halting. And of course an H which never returns is not a halt decider in the sense of
the HP.
But your idea of internally determining something made me think: is it easy to actually do that in
practice? It seems so to me.
With side effects, it is possible. Then we don't have pure functions any more.
E.g. the decider can do this:
puts("I know this doesn't halt, but I can't return because that would change the result.");
for(;;)/**/;
On 2025-09-10 21:17, Kaz Kylheku wrote:
Now P -> Q has a truth table such that P -> Q is only false when
P is true and Q is false.
P Q P -> Q
F F T
F T T
T F F
T T T
Just to warn you, you're venturing into dangerous territory here. Among Olcott's many peculiarities is the fact that in the past he has rejected
the above truth table (though it's never been clear what he wants to
replace it with).
André
(a) DD calls the same function twice in sequence (b) With the sameIt is not the same DD that calls the same function. They aren't even
argument (c) DD has no conditional branch instructions between the
invocation of DD and its call to HHH(DD).
HHH(DD) sees that DD correctly simulated by HHH
cannot possibly reach its own simulated final halt state.
On Fri, 12 Sep 2025 09:47:35 -0500, olcott wrote:
On 9/11/2025 2:04 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:I spent 10,000 hours on this an you only spent a few minutes, you are
On 9/10/2025 10:43 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:You still do not understand that as soon as HHH(DD) matches this
On 9/10/2025 7:41 PM, Kaz Kylheku wrote:Nope; the input, such as DD, fully encapsulates the entire decider
On 2025-09-11, olcott <polcott333@gmail.com> wrote:I just discovered this when I was spending December to May getting >>>>>> chemo therapy, radiation therapy and CAR-T cell therapy in
On 9/10/2025 7:11 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:The diagonal test case never could ever actually exist.
<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>
That is positively true ... provided that D is not the diagonal >>>>>>>>> test case aimed against H!
So it's okay not to mention that to Sipser, who, unlike you,
obviously does believe that diagonal test cases can actually exist? >>>>>>>
Minnesota.
There never has been any ACTUAL INPUT that does the opposite of
whatever its decider decides.
This has always been the error of conflating the behavior that the >>>>>> ACTUAL INPUT ACTUALLY SPECIFIES with other behavior somewhere else. >>>>>
HHH in its description.
In effect, it's as if DD has a copy of that decider.
The actual input to the decider; has the decider in its body.
It is built on it.
There is no "trompe d'oeil", like a hand reaching out of the picture >>>>> to hold a pen which draws the picture.
Programs can easily have themselves as input.
For instance your Unix program /bin/cp can copy itself: "/bin/cp
/bin/cp copy-of-cp"
/bin/cp is a string of bits which is the actual input to /bin/cp.
Without the execution trace that a simulating termination analyzer >>>>>> provides this conflation error remained invisible.
Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.
recursive simulation non halting behavior pattern:
Lines 996 through 1006 matches the *recursive simulation non-halting
behavior pattern*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Here is what you don't understand. In every recursive simulation level.
your HHH(DD) returns 0.
simply wrong and I will explain why and how.
An instance of HHH correctly determines that DD simulated by HHH matches
the infinite recursion behavior pattern as soon as it simulates DD
twice, thus is one step ahead of all of the others.
It sees that DD calls HHH(DD) twice in sequence with no conditional code
between the invocation of DD and its call to HHH(DD). This entails
non-halting behavior for DD.
But DD halts if HHH reports to DD that DD is non-halting ergo HHH is incorrect.
/Flibble
Am Fri, 12 Sep 2025 10:36:59 -0500 schrieb olcott:
(a) DD calls the same function twice in sequence (b) With the same
argument (c) DD has no conditional branch instructions between the
invocation of DD and its call to HHH(DD).
It is not the same DD that calls the same function. They aren't even
in the same simulation level.
There is nothing else in DD. What does HHH(HHH) return?
But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.
/Flibble
On 9/12/2025 10:16 AM, Mr Flibble wrote:
On Fri, 12 Sep 2025 09:47:35 -0500, olcott wrote:This is my basis. Changing the basis does not show any error in my
On 9/11/2025 2:04 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:I spent 10,000 hours on this an you only spent a few minutes, you are
On 9/10/2025 10:43 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:You still do not understand that as soon as HHH(DD) matches this
On 9/10/2025 7:41 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:I just discovered this when I was spending December to May getting >>>>>>> chemo therapy, radiation therapy and CAR-T cell therapy in
On 9/10/2025 7:11 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:The diagonal test case never could ever actually exist.
<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>
That is positively true ... provided that D is not the diagonal >>>>>>>>>> test case aimed against H!
So it's okay not to mention that to Sipser, who, unlike you,
obviously does believe that diagonal test cases can actually
exist?
Minnesota.
There never has been any ACTUAL INPUT that does the opposite of
whatever its decider decides.
This has always been the error of conflating the behavior that the >>>>>>> ACTUAL INPUT ACTUALLY SPECIFIES with other behavior somewhere
else.
Nope; the input, such as DD, fully encapsulates the entire decider >>>>>> HHH in its description.
In effect, it's as if DD has a copy of that decider.
The actual input to the decider; has the decider in its body.
It is built on it.
There is no "trompe d'oeil", like a hand reaching out of the
picture to hold a pen which draws the picture.
Programs can easily have themselves as input.
For instance your Unix program /bin/cp can copy itself: "/bin/cp
/bin/cp copy-of-cp"
/bin/cp is a string of bits which is the actual input to /bin/cp.
Without the execution trace that a simulating termination analyzer >>>>>>> provides this conflation error remained invisible.
Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt,
/your own/ error of reasoning remains invisible to you.
recursive simulation non halting behavior pattern:
Lines 996 through 1006 matches the *recursive simulation non-halting >>>>> behavior pattern*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Here is what you don't understand. In every recursive simulation
level.
your HHH(DD) returns 0.
simply wrong and I will explain why and how.
An instance of HHH correctly determines that DD simulated by HHH
matches the infinite recursion behavior pattern as soon as it
simulates DD twice, thus is one step ahead of all of the others.
It sees that DD calls HHH(DD) twice in sequence with no conditional
code between the invocation of DD and its call to HHH(DD). This
entails non-halting behavior for DD.
But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.
/Flibble
reasoning. My conclusion does logically follow from my basis.
HHH(DD) sees that DD correctly simulated by HHH cannot possibly reach
its own simulated final halt state.
*HHH sees this on the basis that*
(a) DD calls the same function twice in sequence (b) With the same
argument (c) DD has no conditional branch instructions between the
invocation of DD and its call to HHH(DD).
On 12/09/2025 15:36, olcott wrote:
On 9/11/2025 12:12 PM, Richard Heathfield wrote:
On 11/09/2025 17:38, olcott wrote:
<snip>
[HHH] could simulate until just before the heat death of
the universe and then finally report that DD does not halt.
It would still be wrong. DD halts.
I carefully explain all of the details of how
this is incorrect
I and many others frequently and very carefully explain how you're
talking complete gibberish, and you never pay the slightest attention.
DD halts.
On Fri, 12 Sep 2025 11:35:51 -0500, olcott wrote:
But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.
/Flibble
But DD halts if HHH reports to DD that DD is non-halting ergo HHH is incorrect.
/Flibble
On Fri, 12 Sep 2025 11:35:51 -0500, olcott wrote:
On 9/12/2025 10:16 AM, Mr Flibble wrote:
On Fri, 12 Sep 2025 09:47:35 -0500, olcott wrote:This is my basis. Changing the basis does not show any error in my
On 9/11/2025 2:04 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:I spent 10,000 hours on this an you only spent a few minutes, you are
On 9/10/2025 10:43 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:You still do not understand that as soon as HHH(DD) matches this
On 9/10/2025 7:41 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:I just discovered this when I was spending December to May getting >>>>>>>> chemo therapy, radiation therapy and CAR-T cell therapy in
On 9/10/2025 7:11 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:The diagonal test case never could ever actually exist.
<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>
That is positively true ... provided that D is not the diagonal >>>>>>>>>>> test case aimed against H!
So it's okay not to mention that to Sipser, who, unlike you, >>>>>>>>> obviously does believe that diagonal test cases can actually >>>>>>>>> exist?
Minnesota.
There never has been any ACTUAL INPUT that does the opposite of >>>>>>>> whatever its decider decides.
This has always been the error of conflating the behavior that the >>>>>>>> ACTUAL INPUT ACTUALLY SPECIFIES with other behavior somewhere
else.
Nope; the input, such as DD, fully encapsulates the entire decider >>>>>>> HHH in its description.
In effect, it's as if DD has a copy of that decider.
The actual input to the decider; has the decider in its body.
It is built on it.
There is no "trompe d'oeil", like a hand reaching out of the
picture to hold a pen which draws the picture.
Programs can easily have themselves as input.
For instance your Unix program /bin/cp can copy itself: "/bin/cp >>>>>>> /bin/cp copy-of-cp"
/bin/cp is a string of bits which is the actual input to /bin/cp. >>>>>>>
Without the execution trace that a simulating termination analyzer >>>>>>>> provides this conflation error remained invisible.
Without the execution trace showing that the simulation wrongly
abandoned by HHH can be picked up and continued to watch DD halt, >>>>>>> /your own/ error of reasoning remains invisible to you.
recursive simulation non halting behavior pattern:
Lines 996 through 1006 matches the *recursive simulation non-halting >>>>>> behavior pattern*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Here is what you don't understand. In every recursive simulation
level.
your HHH(DD) returns 0.
simply wrong and I will explain why and how.
An instance of HHH correctly determines that DD simulated by HHH
matches the infinite recursion behavior pattern as soon as it
simulates DD twice, thus is one step ahead of all of the others.
It sees that DD calls HHH(DD) twice in sequence with no conditional
code between the invocation of DD and its call to HHH(DD). This
entails non-halting behavior for DD.
But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.
/Flibble
reasoning. My conclusion does logically follow from my basis.
HHH(DD) sees that DD correctly simulated by HHH cannot possibly reach
its own simulated final halt state.
*HHH sees this on the basis that*
(a) DD calls the same function twice in sequence (b) With the same
argument (c) DD has no conditional branch instructions between the
invocation of DD and its call to HHH(DD).
But DD halts if HHH reports to DD that DD is non-halting ergo HHH is incorrect.
/Flibble
DD has no conditional branch instructions
between the invocation of DD and its call to HHH(DD).
On 9/12/2025 11:48 AM, Mr Flibble wrote:
On Fri, 12 Sep 2025 11:35:51 -0500, olcott wrote:When HHH(DD) is supposed to ONLY report on the behavior that its actual
On 9/12/2025 10:16 AM, Mr Flibble wrote:
On Fri, 12 Sep 2025 09:47:35 -0500, olcott wrote:This is my basis. Changing the basis does not show any error in my
On 9/11/2025 2:04 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:I spent 10,000 hours on this an you only spent a few minutes, you
On 9/10/2025 10:43 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:You still do not understand that as soon as HHH(DD) matches this >>>>>>> recursive simulation non halting behavior pattern:
On 9/10/2025 7:41 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:I just discovered this when I was spending December to May
On 9/10/2025 7:11 PM, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:The diagonal test case never could ever actually exist.
<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>
That is positively true ... provided that D is not the >>>>>>>>>>>> diagonal test case aimed against H!
So it's okay not to mention that to Sipser, who, unlike you, >>>>>>>>>> obviously does believe that diagonal test cases can actually >>>>>>>>>> exist?
getting chemo therapy, radiation therapy and CAR-T cell therapy >>>>>>>>> in Minnesota.
There never has been any ACTUAL INPUT that does the opposite of >>>>>>>>> whatever its decider decides.
This has always been the error of conflating the behavior that >>>>>>>>> the ACTUAL INPUT ACTUALLY SPECIFIES with other behavior
somewhere else.
Nope; the input, such as DD, fully encapsulates the entire
decider HHH in its description.
In effect, it's as if DD has a copy of that decider.
The actual input to the decider; has the decider in its body.
It is built on it.
There is no "trompe d'oeil", like a hand reaching out of the
picture to hold a pen which draws the picture.
Programs can easily have themselves as input.
For instance your Unix program /bin/cp can copy itself: "/bin/cp >>>>>>>> /bin/cp copy-of-cp"
/bin/cp is a string of bits which is the actual input to /bin/cp. >>>>>>>>
Without the execution trace that a simulating termination
analyzer provides this conflation error remained invisible.
Without the execution trace showing that the simulation wrongly >>>>>>>> abandoned by HHH can be picked up and continued to watch DD halt, >>>>>>>> /your own/ error of reasoning remains invisible to you.
Lines 996 through 1006 matches the *recursive simulation
non-halting behavior pattern*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Here is what you don't understand. In every recursive simulation
level.
your HHH(DD) returns 0.
are simply wrong and I will explain why and how.
An instance of HHH correctly determines that DD simulated by HHH
matches the infinite recursion behavior pattern as soon as it
simulates DD twice, thus is one step ahead of all of the others.
It sees that DD calls HHH(DD) twice in sequence with no conditional
code between the invocation of DD and its call to HHH(DD). This
entails non-halting behavior for DD.
But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.
/Flibble
reasoning. My conclusion does logically follow from my basis.
HHH(DD) sees that DD correctly simulated by HHH cannot possibly reach
its own simulated final halt state.
*HHH sees this on the basis that*
(a) DD calls the same function twice in sequence (b) With the same
argument (c) DD has no conditional branch instructions between the
invocation of DD and its call to HHH(DD).
But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.
/Flibble
input actually specifies then HHH(DD)==0 is correct. That people keep changing this basis as their rebuttal is only the dishonestly of the
strawman error
On 9/12/2025 11:47 AM, Mr Flibble wrote:
On Fri, 12 Sep 2025 11:35:51 -0500, olcott wrote:When HHH(DD) is supposed to ONLY report on the behavior that its actual
But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.
/Flibble
But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.
/Flibble
input actually specifies then HHH(DD)==0 is correct. That people keep changing this basis as their rebuttal is only the dishonestly of the
strawman error
When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct.
That people keep changing this basis as their
rebuttal is only the dishonestly of the strawman error
When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct.
That people keep changing this basis as their
rebuttal is only the dishonestly of the strawman error
When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct. That people keep changing this basis as their
rebuttal is only the dishonestly of the strawman error
On Fri, 12 Sep 2025 11:50:43 -0500, olcott wrote:
On 9/12/2025 11:48 AM, Mr Flibble wrote:
On Fri, 12 Sep 2025 11:35:51 -0500, olcott wrote:When HHH(DD) is supposed to ONLY report on the behavior that its actual
On 9/12/2025 10:16 AM, Mr Flibble wrote:
On Fri, 12 Sep 2025 09:47:35 -0500, olcott wrote:This is my basis. Changing the basis does not show any error in my
On 9/11/2025 2:04 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:I spent 10,000 hours on this an you only spent a few minutes, you
On 9/10/2025 10:43 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:You still do not understand that as soon as HHH(DD) matches this >>>>>>>> recursive simulation non halting behavior pattern:
On 9/10/2025 7:41 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:I just discovered this when I was spending December to May >>>>>>>>>> getting chemo therapy, radiation therapy and CAR-T cell therapy >>>>>>>>>> in Minnesota.
On 9/10/2025 7:11 PM, Kaz Kylheku wrote:So it's okay not to mention that to Sipser, who, unlike you, >>>>>>>>>>> obviously does believe that diagonal test cases can actually >>>>>>>>>>> exist?
On 2025-09-10, olcott <polcott333@gmail.com> wrote: >>>>>>>>>>>>>> <MIT Professor Sipser agreed to ONLY these verbatim words >>>>>>>>>>>>>> 10/13/2022>The diagonal test case never could ever actually exist. >>>>>>>>>>>
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>
That is positively true ... provided that D is not the >>>>>>>>>>>>> diagonal test case aimed against H!
There never has been any ACTUAL INPUT that does the opposite of >>>>>>>>>> whatever its decider decides.
This has always been the error of conflating the behavior that >>>>>>>>>> the ACTUAL INPUT ACTUALLY SPECIFIES with other behavior
somewhere else.
Nope; the input, such as DD, fully encapsulates the entire
decider HHH in its description.
In effect, it's as if DD has a copy of that decider.
The actual input to the decider; has the decider in its body. >>>>>>>>> It is built on it.
There is no "trompe d'oeil", like a hand reaching out of the >>>>>>>>> picture to hold a pen which draws the picture.
Programs can easily have themselves as input.
For instance your Unix program /bin/cp can copy itself: "/bin/cp >>>>>>>>> /bin/cp copy-of-cp"
/bin/cp is a string of bits which is the actual input to /bin/cp. >>>>>>>>>
Without the execution trace that a simulating terminationWithout the execution trace showing that the simulation wrongly >>>>>>>>> abandoned by HHH can be picked up and continued to watch DD halt, >>>>>>>>> /your own/ error of reasoning remains invisible to you.
analyzer provides this conflation error remained invisible. >>>>>>>>>
Lines 996 through 1006 matches the *recursive simulation
non-halting behavior pattern*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Here is what you don't understand. In every recursive simulation >>>>>>> level.
your HHH(DD) returns 0.
are simply wrong and I will explain why and how.
An instance of HHH correctly determines that DD simulated by HHH
matches the infinite recursion behavior pattern as soon as it
simulates DD twice, thus is one step ahead of all of the others.
It sees that DD calls HHH(DD) twice in sequence with no conditional >>>>>> code between the invocation of DD and its call to HHH(DD). This
entails non-halting behavior for DD.
But DD halts if HHH reports to DD that DD is non-halting ergo HHH is >>>>> incorrect.
/Flibble
reasoning. My conclusion does logically follow from my basis.
HHH(DD) sees that DD correctly simulated by HHH cannot possibly reach
its own simulated final halt state.
*HHH sees this on the basis that*
(a) DD calls the same function twice in sequence (b) With the same
argument (c) DD has no conditional branch instructions between the
invocation of DD and its call to HHH(DD).
But DD halts if HHH reports to DD that DD is non-halting ergo HHH is
incorrect.
/Flibble
input actually specifies then HHH(DD)==0 is correct. That people keep
changing this basis as their rebuttal is only the dishonestly of the
strawman error
DD halts.
/Flibble
On 9/12/2025 10:08 AM, Richard Heathfield wrote:
On 12/09/2025 15:36, olcott wrote:
On 9/11/2025 12:12 PM, Richard Heathfield wrote:
On 11/09/2025 17:38, olcott wrote:
<snip>
[HHH] could simulate until just before the heat death of
the universe and then finally report that DD does not halt.
It would still be wrong. DD halts.
I carefully explain all of the details of how
this is incorrect
I and many others frequently and very carefully explain how you're
talking complete gibberish, and you never pay the slightest attention.
DD halts.
When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct. That people keep changing this basis as their
rebuttal is only the dishonestly of the strawman error
On 9/12/2025 10:08 AM, Richard Heathfield wrote:
On 12/09/2025 15:36, olcott wrote:When HHH(DD) is supposed to ONLY report on the behavior that its actual
On 9/11/2025 12:12 PM, Richard Heathfield wrote:
On 11/09/2025 17:38, olcott wrote:I carefully explain all of the details of how this is incorrect
<snip>
[HHH] could simulate until just before the heat death of the
universe and then finally report that DD does not halt.
It would still be wrong. DD halts.
I and many others frequently and very carefully explain how you're
talking complete gibberish, and you never pay the slightest attention.
DD halts.
input actually specifies then HHH(DD)==0 is correct. That people keep changing this basis as their rebuttal is only the dishonestly of the
strawman error
On 12/09/2025 17:50, olcott wrote:
When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct. That people keep changing this basis as their
rebuttal is only the dishonestly of the strawman error
No matter how many times you repeat this nonsense, nonsense it remains.
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
On 9/12/2025 10:08 AM, Richard Heathfield wrote:
On 12/09/2025 15:36, olcott wrote:
On 9/11/2025 12:12 PM, Richard Heathfield wrote:
On 11/09/2025 17:38, olcott wrote:
<snip>
[HHH] could simulate until just before the heat death of
the universe and then finally report that DD does not halt.
It would still be wrong. DD halts.
I carefully explain all of the details of how
this is incorrect
I and many others frequently and very carefully explain how you're
talking complete gibberish, and you never pay the slightest attention.
DD halts.
When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct. That people keep changing this basis as their
rebuttal is only the dishonestly of the strawman error
The input contains its own HHH. The *correctly and completely* simulated input calls HHH, obtains 0 and returns, exactly like when DD is
run at the outer level zero that is not simulated.
HHH does not *correctly and completely* simulate its input; it
jumps to the wrong conclusion and stops simulating a halting input,
wrongly declaring it to be non-halting.
According to the half-baked halting criteria you have selected, indeed
there is no evidence of halting in the execution trace up to the point
where the decision is made. But that evidence shows up afterward, if the simulation is continued and execution trace further extended.
The simulated HHH is the same as the outside HHH; both return 0.
On 9/12/2025 1:36 PM, Kaz Kylheku wrote:
On 2025-09-12, olcott <polcott333@gmail.com> wrote:You are confusing the simulated input before any abort have been
On 9/12/2025 10:08 AM, Richard Heathfield wrote:
On 12/09/2025 15:36, olcott wrote:When HHH(DD) is supposed to ONLY report on the behavior that its
On 9/11/2025 12:12 PM, Richard Heathfield wrote:
On 11/09/2025 17:38, olcott wrote:I carefully explain all of the details of how this is incorrect
<snip>
[HHH] could simulate until just before the heat death of the
universe and then finally report that DD does not halt.
It would still be wrong. DD halts.
I and many others frequently and very carefully explain how you're
talking complete gibberish, and you never pay the slightest
attention.
DD halts.
actual input actually specifies then HHH(DD)==0 is correct. That
people keep changing this basis as their rebuttal is only the
dishonestly of the strawman error
The input contains its own HHH. The *correctly and completely*
simulated input calls HHH, obtains 0 and returns, exactly like when DD
is run at the outer level zero that is not simulated.
performed with simulating the simulated input after the abort has been performed.
DD.HHH1 is a different execution trace than DD.HHH as proven here
On 9/5/2025 10:29 AM, olcott wrote:
Subject: [Explicitly showing the divergence of behavior between
HHH(DDD) and HHH1(DDD)]
HHH does not *correctly and completely* simulate its input; it jumps to*This is not half baked it is completely correct*
the wrong conclusion and stops simulating a halting input, wrongly
declaring it to be non-halting.
According to the half-baked halting criteria you have selected, indeed
there is no evidence of halting in the execution trace up to the point
where the decision is made. But that evidence shows up afterward, if
the simulation is continued and execution trace further extended.
HHH(DD) sees that DD correctly simulated by HHH cannot possibly reach
its own simulated final halt state.
*HHH sees this on the basis that*
(a) DD calls the same function twice in sequence (b) With the same
argument (c) DD has no conditional branch instructions between the
invocation of DD and its call to HHH(DD).
The simulated HHH is the same as the outside HHH; both return 0.As I already told you HHH(DD) aborts its simulation as soon as the above criteria is met. Its next inner HHH has not met this criteria yet. If
every HHH waits on the next inner one then none of them ever abort.
<snip> *to focus on the above point*
On 9/12/2025 12:10 PM, Richard Heathfield wrote:
On 12/09/2025 17:50, olcott wrote:*The first thing that must be done is for*
When HHH(DD) is supposed to ONLY report on the behavior that its
actual input actually specifies then HHH(DD)==0 is correct. That
people keep changing this basis as their rebuttal is only the
dishonestly of the strawman error
No matter how many times you repeat this nonsense, nonsense it remains.
*people to even understand what I am saying*
People that only have the shallow depth of understanding of
learned-by-rote and dogmatically treat this learned-by-rote as if it is
the infallible word of God prove that they are wholly disinterested in
any actual honest dialogue.
Within *my above basis* the meaning of my words conclusively proves that
I am correct. These words have had many thousands of progressive
refinements where I think these things through again and again. [1]
Once we get past this point THENN [then and only then]
can we move on to examining whether or not the is the correct basis.
That this basis contradicts the received view only proves that it is incorrect when this received view is infallible.
[1] One of my first posts in this forum didn't even know the difference between the halting problem and its proof:
On 7/10/2004 12:00 PM, Peter Olcott wrote:
[Can you find anything wrong with this solution to the Halting Problem?]
On Fri, 12 Sep 2025 13:42:23 -0500, olcott wrote:
On 9/12/2025 12:10 PM, Richard Heathfield wrote:
On 12/09/2025 17:50, olcott wrote:*The first thing that must be done is for*
When HHH(DD) is supposed to ONLY report on the behavior that its
actual input actually specifies then HHH(DD)==0 is correct. That
people keep changing this basis as their rebuttal is only the
dishonestly of the strawman error
No matter how many times you repeat this nonsense, nonsense it remains.
*people to even understand what I am saying*
People that only have the shallow depth of understanding of
learned-by-rote and dogmatically treat this learned-by-rote as if it is
the infallible word of God prove that they are wholly disinterested in
any actual honest dialogue.
Within *my above basis* the meaning of my words conclusively proves that
I am correct. These words have had many thousands of progressive
refinements where I think these things through again and again. [1]
Once we get past this point THENN [then and only then]
can we move on to examining whether or not the is the correct basis.
That this basis contradicts the received view only proves that it is
incorrect when this received view is infallible.
[1] One of my first posts in this forum didn't even know the difference
between the halting problem and its proof:
On 7/10/2004 12:00 PM, Peter Olcott wrote:
[Can you find anything wrong with this solution to the Halting Problem?]
DD halts.
/Flibble
On 12/09/2025 17:50, olcott wrote:
<snip>
When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct.
DD halts. If you stand by your claim that HHH(DD) == 0 is
correct, we are forced to conclude that HHH is not a decider for DD.
On 9/12/2025 12:10 PM, Richard Heathfield wrote:
On 12/09/2025 17:50, olcott wrote:*The first thing that must be done is for*
When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct. That people keep changing this basis as their
rebuttal is only the dishonestly of the strawman error
No matter how many times you repeat this nonsense, nonsense it
remains.
*people to even understand what I am saying*
People that only have the shallow depth of
understanding of learned-by-rote and dogmatically
treat this learned-by-rote as if it is the infallible
word of God prove that they are wholly disinterested
in any actual honest dialogue.
Within *my above basis* the meaning of my words
conclusively proves that I am correct.
These words
have had many thousands of progressive refinements
where I think these things through again and again. [1]
Once we get past this point THENN [then and only then]
can we move on to examining whether or not the is the
correct basis.
That this basis contradicts the received view only
proves that it is incorrect when this received view
is infallible.
[1] One of my first posts in this forum didn't even know
the difference between the halting problem and its proof:
On 7/10/2004 12:00 PM, Peter Olcott wrote:
[Can you find anything wrong with this solution to the Halting
Problem?]
(c) DD has no conditional branch instructions
between the invocation of DD and its call to HHH(DD).
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
(c) DD has no conditional branch instructions
between the invocation of DD and its call to HHH(DD).
But, idiot, this is true of the natively executed DD()
also:
int main(void) { DD(); OutputString("DD halts"); }
This DD also has no conditional branch instructions between
the start of DD and its call to HHH(DD)!
You know that this one halts and have admitted it and dismissed it as irrelevant because "it's not the input to HHH".
But the conditions hold; if the X86 CPU recorded an execution trace, we
could apply the Decide_Halting_H conditions to that trace, and at the
point where it hits the CALL insttruction, we would wrongly conclude
that it needs to be aborted.
On 9/12/2025 1:54 PM, Mr Flibble wrote:
On Fri, 12 Sep 2025 13:42:23 -0500, olcott wrote:You have proven that you can have good reasoning ability do you want to
On 9/12/2025 12:10 PM, Richard Heathfield wrote:
On 12/09/2025 17:50, olcott wrote:*The first thing that must be done is for*
When HHH(DD) is supposed to ONLY report on the behavior that its
actual input actually specifies then HHH(DD)==0 is correct. That
people keep changing this basis as their rebuttal is only the
dishonestly of the strawman error
No matter how many times you repeat this nonsense, nonsense it
remains.
*people to even understand what I am saying*
People that only have the shallow depth of understanding of
learned-by-rote and dogmatically treat this learned-by-rote as if it
is the infallible word of God prove that they are wholly disinterested
in any actual honest dialogue.
Within *my above basis* the meaning of my words conclusively proves
that I am correct. These words have had many thousands of progressive
refinements where I think these things through again and again. [1]
Once we get past this point THENN [then and only then]
can we move on to examining whether or not the is the correct basis.
That this basis contradicts the received view only proves that it is
incorrect when this received view is infallible.
[1] One of my first posts in this forum didn't even know the
difference between the halting problem and its proof:
On 7/10/2004 12:00 PM, Peter Olcott wrote:
[Can you find anything wrong with this solution to the Halting
Problem?]
DD halts.
/Flibble
throw that away now and get plonked?
Many people may have already plonked you.
On 9/12/2025 1:36 PM, Kaz Kylheku wrote:
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
On 9/12/2025 10:08 AM, Richard Heathfield wrote:
On 12/09/2025 15:36, olcott wrote:
On 9/11/2025 12:12 PM, Richard Heathfield wrote:
On 11/09/2025 17:38, olcott wrote:
<snip>
[HHH] could simulate until just before the heat death of
the universe and then finally report that DD does not halt.
It would still be wrong. DD halts.
I carefully explain all of the details of how
this is incorrect
I and many others frequently and very carefully explain how you're
talking complete gibberish, and you never pay the slightest attention. >>>> DD halts.
When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct. That people keep changing this basis as their
rebuttal is only the dishonestly of the strawman error
The input contains its own HHH. The *correctly and completely* simulated
input calls HHH, obtains 0 and returns, exactly like when DD is
run at the outer level zero that is not simulated.
You are confusing the simulated input before any
abort have been performed with simulating the
simulated input after the abort has been performed.
DD.HHH1 is a different execution trace than DD.HHH
as proven here
On 9/5/2025 10:29 AM, olcott wrote:
Subject: [Explicitly showing the divergence of behavior between
HHH(DDD) and HHH1(DDD)]
HHH does not *correctly and completely* simulate its input; it
jumps to the wrong conclusion and stops simulating a halting input,
wrongly declaring it to be non-halting.
According to the half-baked halting criteria you have selected, indeed
there is no evidence of halting in the execution trace up to the point
where the decision is made. But that evidence shows up afterward, if the
simulation is continued and execution trace further extended.
*This is not half baked it is completely correct*
HHH(DD) sees that DD correctly simulated by HHH
cannot possibly reach its own simulated final halt state.
*HHH sees this on the basis that*
(a) DD calls the same function twice in sequence
(b) With the same argument
(c) DD has no conditional branch instructions
between the invocation of DD and its call to HHH(DD).
The simulated HHH is the same as the outside HHH; both return 0.
As I already told you HHH(DD) aborts its simulation
as soon as the above criteria is met.
Its next inner
HHH has not met this criteria yet.
If every HHH waits
on the next inner one then none of them ever abort.
On 9/12/2025 2:01 PM, Kaz Kylheku wrote:
On 2025-09-12, olcott <polcott333@gmail.com> wrote:I conclusively proved that the execution trace of DD correctly simulated
(c) DD has no conditional branch instructions between the invocation
of DD and its call to HHH(DD).
But, idiot, this is true of the natively executed DD()
also:
int main(void) { DD(); OutputString("DD halts"); }
This DD also has no conditional branch instructions between the start
of DD and its call to HHH(DD)!
You know that this one halts and have admitted it and dismissed it as
irrelevant because "it's not the input to HHH".
But the conditions hold; if the X86 CPU recorded an execution trace, we
could apply the Decide_Halting_H conditions to that trace, and at the
point where it hits the CALL insttruction, we would wrongly conclude
that it needs to be aborted.
by HHH (before HHH has aborted its simulation)
is different than the execution trace of DD correctly simulated by HHH1 (after HHH has aborted its simulation).
On 9/5/2025 10:29 AM, olcott wrote:
Subject: [Explicitly showing the divergence of behavior between HHH(DDD)
and HHH1(DDD)]
If ignoring this proof is the basis of your rebuttal then I am sorry to
say that this is dishonest.
On 9/12/2025 12:10 PM, Richard Heathfield wrote:
On 12/09/2025 17:50, olcott wrote:*The first thing that must be done is for*
When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct. That people keep changing this basis as their
rebuttal is only the dishonestly of the strawman error
No matter how many times you repeat this nonsense, nonsense it remains.
*people to even understand what I am saying*
People that only have the shallow depth of
understanding of learned-by-rote and dogmatically
Within *my above basis* the meaning of my words
conclusively proves that I am correct.
These words
have had many thousands of progressive refinements
where I think these things through again and again.
Once we get past this point THENN [then and only then]
can we move on to examining whether or not the is the
correct basis.
That this basis contradicts the received view only
proves that it is incorrect when this received view
is infallible.
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
On 9/12/2025 12:10 PM, Richard Heathfield wrote:
On 12/09/2025 17:50, olcott wrote:*The first thing that must be done is for*
When HHH(DD) is supposed to ONLY report on the behavior that its
actual input actually specifies then HHH(DD)==0 is correct. That
people keep changing this basis as their rebuttal is only the
dishonestly of the strawman error
No matter how many times you repeat this nonsense, nonsense it
remains.
*people to even understand what I am saying*
Pepole understand and it's wrong. People have detailed explanations why
it's wrong, such as that your beliefs are based on the idea that when a simulation is not carried to completion, it's okay to regard it as non-terminating.
People that only have the shallow depth of understanding of
learned-by-rote and dogmatically
Nobody has learned about your exact apparatus by rote and comes armed
with preconceived about it; everyone has been generously analytic.
Even if halting were decidable, your machine is doing it wrong.
Within *my above basis* the meaning of my words conclusively proves
that I am correct.
You don't actually know what it means to prove.
These words have had many thousands of progressive refinements where I
think these things through again and again.
If you repeatedly think identical thoughts, you are not making progress.
The 10,000th day of thinking the same thought is the same as the first
day; like a perpetual Groundhog Day.
Once we get past this point THENN [then and only then]
can we move on to examining whether or not the is the correct basis.
Examining whether or not there is a correct basis requires everyone to
be prepared for the conclusion that the basis is not correct.
It is obvious that you are unprepared for and even fear that conclusion, because then you have nothing to show for all the wasted time.
That this basis contradicts the received view only proves that it is
incorrect when this received view is infallible.
DD halts in your apparatus, while you and your HHH function claim that
it doesn't, /regardless of whether halting is decidable/.
This is not a preconceived idea coming from having learned about the
Halting Theorem from textbooks.
It's a property that derives from nothing but your program,
and elementary logic / critical reasoning.
If halting were somehow decidable, your program would not be showing
that it is. If halting were decidable, then the diagonalization trick
would somehow have to wrong; but your program would not be showing that.
Your progarm would continue to just be some dumb piece of crock which
claims that something that obviously halts is non-halting.
Your claims and your program have had much more attention and other
people's time than they deserve, yet you continue to show yourself ungrateful.
On 9/11/2025 2:46 PM, Kaz Kylheku wrote:
On 2025-09-11, Mike Terry
<news.dead.person.stones@darjeeling.plus.com> wrote:
I think I'm on safe grounds predicting that Sipser is considering
deciding to mean reporting the
decision and halting. And of course an H which never returns is not
a halt decider in the sense of
the HP.
But your idea of internally determining something made me think: is
it easy to actually do that in
practice? It seems so to me.
With side effects, it is possible. Then we don't have pure functions
any more.
E.g. the decider can do this:
puts("I know this doesn't halt, but I can't return because that
would change the result.");
for(;;)/**/;
That has no effect when the measure of halting is
ONLY the semantic property of the input finite string.
On 9/12/2025 10:08 AM, Richard Heathfield wrote:
On 12/09/2025 15:36, olcott wrote:
On 9/11/2025 12:12 PM, Richard Heathfield wrote:
On 11/09/2025 17:38, olcott wrote:
<snip>
[HHH] could simulate until just before the heat death of
the universe and then finally report that DD does not halt.
It would still be wrong. DD halts.
I carefully explain all of the details of how
this is incorrect
I and many others frequently and very carefully explain how you're
talking complete gibberish, and you never pay the slightest attention.
DD halts.
When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies
then HHH(DD)==0
is correct.
On 9/12/2025 12:10 PM, Richard Heathfield wrote:You show that you're not working on the halting problem and any claim
On 12/09/2025 17:50, olcott wrote:*The first thing that must be done is for*
When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct. That people keep changing this basis as their
rebuttal is only the dishonestly of the strawman error
No matter how many times you repeat this nonsense, nonsense it remains.
*people to even understand what I am saying*
People that only have the shallow depth of
understanding of learned-by-rote and dogmatically
treat this learned-by-rote as if it is the infallible
word of God prove that they are wholly disinterested
in any actual honest dialogue.
Within *my above basis*
On 9/12/2025 2:01 PM, Kaz Kylheku wrote:^^^^^^^^^^^^^^^^^^^^^^
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
(c) DD has no conditional branch instructions
between the invocation of DD and its call to HHH(DD).
But, idiot, this is true of the natively executed DD()
also:
int main(void) { DD(); OutputString("DD halts"); }
This DD also has no conditional branch instructions between
the start of DD and its call to HHH(DD)!
You know that this one halts and have admitted it and dismissed it as
irrelevant because "it's not the input to HHH".
But the conditions hold; if the X86 CPU recorded an execution trace, we
could apply the Decide_Halting_H conditions to that trace, and at the
point where it hits the CALL insttruction, we would wrongly conclude
that it needs to be aborted.
I conclusively proved that the
execution trace of DD correctly simulated by HHH
(before HHH has aborted its simulation)
is different than the^^^^^^^^^^^^^^^^^^^^^
execution trace of DD correctly simulated by HHH1
(after HHH has aborted its simulation).
On 9/5/2025 10:29 AM, olcott wrote:
Subject: [Explicitly showing the divergence of behavior between
HHH(DDD) and HHH1(DDD)]
If ignoring this proof is the basis of your rebuttal
then I am sorry to say that this is dishonest.
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
On 9/12/2025 2:01 PM, Kaz Kylheku wrote:^^^^^^^^^^^^^^^^^^^^^^
On 2025-09-12, olcott <polcott333@gmail.com> wrote:I conclusively proved that the execution trace of DD correctly
(c) DD has no conditional branch instructions between the invocation
of DD and its call to HHH(DD).
But, idiot, this is true of the natively executed DD()
also:
int main(void) { DD(); OutputString("DD halts"); }
This DD also has no conditional branch instructions between the start
of DD and its call to HHH(DD)!
You know that this one halts and have admitted it and dismissed it as
irrelevant because "it's not the input to HHH".
But the conditions hold; if the X86 CPU recorded an execution trace,
we could apply the Decide_Halting_H conditions to that trace, and at
the point where it hits the CALL insttruction, we would wrongly
conclude that it needs to be aborted.
simulated by HHH (before HHH has aborted its simulation)
is different than the execution trace of DD correctly simulated by HHH1^^^^^^^^^^^^^^^^^^^^^
(after HHH has aborted its simulation).
Of course the execution traces are different before and after the abort.
They are not different at the same point where the abort decision is
made: where a CALL instruction is observed in DD's instruction stream,
but a conditional jump has not been seen.
On 9/5/2025 10:29 AM, olcott wrote:
Subject: [Explicitly showing the divergence of behavior between
HHH(DDD) and HHH1(DDD)]
If ignoring this proof is the basis of your rebuttal then I am sorry to
say that this is dishonest.
Nowhere did I say that if you have multiple deciders: HHH,
HHH1, HHH2, HHH3, then every HHHi(DD) must behave the same way.
They do not!
What behaves the same way is DD (which calls HHH(DD), which returns 0 to
it).
Deciders that are not HHH have no excuse for deciding DD incorrectly; we expect every H that is not HHH to be capable of correctly returning 1 to attest that DD halts.
(Moreover, those that do return 1 do not have to achieve that with
execution traces identical to each other.)
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
On 9/12/2025 2:01 PM, Kaz Kylheku wrote:^^^^^^^^^^^^^^^^^^^^^^
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
(c) DD has no conditional branch instructions
between the invocation of DD and its call to HHH(DD).
But, idiot, this is true of the natively executed DD()
also:
int main(void) { DD(); OutputString("DD halts"); }
This DD also has no conditional branch instructions between
the start of DD and its call to HHH(DD)!
You know that this one halts and have admitted it and dismissed it as
irrelevant because "it's not the input to HHH".
But the conditions hold; if the X86 CPU recorded an execution trace, we
could apply the Decide_Halting_H conditions to that trace, and at the
point where it hits the CALL insttruction, we would wrongly conclude
that it needs to be aborted.
I conclusively proved that the
execution trace of DD correctly simulated by HHH
(before HHH has aborted its simulation)
is different than the^^^^^^^^^^^^^^^^^^^^^
execution trace of DD correctly simulated by HHH1
(after HHH has aborted its simulation).
Of course the execution traces are different before and
after the abort.
On 9/12/2025 3:01 PM, Kaz Kylheku wrote:
On 2025-09-12, olcott <polcott333@gmail.com> wrote:DD() has the same behavior as DD correctly simulated by HHH1.
On 9/12/2025 2:01 PM, Kaz Kylheku wrote:^^^^^^^^^^^^^^^^^^^^^^
On 2025-09-12, olcott <polcott333@gmail.com> wrote:I conclusively proved that the execution trace of DD correctly
(c) DD has no conditional branch instructions between the invocation >>>>> of DD and its call to HHH(DD).
But, idiot, this is true of the natively executed DD()
also:
int main(void) { DD(); OutputString("DD halts"); }
This DD also has no conditional branch instructions between the start
of DD and its call to HHH(DD)!
You know that this one halts and have admitted it and dismissed it as
irrelevant because "it's not the input to HHH".
But the conditions hold; if the X86 CPU recorded an execution trace,
we could apply the Decide_Halting_H conditions to that trace, and at
the point where it hits the CALL insttruction, we would wrongly
conclude that it needs to be aborted.
simulated by HHH (before HHH has aborted its simulation)
is different than the execution trace of DD correctly simulated by^^^^^^^^^^^^^^^^^^^^^
HHH1 (after HHH has aborted its simulation).
Of course the execution traces are different before and after the
abort.
HHH sees different behavior that it must abort.
<snip> *to keep focus of attention one key point*
On 9/12/2025 1:36 PM, Kaz Kylheku wrote:I really don't get what you mean with "after the abort". When you stop simulating, nothing happens anymore. Can you explain?
The input contains its own HHH. The *correctly and completely*You are confusing the simulated input before any abort have been
simulated input calls HHH, obtains 0 and returns, exactly like when DD
is run at the outer level zero that is not simulated.
performed with simulating the simulated input after the abort has been performed.
DD.HHH1 is a different execution trace than DD.HHH as proven hereIf I showed you one of these traces without saying which, you could
Not *yet*, but it will!The simulated HHH is the same as the outside HHH; both return 0.As I already told you HHH(DD) aborts its simulation as soon as the above criteria is met. Its next inner HHH has not met this criteria yet.
If every HHH waits on the next inner one then none of them ever abort.Let's call HHH_NA the simulator that doesn't abort and DD_NA the program
On 9/12/2025 12:10 PM, Richard Heathfield wrote:That is a bit of a problem when you are saying nonsense.
On 12/09/2025 17:50, olcott wrote:
No matter how many times you repeat this nonsense, nonsense it remains.*The first thing that must be done is for*
*people to even understand what I am saying*
People that only have the shallow depth of understanding ofArgumentum ad hominem.
learned-by-rote and dogmatically treat this learned-by-rote as if it is
the infallible word of God prove that they are wholly disinterested in
any actual honest dialogue.
Within *my above basis* the meaning of my words conclusively proves thatYou are too hung up on specific phrasings. They are not magic words.
I am correct. These words have had many thousands of progressive
refinements where I think these things through again and again. [1]
Once we get past this point THENN [then and only then]That's putting the cart before the horse. You can empirically not be
can we move on to examining whether or not the is the correct basis.
That this basis contradicts the received view only proves that it is incorrect when this received view is infallible.This isn't even an argument.
On 9/11/2025 2:07 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
Lines 996 through 1006 matches the
*recursive simulation non-halting behavior pattern*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Not correctly though. Once that condition fires, and the
simulation is abandoned, it is failing to see that if the
simulation were continued, the simulated HHH(DD) would
return and proceed to the conditional instruction.
As I already said in my prior post and will repeat again
so that you can pay better attention. HHH sees that its
simulated DDD matches a non-halting behavior pattern as
soon as it simulated DD twice.
The next level simulated HHH could only see that DD has
been simulated once when the executed one has already
met is abort criteria.
Since every HHH has the exact same x86 code if the outer
one waited on the inner one then this wold form an infinite
chain of waiting and none of them would ever abort.
You know this is true, but you would rather look brutally
stupid than to admit being wrong.
The bible says: Revelation 21:8 NRSV
"...all liars, their place will be in the lake that burns with
fire and sulfur, which is the second death."
On 9/12/2025 8:21 AM, olcott wrote:
On 9/11/2025 2:07 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
Lines 996 through 1006 matches the
*recursive simulation non-halting behavior pattern*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Not correctly though. Once that condition fires, and the
simulation is abandoned, it is failing to see that if the
simulation were continued, the simulated HHH(DD) would
return and proceed to the conditional instruction.
As I already said in my prior post and will repeat again
so that you can pay better attention. HHH sees that its
simulated DDD matches a non-halting behavior pattern as
soon as it simulated DD twice.
The next level simulated HHH could only see that DD has
been simulated once when the executed one has already
met is abort criteria.
Since every HHH has the exact same x86 code if the outer
one waited on the inner one then this wold form an infinite
chain of waiting and none of them would ever abort.
You know this is true, but you would rather look brutally
stupid than to admit being wrong.
The bible says: Revelation 21:8 NRSV
"...all liars, their place will be in the lake that burns with
fire and sulfur, which is the second death."
You need to be monitored...
On 9/12/2025 3:01 PM, Kaz Kylheku wrote:
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
On 9/12/2025 2:01 PM, Kaz Kylheku wrote:^^^^^^^^^^^^^^^^^^^^^^
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
(c) DD has no conditional branch instructions
between the invocation of DD and its call to HHH(DD).
But, idiot, this is true of the natively executed DD()
also:
int main(void) { DD(); OutputString("DD halts"); }
This DD also has no conditional branch instructions between
the start of DD and its call to HHH(DD)!
You know that this one halts and have admitted it and dismissed it as
irrelevant because "it's not the input to HHH".
But the conditions hold; if the X86 CPU recorded an execution trace, we >>>> could apply the Decide_Halting_H conditions to that trace, and at the
point where it hits the CALL insttruction, we would wrongly conclude
that it needs to be aborted.
I conclusively proved that the
execution trace of DD correctly simulated by HHH
(before HHH has aborted its simulation)
is different than the^^^^^^^^^^^^^^^^^^^^^
execution trace of DD correctly simulated by HHH1
(after HHH has aborted its simulation).
Of course the execution traces are different before and
after the abort.
DD() has the same behavior as DD correctly simulated by HHH1.
HHH sees different behavior that it must abort.
<snip> *to keep focus of attention one key point*
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
On 9/12/2025 3:01 PM, Kaz Kylheku wrote:
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
On 9/12/2025 2:01 PM, Kaz Kylheku wrote:^^^^^^^^^^^^^^^^^^^^^^
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
(c) DD has no conditional branch instructions
between the invocation of DD and its call to HHH(DD).
But, idiot, this is true of the natively executed DD()
also:
int main(void) { DD(); OutputString("DD halts"); }
This DD also has no conditional branch instructions between
the start of DD and its call to HHH(DD)!
You know that this one halts and have admitted it and dismissed it as >>>>> irrelevant because "it's not the input to HHH".
But the conditions hold; if the X86 CPU recorded an execution trace, we >>>>> could apply the Decide_Halting_H conditions to that trace, and at the >>>>> point where it hits the CALL insttruction, we would wrongly conclude >>>>> that it needs to be aborted.
I conclusively proved that the
execution trace of DD correctly simulated by HHH
(before HHH has aborted its simulation)
is different than the^^^^^^^^^^^^^^^^^^^^^
execution trace of DD correctly simulated by HHH1
(after HHH has aborted its simulation).
Of course the execution traces are different before and
after the abort.
DD() has the same behavior as DD correctly simulated by HHH1.
HHH sees different behavior that it must abort.
<snip> *to keep focus of attention one key point*
You are inviting a laser focus on your blatantly inconsistency.
Nothing whatsoever that is loking at DD can see different behavior
from anything else that is looking at DD.
DD is one thing, defined one way, and set in stone in any given scenario.
If we edit DD or HHH, or both, we have a different scenario which is
entirely in a different universe, inaccessible from the previous
scenario in which they had a different definition.
On 2025-09-12, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 12/09/2025 17:50, olcott wrote:
<snip>
When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct.
DD halts. If you stand by your claim that HHH(DD) == 0 is
correct, we are forced to conclude that HHH is not a decider for DD.
HHH is a decider for some half-baked conditions of seeing a CALL
instruction in the hitherto observed execution trace, while not seeing conditional jump instructions.
Olcott's logic has zero logical basis for jumping to the conclusion
that if no conditional jump instructions occur in mere *prefix*
of the instruction stream of a recursively simulating loop, that
they never occur: i.e. shall not be found in the *suffix* of the
execution trace that will be produced when the simulation is taken
to completion.
On 12/09/2025 19:58, Kaz Kylheku wrote:
On 2025-09-12, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 12/09/2025 17:50, olcott wrote:
<snip>
When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct.
DD halts. If you stand by your claim that HHH(DD) == 0 is
correct, we are forced to conclude that HHH is not a decider for DD.
HHH is a decider for some half-baked conditions of seeing a CALL instruction in the hitherto observed execution trace, while not seeing conditional jump instructions.
Olcott's logic has zero logical basis for jumping to the conclusion
that if no conditional jump instructions occur in mere *prefix*
of the instruction stream of a recursively simulating loop, that
they never occur: i.e. shall not be found in the *suffix* of the
execution trace that will be produced when the simulation is taken
to completion.
Right. PO's abort test is unsound (it can match against halting computations). He has a condition:
- there are no conditional branch instructions
*within the C scope of function DD* between the two call instructions. [conditional branch instructions within HHH (called from DD) are ignored!]
That is patent nonsense on multiple levels. E.g. how can PO possibly be thinking that moving a
conditional branch out of DD function scope into a subroutine (HHH) affects the validity of his
rule?
Others rightly point out that there are conditional branch instructions in HHH which PO is ignoring,
so PO is unjustified in his conclusion. True enough, but there is an underlying suggestion here
that his rule would have been sound if only he hadn't restricted the "no conditional branches"
condition to DD scope . That's not the case: even if the condition above read:
- there are no conditional branch instructions (anywhere) between the two call instructions.
the test would still be unsound.
One of PO's basic problems is that he thinks his merged nested simulation trace can be treated
exactly like a single-processor trace. That's one of the reasons he keeps posting about
Infinite_Recursion() being correctly decided by HHH.
void Infinite_Recursion()
{
Infinite_Recursion();
}
He doesn't see how the simulation aspect changes things.
Mike.Firstly, HHH does not simulate anything. HHH simply traces execution path and determine when to stop and what to return in olcott's point of view.
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
On 9/12/2025 3:01 PM, Kaz Kylheku wrote:
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
On 9/12/2025 2:01 PM, Kaz Kylheku wrote:^^^^^^^^^^^^^^^^^^^^^^
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
(c) DD has no conditional branch instructions
between the invocation of DD and its call to HHH(DD).
But, idiot, this is true of the natively executed DD()
also:
int main(void) { DD(); OutputString("DD halts"); }
This DD also has no conditional branch instructions between
the start of DD and its call to HHH(DD)!
You know that this one halts and have admitted it and dismissed it as >>>>> irrelevant because "it's not the input to HHH".
But the conditions hold; if the X86 CPU recorded an execution trace, we >>>>> could apply the Decide_Halting_H conditions to that trace, and at the >>>>> point where it hits the CALL insttruction, we would wrongly conclude >>>>> that it needs to be aborted.
I conclusively proved that the
execution trace of DD correctly simulated by HHH
(before HHH has aborted its simulation)
is different than the^^^^^^^^^^^^^^^^^^^^^
execution trace of DD correctly simulated by HHH1
(after HHH has aborted its simulation).
Of course the execution traces are different before and
after the abort.
DD() has the same behavior as DD correctly simulated by HHH1.
HHH sees different behavior that it must abort.
<snip> *to keep focus of attention one key point*
You are inviting a laser focus on your blatantly inconsistency.
Nothing whatsoever that is loking at DD can see different behavior
from anything else that is looking at DD.
Of course the execution traces are different before and
after the abort.
On Sat, 2025-09-13 at 03:52 +0100, Mike Terry wrote:
On 12/09/2025 19:58, Kaz Kylheku wrote:
On 2025-09-12, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 12/09/2025 17:50, olcott wrote:
<snip>
When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct.
DD halts. If you stand by your claim that HHH(DD) == 0 is
correct, we are forced to conclude that HHH is not a decider for DD.
HHH is a decider for some half-baked conditions of seeing a CALL
instruction in the hitherto observed execution trace, while not seeing
conditional jump instructions.
Olcott's logic has zero logical basis for jumping to the conclusion
that if no conditional jump instructions occur in mere *prefix*
of the instruction stream of a recursively simulating loop, that
they never occur: i.e. shall not be found in the *suffix* of the
execution trace that will be produced when the simulation is taken
to completion.
Right. PO's abort test is unsound (it can match against halting computations). He has a condition:
- there are no conditional branch instructions
*within the C scope of function DD* between the two call instructions.
[conditional branch instructions within HHH (called from DD) are ignored!]
That is patent nonsense on multiple levels. E.g. how can PO possibly be thinking that moving a
conditional branch out of DD function scope into a subroutine (HHH) affects the validity of his
rule?
Others rightly point out that there are conditional branch instructions in HHH which PO is ignoring,
so PO is unjustified in his conclusion. True enough, but there is an underlying suggestion here
that his rule would have been sound if only he hadn't restricted the "no conditional branches"
condition to DD scope . That's not the case: even if the condition above read:
- there are no conditional branch instructions (anywhere) between the two call instructions.
the test would still be unsound.
One of PO's basic problems is that he thinks his merged nested simulation trace can be treated
exactly like a single-processor trace. That's one of the reasons he keeps posting about
Infinite_Recursion() being correctly decided by HHH.
void Infinite_Recursion()
{
Infinite_Recursion();
}
He doesn't see how the simulation aspect changes things.
Mike.
Firstly, HHH does not simulate anything. HHH simply traces execution path and determine when to stop and what to return in olcott's point of view.
On 13/09/2025 01:29, Kaz Kylheku wrote:
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
On 9/12/2025 3:01 PM, Kaz Kylheku wrote:
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
On 9/12/2025 2:01 PM, Kaz Kylheku wrote:
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
(c) DD has no conditional branch instructions
between the invocation of DD and its call to HHH(DD).
But, idiot, this is true of the natively executed DD()
also:
int main(void) { DD(); OutputString("DD halts"); }
This DD also has no conditional branch instructions between
the start of DD and its call to HHH(DD)!
You know that this one halts and have admitted it and dismissed it as
irrelevant because "it's not the input to HHH".
But the conditions hold; if the X86 CPU recorded an execution trace, we
could apply the Decide_Halting_H conditions to that trace, and at the
point where it hits the CALL insttruction, we would wrongly conclude
that it needs to be aborted.
I conclusively proved that the^^^^^^^^^^^^^^^^^^^^^^
execution trace of DD correctly simulated by HHH
(before HHH has aborted its simulation)
is different than the^^^^^^^^^^^^^^^^^^^^^
execution trace of DD correctly simulated by HHH1
(after HHH has aborted its simulation).
Of course the execution traces are different before and
after the abort.
DD() has the same behavior as DD correctly simulated by HHH1.
HHH sees different behavior that it must abort.
<snip> *to keep focus of attention one key point*
You are inviting a laser focus on your blatantly inconsistency.
Nothing whatsoever that is loking at DD can see different behavior
from anything else that is looking at DD.
DD is one thing, defined one way, and set in stone in any given scenario.
I found a previous post with the comparison:
HHH1 Simulation of DD (HHH1 never aborts) HHH Simulation of DD
========================================== ==========================================
S machine machine assembly S machine machine assembly
D address code language D address code language
= ======== ============== ============= = ======== ============== =============
[1][0000213e] 55 push ebp [1][0000213e] 55 push ebp
[1][0000213f] 8bec mov ebp,esp [1][0000213f] 8bec mov ebp,esp
[1][00002141] 51 push ecx [1][00002141] 51 push ecx
[1][00002142] 683e210000 push 0000213e [1][00002142] 683e210000 push 0000213e
[1][00002147] e8a2f4ffff call 000015ee [1][00002147] e8a2f4ffff call 000015ee
[1]New slave_stack at:14e33e [1]New slave_stack at:14e33e
[1]Begin Local Halt Decider Simulation
[2][0000213e] 55 push ebp [2][0000213e] 55 push ebp
[2][0000213f] 8bec mov ebp,esp [2][0000213f] 8bec mov ebp,esp
[2][00002141] 51 push ecx [2][00002141] 51 push ecx
[2][00002142] 683e210000 push 0000213e [2][00002142] 683e210000 push 0000213e
[2][00002147] e8a2f4ffff call 000015ee [2][00002147] e8a2f4ffff call 000015ee
[3]New slave_stack at:198d66 ### THIS IS WHERE HHH stops simulating DD
[3][0000213e] 55 push ebp ### Right up to this point
[3][0000213f] 8bec mov ebp,esp ### HHH's and HHH1's traces match as claimed
[3][00002141] 51 push ecx
[3][00002142] 683e210000 push 0000213e
[3][00002147] e8a2f4ffff call 000015ee
[1]Infinite Recursion Detected Simulation Stopped
[1][0000214c] 83c404 add esp,+04
[1][0000214f] 8945fc mov [ebp-04],eax
[1][00002152] 837dfc00 cmp dword [ebp-04],+00
[1][00002156] 7402 jz 0000215a
[1][0000215a] 8b45fc mov eax,[ebp-04]
[1][0000215d] 8be5 mov esp,ebp
[1][0000215f] 5d pop ebp
[1][00002160] c3 ret
(SD column is simulation depth)
Mike.
If we edit DD or HHH, or both, we have a different scenario which is entirely in a different universe, inaccessible from the previous
scenario in which they had a different definition.
That is why I said it is so important for you to
carefully study this carefully annotated execution
trace instead of continuing to totally ignore it.
On 9/11/2025 1:06 PM, Mike Terry wrote:
On 11/09/2025 04:17, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
On 9/10/2025 7:57 PM, Mike Terry wrote:
On 11/09/2025 01:11, Kaz Kylheku wrote:
On 2025-09-10, olcott <polcott333@gmail.com> wrote:
<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>
That is positively true ... provided that D is not the diagonal
test case aimed against H!
Nope. Reliable sources say that you misinterpreted something that
Sipser wrote.
Separately from that, if Sisper really did say that, he might not >>>>>> have
been aware that D is supposed to be the diagonal test case
targeting H,
such that D is built on top of H, and D's behavior depends on H's
decision. Had that been pointed out, a corection would have swiftly >>>>>> followed.
My explanation is Sipser is considering a general H and a general
input
D. When he says "...its simulated D would never stop running unless >>>>> aborted..." he is naturally talking about criteria that can be applied >>>>> to determine non-halting *OF INPUT D*, and no other input.
Yet input D can be anything it is an arbitrary placeholder.
(However, you should not use the letter D when not intending to
symbolize
a diagonal test case. Maybe something else like P.)
But anyway, I wanted to add that, I can also agree with your verbatim
words above from 10/13/2022.
Paraphrase:
If a halt decider /correctly/ determine, by /correctly/ simulating >>> its
input that the input doesn't halt, then a halt decicer
can stop the simulation and reject the input.
We have an logical if here:
"If it can correctly simulate ... determine, ... THEN it can reject" >>>
IF P THEN Q
P -> Q
Now P -> Q has a truth table such that P -> Q is only false when
P is true and Q is false.
P Q P -> Q
F F T
F T T
T F F
T T T
In the diagonal test case D that is aligned against H, H /cannot/
correctly determine the halting status of D, and therefore doesn't.
Thus P is false.
If P is false then P -> Q is true.
Therefore, it is reasonable to agree with P -> Q.
"If unicorns exist, then pigs fly" --- I don't disagree!
However, there are some reasons to believe we can hit the "T F"
case of the truth table.
Suppose that H correctly determines the halting status of D. H cannot
report that. It has to keep it to itself and not return. In that case, >>> H can stop the simulation of D, but just cannot itself terminate; if it
returns anything to D, it is automatically wrong.
In that situation P is true (H has correctly simulated and determined,
but Q is false: it is not true that H can correctly report anything)
It hinges around the philosophical question of: if H doesn't report
anything, is it deemed to have determined anything?
If we deny this: H is not deemed to determine anything until it
terminates and reports it, then P is necessarily false for the diagonal
case, and your verbatim "Sipser agree text" can be easily agreed with.
If we admit the possiblity that H can internally determine something,
but keep it to itself, so as not to provoke contradictory behavior that
proves it wrong, then it's not easy to agree with your text. H has
determined that D doesn't halt, and H is refraining from reporting this
fact in order to keep it true: for as long as H doesn't return, D
doesn't return and the fact remains true.
The problem is that functions are blackboxes. A result that is secret
within a function effectively doesn't exist; only the return value is
observable, or the fact that the function is not returning. Therefore
the former camp is more on the correct side (H is not deemed to have
correctly determined anything until it returns) and can agree with
your verbatim text.
I think I'm on safe grounds predicting that Sipser is considering
deciding to mean reporting the decision and halting. And of course an
H which never returns is not a halt decider in the sense of the HP.
But your idea of internally determining something made me think: is it
easy to actually do that in practice? It seems so to me.
H can be coded to examine its input computation. If it sees that it
has no reachable code path that leads to any final state, it can be
said to "know" (or have "determined") at that point that its input is
non- halting - if we like we could say it must pass through a
designated "I've worked out the input doesn't halt" state to
"register" its discovery. Regardless of the previous test succeeding,
H then loops.
HHH(DD) sees that DD correctly simulated by HHH
cannot possibly reach its own simulated final halt state.
*HHH sees this on the basis that*
(a) DD calls the same function twice in sequence
(b) With the same argument
(c) DD has no conditional branch instructions
between the invocation of DD and its call to HHH(DD).
So now we construct the diagonal machine D, which embeds H algorithm.
H(D) never halts, and so D never halts. Moreover, D() has no
reachable code path that returns, and that fact can be correctly
ascertained by code in H, so H (coded appropriately) can "determine"
that D() never halts and register this, before continuing with its
infinite loop.
Conclusion: H has correctly proved (internally) that D() does not
halt, and registered that by passing through its designated state.
And indeed D() never halts as proved (internally) by H.
For comparison we could imaging an H that (regardless of input) just
"registers" that the input never halts, then enters an infinite loop.
That's much simpler! But... while this H /correctly/ registers that
its associated diagonal D() never halts, it can't be said to have
"seen"/"determined" that it halts, as you required(??), because there
are alternative inputs which H will also register as never halting but
will in fact halt.
[OK, I'm not sure if you used the word "determined" in the stronger
sense I interpreted it, or in the weaker sense of H simply being
"correct for the case being considered" without any justification. My
H which looks for reachable terminating code paths works with the
stronger "determined" interpretation.]
Mike.
On 9/11/2025 5:05 PM, André G. Isaak wrote:
On 2025-09-10 21:17, Kaz Kylheku wrote:
Now P -> Q has a truth table such that P -> Q is only false when
P is true and Q is false.
P Q P -> Q
F F T
F T T
T F F
T T T
Just to warn you, you're venturing into dangerous territory here.
Among Olcott's many peculiarities is the fact that in the past he has
rejected the above truth table (though it's never been clear what he
wants to replace it with).
André
*I finally have good words for this*
Because implication is thought to model a
logical "if" statement:
If X then Y means that whenever X is true then
Y is true and whenever Y is false then X is false.
On 9/11/2025 2:07 PM, Kaz Kylheku wrote:
On 2025-09-11, olcott <polcott333@gmail.com> wrote:
Lines 996 through 1006 matches the
*recursive simulation non-halting behavior pattern*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
Not correctly though. Once that condition fires, and the
simulation is abandoned, it is failing to see that if the
simulation were continued, the simulated HHH(DD) would
return and proceed to the conditional instruction.
As I already said in my prior post and will repeat again
so that you can pay better attention. HHH sees that its
simulated DDD matches a non-halting behavior pattern as
soon as it simulated DD twice.
The next level simulated HHH could only see that DD has
been simulated once when the executed one has already
met is abort criteria.
Since every HHH has the exact same x86 code if the outer
one waited on the inner one then this wold form an infinite
chain of waiting and none of them would ever abort.
On 9/12/2025 7:29 PM, Kaz Kylheku wrote:
On 2025-09-12, olcott <polcott333@gmail.com> wrote:On 9/12/2025 3:01 PM, Kaz Kylheku wrote:
On 9/12/2025 3:01 PM, Kaz Kylheku wrote:
On 2025-09-12, olcott <polcott333@gmail.com> wrote:DD() has the same behavior as DD correctly simulated by HHH1.
On 9/12/2025 2:01 PM, Kaz Kylheku wrote:^^^^^^^^^^^^^^^^^^^^^^
On 2025-09-12, olcott <polcott333@gmail.com> wrote:I conclusively proved that the execution trace of DD correctly
(c) DD has no conditional branch instructions between the
invocation of DD and its call to HHH(DD).
But, idiot, this is true of the natively executed DD()
also:
int main(void) { DD(); OutputString("DD halts"); }
This DD also has no conditional branch instructions between the
start of DD and its call to HHH(DD)!
You know that this one halts and have admitted it and dismissed it >>>>>> as irrelevant because "it's not the input to HHH".
But the conditions hold; if the X86 CPU recorded an execution
trace, we could apply the Decide_Halting_H conditions to that
trace, and at the point where it hits the CALL insttruction, we
would wrongly conclude that it needs to be aborted.
simulated by HHH (before HHH has aborted its simulation)
is different than the execution trace of DD correctly simulated by^^^^^^^^^^^^^^^^^^^^^
HHH1 (after HHH has aborted its simulation).
Of course the execution traces are different before and after the
abort.
HHH sees different behavior that it must abort.
<snip> *to keep focus of attention one key point*
You are inviting a laser focus on your blatantly inconsistency.
Nothing whatsoever that is loking at DD can see different behavior from
anything else that is looking at DD.
Of course the execution traces are different before and after the
abort.
HHH1 ONLY sees the behavior of DD *AFTER* HHH has aborted DD thus need
not abort DD itself.
HHH ONLY sees the behavior of DD *BEFORE* HHH has aborted DD thus must
abort DD itself.
That is why I said it is so important for you to carefully study this carefully annotated execution trace instead of continuing to totally
ignore it.
On 9/5/2025 10:29 AM, olcott wrote:
SUBJECT: [Explicitly showing the divergence of
behavior between HHH(DDD) and HHH1(DDD)]
On 9/12/2025 10:24 PM, wij wrote:
On Sat, 2025-09-13 at 03:52 +0100, Mike Terry wrote:Counter-factual.
On 12/09/2025 19:58, Kaz Kylheku wrote:
On 2025-09-12, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 12/09/2025 17:50, olcott wrote:
<snip>
When HHH(DD) is supposed to ONLY report on the behavior that its
actual input actually specifies then HHH(DD)==0 is correct.
DD halts. If you stand by your claim that HHH(DD) == 0 is correct,
we are forced to conclude that HHH is not a decider for DD.
HHH is a decider for some half-baked conditions of seeing a CALL
instruction in the hitherto observed execution trace, while not
seeing conditional jump instructions.
Olcott's logic has zero logical basis for jumping to the conclusion
that if no conditional jump instructions occur in mere *prefix*
of the instruction stream of a recursively simulating loop, that they
never occur: i.e. shall not be found in the *suffix* of the execution
trace that will be produced when the simulation is taken to
completion.
Right. PO's abort test is unsound (it can match against halting
computations). He has a condition:
- there are no conditional branch instructions
*within the C scope of function DD* between the two call
instructions. [conditional branch instructions within HHH
(called from DD) are ignored!]
That is patent nonsense on multiple levels. E.g. how can PO possibly
be thinking that moving a conditional branch out of DD function scope
into a subroutine (HHH) affects the validity of his rule?
Others rightly point out that there are conditional branch
instructions in HHH which PO is ignoring, so PO is unjustified in his
conclusion. True enough, but there is an underlying suggestion here
that his rule would have been sound if only he hadn't restricted the
"no conditional branches" condition to DD scope . That's not the
case: even if the condition above read:
- there are no conditional branch instructions (anywhere) between the
two call instructions.
the test would still be unsound.
One of PO's basic problems is that he thinks his merged nested
simulation trace can be treated exactly like a single-processor
trace. That's one of the reasons he keeps posting about
Infinite_Recursion() being correctly decided by HHH.
void Infinite_Recursion()
{
Infinite_Recursion();
}
He doesn't see how the simulation aspect changes things.
Mike.
Firstly, HHH does not simulate anything. HHH simply traces execution
path and determine when to stop and what to return in olcott's point of
view.
HHH uses an embedded copy of a world class x86 emulator named libx86emu.
On 9/12/2025 10:24 PM, wij wrote:
On Sat, 2025-09-13 at 03:52 +0100, Mike Terry wrote:
On 12/09/2025 19:58, Kaz Kylheku wrote:
On 2025-09-12, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 12/09/2025 17:50, olcott wrote:
<snip>
When HHH(DD) is supposed to ONLY report on the behavior
that its actual input actually specifies then HHH(DD)==0
is correct.
DD halts. If you stand by your claim that HHH(DD) == 0 is
correct, we are forced to conclude that HHH is not a decider for DD.
HHH is a decider for some half-baked conditions of seeing a CALL instruction in the hitherto observed execution trace, while not seeing conditional jump instructions.
Olcott's logic has zero logical basis for jumping to the conclusion that if no conditional jump instructions occur in mere *prefix*
of the instruction stream of a recursively simulating loop, that
they never occur: i.e. shall not be found in the *suffix* of the execution trace that will be produced when the simulation is taken
to completion.
Right. PO's abort test is unsound (it can match against halting computations). He has a
condition:
- there are no conditional branch instructions
*within the C scope of function DD* between the two call instructions.
[conditional branch instructions within HHH (called from DD) are ignored!]
That is patent nonsense on multiple levels. E.g. how can PO possibly be thinking that moving a
conditional branch out of DD function scope into a subroutine (HHH) affects the validity of his
rule?
Others rightly point out that there are conditional branch instructions in HHH which PO is
ignoring,
so PO is unjustified in his conclusion. True enough, but there is an underlying suggestion here
that his rule would have been sound if only he hadn't restricted the "no conditional branches"
condition to DD scope . That's not the case: even if the condition above read:
- there are no conditional branch instructions (anywhere) between the two call instructions.
the test would still be unsound.
One of PO's basic problems is that he thinks his merged nested simulation trace can be treated
exactly like a single-processor trace. That's one of the reasons he keeps posting about
Infinite_Recursion() being correctly decided by HHH.
void Infinite_Recursion()
{
Infinite_Recursion();
}
He doesn't see how the simulation aspect changes things.
Mike.
Firstly, HHH does not simulate anything. HHH simply traces execution path and
determine when to stop and what to return in olcott's point of view.
Counter-factual.The libx86emu that HHH uses is a CPU emulator of x86 instruction stream.
HHH uses an embedded copy of a world
class x86 emulator named libx86emu.
On Sat, 2025-09-13 at 03:33 +0100, Mike Terry wrote:
On 13/09/2025 01:29, Kaz Kylheku wrote:
On 2025-09-12, olcott <polcott333@gmail.com> wrote:I found a previous post with the comparison:
On 9/12/2025 3:01 PM, Kaz Kylheku wrote:
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
On 9/12/2025 2:01 PM, Kaz Kylheku wrote:^^^^^^^^^^^^^^^^^^^^^^
On 2025-09-12, olcott <polcott333@gmail.com> wrote:
(c) DD has no conditional branch instructions
between the invocation of DD and its call to HHH(DD).
But, idiot, this is true of the natively executed DD()
also:
int main(void) { DD(); OutputString("DD halts"); }
This DD also has no conditional branch instructions between
the start of DD and its call to HHH(DD)!
You know that this one halts and have admitted it and dismissed it as >>>>>>> irrelevant because "it's not the input to HHH".
But the conditions hold; if the X86 CPU recorded an execution trace, we >>>>>>> could apply the Decide_Halting_H conditions to that trace, and at the >>>>>>> point where it hits the CALL insttruction, we would wrongly conclude >>>>>>> that it needs to be aborted.
I conclusively proved that the
execution trace of DD correctly simulated by HHH
(before HHH has aborted its simulation)
is different than the^^^^^^^^^^^^^^^^^^^^^
execution trace of DD correctly simulated by HHH1
(after HHH has aborted its simulation).
Of course the execution traces are different before and
after the abort.
DD() has the same behavior as DD correctly simulated by HHH1.
HHH sees different behavior that it must abort.
<snip> *to keep focus of attention one key point*
You are inviting a laser focus on your blatantly inconsistency.
Nothing whatsoever that is loking at DD can see different behavior
from anything else that is looking at DD.
DD is one thing, defined one way, and set in stone in any given scenario. >>
HHH1 Simulation of DD (HHH1 never aborts) HHH Simulation of DD
========================================== ==========================================
S machine machine assembly S machine machine assembly
D address code language D address code language
= ======== ============== ============= = ======== ============== =============
[1][0000213e] 55 push ebp [1][0000213e] 55 push ebp
[1][0000213f] 8bec mov ebp,esp [1][0000213f] 8bec mov ebp,esp
[1][00002141] 51 push ecx [1][00002141] 51 push ecx
[1][00002142] 683e210000 push 0000213e [1][00002142] 683e210000 push 0000213e
[1][00002147] e8a2f4ffff call 000015ee [1][00002147] e8a2f4ffff call 000015ee
[1]New slave_stack at:14e33e [1]New slave_stack at:14e33e
[1]Begin Local Halt Decider Simulation
[2][0000213e] 55 push ebp [2][0000213e] 55 push ebp
[2][0000213f] 8bec mov ebp,esp [2][0000213f] 8bec mov ebp,esp
[2][00002141] 51 push ecx [2][00002141] 51 push ecx
[2][00002142] 683e210000 push 0000213e [2][00002142] 683e210000 push 0000213e
[2][00002147] e8a2f4ffff call 000015ee [2][00002147] e8a2f4ffff call 000015ee
[3]New slave_stack at:198d66 ### THIS IS WHERE HHH stops simulating DD
[3][0000213e] 55 push ebp ### Right up to this point
[3][0000213f] 8bec mov ebp,esp ### HHH's and HHH1's traces match as claimed
[3][00002141] 51 push ecx
[3][00002142] 683e210000 push 0000213e
[3][00002147] e8a2f4ffff call 000015ee
[1]Infinite Recursion Detected Simulation Stopped
[1][0000214c] 83c404 add esp,+04
[1][0000214f] 8945fc mov [ebp-04],eax
[1][00002152] 837dfc00 cmp dword [ebp-04],+00
[1][00002156] 7402 jz 0000215a
[1][0000215a] 8b45fc mov eax,[ebp-04]
[1][0000215d] 8be5 mov esp,ebp
[1][0000215f] 5d pop ebp
[1][00002160] c3 ret
(SD column is simulation depth)
Mike.
At the beginning of newly invented 'x86utm operating system', before olcott quickly understood HHH has to return to be a halt decider, his 'abort'
should mean 'menual abort'). Latter, he added code to detect address to identify
which copy of the test case that H should 'abort'....
What does the listing above suggest? (I lost the context)
On 9/12/2025 9:33 PM, Mike Terry wrote:
*This is the execution trace to use*
It is very carefully annotated
On 9/5/2025 10:29 AM, olcott wrote:
SUBJECT:
[Explicitly showing the divergence of behavior
between HHH(DDD) and HHH1(DDD)]
I don't want to clutter things up by posting all of
this detail over and over. If I always refer to the
exact same post this will minimize confusion.
On 9/12/2025 9:33 PM, Mike Terry wrote:
*This is the execution trace to use*
It is very carefully annotated
On 9/5/2025 10:29 AM, olcott wrote:
SUBJECT:
[Explicitly showing the divergence of behavior
between HHH(DDD) and HHH1(DDD)]
I don't want to clutter things up by posting all of
this detail over and over. If I always refer to the
exact same post this will minimize confusion.
On 9/10/2025 2:57 AM, Mikko wrote:
On 2025-09-10 03:41:32 +0000, olcott said:
Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.
That does not define halting as the term "final halt state" is undefined.
When we are in a comp.theory forum we expect people
to know the terms of the art.
Eventually, the whole process may terminate,
which we achieve in a Turing machine by putting
it into a halt state. A Turing machine is said
to halt whenever it reaches a configuration for
which δ is not defined; this is possible because
δ is a partial function. In fact, we will assume
that no transitions are defined for any final
state, so the Turing machine will halt whenever
it enters a final state. page 1990:234 Linz
Besides, many authors define halting as reacheng any configuration
where the execution cannot be continued.
On 8/2/2024 11:32 PM, Jeff Barnett wrote:
On 8/2/2024 7:19 PM, Mike Terry wrote:
Definition: A TM P given input I is said to "halt" iff ?????
or whatever...
I think this is a rather hopeless venture without
formally defining the representation of a TM. For
example: In some formulations, there are specific
states defined as "halting states" and the machine
only halts if either the start state is a halt state or
there is a transition to a halt state within the execution
trace; In another formulation, machines halt if there
is a transition to an undefined state. Note a few things:
1) the if's above are really iff's, 2) these and many
other definitions all have equivalent computing prowess,
3) Some formulations define results by what is left on
the tape (or other storage device) while others add the
actual halting state to determine the results.
In a conversation about such topics, gentlemen of good
faith and reasonable knowledge can simple ignore these
differences and not go off the rails.
When simulating termination analyzer H correctly
determines D simulated by any H cannot possibly reach
its own simulated final halt state this means that
the input to H(D) specifies a non-halting sequence
of moves.
It is bad style and often considered wrong to use the same symbol
for two meanings like H is used above.
On 9/4/2025 4:16 PM, Kaz Kylheku wrote:
If we somehow correctly detect that successive
nested simulations are identical, we can conclude
by induction that we have a repeating pattern:
all subsequent levels are the same.
It takes two recursive simulations to establish
that additional recursive simulations will never halt.
On 2025-09-10 15:51:21 +0000, olcott said:
On 9/10/2025 2:57 AM, Mikko wrote:
On 2025-09-10 03:41:32 +0000, olcott said:
Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.
That does not define halting as the term "final halt state" is
undefined.
When we are in a comp.theory forum we expect people
to know the terms of the art.
Most of them also know that you often use the terms or the art for
meanings that they don't have as terms of the art.
Eventually, the whole process may terminate,
which we achieve in a Turing machine by putting
it into a halt state. A Turing machine is said
to halt whenever it reaches a configuration for
which δ is not defined; this is possible because
δ is a partial function. In fact, we will assume
that no transitions are defined for any final
state, so the Turing machine will halt whenever
it enters a final state. page 1990:234 Linz
Besides, many authors define halting as reacheng any configuration
where the execution cannot be continued.
As seen in the quoted text, Linz of one of those many.
On 8/2/2024 11:32 PM, Jeff Barnett wrote:
On 8/2/2024 7:19 PM, Mike Terry wrote:
;;
Definition: A TM P given input I is said to "halt" iff ?????
or whatever...
I think this is a rather hopeless venture without
formally defining the representation of a TM. For
example: In some formulations, there are specific
states defined as "halting states" and the machine
only halts if either the start state is a halt state or
there is a transition to a halt state within the execution
trace; In another formulation, machines halt if there
is a transition to an undefined state. Note a few things:
1) the if's above are really iff's, 2) these and many
other definitions all have equivalent computing prowess,
3) Some formulations define results by what is left on
the tape (or other storage device) while others add the
actual halting state to determine the results.
Nice to see that Mike agrees.
In a conversation about such topics, gentlemen of good
faith and reasonable knowledge can simple ignore these
differences and not go off the rails.
Unfortunately all participants are not gentlemen of good faith and
reasonable knowledge.
When simulating termination analyzer H correctly
determines D simulated by any H cannot possibly reach
its own simulated final halt state this means that
the input to H(D) specifies a non-halting sequence
of moves.
It is bad style and often considered wrong to use the same symbol
for two meanings like H is used above.
Nice to see that you don't disagree. Remainst to be seen whether you
can do better next time.
On 9/4/2025 4:16 PM, Kaz Kylheku wrote:
;
If we somehow correctly detect that successive
nested simulations are identical, we can conclude
by induction that we have a repeating pattern:
all subsequent levels are the same.
It takes two recursive simulations to establish
that additional recursive simulations will never halt.
Only if enough is determined about the simulations. If the simulator
never simulates more than two levels the process does halt.
On 9/14/2025 3:46 AM, Mikko wrote:
On 2025-09-10 15:51:21 +0000, olcott said:
On 9/10/2025 2:57 AM, Mikko wrote:
On 2025-09-10 03:41:32 +0000, olcott said:When we are in a comp.theory forum we expect people
Halting is defined as reaching a final halt state
stopping running for any other reason is not
construed as halting.
That does not define halting as the term "final halt state" is undefined. >>>
to know the terms of the art.
Most of them also know that you often use the terms or the art for
meanings that they don't have as terms of the art.
Eventually, the whole process may terminate,
which we achieve in a Turing machine by putting
it into a halt state. A Turing machine is said
to halt whenever it reaches a configuration for
which δ is not defined; this is possible because
δ is a partial function. In fact, we will assume
that no transitions are defined for any final
state, so the Turing machine will halt whenever
it enters a final state. page 1990:234 Linz
Besides, many authors define halting as reacheng any configuration
where the execution cannot be continued.
As seen in the quoted text, Linz of one of those many.
On 8/2/2024 11:32 PM, Jeff Barnett wrote:
On 8/2/2024 7:19 PM, Mike Terry wrote:
;;
Definition: A TM P given input I is said to "halt" iff ?????
or whatever...
I think this is a rather hopeless venture without
formally defining the representation of a TM. For
example: In some formulations, there are specific
states defined as "halting states" and the machine
only halts if either the start state is a halt state or
there is a transition to a halt state within the execution
trace; In another formulation, machines halt if there
is a transition to an undefined state. Note a few things:
1) the if's above are really iff's, 2) these and many
other definitions all have equivalent computing prowess,
3) Some formulations define results by what is left on
the tape (or other storage device) while others add the
actual halting state to determine the results.
Nice to see that Mike agrees.
In a conversation about such topics, gentlemen of good
faith and reasonable knowledge can simple ignore these
differences and not go off the rails.
Unfortunately all participants are not gentlemen of good faith and
reasonable knowledge.
When simulating termination analyzer H correctly
determines D simulated by any H cannot possibly reach
its own simulated final halt state this means that
the input to H(D) specifies a non-halting sequence
of moves.
It is bad style and often considered wrong to use the same symbol
for two meanings like H is used above.
Nice to see that you don't disagree. Remainst to be seen whether you
can do better next time.
On 9/4/2025 4:16 PM, Kaz Kylheku wrote:
;
If we somehow correctly detect that successive
nested simulations are identical, we can conclude
by induction that we have a repeating pattern:
all subsequent levels are the same.
It takes two recursive simulations to establish
that additional recursive simulations will never halt.
Only if enough is determined about the simulations. If the simulator
never simulates more than two levels the process does halt.
void Infinite_Recursion()
{
Infinite_Recursion();
return;
}
Then is it likewise for Infinite_Recursion().
The above shows the traces of HHH and HHH1 simulating DD.
*This is the beginning of the divergence of the behavior*
*of DDD emulated by HHH versus DDD emulated by HHH1*
On 13/09/2025 04:26, olcott wrote:
<snip>
That is why I said it is so important for you to
carefully study this carefully annotated execution
trace instead of continuing to totally ignore it.
You keep coming back to this.
On 9/13/2025 12:46 AM, Richard Heathfield wrote:
On 13/09/2025 04:26, olcott wrote:The execution trace conclusively proves two of the most important
<snip>
That is why I said it is so important for you to carefully study this
carefully annotated execution trace instead of continuing to totally
ignore it.
You keep coming back to this.
points:
(1) DDD correctly simulated by HHH has different behavior than DDD
correctly simulated by HHH1.
(2) DDD correctly simulated by HHH cannot possibly reach its own final
halt state.
So I am going to keep coming back to this again and again however many
times needed until this is understood. I have already stopped talking to
some people that have proved that they are not interested in any honest dialogue.
On Mon, 15 Sep 2025 12:46:48 -0500, olcott wrote:
On 9/13/2025 12:46 AM, Richard Heathfield wrote:
On 13/09/2025 04:26, olcott wrote:The execution trace conclusively proves two of the most important
<snip>
That is why I said it is so important for you to carefully study this
carefully annotated execution trace instead of continuing to totally
ignore it.
You keep coming back to this.
points:
(1) DDD correctly simulated by HHH has different behavior than DDD
correctly simulated by HHH1.
(2) DDD correctly simulated by HHH cannot possibly reach its own final
halt state.
So I am going to keep coming back to this again and again however many
times needed until this is understood. I have already stopped talking to
some people that have proved that they are not interested in any honest
dialogue.
DDD halts.
/Flibble
So I am going to keep coming back to this again
and again however many times needed until this
is understood.
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
*This is the beginning of the divergence of the behavior*
*of DDD emulated by HHH versus DDD emulated by HHH1*
No that is the beginning of the divergence of the behavior of HHH1
and HHH, not of DDD. DDD is not built on HHH1, so its behavior does not diverge in any way. DDD is tied to the behavior of HHH.
There is only one DDD behavior.
HHH1 seems to completely trace the behavior and is returning 1
(conveniently not shown in your trace)
HHH abandons tracing DDD.
The fact that HHH abandons DDD wherease HHH1 doesn't does not give
rise to two different DDD's. The treatment of the simulation of DDD
has no bearing on whether that simulation is a halting computation.
On 9/15/2025 12:39 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:HHH1 simulated DDD exactly once. The above referenced execution trace
*This is the beginning of the divergence of the behavior*
*of DDD emulated by HHH versus DDD emulated by HHH1*
No that is the beginning of the divergence of the behavior of HHH1 and
HHH, not of DDD. DDD is not built on HHH1, so its behavior does not
diverge in any way. DDD is tied to the behavior of HHH.
point is where HHH begins to simulate DDD again.
There is only one DDD behavior.
HHH1 seems to completely trace the behavior and is returning 1
(conveniently not shown in your trace)
HHH abandons tracing DDD.
The fact that HHH abandons DDD wherease HHH1 doesn't does not give rise
to two different DDD's. The treatment of the simulation of DDD has no
bearing on whether that simulation is a halting computation.
On 9/15/2025 12:55 PM, Mr Flibble wrote:
On Mon, 15 Sep 2025 12:46:48 -0500, olcott wrote:THE ACTUAL BEHAVIOR THAT THE ACTUAL INPUT ACTUALLY SPECIFIES THE ACTUAL BEHAVIOR THAT THE ACTUAL INPUT ACTUALLY SPECIFIES THE ACTUAL BEHAVIOR
On 9/13/2025 12:46 AM, Richard Heathfield wrote:
On 13/09/2025 04:26, olcott wrote:The execution trace conclusively proves two of the most important
<snip>
That is why I said it is so important for you to carefully study
this carefully annotated execution trace instead of continuing to
totally ignore it.
You keep coming back to this.
points:
(1) DDD correctly simulated by HHH has different behavior than DDD
correctly simulated by HHH1.
(2) DDD correctly simulated by HHH cannot possibly reach its own final
halt state.
So I am going to keep coming back to this again and again however many
times needed until this is understood. I have already stopped talking
to some people that have proved that they are not interested in any
honest dialogue.
DDD halts.
/Flibble
THAT THE ACTUAL INPUT ACTUALLY SPECIFIES THE ACTUAL BEHAVIOR THAT THE
ACTUAL INPUT ACTUALLY SPECIFIES THE ACTUAL BEHAVIOR THAT THE ACTUAL
INPUT ACTUALLY SPECIFIES THE ACTUAL BEHAVIOR THAT THE ACTUAL INPUT
ACTUALLY SPECIFIES THE ACTUAL BEHAVIOR THAT THE ACTUAL INPUT ACTUALLY SPECIFIES THE ACTUAL BEHAVIOR THAT THE ACTUAL INPUT ACTUALLY SPECIFIES
On 9/13/2025 12:46 AM, Richard Heathfield wrote:
On 13/09/2025 04:26, olcott wrote:
<snip>
That is why I said it is so important for you to
carefully study this carefully annotated execution
trace instead of continuing to totally ignore it.
You keep coming back to this.
The execution trace conclusively proves two of
the most important points:
(1) DDD correctly simulated by HHH has different behavior
than DDD correctly simulated by HHH1.
(2) DDD correctly simulated by HHH cannot possibly
reach its own final halt state.
So I am going to keep coming back to this again
and again however many times needed until this
On 15/09/2025 18:46, olcott wrote:
<nonsense snipped>
So I am going to keep coming back to this again
and again however many times needed until this
is understood.
You keep coming back to this, but it will never be understood, because
it makes no sense to anyone but you.
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/13/2025 12:46 AM, Richard Heathfield wrote:
On 13/09/2025 04:26, olcott wrote:
<snip>
That is why I said it is so important for you to
carefully study this carefully annotated execution
trace instead of continuing to totally ignore it.
You keep coming back to this.
The execution trace conclusively proves two of
the most important points:
(1) DDD correctly simulated by HHH has different behavior
than DDD correctly simulated by HHH1.
1. DDD() simply must not have multiple different behaviors; it is
Might I suggest that in this case the maieutic approach is not
working?
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/13/2025 12:46 AM, Richard Heathfield wrote:
On 13/09/2025 04:26, olcott wrote:
<snip>
That is why I said it is so important for you to
carefully study this carefully annotated execution
trace instead of continuing to totally ignore it.
You keep coming back to this.
The execution trace conclusively proves two of
the most important points:
(1) DDD correctly simulated by HHH has different behavior
than DDD correctly simulated by HHH1.
1. DDD() simply must not have multiple different behaviors; it is
On 9/15/2025 12:39 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
*This is the beginning of the divergence of the behavior*
*of DDD emulated by HHH versus DDD emulated by HHH1*
No that is the beginning of the divergence of the behavior of HHH1
and HHH, not of DDD. DDD is not built on HHH1, so its behavior does not
diverge in any way. DDD is tied to the behavior of HHH.
HHH1 simulated DDD exactly once. The above referenced
execution trace point is where HHH begins to simulate
DDD again.
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 12:39 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
*This is the beginning of the divergence of the behavior*
*of DDD emulated by HHH versus DDD emulated by HHH1*
No that is the beginning of the divergence of the behavior of HHH1
and HHH, not of DDD. DDD is not built on HHH1, so its behavior does not >>> diverge in any way. DDD is tied to the behavior of HHH.
HHH1 simulated DDD exactly once. The above referenced
execution trace point is where HHH begins to simulate
DDD again.
Yes; since DDD calls HHH(DDD), then simulating DDD implies
simulating HHH. So what?
On 9/15/2025 1:27 PM, Richard Heathfield wrote:
On 15/09/2025 18:46, olcott wrote:
<nonsense snipped>
So I am going to keep coming back to this again
and again however many times needed until this
is understood.
You keep coming back to this, but it will never be understood, because
it makes no sense to anyone but you.
Only because they are so damned sure that I must
be wrong that they perpetually refuse to pay any
attention at all.
On 9/15/2025 1:55 PM, Kaz Kylheku wrote:
1. DDD() simply must not have multiple different behaviors; it is
No sense proceeding with this until you study the
actual trace well enough that you can see that HHH1
simulates DDD once and HHH simulates DDD twice.
On 9/15/2025 1:27 PM, Richard Heathfield wrote:
On 15/09/2025 18:46, olcott wrote:
<nonsense snipped>
So I am going to keep coming back to this again
and again however many times needed until this
is understood.
You keep coming back to this, but it will never be understood,
because it makes no sense to anyone but you.
Only because they are so damned sure that I must
be wrong that they perpetually refuse to pay any
attention at all.
Anyone that knows much about Rice's theorem has
heard about semantic properties of programs yet
think its total nonsense what I bring this up.
On 9/15/2025 1:55 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/13/2025 12:46 AM, Richard Heathfield wrote:
On 13/09/2025 04:26, olcott wrote:
<snip>
That is why I said it is so important for you to
carefully study this carefully annotated execution
trace instead of continuing to totally ignore it.
You keep coming back to this.
The execution trace conclusively proves two of
the most important points:
(1) DDD correctly simulated by HHH has different behavior
than DDD correctly simulated by HHH1.
1. DDD() simply must not have multiple different behaviors; it is
If it does not halt then it is not a pure function.
It is allowed to not halt, that is the whole point.
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 1:27 PM, Richard Heathfield wrote:
On 15/09/2025 18:46, olcott wrote:
<nonsense snipped>
So I am going to keep coming back to this again
and again however many times needed until this
is understood.
You keep coming back to this, but it will never be understood, because
it makes no sense to anyone but you.
Only because they are so damned sure that I must
be wrong that they perpetually refuse to pay any
attention at all.
It is in fact YOUR OWN JOB to look for anything that may be wrong in
your own work, such that the work's hypothesis is not justified.
On 2025-09-15, Richard Heathfield <rjh@cpax.org.uk> wrote:
Might I suggest that in this case the maieutic approach is not
working?
I like that word; we could coin that as a brand new Japanese word with a different meaning; how about:
舞絵迂的 (MAI-E-U-TEKI)
舞(MAI) -> dancing (esp. twirling type rather than leaping);
絵(E) -> picture, drawing;
迂(U) -> detour, roundabout way;
的(-TEKI) -> -ic; -istic; having to do with
"Having to do with some roundabout twirly dancing around
some pictures; i.e. interpretive dance."
Example usage:
この筋のない舞絵迂的なお話しは、もうそろそrいい加減にしましょうか。
Kono suji-no-nai maieuteki-na o-hanashi wa, mou soro-soro
iikagen-ni shimashouka?
"Regarding this illogical, interpretative twirly dance talk, might it
not be high timet we let ourselves put an end to it?"
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 1:55 PM, Kaz Kylheku wrote:
1. DDD() simply must not have multiple different behaviors; it is
No sense proceeding with this until you study the
actual trace well enough that you can see that HHH1
simulates DDD once and HHH simulates DDD twice.
No sense proceeding with your traces until they capture every single instruction, including those inside the simulator, and dump the values
of all the registers at every step.
I do see that HHH simulates DDD twice; it needs two times in order for
the new abort logic to see two CALL instructions to the same address.
That sameness is how you avoid encoding the name of HHH into the
simulation.
It looks as if under this new way of doing things, DDD is always the
same, as required. That should be the case if every HHH simulation
level has its own private execution trace; if there is no communication
among different instances of HHH through a shared execution trace.
Unfortunately, HHH decides that DDD is non-halting, when it's halting.
On 15/09/2025 19:56, olcott wrote:
Anyone that knows much about Rice's theorem has
heard about semantic properties of programs yet
think its total nonsense what I bring this up.
Rice's Theorem don't enter into it. The fact remains that you
have a halting program that you claim doesn't halt.
Until you fix that, nobody is going to take seriously anything
you claim.
On 15/09/2025 19:56, olcott wrote:Yet cannot show any details of any mistake
On 9/15/2025 1:27 PM, Richard Heathfield wrote:
On 15/09/2025 18:46, olcott wrote:
<nonsense snipped>
So I am going to keep coming back to this again
and again however many times needed until this
is understood.
You keep coming back to this, but it will never be understood,
because it makes no sense to anyone but you.
Only because they are so damned sure that I must
be wrong that they perpetually refuse to pay any
attention at all.
Yep. Everybody (except you) knows you're wrong.
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 1:55 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/13/2025 12:46 AM, Richard Heathfield wrote:
On 13/09/2025 04:26, olcott wrote:
<snip>
That is why I said it is so important for you to
carefully study this carefully annotated execution
trace instead of continuing to totally ignore it.
You keep coming back to this.
The execution trace conclusively proves two of
the most important points:
(1) DDD correctly simulated by HHH has different behavior
than DDD correctly simulated by HHH1.
1. DDD() simply must not have multiple different behaviors; it is
If it does not halt then it is not a pure function.
If it doesn't halt, it is not a pure function, since it isn't a
function. In that case, it must still be a Turing Machine.
All instances of the DDD() expression anywhere must denote
the same non-halting computation, which depends on nothing other
than its empty argument list.
On 15/09/2025 19:56, olcott wrote:
On 9/15/2025 1:27 PM, Richard Heathfield wrote:
On 15/09/2025 18:46, olcott wrote:
<nonsense snipped>
So I am going to keep coming back to this again
and again however many times needed until this
is understood.
You keep coming back to this, but it will never be understood,
because it makes no sense to anyone but you.
Only because they are so damned sure that I must
be wrong that they perpetually refuse to pay any
attention at all.
Yep. Everybody (except you) knows you're wrong. You have given them no reason to take you seriously.
Anyone that knows much about Rice's theorem has
heard about semantic properties of programs yet
think its total nonsense what I bring this up.
Rice's Theorem don't enter into it.
On 9/15/2025 2:47 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 1:55 PM, Kaz Kylheku wrote:
1. DDD() simply must not have multiple different behaviors; it is
No sense proceeding with this until you study the
actual trace well enough that you can see that HHH1
simulates DDD once and HHH simulates DDD twice.
No sense proceeding with your traces until they capture every single
instruction, including those inside the simulator, and dump the values
of all the registers at every step.
I do see that HHH simulates DDD twice; it needs two times in order for
the new abort logic to see two CALL instructions to the same address.
That sameness is how you avoid encoding the name of HHH into the
simulation.
It looks as if under this new way of doing things, DDD is always the
same, as required. That should be the case if every HHH simulation
level has its own private execution trace; if there is no communication
among different instances of HHH through a shared execution trace.
Unfortunately, HHH decides that DDD is non-halting, when it's halting.
That DDD.HHH1 is halting does not say a damn thing about DDD.HHH.
On 2025-09-15, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 15/09/2025 19:56, olcott wrote:
Anyone that knows much about Rice's theorem has
heard about semantic properties of programs yet
think its total nonsense what I bring this up.
Rice's Theorem don't enter into it. The fact remains that you
have a halting program that you claim doesn't halt.
Until you fix that, nobody is going to take seriously anything
you claim.
It's exactly as if Olott tried to claim that a brick and a feather have different acceleration due to gravity.
Everyone is pointing out that his experiment is not conducted in
a vacuum, and therefore its conclusion is invalid.
But, nope, they are just so convinced Olcott is wrong they are not
paying attention to his actual experiment and its captures showing that
the brick hits the ground before the feather. Here is the slow-motion
video again, for the ten-thousandth time ...
On 2025-09-15, olcott <NoOne@NoWhere.com> wrote:*It looks like you are becoming dishonest*
On 9/15/2025 2:47 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 1:55 PM, Kaz Kylheku wrote:
1. DDD() simply must not have multiple different behaviors; it is
No sense proceeding with this until you study the
actual trace well enough that you can see that HHH1
simulates DDD once and HHH simulates DDD twice.
No sense proceeding with your traces until they capture every single
instruction, including those inside the simulator, and dump the values
of all the registers at every step.
I do see that HHH simulates DDD twice; it needs two times in order for
the new abort logic to see two CALL instructions to the same address.
That sameness is how you avoid encoding the name of HHH into the
simulation.
It looks as if under this new way of doing things, DDD is always the
same, as required. That should be the case if every HHH simulation
level has its own private execution trace; if there is no communication
among different instances of HHH through a shared execution trace.
Unfortunately, HHH decides that DDD is non-halting, when it's halting.
That DDD.HHH1 is halting does not say a damn thing about DDD.HHH.
1. But, if that were to be true, it means that DDD isn't a pure
function.
Yep. Everybody (except you) knows you're wrong.Yet cannot show any details of any mistake
because there is no mistake.
On 9/15/2025 3:01 PM, Kaz Kylheku wrote:Lol, you still have no idea about purity. The halting status of impure functions depends on side effects. Do you mean partial functions?
On 2025-09-15, olcott <NoOne@NoWhere.com> wrote:
On 9/15/2025 2:47 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 1:55 PM, Kaz Kylheku wrote:
*It looks like you are becoming dishonest* You know that DDD need not beThat DDD.HHH1 is halting does not say a damn thing about DDD.HHH.1. DDD() simply must not have multiple different behaviors; it is
No sense proceeding with this until you study the actual trace well
enough that you can see that HHH1 simulates DDD once and HHH
simulates DDD twice.
No sense proceeding with your traces until they capture every single
instruction, including those inside the simulator, and dump the
values of all the registers at every step.
I do see that HHH simulates DDD twice; it needs two times in order
for the new abort logic to see two CALL instructions to the same
address. That sameness is how you avoid encoding the name of HHH into
the simulation.
It looks as if under this new way of doing things, DDD is always the
same, as required. That should be the case if every HHH simulation
level has its own private execution trace; if there is no
communication among different instances of HHH through a shared
execution trace.
Unfortunately, HHH decides that DDD is non-halting, when it's
halting.
1. But, if that were to be true, it means that DDD isn't a pure
function.
a pure function otherwise there would be no point in testing its halt
status.
Find a damn error otherwise
you implicitly admit there is none.
On 9/15/2025 2:51 PM, Kaz Kylheku wrote:Wrong. It is not total.
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 1:55 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/13/2025 12:46 AM, Richard Heathfield wrote:
On 13/09/2025 04:26, olcott wrote:
The execution trace conclusively proves two of the most important
points:
(1) DDD correctly simulated by HHH has different behavior than DDD
correctly simulated by HHH1.
1. DDD() simply must not have multiple different behaviors; it is
If it does not halt then it is not a pure function.
*You* are trying to get away with saying HHH=HHH1.All instances of the DDD() expression anywhere must denote the sameThat is a false assumption as I proved by HHH simulating DDD twice and
non-halting computation, which depends on nothing other than its empty
argument list.
HHH1 simulating DDD once.
Are you trying to get away with saying 1==2 ???
On 2025-09-15, olcott <NoOne@NoWhere.com> wrote:
On 9/15/2025 2:47 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 1:55 PM, Kaz Kylheku wrote:
1. DDD() simply must not have multiple different behaviors; it is
No sense proceeding with this until you study the
actual trace well enough that you can see that HHH1
simulates DDD once and HHH simulates DDD twice.
No sense proceeding with your traces until they capture every single
instruction, including those inside the simulator, and dump the values
of all the registers at every step.
I do see that HHH simulates DDD twice; it needs two times in order for
the new abort logic to see two CALL instructions to the same address.
That sameness is how you avoid encoding the name of HHH into the
simulation.
It looks as if under this new way of doing things, DDD is always the
same, as required. That should be the case if every HHH simulation
level has its own private execution trace; if there is no communication
among different instances of HHH through a shared execution trace.
Unfortunately, HHH decides that DDD is non-halting, when it's halting.
That DDD.HHH1 is halting does not say a damn thing about DDD.HHH.
1. But, if that were to be true, it means that DDD isn't a pure
function. It is (at least) two different computations that
somehow differentiate based on something in their environment.
That completely damns your entire apparatus as being
inapplicable to the Halting Theorem.
2. Fortunately, it looks like in your present apparatus, it is not
actually true. If every simulation conducted by your HHH is
completely isolated from other simulations (has its own private
execution trace not mixed up with anything), that should be true.
This is a good thing; but unfortunately it stil leaves your HHH(DDD)
-> 0 result in a lurch. (We have an air-tight theorem which tells us
that this result will happen no matter what, even if your apparatus
100% follows all the conditions of purity.)
On 9/15/2025 2:55 PM, Kaz Kylheku wrote:
On 2025-09-15, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 15/09/2025 19:56, olcott wrote:
Anyone that knows much about Rice's theorem has
heard about semantic properties of programs yet
think its total nonsense what I bring this up.
Rice's Theorem don't enter into it. The fact remains that you
have a halting program that you claim doesn't halt.
Until you fix that, nobody is going to take seriously anything
you claim.
It's exactly as if Olott tried to claim that a brick and a feather have
different acceleration due to gravity.
If you don't ignore terminal velocity.
Everyone is pointing out that his experiment is not conducted in
a vacuum, and therefore its conclusion is invalid.
That is pure bullshit. Find a damn error otherwise
you implicitly admit there is none.
DDD.HHH does not halt.
Changing the subject to DDD.HHH1 as the basis of
rebuttal is the dishonest tactic known as strawman.
But, nope, they are just so convinced Olcott is wrong they are not
paying attention to his actual experiment and its captures showing that
the brick hits the ground before the feather. Here is the slow-motion
video again, for the ten-thousandth time ...
On 9/15/2025 3:01 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <NoOne@NoWhere.com> wrote:
On 9/15/2025 2:47 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 1:55 PM, Kaz Kylheku wrote:
1. DDD() simply must not have multiple different behaviors;
it is
No sense proceeding with this until you study the
actual trace well enough that you can see that HHH1
simulates DDD once and HHH simulates DDD twice.
No sense proceeding with your traces until they capture every
single
instruction, including those inside the simulator, and dump
the values
of all the registers at every step.
I do see that HHH simulates DDD twice; it needs two times in
order for
the new abort logic to see two CALL instructions to the same
address.
That sameness is how you avoid encoding the name of HHH into the
simulation.
It looks as if under this new way of doing things, DDD is
always the
same, as required. That should be the case if every HHH
simulation
level has its own private execution trace; if there is no
communication
among different instances of HHH through a shared execution
trace.
Unfortunately, HHH decides that DDD is non-halting, when it's
halting.
That DDD.HHH1 is halting does not say a damn thing about DDD.HHH.
1. But, if that were to be true, it means that DDD isn't a pure
function. It is (at least) two different computations that
somehow differentiate based on something in their environment.
That completely damns your entire apparatus as being
inapplicable to the Halting Theorem.
2. Fortunately, it looks like in your present apparatus, it
is not actually true. If every simulation conducted by
your HHH is completely isolated from other simulations (has
its own private execution trace not mixed up with
anything), that should be true. This is a good thing; but
unfortunately it stil leaves your HHH(DDD) -> 0 result in a
lurch. (We have an air-tight theorem which tells us that
this result will happen no matter what, even if your
apparatus 100% follows all the conditions of purity.)
That air-tight theorem crucially depends on requiring a
decider to report on something other than the actual
behavior actually specified by its actual input.
On 9/15/2025 3:01 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <NoOne@NoWhere.com> wrote:*It looks like you are becoming dishonest*
On 9/15/2025 2:47 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 1:55 PM, Kaz Kylheku wrote:
1. DDD() simply must not have multiple different behaviors; it is
No sense proceeding with this until you study the
actual trace well enough that you can see that HHH1
simulates DDD once and HHH simulates DDD twice.
No sense proceeding with your traces until they capture every single
instruction, including those inside the simulator, and dump the values >>>> of all the registers at every step.
I do see that HHH simulates DDD twice; it needs two times in order for >>>> the new abort logic to see two CALL instructions to the same address.
That sameness is how you avoid encoding the name of HHH into the
simulation.
It looks as if under this new way of doing things, DDD is always the
same, as required. That should be the case if every HHH simulation
level has its own private execution trace; if there is no communication >>>> among different instances of HHH through a shared execution trace.
Unfortunately, HHH decides that DDD is non-halting, when it's halting. >>>>
That DDD.HHH1 is halting does not say a damn thing about DDD.HHH.
1. But, if that were to be true, it means that DDD isn't a pure
function.
You know that DDD need not be a pure function
otherwise there would be no point in testing
its halt status.
On 15/09/2025 21:58, olcott wrote:
On 9/15/2025 3:01 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <NoOne@NoWhere.com> wrote:
On 9/15/2025 2:47 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 1:55 PM, Kaz Kylheku wrote:
1. DDD() simply must not have multiple different behaviors; it is >>>>>>No sense proceeding with this until you study the
actual trace well enough that you can see that HHH1
simulates DDD once and HHH simulates DDD twice.
No sense proceeding with your traces until they capture every single >>>>> instruction, including those inside the simulator, and dump the values >>>>> of all the registers at every step.
I do see that HHH simulates DDD twice; it needs two times in order for >>>>> the new abort logic to see two CALL instructions to the same address. >>>>> That sameness is how you avoid encoding the name of HHH into the
simulation.
It looks as if under this new way of doing things, DDD is always the >>>>> same, as required. That should be the case if every HHH simulation
level has its own private execution trace; if there is no
communication
among different instances of HHH through a shared execution trace.
Unfortunately, HHH decides that DDD is non-halting, when it's halting. >>>>>
That DDD.HHH1 is halting does not say a damn thing about DDD.HHH.
1. But, if that were to be true, it means that DDD isn't a pure
function. It is (at least) two different computations that
somehow differentiate based on something in their environment.
That completely damns your entire apparatus as being
inapplicable to the Halting Theorem.
2. Fortunately, it looks like in your present apparatus, it
is not actually true. If every simulation conducted by
your HHH is completely isolated from other simulations (has
its own private execution trace not mixed up with
anything), that should be true. This is a good thing; but
unfortunately it stil leaves your HHH(DDD) -> 0 result in a
lurch. (We have an air-tight theorem which tells us that
this result will happen no matter what, even if your apparatus 100%
follows all the conditions of purity.)
That air-tight theorem crucially depends on requiring a
decider to report on something other than the actual
behavior actually specified by its actual input.
That's lucky for you, because that's precisely what you do.
The actual behaviour specified by DD is halting, and you instead report
on the subset of that behaviour that your flawed and semi-blind
simulator can see and misinterpret.
DD halts. Deal with it.
On 9/15/2025 4:55 PM, Richard Heathfield wrote:
On 15/09/2025 21:58, olcott wrote:
On 9/15/2025 3:01 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <NoOne@NoWhere.com> wrote:
On 9/15/2025 2:47 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 1:55 PM, Kaz Kylheku wrote:
1. DDD() simply must not have multiple different behaviors; it is >>>>>>>No sense proceeding with this until you study the
actual trace well enough that you can see that HHH1
simulates DDD once and HHH simulates DDD twice.
No sense proceeding with your traces until they capture every single >>>>>> instruction, including those inside the simulator, and dump the
values
of all the registers at every step.
I do see that HHH simulates DDD twice; it needs two times in order >>>>>> for
the new abort logic to see two CALL instructions to the same address. >>>>>> That sameness is how you avoid encoding the name of HHH into the
simulation.
It looks as if under this new way of doing things, DDD is always the >>>>>> same, as required. That should be the case if every HHH simulation >>>>>> level has its own private execution trace; if there is no
communication
among different instances of HHH through a shared execution trace. >>>>>>
Unfortunately, HHH decides that DDD is non-halting, when it's
halting.
That DDD.HHH1 is halting does not say a damn thing about DDD.HHH.
1. But, if that were to be true, it means that DDD isn't a pure
function. It is (at least) two different computations that
somehow differentiate based on something in their environment.
That completely damns your entire apparatus as being
inapplicable to the Halting Theorem.
2. Fortunately, it looks like in your present apparatus, it
is not actually true. If every simulation conducted by
your HHH is completely isolated from other simulations (has
its own private execution trace not mixed up with
anything), that should be true. This is a good thing; but
unfortunately it stil leaves your HHH(DDD) -> 0 result in a
lurch. (We have an air-tight theorem which tells us that
this result will happen no matter what, even if your apparatus 100%
follows all the conditions of purity.)
That air-tight theorem crucially depends on requiring a
decider to report on something other than the actual
behavior actually specified by its actual input.
That's lucky for you, because that's precisely what you do.
The actual behaviour specified by DD is halting, and you instead
report on the subset of that behaviour that your flawed and semi-blind
simulator can see and misinterpret.
DD halts. Deal with it.
The actual behavior of DD.exe is halting.
The actual behavior that DD.HHH specifies
is never reaching a final halt state.
actually seen code where an IOCP completion thread locks a global mutex. Something like this pseudo-code:--
_________________
for (;;)
{
iocp_overlapped& p = GQCS(INFINITE);
lock_mutex(global);
// process event...
unlock_mutex(global);
}
_________________
This is really BAD! It will create a rather massive bottleneck under
times of heavy load... Also, it creates a nasty condition where things
can become deadlocked if processing the overlapped completion calls into unknown user code to do some work. I have had to debug some others code
like this before. Not exactly fun...
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 3:01 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <NoOne@NoWhere.com> wrote:*It looks like you are becoming dishonest*
On 9/15/2025 2:47 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 1:55 PM, Kaz Kylheku wrote:
1. DDD() simply must not have multiple different behaviors; it is >>>>>>No sense proceeding with this until you study the
actual trace well enough that you can see that HHH1
simulates DDD once and HHH simulates DDD twice.
No sense proceeding with your traces until they capture every single >>>>> instruction, including those inside the simulator, and dump the values >>>>> of all the registers at every step.
I do see that HHH simulates DDD twice; it needs two times in order for >>>>> the new abort logic to see two CALL instructions to the same address. >>>>> That sameness is how you avoid encoding the name of HHH into the
simulation.
It looks as if under this new way of doing things, DDD is always the >>>>> same, as required. That should be the case if every HHH simulation
level has its own private execution trace; if there is no communication >>>>> among different instances of HHH through a shared execution trace.
Unfortunately, HHH decides that DDD is non-halting, when it's halting. >>>>>
That DDD.HHH1 is halting does not say a damn thing about DDD.HHH.
1. But, if that were to be true, it means that DDD isn't a pure
function.
You know that DDD need not be a pure function
otherwise there would be no point in testing
its halt status.
Since DD need not be terminating, it need not be a function. It does
need to be an "effect free" computation. If it does return a value, then
it is a pure function. This is just a minor matter of terminology.
Nontermination can occur as an accident when we have done our utmost
to write a pure function.
While a computation has not yet terminated, we don't know whether
it is a function (will terminate with a value) or not terminate.
Don't get distracted by minor terminology matters.
On 9/15/2025 6:14 PM, Chris M. Thomasson wrote:
You are not a fool, why act like one?
On 9/15/2025 4:29 PM, olcott wrote:
On 9/15/2025 6:14 PM, Chris M. Thomasson wrote:
You are not a fool, why act like one?
Well, you are making me ponder.
_____________________
10 PRINT "Infinite..."
20 GOTO 10
_____________________
does not halt. However,
_____________________
10 PRINT "Halt..."
_____________________
does halt. No simulation needed. So, what your main point? What am I
missing here? Why do need a simulator for this in the first place?
[...]
That air-tight theorem crucially depends on requiring a
decider to report on something other than the actual
behavior actually specified by its actual input.
On 9/15/2025 2:55 PM, Kaz Kylheku wrote:
On 2025-09-15, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 15/09/2025 19:56, olcott wrote:
Anyone that knows much about Rice's theorem has
heard about semantic properties of programs yet
think its total nonsense what I bring this up.
Rice's Theorem don't enter into it. The fact remains that you
have a halting program that you claim doesn't halt.
Until you fix that, nobody is going to take seriously anything
you claim.
It's exactly as if Olott tried to claim that a brick and a feather have
different acceleration due to gravity.
If you don't ignore terminal velocity.
Everyone is pointing out that his experiment is not conducted in
a vacuum, and therefore its conclusion is invalid.
That is pure bullshit. Find a damn error otherwise
you implicitly admit there is none.
DDD.HHH does not halt.
Changing the subject to DDD.HHH1 as the basis of
rebuttal is the dishonest tactic known as strawman.
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
That air-tight theorem crucially depends on requiring a
decider to report on something other than the actual
behavior actually specified by its actual input.
This is just a horribly false claim which you use as a pretext for
believing that it's okay that your coded apparatus reports on
information other than / in addition to the input. (It isn't.)
On 15/09/2025 20:56, olcott wrote:
<snip>
Yep. Everybody (except you) knows you're wrong.Yet cannot show any details of any mistake
because there is no mistake.
$ ./plaindd
DD halted.
That's all the detail anyone needs.
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 2:55 PM, Kaz Kylheku wrote:
On 2025-09-15, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 15/09/2025 19:56, olcott wrote:
Anyone that knows much about Rice's theorem has
heard about semantic properties of programs yet
think its total nonsense what I bring this up.
Rice's Theorem don't enter into it. The fact remains that you
have a halting program that you claim doesn't halt.
Until you fix that, nobody is going to take seriously anything
you claim.
It's exactly as if Olott tried to claim that a brick and a feather have
different acceleration due to gravity.
If you don't ignore terminal velocity.
Everyone is pointing out that his experiment is not conducted in
a vacuum, and therefore its conclusion is invalid.
That is pure bullshit. Find a damn error otherwise
you implicitly admit there is none.
DDD.HHH does not halt.
Changing the subject to DDD.HHH1 as the basis of
rebuttal is the dishonest tactic known as strawman.
Bug that is your tactic. You invented this superfluous HHH1, the
notation DD.HHH1
and the invalid idea that the single function DD can
have two different behaviors
identified as HHH.DD and HHH1.DD, yet be a
valid diagonal test case meeting the requirements of the diagonal-based Halting Theorem proofs require.
The alleged bullshit is all of your making.
On 9/15/2025 7:54 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
That air-tight theorem crucially depends on requiring a
decider to report on something other than the actual
behavior actually specified by its actual input.
This is just a horribly false claim which you use as a pretext for
believing that it's okay that your coded apparatus reports on
information other than / in addition to the input. (It isn't.)
You only say that because you insist on not paying
enough attention to the actual execution trace of
DD correctly simulated by HHH.
On 9/15/2025 7:58 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 2:55 PM, Kaz Kylheku wrote:
On 2025-09-15, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 15/09/2025 19:56, olcott wrote:
Anyone that knows much about Rice's theorem has
heard about semantic properties of programs yet
think its total nonsense what I bring this up.
Rice's Theorem don't enter into it. The fact remains that you
have a halting program that you claim doesn't halt.
Until you fix that, nobody is going to take seriously anything
you claim.
It's exactly as if Olott tried to claim that a brick and a feather have >>>> different acceleration due to gravity.
If you don't ignore terminal velocity.
Everyone is pointing out that his experiment is not conducted in
a vacuum, and therefore its conclusion is invalid.
That is pure bullshit. Find a damn error otherwise
you implicitly admit there is none.
DDD.HHH does not halt.
Changing the subject to DDD.HHH1 as the basis of
rebuttal is the dishonest tactic known as strawman.
Bug that is your tactic. You invented this superfluous HHH1, the
notation DD.HHH1
That was your own idea and a great way to point out
and the invalid idea that the single function DD can
have two different behaviors
It does have two different behaviors as conclusively
proven by the execution trace that you refuse to pay
attention to.
You even claim that DDD simulated by HHH
according to the semantics of the x86 language
reaches its final halt state and yet cannot show
how this is possible *BECAUSE IT IS NOT POSSIBLE*
On 9/15/2025 4:55 PM, Richard Heathfield wrote:
On 15/09/2025 21:58, olcott wrote:
On 9/15/2025 3:01 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <NoOne@NoWhere.com> wrote:
On 9/15/2025 2:47 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 1:55 PM, Kaz Kylheku wrote:
1. DDD() simply must not have multiple different
behaviors; it is
No sense proceeding with this until you study the
actual trace well enough that you can see that HHH1
simulates DDD once and HHH simulates DDD twice.
No sense proceeding with your traces until they capture
every single
instruction, including those inside the simulator, and dump
the values
of all the registers at every step.
I do see that HHH simulates DDD twice; it needs two times
in order for
the new abort logic to see two CALL instructions to the
same address.
That sameness is how you avoid encoding the name of HHH
into the
simulation.
It looks as if under this new way of doing things, DDD is
always the
same, as required. That should be the case if every HHH
simulation
level has its own private execution trace; if there is no
communication
among different instances of HHH through a shared execution
trace.
Unfortunately, HHH decides that DDD is non-halting, when
it's halting.
That DDD.HHH1 is halting does not say a damn thing about
DDD.HHH.
1. But, if that were to be true, it means that DDD isn't a pure
function. It is (at least) two different computations that
somehow differentiate based on something in their
environment.
That completely damns your entire apparatus as being
inapplicable to the Halting Theorem.
2. Fortunately, it looks like in your present apparatus, it
is not actually true. If every simulation conducted by
your HHH is completely isolated from other simulations (has
its own private execution trace not mixed up with
anything), that should be true. This is a good thing; but
unfortunately it stil leaves your HHH(DDD) -> 0 result in a
lurch. (We have an air-tight theorem which tells us that
this result will happen no matter what, even if your
apparatus 100% follows all the conditions of purity.)
That air-tight theorem crucially depends on requiring a
decider to report on something other than the actual
behavior actually specified by its actual input.
That's lucky for you, because that's precisely what you do.
The actual behaviour specified by DD is halting, and you
instead report on the subset of that behaviour that your flawed
and semi-blind simulator can see and misinterpret.
DD halts. Deal with it.
The actual behavior of DD.exe is halting.
The actual behavior that DD.HHH specifies
is never reaching a final halt state.
On 2025-09-16, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 7:54 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
That air-tight theorem crucially depends on requiring a
decider to report on something other than the actual
behavior actually specified by its actual input.
This is just a horribly false claim which you use as a pretext for
believing that it's okay that your coded apparatus reports on
information other than / in addition to the input. (It isn't.)
You only say that because you insist on not paying
enough attention to the actual execution trace of
DD correctly simulated by HHH.
I understand your stuff enough to recognize that the
simulation abandoned by HHH can be continued, and DD
will terminate in that simulation.
It could be confirmed by execution trace, or by some
OutputString statement in DD just before its return.
On 16/09/2025 00:11, olcott wrote:
The actual behavior that DD.HHH specifies
is never reaching a final halt state.
In other words. HHH gets the answer wrong. But then we always knew it
would, because there's a proof.
On 9/15/2025 8:12 PM, Kaz Kylheku wrote:
On 2025-09-16, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 7:54 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
That air-tight theorem crucially depends on requiring a
decider to report on something other than the actual
behavior actually specified by its actual input.
This is just a horribly false claim which you use as a pretext for
believing that it's okay that your coded apparatus reports on
information other than / in addition to the input. (It isn't.)
You only say that because you insist on not paying
enough attention to the actual execution trace of
DD correctly simulated by HHH.
I understand your stuff enough to recognize that the
simulation abandoned by HHH can be continued, and DD
will terminate in that simulation.
*I say that is bullshit and you know it*
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
The only way for DDD simulated by HHH according
to the semantics of the x86 language to reach it
"ret" instruction is to cheat.
Interpreting "push ebp" to mean "jmp 000021a3"
is one of these cheats.
On 2025-09-16, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 8:12 PM, Kaz Kylheku wrote:
On 2025-09-16, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 7:54 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
That air-tight theorem crucially depends on requiring a
decider to report on something other than the actual
behavior actually specified by its actual input.
This is just a horribly false claim which you use as a pretext for
believing that it's okay that your coded apparatus reports on
information other than / in addition to the input. (It isn't.)
You only say that because you insist on not paying
enough attention to the actual execution trace of
DD correctly simulated by HHH.
I understand your stuff enough to recognize that the
simulation abandoned by HHH can be continued, and DD
will terminate in that simulation.
*I say that is bullshit and you know it*
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
The only way for DDD simulated by HHH according
to the semantics of the x86 language to reach it
"ret" instruction is to cheat.
If DDD is simulated by the semantics of x86, then "call 000015d2"
returns, and control flow goes on to the next function. We know this
since we can just run DDD() in main() on the host processor which
correctly implements x86.
But you say "correctly simulated /by HHH/ according to the x86
semantics". This is an oxymoron then. If HHH does anything different
from the x86 semantics, then the simulation is wrong.
Here is the thing though; HHH most likely isn't doing anything wrong according to the x86 semantics other than just giving up on DDD early
(where the real processor, or even HHH1, would just keep going).
On 9/15/2025 9:03 PM, Kaz Kylheku wrote:
On 2025-09-16, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 8:12 PM, Kaz Kylheku wrote:
On 2025-09-16, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 7:54 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
That air-tight theorem crucially depends on requiring a
decider to report on something other than the actual
behavior actually specified by its actual input.
This is just a horribly false claim which you use as a pretext for >>>>>> believing that it's okay that your coded apparatus reports on
information other than / in addition to the input. (It isn't.)
You only say that because you insist on not paying
enough attention to the actual execution trace of
DD correctly simulated by HHH.
I understand your stuff enough to recognize that the
simulation abandoned by HHH can be continued, and DD
will terminate in that simulation.
*I say that is bullshit and you know it*
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
The only way for DDD simulated by HHH according
to the semantics of the x86 language to reach it
"ret" instruction is to cheat.
If DDD is simulated by the semantics of x86, then "call 000015d2"
returns, and control flow goes on to the next function. We know this
since we can just run DDD() in main() on the host processor which
correctly implements x86.
But you say "correctly simulated /by HHH/ according to the x86
semantics". This is an oxymoron then. If HHH does anything different
from the x86 semantics, then the simulation is wrong.
Here is the thing though; HHH most likely isn't doing anything wrong
according to the x86 semantics other than just giving up on DDD early
(where the real processor, or even HHH1, would just keep going).
I just don't understand how it is possible for a guy
as bright as you to not understand the behavioral
difference of DD simulated by HHH [called in recursive emulation]
contrasted with DD simulated by HHH1 [not called at all].
In the first case HHH keeps getting told to go
back and do it again and HHH1 isn't told anything.
On 2025-09-16, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 9:03 PM, Kaz Kylheku wrote:
On 2025-09-16, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 8:12 PM, Kaz Kylheku wrote:
On 2025-09-16, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 7:54 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
That air-tight theorem crucially depends on requiring a
decider to report on something other than the actual
behavior actually specified by its actual input.
This is just a horribly false claim which you use as a pretext for >>>>>>> believing that it's okay that your coded apparatus reports on
information other than / in addition to the input. (It isn't.)
You only say that because you insist on not paying
enough attention to the actual execution trace of
DD correctly simulated by HHH.
I understand your stuff enough to recognize that the
simulation abandoned by HHH can be continued, and DD
will terminate in that simulation.
*I say that is bullshit and you know it*
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192 // push DDD
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
The only way for DDD simulated by HHH according
to the semantics of the x86 language to reach it
"ret" instruction is to cheat.
If DDD is simulated by the semantics of x86, then "call 000015d2"
returns, and control flow goes on to the next function. We know this
since we can just run DDD() in main() on the host processor which
correctly implements x86.
But you say "correctly simulated /by HHH/ according to the x86
semantics". This is an oxymoron then. If HHH does anything different
from the x86 semantics, then the simulation is wrong.
Here is the thing though; HHH most likely isn't doing anything wrong
according to the x86 semantics other than just giving up on DDD early
(where the real processor, or even HHH1, would just keep going).
I just don't understand how it is possible for a guy
as bright as you to not understand the behavioral
difference of DD simulated by HHH [called in recursive emulation]
contrasted with DD simulated by HHH1 [not called at all].
In the first case HHH keeps getting told to go
back and do it again and HHH1 isn't told anything.
HHH is not being told to go back. DD is freshly simulated in new
levels of a simulation and the CALL isn't exactly going "back";
it is happening afresh in a new simulation level.
In each simulation, the conditional jump instructions (whose absence
your abort logic is confirming) are in fact coming. They are in the
(near!) future execution trace.
But the parent HHH pulls the plug on the simulation before that future arrives in the child HHH. HHH has seen a couple of CALL instructions
to the same address, and no conditional jumps and declared, gee,
this /must/ be inifnite.
But if the simulation is carried out a little bit past that point (as is
done in HHH1) it comes to light that a CALL HHH DD all of a sudden
returns, and control passes into the block below where there is a
conditional jump.
The trick is that we must allow HHH(DD) to return 0, as it wants to, let
the test case finish, then inspect and continue the abandoned
simulations to do some reckoning as to whether HHH(DD) made the right decision.
On 9/15/2025 9:26 PM, Kaz Kylheku wrote:If the simulation could not be continued, it would be terminating.
On 2025-09-16, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 9:03 PM, Kaz Kylheku wrote:
On 2025-09-16, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 8:12 PM, Kaz Kylheku wrote:
I understand your stuff enough to recognize that the simulation
abandoned by HHH can be continued, and DD will terminate in that
simulation.
*I say that is bullshit and you know it*
I mean, HHH aborts before reaching that, so it can't reach it...The only way for DDD simulated by HHH according to the semantics of
the x86 language to reach it "ret" instruction is to cheat.
HHH has not seen the conditional jumps in itself.HHH is not being told to go back. DD is freshly simulated in new levels
of a simulation and the CALL isn't exactly going "back";
it is happening afresh in a new simulation level.
In each simulation, the conditional jump instructions (whose absence
your abort logic is confirming) are in fact coming. They are in the
(near!) future execution trace.
But the parent HHH pulls the plug on the simulation before that future
arrives in the child HHH. HHH has seen a couple of CALL instructions to
the same address, and no conditional jumps and declared, gee,
this /must/ be inifnite.
That is a different DD because it calls a different HHH.But if the simulation is carried out a little bit past that point (as
is done in HHH1) it comes to light that a CALL HHH DD all of a sudden
returns, and control passes into the block below where there is a
conditional jump.
I have already proved that DD simulated by HHH never halts by commenting
out this flag
#define ENABLE_ABORT_CODE 1
On 9/15/2025 2:34 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 12:39 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
*This is the beginning of the divergence of the behavior*
*of DDD emulated by HHH versus DDD emulated by HHH1*
No that is the beginning of the divergence of the behavior of HHH1
and HHH, not of DDD. DDD is not built on HHH1, so its behavior does >>>> not
diverge in any way. DDD is tied to the behavior of HHH.
HHH1 simulated DDD exactly once. The above referenced
execution trace point is where HHH begins to simulate
DDD again.
Yes; since DDD calls HHH(DDD), then simulating DDD implies
simulating HHH. So what?
ONCE VERSUS TWICE THUS NOT THE SAME
ONCE VERSUS TWICE THUS NOT THE SAME
ONCE VERSUS TWICE THUS NOT THE SAME
ONCE VERSUS TWICE THUS NOT THE SAME
ONCE VERSUS TWICE THUS NOT THE SAME
ONCE VERSUS TWICE THUS NOT THE SAME
ONCE VERSUS TWICE THUS NOT THE SAME
ONCE VERSUS TWICE THUS NOT THE SAME
ONCE VERSUS TWICE THUS NOT THE SAME
ONCE VERSUS TWICE THUS NOT THE SAME
ONCE VERSUS TWICE THUS NOT THE SAME
On 9/15/2025 7:58 PM, Kaz Kylheku wrote:Yeah, HHH's is wrong. If the halting status of a program (it can't be
and the invalid idea that the single function DD can have two differentIt does have two different behaviors as conclusively proven by the
behaviors
execution trace that you refuse to pay attention to.
You even claim that DDD simulated by HHH according to the semantics ofNo, HHH does in fact not simulate the return, but it could, if you
the x86 language reaches its final halt state and yet cannot show how
this is possible *BECAUSE IT IS NOT POSSIBLE*
--identified as HHH.DD and HHH1.DD, yet be a valid diagonal test case
meeting the requirements of the diagonal-based Halting Theorem proofs
require. The alleged bullshit is all of your making.
On 9/15/2025 2:41 PM, Kaz Kylheku wrote:
On 2025-09-15, olcott <polcott333@gmail.com> wrote:
On 9/15/2025 1:27 PM, Richard Heathfield wrote:
On 15/09/2025 18:46, olcott wrote:
<nonsense snipped>
So I am going to keep coming back to this again
and again however many times needed until this
is understood.
You keep coming back to this, but it will never be understood, because >>>> it makes no sense to anyone but you.
Only because they are so damned sure that I must
be wrong that they perpetually refuse to pay any
attention at all.
It is in fact YOUR OWN JOB to look for anything that may be wrong in
your own work, such that the work's hypothesis is not justified.
<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern:
abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
What value should HHH(DD) correctly return?
<Input to LLM systems>
That HHH(DD)==0 is categorically infallible yet you
pretend that you don't even know what mutual recursion is.
On 9/15/2025 8:52 PM, Richard Heathfield wrote:
On 16/09/2025 00:11, olcott wrote:
The actual behavior that DD.HHH specifies
is never reaching a final halt state.
In other words. HHH gets the answer wrong. But then we always knew it
would, because there's a proof.
The input to HHH(DD) specifies behavior that
cannot possibly reach its own final halt state.
I can't tell if you are a liar or of insufficient skill.
On 9/15/2025 8:52 PM, Richard Heathfield wrote:
On 16/09/2025 00:11, olcott wrote:
The actual behavior that DD.HHH specifies
is never reaching a final halt state.
In other words. HHH gets the answer wrong. But then we always
knew it would, because there's a proof.
The input to HHH(DD) specifies behavior that
cannot possibly reach its own final halt state.
I can't tell if you are a liar or of insufficient skill.
On 9/15/2025 2:55 PM, Kaz Kylheku wrote:The semantics of the program the description of DD describes, i.e. DD,
On 2025-09-15, Richard Heathfield <rjh@cpax.org.uk> wrote:
On 15/09/2025 19:56, olcott wrote:
Anyone that knows much about Rice's theorem has heard about semantic
properties of programs yet think its total nonsense what I bring this
up.
Can't tell, it aborts. HHH certainly *returns* that.If you don't ignore terminal velocity.Rice's Theorem don't enter into it. The fact remains that you have aIt's exactly as if Olott tried to claim that a brick and a feather have
halting program that you claim doesn't halt.
Until you fix that, nobody is going to take seriously anything you
claim.
different acceleration due to gravity.
Everyone is pointing out that his experiment is not conducted in aThat is pure bullshit. Find a damn error otherwise you implicitly admit
vacuum, and therefore its conclusion is invalid.
there is none.
DDD.HHH does not halt.
Well said. Unfortunately olcott is oblivious to this.But, nope, they are just so convinced Olcott is wrong they are not
paying attention to his actual experiment and its captures showing that
the brick hits the ground before the feather. Here is the slow-motion
video again, for the ten-thousandth time ...
On 2025-09-16, olcott <polcott333@gmail.com> wrote:
I insisted that if you have multple deciders, you identify them, and
call them HHH1, HHH2, ... and consequently that since DD is built on
HHH, you have corresponding DD1, DD2.
Moreover, only the matching numbers are diagonal pairs, like
HHH1/DD1, HHH2/DD2, and so on.
Diagonal-based proofs of the Halting Theorem only say that
each diagonal test case cannot be correctly decided by
that decider which is involved in that test case.
So HHH1(DD1) cannot correctly report, and neither can HHH2(DD2).
But HHH2(DD1) can potentially report correctly, as well as HH1(DD2),
and any other "off-diagonal" configuration.
Diagnoal-basd proofs of the Halting Theorem never say that
a decider cannot decide a case that is not its diagonal case.
Why you latched on to HHH1 name, and the way you are trying to
use it, and to what purpose, is beyond me.
and the invalid idea that the single function DD can
have two different behaviors
It does have two different behaviors as conclusively
proven by the execution trace that you refuse to pay
attention to.
But (1) I think it actually does not. You have a decider
which stops simulating DD. DD not being simulated any
more isn't a behavior specified by DD.
(2) if DD did have two different behaviors, that would make your
apparatus invalid,
The argument "but, are you paying attention, it does
have two behaviors in my apparatus" isn't valid; yua re just testifying
to the invalidity of your apparatus.
You even claim that DDD simulated by HHH
according to the semantics of the x86 language
reaches its final halt state and yet cannot show
how this is possible *BECAUSE IT IS NOT POSSIBLE*
Sure it is possible. When HHH is about to return, just have it push the Registers of the simulation into a global cleanup list.
(HHH has no behavior dependent on the content of this list, so it is
valid; it is just instrumentation.)
Then at the end of main() have a clean-up routine walk through the list
and complete all those abandoned simulations.
I recently showed some of the code for doing this, except for
the details of the clean-up routine.
On 9/15/2025 8:29 PM, Kaz Kylheku wrote:That clears things up. The only problem is that you think they are
On 2025-09-16, olcott <polcott333@gmail.com> wrote:
I insisted that if you have multple deciders, you identify them, and
call them HHH1, HHH2, ... and consequently that since DD is built on
HHH, you have corresponding DD1, DD2.
Moreover, only the matching numbers are diagonal pairs, like HHH1/DD1,
HHH2/DD2, and so on.
Diagonal-based proofs of the Halting Theorem only say that each
diagonal test case cannot be correctly decided by that decider which is
involved in that test case.
So HHH1(DD1) cannot correctly report, and neither can HHH2(DD2).
But HHH2(DD1) can potentially report correctly, as well as HH1(DD2),
and any other "off-diagonal" configuration.
Diagnoal-basd proofs of the Halting Theorem never say that a decider
cannot decide a case that is not its diagonal case.
Why you latched on to HHH1 name, and the way you are trying to use it,
and to what purpose, is beyond me.
HHH(DD) is what has been historically referred to as the diagonal case. HHH1(DD) is the decider that is unaffected by the diagonal case.
Simulating termination analyzer HHH(DD) defeats the diagonal caseAny analyser could see that and return that DD doesn't halt.
because it takes into account that DD calls itself in recursive
simulation, that is just like mutual recursion.
Also with a simulating termination analyzer the "do the opposite"Emphasis on "becomes": HHH can't simulate it.
code of the HP proofs becomes unreachable.
Then it's not a function or one the simulators is wrong.and the invalid idea that the single function DD can have twoIt does have two different behaviors as conclusively proven by the
different behaviors
execution trace that you refuse to pay attention to.
Yes, since it treats HHH as a black box.But (1) I think it actually does not. You have a decider which stops
simulating DD. DD not being simulated any more isn't a behavior
specified by DD.
In other words you are saying that when HHH has complete proof that an
input cannot possibly reach its own final halt state that this complete
proof DOES NOT COUNT.
No, it is not the job of HHH to determine whether it can simulate DD'sYou even claim that DDD simulated by HHH according to the semantics ofSure it is possible. When HHH is about to return, just have it push the
the x86 language reaches its final halt state and yet cannot show how
this is possible *BECAUSE IT IS NOT POSSIBLE*
Registers of the simulation into a global cleanup list.
(HHH has no behavior dependent on the content of this list, so it is
valid; it is just instrumentation.)
Then at the end of main() have a clean-up routine walk through the list
and complete all those abandoned simulations.
I recently showed some of the code for doing this, except for theIt is the job of HHH to determine whether or not DD emulated by HHH
details of the clean-up routine.
according to the semantics of the x86 language would reach its own
simulated "ret"
instruction final halt state on its own without any interference. Your
idea is interference, adding steps that are not already in the pure simulation.
Am Tue, 16 Sep 2025 10:06:15 -0500 schrieb olcott:
On 9/15/2025 8:29 PM, Kaz Kylheku wrote:
On 2025-09-16, olcott <polcott333@gmail.com> wrote:
I insisted that if you have multple deciders, you identify them, and
call them HHH1, HHH2, ... and consequently that since DD is built on
HHH, you have corresponding DD1, DD2.
Moreover, only the matching numbers are diagonal pairs, like HHH1/DD1,
HHH2/DD2, and so on.
Diagonal-based proofs of the Halting Theorem only say that each
diagonal test case cannot be correctly decided by that decider which is
involved in that test case.
So HHH1(DD1) cannot correctly report, and neither can HHH2(DD2).
But HHH2(DD1) can potentially report correctly, as well as HH1(DD2),
and any other "off-diagonal" configuration.
Diagnoal-basd proofs of the Halting Theorem never say that a decider
cannot decide a case that is not its diagonal case.
Why you latched on to HHH1 name, and the way you are trying to use it,
and to what purpose, is beyond me.
HHH(DD) is what has been historically referred to as the diagonal case.
HHH1(DD) is the decider that is unaffected by the diagonal case.
That clears things up. The only problem is that you think they are
identical.
Simulating termination analyzer HHH(DD) defeats the diagonal case
because it takes into account that DD calls itself in recursive
simulation, that is just like mutual recursion.
Any analyser could see that and return that DD doesn't halt.
Also with a simulating termination analyzer the "do the opposite"
code of the HP proofs becomes unreachable.
Emphasis on "becomes": HHH can't simulate it.
and the invalid idea that the single function DD can have twoIt does have two different behaviors as conclusively proven by the
different behaviors
execution trace that you refuse to pay attention to.
Then it's not a function or one the simulators is wrong.
But (1) I think it actually does not. You have a decider which stops
simulating DD. DD not being simulated any more isn't a behavior
specified by DD.
In other words you are saying that when HHH has complete proof that anYes, since it treats HHH as a black box.
input cannot possibly reach its own final halt state that this complete
proof DOES NOT COUNT.
You even claim that DDD simulated by HHH according to the semantics of >>>> the x86 language reaches its final halt state and yet cannot show howSure it is possible. When HHH is about to return, just have it push the
this is possible *BECAUSE IT IS NOT POSSIBLE*
Registers of the simulation into a global cleanup list.
(HHH has no behavior dependent on the content of this list, so it is
valid; it is just instrumentation.)
Then at the end of main() have a clean-up routine walk through the list
and complete all those abandoned simulations.
I recently showed some of the code for doing this, except for theIt is the job of HHH to determine whether or not DD emulated by HHH
details of the clean-up routine.
according to the semantics of the x86 language would reach its own
simulated "ret"
instruction final halt state on its own without any interference. Your
idea is interference, adding steps that are not already in the pure
simulation.
No, it is not the job of HHH to determine whether it can simulate DD's return. Besides, HHH already does many other things in order to even simulate.
It has always been about the actual input's actual behavior.
The biggest problem is that hardly anyone pays
any attention
that I have been correct in every
detail of this all along:
On 16/09/2025 18:34, olcott wrote:
It has always been about the actual input's actual behavior.
Well, no. We've seen the actual input's actual behaviour. It actually
halts. It has always been about pretending the actual input's actual behavior isn't actual.
On 16/09/2025 18:34, olcott wrote:
It has always been about the actual input's actual behavior.
Well, no. We've seen the actual input's actual behaviour. It actually
halts. It has always been about pretending the actual input's actual behavior isn't actual.
On 9/16/2025 1:04 PM, Richard Heathfield wrote:Yes. HHH1 correctly decides "halting", and HHH incorrectly decides
On 16/09/2025 18:34, olcott wrote:It has ALWAYS been known that the halting problem proof case of HHH(DD)
It has always been about the actual input's actual behavior.
Well, no. We've seen the actual input's actual behaviour. It actually
halts. It has always been about pretending the actual input's actual
behavior isn't actual.
that forms the conventional diagonal could be correct decided by another
halt decider HHH1(DD) that does not have the conventional diagonal relationship.
This means that it has always been common knowledge that the behavior of
DD with HHH(DD) is different than the behavior of DD with HHH1(DD).
Am Tue, 16 Sep 2025 13:25:05 -0500 schrieb olcott:
On 9/16/2025 1:04 PM, Richard Heathfield wrote:
On 16/09/2025 18:34, olcott wrote:It has ALWAYS been known that the halting problem proof case of HHH(DD)
It has always been about the actual input's actual behavior.
Well, no. We've seen the actual input's actual behaviour. It actually
halts. It has always been about pretending the actual input's actual
behavior isn't actual.
that forms the conventional diagonal could be correct decided by another
halt decider HHH1(DD) that does not have the conventional diagonal
relationship.
This means that it has always been common knowledge that the behavior of
DD with HHH(DD) is different than the behavior of DD with HHH1(DD).
Yes. HHH1 correctly decides "halting", and HHH incorrectly decides
"not halting".
On 9/16/2025 1:04 PM, Richard Heathfield wrote:
On 16/09/2025 18:34, olcott wrote:
It has always been about the actual input's actual behavior.
Well, no. We've seen the actual input's actual behaviour. It
actually halts. It has always been about pretending the actual
input's actual behavior isn't actual.
It has ALWAYS been known that the halting problem
proof case of HHH(DD)
On 9/16/2025 1:04 PM, Richard Heathfield wrote:
On 16/09/2025 18:34, olcott wrote:
It has always been about the actual input's actual behavior.
Well, no. We've seen the actual input's actual behaviour. It
actually halts. It has always been about pretending the actual
input's actual behavior isn't actual.
It has ALWAYS been known that the halting problem
proof case of HHH(DD)
that forms the conventional
diagonal could be correct decided by another halt
decider HHH1(DD) that does not have the conventional
diagonal relationship.
This means that it has always been common knowledge
that the behavior of DD with HHH(DD) is different
than the behavior of DD with HHH1(DD).
My point is that it has always been known that DD
has different behavior under HHH than HHH1. Kaz
still thinks that this is impossible.
On 9/16/2025 2:05 PM, joes wrote:Yes, because it is wrong. One program = one behaviour. It does not
Am Tue, 16 Sep 2025 13:25:05 -0500 schrieb olcott:
On 9/16/2025 1:04 PM, Richard Heathfield wrote:
On 16/09/2025 18:34, olcott wrote:It has ALWAYS been known that the halting problem proof case of
It has always been about the actual input's actual behavior.
Well, no. We've seen the actual input's actual behaviour. It actually
halts. It has always been about pretending the actual input's actual
behavior isn't actual.
HHH(DD) that forms the conventional diagonal could be correct decided
by another halt decider HHH1(DD) that does not have the conventional
diagonal relationship.
This means that it has always been common knowledge that the behavior
of DD with HHH(DD) is different than the behavior of DD with HHH1(DD).
Yes. HHH1 correctly decides "halting", and HHH incorrectly decides "notMy point is that it has always been known that DD has different behavior under HHH than HHH1. Kaz still thinks that this is impossible.
halting".
Am Tue, 16 Sep 2025 14:17:13 -0500 schrieb olcott:
On 9/16/2025 2:05 PM, joes wrote:Yes, because it is wrong. One program = one behaviour. It does not
Am Tue, 16 Sep 2025 13:25:05 -0500 schrieb olcott:My point is that it has always been known that DD has different behavior
On 9/16/2025 1:04 PM, Richard Heathfield wrote:
On 16/09/2025 18:34, olcott wrote:It has ALWAYS been known that the halting problem proof case of
It has always been about the actual input's actual behavior.
Well, no. We've seen the actual input's actual behaviour. It actually >>>>> halts. It has always been about pretending the actual input's actual >>>>> behavior isn't actual.
HHH(DD) that forms the conventional diagonal could be correct decided
by another halt decider HHH1(DD) that does not have the conventional
diagonal relationship.
This means that it has always been common knowledge that the behavior
of DD with HHH(DD) is different than the behavior of DD with HHH1(DD).
Yes. HHH1 correctly decides "halting", and HHH incorrectly decides "not
halting".
under HHH than HHH1. Kaz still thinks that this is impossible.
depend on the simulator. That is why HHH is wrong.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,070 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 162:19:48 |
| Calls: | 13,734 |
| Calls today: | 2 |
| Files: | 186,966 |
| D/L today: |
858 files (307M bytes) |
| Messages: | 2,418,776 |