On 8/12/2025 3:47 AM, Mikko wrote:
On 2025-08-11 14:34:50 +0000, olcott said:Can DDD emulated by HHH according to the semantics
So you understand that HHH(DD)==0 on the basis of the
behavior of DD correctly simulated by HHH?
No but on the basis of failure to simulate correctly the behavoiur of DD,
in particular the point where the HHH called by DD aborts its simulation
and returns 0 to DD which then halts.
of the x86 language reach its own emulated "ret"
instruction final halt state?
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]
(a) HHH executes.
(b) HHH creates a separate process context having
its own stack and set of 16 virtual registers
to simulate DDD using cooperative multi-tasking.
(c) HHH emulates the first four instructions of DDD
in this separate process context.
(d) HHH emulates an instance of itself in this same
process context.
(e) This HHH instance creates another process context
for its own emulated DDD instance.
(f) This HHH instance emulates the first three
instructions of DDD in this separate process
context and sees the call 000015d2 instruction.
It is a verified fact HHH did emulate DDD according
to the semantics of the x86 language. That *is* the
ultimate measure of correct emulation. Disagreeing
with the x86 language is necessarily incorrect.
On 8/12/2025 3:47 AM, Mikko wrote:
On 2025-08-11 14:34:50 +0000, olcott said:
So you understand that HHH(DD)==0 on the basis of the
behavior of DD correctly simulated by HHH?
No but on the basis of failure to simulate correctly the behavoiur of DD,
in particular the point where the HHH called by DD aborts its simulation
and returns 0 to DD which then halts.
Can DDD emulated by HHH according to the semantics
of the x86 language reach its own emulated "ret"
instruction final halt state?
On 8/13/2025 2:50 AM, Mikko wrote:
On 2025-08-12 14:38:32 +0000, olcott said:
Counter-factualCan DDD emulated by HHH according to the semantics
of the x86 language reach its own emulated "ret"
instruction final halt state?
Yes, if the instructions in HHH are not simulated.
On 8/13/2025 11:01 AM, Richard Heathfield wrote:
On 13/08/2025 16:00, olcott wrote:
On 8/13/2025 2:50 AM, Mikko wrote:
On 2025-08-12 14:38:32 +0000, olcott said:
<snip>
Counter-factualCan DDD emulated by HHH according to the semantics
of the x86 language reach its own emulated "ret"
instruction final halt state?
Yes, if the instructions in HHH are not simulated.
Excuse me? You just argued - and it's quoted above - that HHH
can't emulate DDD's ret instruction.
You can't have it both ways.
A provably correct emulation of DD by HHH keeps
DD stuck recursive emulation until aborted.
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
On 8/13/2025 2:50 AM, Mikko wrote:
On 2025-08-12 14:38:32 +0000, olcott said:Counter-factual
On 8/12/2025 3:47 AM, Mikko wrote:
On 2025-08-11 14:34:50 +0000, olcott said:
So you understand that HHH(DD)==0 on the basis of the
behavior of DD correctly simulated by HHH?
No but on the basis of failure to simulate correctly the behavoiur
of DD,
in particular the point where the HHH called by DD aborts its
simulation
and returns 0 to DD which then halts.
Can DDD emulated by HHH according to the semantics
of the x86 language reach its own emulated "ret"
instruction final halt state?
Yes, if the instructions in HHH are not simulated.
On 8/13/2025 11:01 AM, Richard Heathfield wrote:
On 13/08/2025 16:00, olcott wrote:
On 8/13/2025 2:50 AM, Mikko wrote:
On 2025-08-12 14:38:32 +0000, olcott said:
<snip>
Counter-factualCan DDD emulated by HHH according to the semantics
of the x86 language reach its own emulated "ret"
instruction final halt state?
Yes, if the instructions in HHH are not simulated.
Excuse me? You just argued - and it's quoted above - that HHH can't
emulate DDD's ret instruction.
You can't have it both ways.
A provably correct emulation of DD by HHH keeps
DD stuck recursive emulation until aborted.
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
On 8/13/2025 2:50 AM, Mikko wrote:
On 2025-08-12 14:38:32 +0000, olcott said:Counter-factual
On 8/12/2025 3:47 AM, Mikko wrote:
On 2025-08-11 14:34:50 +0000, olcott said:
So you understand that HHH(DD)==0 on the basis of the
behavior of DD correctly simulated by HHH?
No but on the basis of failure to simulate correctly the behavoiur of DD, >>>> in particular the point where the HHH called by DD aborts its simulation >>>> and returns 0 to DD which then halts.
Can DDD emulated by HHH according to the semantics
of the x86 language reach its own emulated "ret"
instruction final halt state?
Yes, if the instructions in HHH are not simulated.
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
On 8/14/2025 3:40 AM, Richard Heathfield wrote:
On 14/08/2025 09:24, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
Yes.
Perhaps this is because some/most/all of us are imagining DD
kicking HHH off for the first time (as suggested by the source
code he posts here), whereas Mr Olcott is imagining HHH kicking
DD off for the first time (as suggested by the source code he
has tucked away on the Web).
This would explain why he sets so little (and we set so much)
store by DD's return value.
The problem seems to be that no one ever bothers
to carefully study all of the words that I said.
They only glance at a couple of words then leap
to an incorrect conclusion.
When I prove that their assumptions are false
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:*That would mean that you agree with this*
That everyone here seems to think that the notion of recursive
emulation is incomprehensibly more difficult to understand that
ordinary recursion seems absurd unless the respondent has no idea what
ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
When HHH(DD) is executed that this begins simulating DD that calls
HHH(DD) that begins simulating DD that calls HHH(DD) again.
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
On 8/14/2025 3:22 AM, Mikko wrote:
On 2025-08-13 15:00:31 +0000, olcott said:
On 8/13/2025 2:50 AM, Mikko wrote:
On 2025-08-12 14:38:32 +0000, olcott said:Counter-factual
On 8/12/2025 3:47 AM, Mikko wrote:
On 2025-08-11 14:34:50 +0000, olcott said:
So you understand that HHH(DD)==0 on the basis of the
behavior of DD correctly simulated by HHH?
No but on the basis of failure to simulate correctly the behavoiur of DD,
in particular the point where the HHH called by DD aborts its simulation >>>>>> and returns 0 to DD which then halts.
Can DDD emulated by HHH according to the semantics
of the x86 language reach its own emulated "ret"
instruction final halt state?
Yes, if the instructions in HHH are not simulated.
Indeed, your HHH is unable to do what it should do.
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
This is enough to match the:
*recursive simulation non-halting behavior pattern*
On 8/14/2025 3:40 AM, Richard Heathfield wrote:
On 14/08/2025 09:24, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
Yes.
Perhaps this is because some/most/all of us are imagining DD kicking
HHH off for the first time (as suggested by the source code he posts
here), whereas Mr Olcott is imagining HHH kicking DD off for the first
time (as suggested by the source code he has tucked away on the Web).
This would explain why he sets so little (and we set so much) store by
DD's return value.
The problem seems to be that no one ever bothers
to carefully study all of the words that I said.
They only glance at a couple of words then leap
to an incorrect conclusion.
When I prove that their assumptions are false
no one ever notices any of these words.
I am correcting an erroneous aspect of the theory
of computation. All deciders must only compute the
mapping from their finite string input. Anything that
is not a finite string input is outside of the scope
of any decider.
M.H applied to ⟨M⟩ ⟨M⟩ does correctly report on
the behavior of its actual input: M applied to ⟨M⟩
is not an actual input to M.H.
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
(b) M invokes M.H ⟨M⟩ ⟨M⟩
(c) M.H simulates ⟨M⟩ ⟨M⟩
then M.H ⟨M⟩ ⟨M⟩ transitions to M.qn causing M
applied to ⟨M⟩ halt
On 8/15/2025 3:59 AM, Mikko wrote:
On 2025-08-14 17:20:43 +0000, olcott said:
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
No, I don't. That is too unimportant that I would bother
to verify whether it is true.
In any case, your "That would mean" is obviously false.
It proves that the input to HHH(DD) is non halting.
Halt deciders are only accountable for their inputs.
Halt deciders are NEVER accountable for NON-INPUTS.
On 8/14/2025 3:22 AM, Mikko wrote:
On 2025-08-13 15:00:31 +0000, olcott said:
On 8/13/2025 2:50 AM, Mikko wrote:
On 2025-08-12 14:38:32 +0000, olcott said:Counter-factual
On 8/12/2025 3:47 AM, Mikko wrote:
On 2025-08-11 14:34:50 +0000, olcott said:
So you understand that HHH(DD)==0 on the basis of the
behavior of DD correctly simulated by HHH?
No but on the basis of failure to simulate correctly the behavoiur >>>>>> of DD,
in particular the point where the HHH called by DD aborts its
simulation
and returns 0 to DD which then halts.
Can DDD emulated by HHH according to the semantics
of the x86 language reach its own emulated "ret"
instruction final halt state?
Yes, if the instructions in HHH are not simulated.
Indeed, your HHH is unable to do what it should do.
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
This is enough to match the:
*recursive simulation non-halting behavior pattern*
On 8/15/2025 7:27 AM, dbush wrote:
On 8/15/2025 8:24 AM, olcott wrote:
On 8/15/2025 4:01 AM, Mikko wrote:The machines that their inputs are defined to describe / specify
On 2025-08-14 17:18:19 +0000, olcott said:
On 8/14/2025 3:22 AM, Mikko wrote:
On 2025-08-13 15:00:31 +0000, olcott said:
On 8/13/2025 2:50 AM, Mikko wrote:
On 2025-08-12 14:38:32 +0000, olcott said:Counter-factual
On 8/12/2025 3:47 AM, Mikko wrote:
On 2025-08-11 14:34:50 +0000, olcott said:
So you understand that HHH(DD)==0 on the basis of the
behavior of DD correctly simulated by HHH?
No but on the basis of failure to simulate correctly the
behavoiur of DD,
in particular the point where the HHH called by DD aborts its >>>>>>>>>> simulation
and returns 0 to DD which then halts.
Can DDD emulated by HHH according to the semantics
of the x86 language reach its own emulated "ret"
instruction final halt state?
Yes, if the instructions in HHH are not simulated.
Indeed, your HHH is unable to do what it should do.
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
This is enough to match the:
*recursive simulation non-halting behavior pattern*
A direct execution of DD matches all patterns a partial simulation
does and more.
To call a pattern that a halting computation matches a "non-halting
behaviour pattern" is a lie.
Halt deciders are only accountable for
Why lie?
Halt deciders are only accountable for their inputs.
Halt deciders are NEVER accountable for NON-INPUTS.
On 8/15/2025 8:01 AM, dbush wrote:
Definitions matter. Just like a shape with straight sides is
not a circle, a Turing machine that doesn't meet the above
requirements is not a halt decider.
How about this one:
The area of a square circle is its radius multiplied
by the length of one of its four equal length sides
times π.
On 8/15/2025 8:01 AM, dbush wrote:
On 8/15/2025 8:51 AM, olcott wrote:
On 8/15/2025 7:41 AM, dbush wrote:
On 8/15/2025 8:29 AM, olcott wrote:
On 8/15/2025 7:27 AM, dbush wrote:The machines that their inputs are defined to describe / specify as
On 8/15/2025 8:24 AM, olcott wrote:
On 8/15/2025 4:01 AM, Mikko wrote:The machines that their inputs are defined to describe / specify
On 2025-08-14 17:18:19 +0000, olcott said:
On 8/14/2025 3:22 AM, Mikko wrote:
On 2025-08-13 15:00:31 +0000, olcott said:
On 8/13/2025 2:50 AM, Mikko wrote:
On 2025-08-12 14:38:32 +0000, olcott said:Counter-factual
On 8/12/2025 3:47 AM, Mikko wrote:
On 2025-08-11 14:34:50 +0000, olcott said:
So you understand that HHH(DD)==0 on the basis of the >>>>>>>>>>>>>>> behavior of DD correctly simulated by HHH?
No but on the basis of failure to simulate correctly the >>>>>>>>>>>>>> behavoiur of DD,
in particular the point where the HHH called by DD aborts >>>>>>>>>>>>>> its simulation
and returns 0 to DD which then halts.
Can DDD emulated by HHH according to the semantics
of the x86 language reach its own emulated "ret"
instruction final halt state?
Yes, if the instructions in HHH are not simulated.
Indeed, your HHH is unable to do what it should do.
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
This is enough to match the:
*recursive simulation non-halting behavior pattern*
A direct execution of DD matches all patterns a partial simulation >>>>>>>> does and more.
To call a pattern that a halting computation matches a "non-halting >>>>>>>> behaviour pattern" is a lie.
Halt deciders are only accountable for
Why lie?
Halt deciders are only accountable for
per the below requirements. If not, it's not a halt decider.
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes
the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
Swearing your allegiance to the infallible word of textbook
seems like blasphemy to me
Definitions matter. Just like a shape with straight sides is not a
circle, a Turing machine that doesn't meet the above requirements is
not a halt decider.
How about this one:
The area of a square circle is its radius multiplied
by the length of one of its four equal length sides
times π.
On 8/15/2025 3:59 AM, Mikko wrote:
On 2025-08-14 17:20:43 +0000, olcott said:
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
No, I don't. That is too unimportant that I would bother
to verify whether it is true.
In any case, your "That would mean" is obviously false.
It proves that the input to HHH(DD) is non halting.
Halt deciders are only accountable for their inputs.
Halt deciders are NEVER accountable for NON-INPUTS.
On 8/15/2025 4:01 AM, Mikko wrote:
On 2025-08-14 17:18:19 +0000, olcott said:
On 8/14/2025 3:22 AM, Mikko wrote:
On 2025-08-13 15:00:31 +0000, olcott said:
On 8/13/2025 2:50 AM, Mikko wrote:
On 2025-08-12 14:38:32 +0000, olcott said:Counter-factual
On 8/12/2025 3:47 AM, Mikko wrote:
On 2025-08-11 14:34:50 +0000, olcott said:
So you understand that HHH(DD)==0 on the basis of the
behavior of DD correctly simulated by HHH?
No but on the basis of failure to simulate correctly the behavoiur of DD,
in particular the point where the HHH called by DD aborts its simulation
and returns 0 to DD which then halts.
Can DDD emulated by HHH according to the semantics
of the x86 language reach its own emulated "ret"
instruction final halt state?
Yes, if the instructions in HHH are not simulated.
Indeed, your HHH is unable to do what it should do.
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
This is enough to match the:
*recursive simulation non-halting behavior pattern*
A direct execution of DD matches all patterns a partial simulation
does and more.
To call a pattern that a halting computation matches a "non-halting
behaviour pattern" is a lie.
Halt deciders are only accountable for their inputs.
Halt deciders are NEVER accountable for NON-INPUTS.
On 8/15/2025 3:59 AM, Mikko wrote:
On 2025-08-14 17:20:43 +0000, olcott said:
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
No, I don't. That is too unimportant that I would bother
to verify whether it is true.
In any case, your "That would mean" is obviously false.
It proves that the input to HHH(DD) is non halting.
Halt deciders are only accountable for their inputs.
Halt deciders are NEVER accountable for NON-INPUTS.
I will not proceed with you until after
you tell me your programming experience.
On 8/16/2025 2:43 AM, Mikko wrote:
On 2025-08-15 12:22:22 +0000, olcott said:
On 8/15/2025 3:59 AM, Mikko wrote:
On 2025-08-14 17:20:43 +0000, olcott said:
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
No, I don't. That is too unimportant that I would bother
to verify whether it is true.
In any case, your "That would mean" is obviously false.
It proves that the input to HHH(DD) is non halting.
No, it does not. The input to HHH(DD) is a byte string. The term
"non-halting" is not applicable to a byte string. It is only
applicable to the program that the byte string encodes, in this
case DD. That program is not non-halting.
The ONLY way to consistently measure the behavior that
the actual input actually specifies is the execution trace
of DD correctly simulated by HHH.
Halt deciders are only accountable for their inputs.
Halt deciders are NEVER accountable for NON-INPUTS.
The term "accountable" is only applicable to people. Halt deciders
are not people.
Deciders are required to derive the results specified
by their inputs as their design spec.
On 8/16/2025 3:58 AM, Fred. Zwarts wrote:
Op 15.aug.2025 om 14:22 schreef olcott:
On 8/15/2025 3:59 AM, Mikko wrote:
On 2025-08-14 17:20:43 +0000, olcott said:
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
No, I don't. That is too unimportant that I would bother
to verify whether it is true.
In any case, your "That would mean" is obviously false.
It proves that the input to HHH(DD) is non halting.
Halt deciders are only accountable for their inputs.
Halt deciders are NEVER accountable for NON-INPUTS.
As usual repeated incorrect/irrelevant claims without evidence.
The input is a DD that calls a HHH that (incorrectly) aborts after a
few cycles of recursive simulation then returns to DD after which DD
halts.
The DD that calls the hypothetical HHH that does not abort is a non-
input and therefore irrelevant.
I will not proceed with you until after
you tell me your programming experience.
When HHH is unable to simulate the input correctly up to its specified
end, it simply fails, where other simulators have no problem to reach
the final halt state specified in exactly the same input.
This proves that the INPUT specifies a halting program.
When HHH fails to see that, that is in no way a proof that the input
changed to a non-input.
Talking about NON-INPUTS is irrelevant here.
On 8/16/2025 7:05 AM, Richard Heathfield wrote:
On 16/08/2025 12:56, olcott wrote:
I will not proceed with you until after
you tell me your programming experience.
Sheer hypocrisy! This from the man that says DD is not an input into
HHH. You are in no position to make judgements about other people's
programming experience.
He is denigrating my work on the basis of his woeful
ignorance of basic programming concepts.
On 8/12/2025 2:50 PM, Kaz Kylheku wrote:
If you're trying to demonstrate your work using
stateful procedures, you must be explicit about
revealing the state, and ensure that two instances
of a computations which you are identifying as
being of the same computation have exactly the
same initial state, same inputs, and same subsequent
state transitions. You cannot call two different
computations with different state transitions "DD"
and claim they are the same.
So DD correctly emulated by HHH and the directly
executed DD() are two distinctly different entities.
Whereas DD correctly emulated by HHH1 and the directly
executed DD() are the same entity.
DD emulated by HHH emulates the initial sequence of
instructions of DD one more time that HHH1 does as
I have just proven again in another reply using DDD.
So DD correctly emulated by HHH and the directly
executed DD() are two distinctly different entities.
Whereas DD correctly emulated by HHH1 and the directly
executed DD() are the same entity.
On 8/16/2025 7:05 AM, Richard Heathfield wrote:
On 16/08/2025 12:56, olcott wrote:He is denigrating my work on the basis of his woeful ignorance of basic programming concepts.
I will not proceed with you until after you tell me your programming
experience.
Sheer hypocrisy! This from the man that says DD is not an input into
HHH. You are in no position to make judgements about other people's
programming experience.
On 8/16/2025 5:05 PM, Mr Flibble wrote:
On Sat, 16 Aug 2025 07:41:05 -0500, olcott wrote:
On 8/16/2025 7:05 AM, Richard Heathfield wrote:
On 16/08/2025 12:56, olcott wrote:He is denigrating my work on the basis of his woeful ignorance of basic
I will not proceed with you until after you tell me your programming >>>>> experience.
Sheer hypocrisy! This from the man that says DD is not an input into
HHH. You are in no position to make judgements about other people's
programming experience.
programming concepts.
Your work has no value (it is 22 years wasted effort) so of course it is
OK to denigrate it.
/Flibble
You have a clue, they didn't even have a clue.
On 8/16/2025 7:05 AM, Richard Heathfield wrote:
On 16/08/2025 12:56, olcott wrote:
I will not proceed with you until after
you tell me your programming experience.
Sheer hypocrisy! This from the man that says DD is not an input into
HHH. You are in no position to make judgements about other people's
programming experience.
He is denigrating my work on the basis of his woeful
ignorance of basic programming concepts.
On 8/12/2025 2:50 PM, Kaz Kylheku wrote:
If you're trying to demonstrate your work using
stateful procedures, you must be explicit about
revealing the state, and ensure that two instances
of a computations which you are identifying as
being of the same computation have exactly the
same initial state, same inputs, and same subsequent
state transitions. You cannot call two different
computations with different state transitions "DD"
and claim they are the same.
So DD correctly emulated by HHH and the directly
executed DD() are two distinctly different entities.
Whereas DD correctly emulated by HHH1 and the directly
executed DD() are the same entity.
DD emulated by HHH emulates the initial sequence of
instructions of DD one more time that HHH1 does as
I have just proven again in another reply using DDD.
On 8/16/2025 3:58 AM, Fred. Zwarts wrote:
Op 15.aug.2025 om 14:22 schreef olcott:
On 8/15/2025 3:59 AM, Mikko wrote:
On 2025-08-14 17:20:43 +0000, olcott said:
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
No, I don't. That is too unimportant that I would bother
to verify whether it is true.
In any case, your "That would mean" is obviously false.
It proves that the input to HHH(DD) is non halting.
Halt deciders are only accountable for their inputs.
Halt deciders are NEVER accountable for NON-INPUTS.
As usual repeated incorrect/irrelevant claims without evidence.
The input is a DD that calls a HHH that (incorrectly) aborts after a
few cycles of recursive simulation then returns to DD after which DD
halts.
The DD that calls the hypothetical HHH that does not abort is a non-
input and therefore irrelevant.
I will not proceed with you until after
you tell me your programming experience.
When HHH is unable to simulate the input correctly up to its specified
end, it simply fails, where other simulators have no problem to reach
the final halt state specified in exactly the same input.
This proves that the INPUT specifies a halting program.
When HHH fails to see that, that is in no way a proof that the input
changed to a non-input.
Talking about NON-INPUTS is irrelevant here.
Op 16.aug.2025 om 13:56 schreef olcott:
I will not proceed with you until after
you tell me your programming experience.
Irrelevant change of subject that I will not tolerate.
My experience is irrelevant.
The fact that you cannot find a counter argument is relevant.
On 8/16/2025 2:43 AM, Mikko wrote:
On 2025-08-15 12:22:22 +0000, olcott said:The ONLY way to consistently measure the behavior that the actual input actually specifies is the execution trace of DD correctly simulated by
On 8/15/2025 3:59 AM, Mikko wrote:
On 2025-08-14 17:20:43 +0000, olcott said:
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion of recursive
emulation is incomprehensibly more difficult to understand that
ordinary recursion seems absurd unless the respondent has no idea >>>>>>> what ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating DD that calls
HHH(DD) that begins simulating DD that calls HHH(DD) again.
No, I don't. That is too unimportant that I would bother to verify
whether it is true.
In any case, your "That would mean" is obviously false.
It proves that the input to HHH(DD) is non halting.
No, it does not. The input to HHH(DD) is a byte string. The term
"non-halting" is not applicable to a byte string. It is only applicable
to the program that the byte string encodes, in this case DD. That
program is not non-halting.
HHH.
On 8/16/2025 2:43 AM, Mikko wrote:
On 2025-08-15 12:22:22 +0000, olcott said:
On 8/15/2025 3:59 AM, Mikko wrote:
On 2025-08-14 17:20:43 +0000, olcott said:
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
No, I don't. That is too unimportant that I would bother
to verify whether it is true.
In any case, your "That would mean" is obviously false.
It proves that the input to HHH(DD) is non halting.
No, it does not. The input to HHH(DD) is a byte string. The term
"non-halting" is not applicable to a byte string. It is only
applicable to the program that the byte string encodes, in this
case DD. That program is not non-halting.
The ONLY way to consistently measure the behavior that
the actual input actually specifies is the execution trace
of DD correctly simulated by HHH.
Halt deciders are only accountable for their inputs.
Halt deciders are NEVER accountable for NON-INPUTS.
The term "accountable" is only applicable to people. Halt deciders
are not people.
Deciders are required to derive the results specified
by their inputs as their design spec.
On 8/17/2025 3:53 AM, Mikko wrote:Nope, it would be the same as HHH1 simulating DD. Now if DD called HHH1,
A proof of non-halting is a proof that the full trace of the executionDD correctly and completely simulated by HHH would be infinitely long.
is infinitely long.
On 8/17/2025 11:16 AM, joes wrote:That’s a different DD.
Am Sun, 17 Aug 2025 10:39:31 -0500 schrieb olcott:If HHH(DD) never aborted the simulation of its input then the fact that HHH1(DD), DD() and HHH(DD) never stop running proves that HHH(DD)==0 is correct.
On 8/17/2025 3:53 AM, Mikko wrote:Nope, it would be the same as HHH1 simulating DD. Now if DD called
A proof of non-halting is a proof that the full trace of theDD correctly and completely simulated by HHH would be infinitely long.
execution is infinitely long.
HHH1, *that* would run forever; but it doesn’t. And HHH doesn’t
simulate completely anyway, so it’s moot to talk about a different DD.
On 8/17/2025 11:03 AM, dbush wrote:
On 8/17/2025 9:31 AM, olcott wrote:
On 8/17/2025 1:47 AM, joes wrote:
Am Sat, 16 Aug 2025 07:15:25 -0500 schrieb olcott:
On 8/16/2025 2:43 AM, Mikko wrote:
On 2025-08-15 12:22:22 +0000, olcott said:The ONLY way to consistently measure the behavior that the actual
On 8/15/2025 3:59 AM, Mikko wrote:
On 2025-08-14 17:20:43 +0000, olcott said:
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion of recursive >>>>>>>>>>> emulation is incomprehensibly more difficult to understand that >>>>>>>>>>> ordinary recursion seems absurd unless the respondent has no >>>>>>>>>>> idea
what ordinary recursion is.
As far as I have seen, there is only one participant in these >>>>>>>>>> discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating DD that calls >>>>>>>>> HHH(DD) that begins simulating DD that calls HHH(DD) again.
No, I don't. That is too unimportant that I would bother to verify >>>>>>>> whether it is true.
In any case, your "That would mean" is obviously false.
It proves that the input to HHH(DD) is non halting.
No, it does not. The input to HHH(DD) is a byte string. The term
"non-halting" is not applicable to a byte string. It is only
applicable
to the program that the byte string encodes, in this case DD. That >>>>>> program is not non-halting.
input
actually specifies is the execution trace of DD correctly simulated by >>>>> HHH.
So when I take this input, the description of DD, and try to execute
it as code, it specifies the wrong behaviour?
If we remove the use of static data then DD()
never stops running.
And therefore HHH(DD) fails to return.
If it never stops running
then we can see that it is decidable as non-halting.
But since HHH(DD) now doesn't return you can't get the answer.
Six outside observers did see that HHH(DD)==0 is correct.
That is a great improvement over both [halts] and [does not halt]
are the wrong answer.
On 8/17/2025 1:47 AM, joes wrote:
Am Sat, 16 Aug 2025 07:15:25 -0500 schrieb olcott:
On 8/16/2025 2:43 AM, Mikko wrote:
On 2025-08-15 12:22:22 +0000, olcott said:The ONLY way to consistently measure the behavior that the actual input
On 8/15/2025 3:59 AM, Mikko wrote:
On 2025-08-14 17:20:43 +0000, olcott said:
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion of recursive >>>>>>>>> emulation is incomprehensibly more difficult to understand that >>>>>>>>> ordinary recursion seems absurd unless the respondent has no idea >>>>>>>>> what ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating DD that calls >>>>>>> HHH(DD) that begins simulating DD that calls HHH(DD) again.
No, I don't. That is too unimportant that I would bother to verify >>>>>> whether it is true.
In any case, your "That would mean" is obviously false.
It proves that the input to HHH(DD) is non halting.
No, it does not. The input to HHH(DD) is a byte string. The term
"non-halting" is not applicable to a byte string. It is only applicable >>>> to the program that the byte string encodes, in this case DD. That
program is not non-halting.
actually specifies is the execution trace of DD correctly simulated by
HHH.
So when I take this input, the description of DD, and try to execute
it as code, it specifies the wrong behaviour?
If we remove the use of static data then DD()
never stops running. If it never stops running
then we can see that it is decidable as non-halting.
This is much more progress than anyone else has
ever made on the halting problem.
Mike said that there is a way that I can achieve
the same result as the HHH with static data without
static data. I could never understand his method.
I still envision the static data as possibly correct
because when HHH simulates itself simulating DD
this is still part of the same computation sharing
data with itself. My code is analogous to a master
UTM sharing a portion of its own tape with its slave
UTMs.
On 8/17/2025 3:53 AM, Mikko wrote:
On 2025-08-16 12:15:25 +0000, olcott said:
On 8/16/2025 2:43 AM, Mikko wrote:
On 2025-08-15 12:22:22 +0000, olcott said:
On 8/15/2025 3:59 AM, Mikko wrote:
On 2025-08-14 17:20:43 +0000, olcott said:
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
No, I don't. That is too unimportant that I would bother
to verify whether it is true.
In any case, your "That would mean" is obviously false.
It proves that the input to HHH(DD) is non halting.
No, it does not. The input to HHH(DD) is a byte string. The term
"non-halting" is not applicable to a byte string. It is only
applicable to the program that the byte string encodes, in this
case DD. That program is not non-halting.
The ONLY way to consistently measure the behavior that
the actual input actually specifies is the execution trace
of DD correctly simulated by HHH.
No, that is neither the only nor another way. The measure of the
behaviour of the behaviour DD specifies is the trace of the
execution of DD.
That is not the behavior of the actual input to HHH.
A proof of non-halting is a proof that the full
trace of the execution is infinitely long.
DD correctly and completely simulated by HHH would be infinitely long.
Halt deciders are only accountable for their inputs.
Halt deciders are NEVER accountable for NON-INPUTS.
The term "accountable" is only applicable to people. Halt deciders
are not people.
Deciders are required to derive the results specified
by their inputs as their design spec.
Deciders are required to return "yes" or "no" that satisfies their
specified requirements.
on the basis of computing this value from their actual inputs.
They can safely ignore everything else in the universe.
Partial deciders are permitted to return
other values and to run forever.
On 8/17/2025 11:16 AM, joes wrote:
Am Sun, 17 Aug 2025 10:39:31 -0500 schrieb olcott:
On 8/17/2025 3:53 AM, Mikko wrote:Nope, it would be the same as HHH1 simulating DD. Now if DD called HHH1,
A proof of non-halting is a proof that the full trace of the execution >>>> is infinitely long.DD correctly and completely simulated by HHH would be infinitely long.
*that* would run forever; but it doesn’t. And HHH doesn’t simulate
completely anyway, so it’s moot to talk about a different DD.
If HHH(DD) never aborted the simulation of its input
then the fact that HHH1(DD), DD() and HHH(DD) never
stop running proves that HHH(DD)==0 is correct.
On 8/17/2025 1:11 PM, joes wrote:
Am Sun, 17 Aug 2025 11:34:11 -0500 schrieb olcott:
On 8/17/2025 11:16 AM, joes wrote:That’s a different DD.
Am Sun, 17 Aug 2025 10:39:31 -0500 schrieb olcott:HHH1(DD), DD() and HHH(DD) never stop running proves that HHH(DD)==0 is
On 8/17/2025 3:53 AM, Mikko wrote:HHH1, *that* would run forever; but it doesn’t. And HHH doesn’t
A proof of non-halting is a proof that the full trace of theDD correctly and completely simulated by HHH would be infinitely long. >>>> Nope, it would be the same as HHH1 simulating DD. Now if DD called
execution is infinitely long.
simulate completely anyway, so it’s moot to talk about a different DD. >>> If HHH(DD) never aborted the simulation of its input then the fact that
correct.
Its the exact same DD and the exact same HHH except
that HHH never aborts conclusively proving that
HHH(DD)==0 is correct.
In both cases an HHH that aborts after N steps
(where N is any natural number) and HHH that
never aborts are exactly the same in that DD
correctly simulated by HHH cannot possibly reach
its own simulated "return" instruction final halt
state.
The other differences are of no consequence
because these two cases are exactly the same
by the only measure that matters.
HHH aborts at the first repetition and DD calls it. If you create the
modified HHH2 that aborts after the second repetition and run the
original DD (that still calls the immediately-aborting HHH) through it,
it will halt without aborting. Of course, running DD2 (which calls HHH2)
on HHH2 will be aborted, but that is a different program from DD.
(HHH(DD2) will also abort.) Now you can keep creating simulators that
abort after more and more levels of simulation and corresponding DDn’s
and all of them will be aborted early, but all „smaller” DDn’s will
finish.
On 8/17/2025 1:11 AM, Fred. Zwarts wrote:
Op 16.aug.2025 om 14:41 schreef olcott:
On 8/16/2025 7:05 AM, Richard Heathfield wrote:
On 16/08/2025 12:56, olcott wrote:
I will not proceed with you until after
you tell me your programming experience.
Sheer hypocrisy! This from the man that says DD is not an input into
HHH. You are in no position to make judgements about other people's
programming experience.
He is denigrating my work on the basis of his woeful
ignorance of basic programming concepts.
As usual incorrect claims without evidence.
Whenever I provide complete proof you say
that this is no evidence.
I proved your errors and you have no counter argument left.
You proved much more deeply ingrained ignorance
than anyone else here. When I correct your errors
you ignore these corrections.
You try to hide that by changing the subject.
On 8/12/2025 2:50 PM, Kaz Kylheku wrote:
;
If you're trying to demonstrate your work using
stateful procedures, you must be explicit about
revealing the state, and ensure that two instances
of a computations which you are identifying as
being of the same computation have exactly the
same initial state, same inputs, and same subsequent
state transitions. You cannot call two different
computations with different state transitions "DD"
and claim they are the same.
;
So DD correctly emulated by HHH and the directly
executed DD() are two distinctly different entities.
Whereas DD correctly emulated by HHH1 and the directly
executed DD() are the same entity.
DD emulated by HHH emulates the initial sequence of
instructions of DD one more time that HHH1 does as
I have just proven again in another reply using DDD.
On 8/17/2025 1:11 PM, joes wrote:Exactly, they are not the same. And your HHH does abort, as does HHH1.
Am Sun, 17 Aug 2025 11:34:11 -0500 schrieb olcott:
On 8/17/2025 11:16 AM, joes wrote:
Am Sun, 17 Aug 2025 10:39:31 -0500 schrieb olcott:
Its the exact same DD and the exact same HHH except that HHH neverThat’s a different DD.If HHH(DD) never aborted the simulation of its input then the factDD correctly and completely simulated by HHH would be infinitelyNope, it would be the same as HHH1 simulating DD. Now if DD called
long.
HHH1, *that* would run forever; but it doesn’t. And HHH doesn’t
simulate completely anyway, so it’s moot to talk about a different
DD.
that HHH1(DD), DD() and HHH(DD) never stop running proves that
HHH(DD)==0 is correct.
aborts conclusively proving that HHH(DD)==0 is correct.
In both cases an HHH that aborts after N steps (where N is any natural number) and HHH that never aborts are exactly the same in that DDThere is only one HHH which aborts after 1 recursive simulation.
correctly simulated by HHH cannot possibly reach its own simulated
"return" instruction final halt state.
The other differences are of no consequence because these two cases are exactly the same by the only measure that matters.You haven’t mentioned that your measure allows templates/incomplete functions/changing the input/call-by-name.
Pearls before swine.HHH aborts at the first repetition and DD calls it. If you create the
modified HHH2 that aborts after the second repetition and run the
original DD (that still calls the immediately-aborting HHH) through it,
it will halt without aborting. Of course, running DD2 (which calls
HHH2) on HHH2 will be aborted, but that is a different program from DD.
(HHH(DD2) will also abort.) Now you can keep creating simulators that
abort after more and more levels of simulation and corresponding DDn’s
and all of them will be aborted early, but all „smaller” DDn’s will
finish.
On 8/17/25 5:52 PM, olcott wrote:
People have been arguing that an inconsequential
difference is consequential knowing that it is not,
perpetually.
No, the fact that HHH looks at code that isn't part of the
'input" is a major failing.
On 18/08/2025 01:41, Richard Damon wrote:
On 8/17/25 5:52 PM, olcott wrote:
<snip>
People have been arguing that an inconsequential
difference is consequential knowing that it is not,
perpetually.
No, the fact that HHH looks at code that isn't part of the 'input" is
a major failing.
Not to mention its failure to look at code that /is/ part of the input.
On 8/17/2025 4:45 PM, joes wrote:
Am Sun, 17 Aug 2025 13:21:29 -0500 schrieb olcott:
On 8/17/2025 1:11 PM, joes wrote:Exactly, they are not the same. And your HHH does abort, as does HHH1.
Am Sun, 17 Aug 2025 11:34:11 -0500 schrieb olcott:
On 8/17/2025 11:16 AM, joes wrote:
Am Sun, 17 Aug 2025 10:39:31 -0500 schrieb olcott:
Its the exact same DD and the exact same HHH except that HHH neverThat’s a different DD.If HHH(DD) never aborted the simulation of its input then the factDD correctly and completely simulated by HHH would be infinitely >>>>>>> long.Nope, it would be the same as HHH1 simulating DD. Now if DD called >>>>>> HHH1, *that* would run forever; but it doesn’t. And HHH doesn’t >>>>>> simulate completely anyway, so it’s moot to talk about a different >>>>>> DD.
that HHH1(DD), DD() and HHH(DD) never stop running proves that
HHH(DD)==0 is correct.
aborts conclusively proving that HHH(DD)==0 is correct.
In both cases an HHH that aborts after N steps (where N is any naturalThere is only one HHH which aborts after 1 recursive simulation.
number) and HHH that never aborts are exactly the same in that DD
correctly simulated by HHH cannot possibly reach its own simulated
"return" instruction final halt state.
You mean HHH_n. You could actually implement them, with a counter
instead of a flag! There is also only one DD, which calls the only HHH.
It can be completely simulated by HHH2, HHH3, …
The other differences are of no consequence because these two cases are
exactly the same by the only measure that matters.
You haven’t mentioned that your measure allows templates/incomplete
functions/changing the input/call-by-name.
*Hence you dodge the point*
People have been arguing that an inconsequential
difference is consequential knowing that it is not,
perpetually.
Pearls before swine.HHH aborts at the first repetition and DD calls it. If you create the
modified HHH2 that aborts after the second repetition and run the
original DD (that still calls the immediately-aborting HHH) through it, >>>> it will halt without aborting. Of course, running DD2 (which calls
HHH2) on HHH2 will be aborted, but that is a different program from DD. >>>> (HHH(DD2) will also abort.) Now you can keep creating simulators that
abort after more and more levels of simulation and corresponding DDn’s >>>> and all of them will be aborted early, but all „smaller” DDn’s will >>>> finish.
Op 17.aug.2025 om 15:34 schreef olcott:
If you tell me your experience and you have very
little I will focus my words on the experience
that you do have and keep talking to you. If you
do not then the evidence that I have seen indicates
that yo are mostly clueless about these things
and I will stop talking to you.
One of your huge mistakes is that you think that logic is based
on authority. It is not. It is based on logic reasoning. If I
prove you wrong you cannot ignore it with the reason that you
don't understand my authority.
On 8/17/2025 1:09 AM, Fred. Zwarts wrote:
Op 16.aug.2025 om 13:56 schreef olcott:
On 8/16/2025 3:58 AM, Fred. Zwarts wrote:
Op 15.aug.2025 om 14:22 schreef olcott:
On 8/15/2025 3:59 AM, Mikko wrote:
On 2025-08-14 17:20:43 +0000, olcott said:
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
No, I don't. That is too unimportant that I would bother
to verify whether it is true.
In any case, your "That would mean" is obviously false.
It proves that the input to HHH(DD) is non halting.
Halt deciders are only accountable for their inputs.
Halt deciders are NEVER accountable for NON-INPUTS.
As usual repeated incorrect/irrelevant claims without evidence.
The input is a DD that calls a HHH that (incorrectly) aborts after a
few cycles of recursive simulation then returns to DD after which DD
halts.
The DD that calls the hypothetical HHH that does not abort is a non-
input and therefore irrelevant.
I will not proceed with you until after
you tell me your programming experience.
Irrelevant change of subject that I will not tolerate.
My experience is irrelevant.
The fact that you cannot find a counter argument is relevant.
If you tell me your experience and you have very
little I will focus my words on the experience
that you do have and keep talking to you. If you
do not then the evidence that I have seen indicates
that yo are mostly clueless about these things
and I will stop talking to you.
When HHH is unable to simulate the input correctly up to its
specified end, it simply fails, where other simulators have no
problem to reach the final halt state specified in exactly the same
input.
This proves that the INPUT specifies a halting program.
When HHH fails to see that, that is in no way a proof that the input
changed to a non-input.
Talking about NON-INPUTS is irrelevant here.
On 8/17/2025 1:11 AM, Fred. Zwarts wrote:
Op 16.aug.2025 om 14:41 schreef olcott:
On 8/16/2025 7:05 AM, Richard Heathfield wrote:
On 16/08/2025 12:56, olcott wrote:
I will not proceed with you until after
you tell me your programming experience.
Sheer hypocrisy! This from the man that says DD is not an input into
HHH. You are in no position to make judgements about other people's
programming experience.
He is denigrating my work on the basis of his woeful
ignorance of basic programming concepts.
As usual incorrect claims without evidence.
Whenever I provide complete proof you say
that this is no evidence.
I proved your errors and you have no counter argument left.
You proved much more deeply ingrained ignorance
than anyone else here. When I correct your errors
you ignore these corrections.
You try to hide that by changing the subject.
On 8/12/2025 2:50 PM, Kaz Kylheku wrote:
;
If you're trying to demonstrate your work using
stateful procedures, you must be explicit about
revealing the state, and ensure that two instances
of a computations which you are identifying as
being of the same computation have exactly the
same initial state, same inputs, and same subsequent
state transitions. You cannot call two different
computations with different state transitions "DD"
and claim they are the same.
;
So DD correctly emulated by HHH and the directly
executed DD() are two distinctly different entities.
Whereas DD correctly emulated by HHH1 and the directly
executed DD() are the same entity.
DD emulated by HHH emulates the initial sequence of
instructions of DD one more time that HHH1 does as
I have just proven again in another reply using DDD.
On 8/17/2025 4:45 PM, joes wrote:This would help your demonstration.
Am Sun, 17 Aug 2025 13:21:29 -0500 schrieb olcott:
On 8/17/2025 1:11 PM, joes wrote:
Am Sun, 17 Aug 2025 11:34:11 -0500 schrieb olcott:
On 8/17/2025 11:16 AM, joes wrote:
Am Sun, 17 Aug 2025 10:39:31 -0500 schrieb olcott:
Exactly, they are not the same. And your HHH does abort, as does HHH1.Its the exact same DD and the exact same HHH except that HHH neverIf HHH(DD) never aborted the simulation of its input then the factThat’s a different DD.
that HHH1(DD), DD() and HHH(DD) never stop running proves that
HHH(DD)==0 is correct.
aborts conclusively proving that HHH(DD)==0 is correct.
In both cases an HHH that aborts after N steps (where N is any naturalThere is only one HHH which aborts after 1 recursive simulation.
number) and HHH that never aborts are exactly the same in that DD
correctly simulated by HHH cannot possibly reach its own simulated
"return" instruction final halt state.
You mean HHH_n. You could actually implement them, with a counter
instead of a flag! There is also only one DD, which calls the only HHH.
It can be completely simulated by HHH2, HHH3, …
What point? That HHH_n aborts DD_n? You need to make clear that you*Hence you dodge the point*The other differences are of no consequence because these two casesYou haven’t mentioned that your measure allows templates/incomplete
are exactly the same by the only measure that matters.
functions/changing the input/call-by-name.
People have been arguing that an inconsequential difference is
consequential knowing that it is not, perpetually.
On 8/17/2025 3:53 AM, Mikko wrote:
On 2025-08-16 12:15:25 +0000, olcott said:
On 8/16/2025 2:43 AM, Mikko wrote:
On 2025-08-15 12:22:22 +0000, olcott said:
On 8/15/2025 3:59 AM, Mikko wrote:
On 2025-08-14 17:20:43 +0000, olcott said:
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
As far as I have seen, there is only one participant in these
discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
No, I don't. That is too unimportant that I would bother
to verify whether it is true.
In any case, your "That would mean" is obviously false.
It proves that the input to HHH(DD) is non halting.
No, it does not. The input to HHH(DD) is a byte string. The term
"non-halting" is not applicable to a byte string. It is only
applicable to the program that the byte string encodes, in this
case DD. That program is not non-halting.
The ONLY way to consistently measure the behavior that
the actual input actually specifies is the execution trace
of DD correctly simulated by HHH.
No, that is neither the only nor another way. The measure of the
behaviour of the behaviour DD specifies is the trace of the
execution of DD.
That is not the behavior of the actual input to HHH.
A proof of non-halting is a proof that the full
trace of the execution is infinitely long.
DD correctly and completely simulated by HHH would be infinitely long.
On 2025-08-17 15:39:31 +0000, olcott said:
DD correctly and completely simulated by HHH would be
infinitely long.
The input to HHH(DD) specifies an input that halts after a finite
number of steps.
On 8/18/2025 2:40 AM, Fred. Zwarts wrote:
One of your huge mistakes is that you think that logic is based
on authority. It is not. It is based on logic reasoning. If I
prove you wrong you cannot ignore it with the reason that you
don't understand my authority.
The "logic" that you use is based on a lack
of an understanding of computer programming.
On 8/18/2025 5:07 AM, Richard Heathfield wrote:
On 18/08/2025 10:27, Mikko wrote:
On 2025-08-17 15:39:31 +0000, olcott said:
<snip>
DD correctly and completely simulated by HHH would be
infinitely long.
The input to HHH(DD) specifies an input that halts after a finite
number of steps.
For that to be true, HHH (which is part of the behaviour
encoded in DD) is required to abort its simulation before being
able to fully explore the behaviour encoded by DD.
Inspection of DD shows that DD cannot terminate until HHH
returns, and that its behaviour thereafter depends entirely on
the value that HHH yields.
When 0 to ∞ instructions of DD are correctly
simulated by HHH no DD reaches its own simulated
"return" statement final halt state.
On 8/18/2025 4:27 AM, Mikko wrote:
On 2025-08-17 15:39:31 +0000, olcott said:The encoded behavior OF THE ACTUAL INPUT NOT ONE DAMN THING ELSE.
On 8/17/2025 3:53 AM, Mikko wrote:
On 2025-08-16 12:15:25 +0000, olcott said:
On 8/16/2025 2:43 AM, Mikko wrote:
On 2025-08-15 12:22:22 +0000, olcott said:
On 8/15/2025 3:59 AM, Mikko wrote:
On 2025-08-14 17:20:43 +0000, olcott said:
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion of recursive >>>>>>>>>>> emulation is incomprehensibly more difficult to understand >>>>>>>>>>> that ordinary recursion seems absurd unless the respondent has >>>>>>>>>>> no idea what ordinary recursion is.
As far as I have seen, there is only one participant in these >>>>>>>>>> discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating DD that >>>>>>>>> calls HHH(DD) that begins simulating DD that calls HHH(DD)
again.
No, I don't. That is too unimportant that I would bother to
verify whether it is true.
In any case, your "That would mean" is obviously false.
It proves that the input to HHH(DD) is non halting.
No, it does not. The input to HHH(DD) is a byte string. The term
"non-halting" is not applicable to a byte string. It is only
applicable to the program that the byte string encodes, in this
case DD. That program is not non-halting.
The ONLY way to consistently measure the behavior that the actual
input actually specifies is the execution trace of DD correctly
simulated by HHH.
No, that is neither the only nor another way. The measure of the
behaviour of the behaviour DD specifies is the trace of the execution
of DD.
That is not the behavior of the actual input to HHH.
The input to HHH is a data. Data has no behaviour. But the input to HHH
encodes a behaviour. A halt decider is required to tell whether the
encoded behaviour halts after finite number of steps or can be
continued beyond any limit.
The encoded behavior of the actual input can only be correctly measured
by DD correctly simulated by HHH.
After I tell you this 50 f-cking times you never hear it even one damnA proof of non-halting is a proof that the full trace of the
execution is infinitely long.
DD correctly and completely simulated by HHH would be infinitely long.
The input to HHH(DD) specifies an input that halts after a finite
number of steps.
time.
DD correctly simulated by HHH cannot possibly reach its own simulated "return" statement final halt state.
That it stops running when its simulation is aborted does not make one f-cking bit of difference to this. Stopping running and halting are two different things.
On 8/18/2025 12:59 PM, Mr Flibble wrote:
On Mon, 18 Aug 2025 12:53:00 -0500, olcott wrote:
On 8/18/2025 4:27 AM, Mikko wrote:
On 2025-08-17 15:39:31 +0000, olcott said:The encoded behavior OF THE ACTUAL INPUT NOT ONE DAMN THING ELSE.
On 8/17/2025 3:53 AM, Mikko wrote:
On 2025-08-16 12:15:25 +0000, olcott said:
On 8/16/2025 2:43 AM, Mikko wrote:
On 2025-08-15 12:22:22 +0000, olcott said:
On 8/15/2025 3:59 AM, Mikko wrote:
On 2025-08-14 17:20:43 +0000, olcott said:
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion of >>>>>>>>>>>>> recursive emulation is incomprehensibly more difficult to >>>>>>>>>>>>> understand that ordinary recursion seems absurd unless the >>>>>>>>>>>>> respondent has no idea what ordinary recursion is.
As far as I have seen, there is only one participant in these >>>>>>>>>>>> discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating DD that >>>>>>>>>>> calls HHH(DD) that begins simulating DD that calls HHH(DD) >>>>>>>>>>> again.
No, I don't. That is too unimportant that I would bother to >>>>>>>>>> verify whether it is true.
In any case, your "That would mean" is obviously false.
It proves that the input to HHH(DD) is non halting.
No, it does not. The input to HHH(DD) is a byte string. The term >>>>>>>> "non-halting" is not applicable to a byte string. It is only
applicable to the program that the byte string encodes, in this >>>>>>>> case DD. That program is not non-halting.
The ONLY way to consistently measure the behavior that the actual >>>>>>> input actually specifies is the execution trace of DD correctly
simulated by HHH.
No, that is neither the only nor another way. The measure of the
behaviour of the behaviour DD specifies is the trace of the
execution of DD.
That is not the behavior of the actual input to HHH.
The input to HHH is a data. Data has no behaviour. But the input to
HHH encodes a behaviour. A halt decider is required to tell whether
the encoded behaviour halts after finite number of steps or can be
continued beyond any limit.
The encoded behavior of the actual input can only be correctly
measured by DD correctly simulated by HHH.
After I tell you this 50 f-cking times you never hear it even one damnA proof of non-halting is a proof that the full trace of the
execution is infinitely long.
DD correctly and completely simulated by HHH would be infinitely
long.
The input to HHH(DD) specifies an input that halts after a finite
number of steps.
time.
DD correctly simulated by HHH cannot possibly reach its own simulated
"return" statement final halt state.
That it stops running when its simulation is aborted does not make one
f-cking bit of difference to this. Stopping running and halting are
two different things.
And so HHH(DD) reports non-halting to directly executed DD() which then
halts confirming the Halting Problem is undecidable.
/Flibble
Turing machine deciders only compute the mapping from their inputs...
Otherwise HHH is not any kind of decider at all. The directly executed
DD() is the caller of HHH()
thus not any kind of input at all.
On 8/18/2025 4:27 AM, Mikko wrote:
The input to HHH is a data. Data has no behaviour. But the
input to
HHH encodes a behaviour. A halt decider is required to tell
whether
the encoded behaviour halts after finite number of steps or can be
continued beyond any limit.
The encoded behavior OF THE ACTUAL INPUT NOT
ONE DAMN THING ELSE.
The encoded behavior of the actual input can
only be correctly measured by DD correctly
simulated by HHH.
The input to HHH(DD) specifies an input that halts after a finite
number of steps.
After I tell you this 50 f-cking times you never hear
it even one damn time.
DD correctly simulated by HHH cannot possibly reach
its own simulated "return" statement final halt state.
That it stops running when its simulation is aborted
does not make one f-cking bit of difference to this.
Stopping running and halting are two different things.
Otherwise HHH is not any kind of decider at all.
No halt decider can possibly report on
*the behavior of its caller*
On 8/18/2025 1:29 PM, Richard Heathfield wrote:
On 18/08/2025 18:53, olcott wrote:
The encoded behavior of the actual input can
only be correctly measured by DD correctly
simulated by HHH.
Well, that's clearly not true. *We have the source code!* We
can measure the encoded behaviour of DD by inspection.
And by inspection we can see that HHH is most definitely *not*
correctly simulating DD.
Only when one is too stupid to use the correct measure
of correct simulation (the semantics of the language).
People that are too stupid to understand what the term
"semantics" means even after they look it up will not
understand.
On 8/18/2025 2:12 PM, Richard Heathfield wrote:
On 18/08/2025 19:54, olcott wrote:
On 8/18/2025 1:29 PM, Richard Heathfield wrote:
On 18/08/2025 18:53, olcott wrote:
<snip>
Only when one is too stupid to use the correct measure of correctThe encoded behavior of the actual input can only be correctly
measured by DD correctly simulated by HHH.
Well, that's clearly not true. *We have the source code!* We can
measure the encoded behaviour of DD by inspection.
And by inspection we can see that HHH is most definitely *not*
correctly simulating DD.
simulation (the semantics of the language).
Ah, we're back to stupid, are we? Jolly good. But do *please* try to
grow up at some point.
If simulation is incapable of assessing a program's actual behaviour
when not being simulated, it's clearly not fit for purpose because it
isn't properly assessing the program's behaviour under normal
conditions, which is all we care about. It cannot therefore be
reasonably described as "correct".
People that are too stupid to understand what the term "semantics"
means even after they look it up will not understand.
DD is a C program. Therefore, the proper semantic arbiter is not x86
but ISO/IEC 9899. Indeed, given a suitable port of HHH, there's nothing
in principle to stop us running DD on any platform we like, and we
should look to C, not a specific architecture, to tell us what will
happen.
Under the rules of C, DD waits for a result from HHH before deciding
how to proceed.
Not at all. DD() never decides jack shit.
DD() does wait for a result from HHH(DD).
On 8/18/2025 1:32 PM, Richard Heathfield wrote:
On 18/08/2025 19:23, olcott wrote:
The directly executed DD() is the caller of HHH()
thus not any kind of input at all.
So why pass it as an argument?
You are too stupid
to understand that a finite
string and an executing process are not the same thing.
On 8/18/2025 1:56 PM, Richard Heathfield wrote:
On 18/08/2025 19:51, olcott wrote:Even the actual all knowing mind of God
<snip>
No halt decider can possibly report on
*the behavior of its caller*
If it existed, a *universal* halt decider could.
cannot report the area of any square circle.
Likewise universal Turing machines cannot
report on the behavior of their actual caller.
That is just not the way that reality actually works.
On 8/18/2025 2:12 PM, Richard Heathfield wrote:
Under the rules of C, DD waits for a result from HHH before
deciding how to proceed.
Not at all.
DD() never decides jack shit.
DD() does wait for a result from HHH(DD).
If you weren't clueless about programming
then
you would know that a decision is captured.
You assure us that HHH will return 0.
It is a matter of correct analytical proof
that the correct return value from HHH(DD)
is zero
based on the verified fact that DD
correctly simulated by HHH cannot possibly
reach its own simulated "return" statement
final halt state.
You seems to be either too stupid or insufficiently
honest to see this.
On 8/18/2025 12:41 PM, Richard Heathfield wrote:
On 18/08/2025 18:13, olcott wrote:
On 8/18/2025 2:40 AM, Fred. Zwarts wrote:
<snip>
One of your huge mistakes is that you think that logic is
based on authority. It is not. It is based on logic
reasoning. If I prove you wrong you cannot ignore it with the
reason that you don't understand my authority.
The "logic" that you use is based on a lack
of an understanding of computer programming.
I only know Fred from these hallowed halls, but from what I've
seen of it his understanding of computer programming seems
solid enough. I'd be more worried about a chap who claims to
understand C but who thinks that function pointer DD is a
different entity to function pointer DD.
When you change the words that I said and base a
rebuttal on these changed words this is known as
the strawman error of reasoning.
A pointer to the static string of machine code
is
not a pointer to a process that is currently executing.
On 8/18/2025 5:07 AM, Richard Heathfield wrote:You mean HHH_n and lower can’t simulate DDD_n and up, even though
On 18/08/2025 10:27, Mikko wrote:
When 0 to ∞ instructions of DD are correctly simulated by HHH no DDThe input to HHH(DD) specifies an input that halts after a finite
number of steps.
For that to be true, HHH (which is part of the behaviour encoded in DD)
is required to abort its simulation before being able to fully explore
the behaviour encoded by DD.
Inspection of DD shows that DD cannot terminate until HHH returns, and
that its behaviour thereafter depends entirely on the value that HHH
yields.
reaches its own simulated "return" statement final halt state.
Thus the differences between these different simulations has noTrue, but then we’re comparing the simulation of different programs
consequence on whether or not the DD of this DD/HHH pair correctly
simulated by its HHH reaches its own simulated "return" statement final
halt state.
On 8/18/2025 3:21 AM, joes wrote:Very courteous of you not to snip rebuttals.
Am Sun, 17 Aug 2025 16:52:02 -0500 schrieb olcott:
On 8/17/2025 4:45 PM, joes wrote:
Am Sun, 17 Aug 2025 13:21:29 -0500 schrieb olcott:
Its the exact same DD and the exact same HHH except that HHH neverExactly, they are not the same. And your HHH does abort, as does
aborts conclusively proving that HHH(DD)==0 is correct.
HHH1.
This would help your demonstration.In both cases an HHH that aborts after N steps (where N is anyThere is only one HHH which aborts after 1 recursive simulation.
natural number) and HHH that never aborts are exactly the same in
that DD correctly simulated by HHH cannot possibly reach its own
simulated "return" instruction final halt state.
You mean HHH_n. You could actually implement them, with a counter
instead of a flag! There is also only one DD, which calls the only
HHH.
It can be completely simulated by HHH2, HHH3, …
I specifically addressed that those DD’s are different programs.*The point that you dodged*What point? That HHH_n aborts DD_n? You need to make clear that you*Hence you dodge the point*The other differences are of no consequence because these two casesYou haven’t mentioned that your measure allows templates/incomplete
are exactly the same by the only measure that matters.
functions/changing the input/call-by-name.
People have been arguing that an inconsequential difference is
consequential knowing that it is not, perpetually.
consider DD the same even though it calls a modified HHH.
When 0 to ∞ instructions of DD are correctly simulated by HHH no DD
reaches its own simulated "return" statement final halt state.
Thus the differences between these different simulations has noSure, but we don’t care about other DD’s.
consequence on whether or not the DD of this DD/HHH pair correctly
simulated by its HHH reaches its own simulated "return" statement final
halt state.
HHH aborts at the first repetition and DD calls it. If you create the
modified HHH2 that aborts after the second repetition and run the
original DD (that still calls the immediately-aborting HHH) through it,
it will halt without aborting. Of course, running DD2 (which calls
HHH2) on HHH2 will be aborted, but that is a different program from DD.
(HHH(DD2) will also abort.) Now you can keep creating simulators that
abort after more and more levels of simulation and corresponding DDn’s
and all of them will be aborted early, but all „smaller” DDn’s will
finish.
Ah the appeal to authority error?
The decision was captured if he is too stupid
to notice this then he is too stupid.
On 8/18/2025 3:21 AM, joes wrote:
Am Sun, 17 Aug 2025 16:52:02 -0500 schrieb olcott:
On 8/17/2025 4:45 PM, joes wrote:This would help your demonstration.
Am Sun, 17 Aug 2025 13:21:29 -0500 schrieb olcott:
On 8/17/2025 1:11 PM, joes wrote:
Am Sun, 17 Aug 2025 11:34:11 -0500 schrieb olcott:
On 8/17/2025 11:16 AM, joes wrote:
Am Sun, 17 Aug 2025 10:39:31 -0500 schrieb olcott:
Exactly, they are not the same. And your HHH does abort, as does HHH1.Its the exact same DD and the exact same HHH except that HHH neverIf HHH(DD) never aborted the simulation of its input then the fact >>>>>>> that HHH1(DD), DD() and HHH(DD) never stop running proves thatThat’s a different DD.
HHH(DD)==0 is correct.
aborts conclusively proving that HHH(DD)==0 is correct.
In both cases an HHH that aborts after N steps (where N is any natural >>>>> number) and HHH that never aborts are exactly the same in that DDThere is only one HHH which aborts after 1 recursive simulation.
correctly simulated by HHH cannot possibly reach its own simulated
"return" instruction final halt state.
You mean HHH_n. You could actually implement them, with a counter
instead of a flag! There is also only one DD, which calls the only HHH. >>>> It can be completely simulated by HHH2, HHH3, …
What point? That HHH_n aborts DD_n? You need to make clear that you*Hence you dodge the point*The other differences are of no consequence because these two casesYou haven’t mentioned that your measure allows templates/incomplete
are exactly the same by the only measure that matters.
functions/changing the input/call-by-name.
People have been arguing that an inconsequential difference is
consequential knowing that it is not, perpetually.
consider DD the same even though it calls a modified HHH.
*The point that you dodged*
When 0 to ∞ instructions of DD are correctly
simulated by HHH no DD reaches its own simulated
"return" statement final halt state.
Thus the differences between these different simulations
has no consequence on whether or not the DD of this
DD/HHH pair correctly simulated by its HHH reaches
its own simulated "return" statement final halt state.
Deceptive people here have been arguing that the
differences are consequential knowing full well
that they are not.
HHH aborts at the first repetition and DD calls it. If you create the
modified HHH2 that aborts after the second repetition and run the
original DD (that still calls the immediately-aborting HHH) through
it, it will halt without aborting. Of course, running DD2 (which
calls HHH2) on HHH2 will be aborted, but that is a different program
from DD. (HHH(DD2) will also abort.) Now you can keep creating
simulators that abort after more and more levels of simulation and
corresponding DDn’s and all of them will be aborted early, but all
„smaller” DDn’s will finish.
On 8/18/2025 5:13 PM, Richard Heathfield wrote:
On 18/08/2025 22:51, olcott wrote:
<snip>
Ah the appeal to authority error?
What appeal, and what authority? All he said was that you may
have jumped to an erroneous conclusion.
The decision was captured if he is too stupid
to notice this then he is too stupid.
The only decision you've "captured" is the decision is that
HHH(DD) must return 0. Fine, so what's stopping HHH from
memoising that result, plugging it into DD, and continuing the
simulation?
Answer: nothing. HHH() is therefore not as complete as it sould
be, and therefore it fails to correctly simulate.
It is an easily verified fact that DD correctly
simulated by HHH cannot possibly reach its own
simulated "return" instruction final halt state
no matter WTF that HHH does.
Either you are too stupid to see that (others say
that you are not too stupid) or too dishonest to
acknowledge that.
On 8/18/2025 2:40 AM, Fred. Zwarts wrote:
Op 17.aug.2025 om 15:34 schreef olcott:
On 8/17/2025 1:09 AM, Fred. Zwarts wrote:
Op 16.aug.2025 om 13:56 schreef olcott:
On 8/16/2025 3:58 AM, Fred. Zwarts wrote:
Op 15.aug.2025 om 14:22 schreef olcott:
On 8/15/2025 3:59 AM, Mikko wrote:
On 2025-08-14 17:20:43 +0000, olcott said:
On 8/14/2025 3:24 AM, Mikko wrote:
On 2025-08-13 17:09:00 +0000, olcott said:
That everyone here seems to think that the notion
of recursive emulation is incomprehensibly more
difficult to understand that ordinary recursion
seems absurd unless the respondent has no idea
what ordinary recursion is.
As far as I have seen, there is only one participant in these >>>>>>>>>> discussions who seems to think so: Olcott.
*That would mean that you agree with this*
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
No, I don't. That is too unimportant that I would bother
to verify whether it is true.
In any case, your "That would mean" is obviously false.
It proves that the input to HHH(DD) is non halting.
Halt deciders are only accountable for their inputs.
Halt deciders are NEVER accountable for NON-INPUTS.
As usual repeated incorrect/irrelevant claims without evidence.
The input is a DD that calls a HHH that (incorrectly) aborts after >>>>>> a few cycles of recursive simulation then returns to DD after
which DD halts.
The DD that calls the hypothetical HHH that does not abort is a
non- input and therefore irrelevant.
I will not proceed with you until after
you tell me your programming experience.
Irrelevant change of subject that I will not tolerate.
My experience is irrelevant.
The fact that you cannot find a counter argument is relevant.
If you tell me your experience and you have very
little I will focus my words on the experience
that you do have and keep talking to you. If you
do not then the evidence that I have seen indicates
that yo are mostly clueless about these things
and I will stop talking to you.
One of your huge mistakes is that you think that logic is based on
authority. It is not. It is based on logic reasoning. If I prove you
wrong you cannot ignore it with the reason that you don't understand
my authority.
The "logic" that you use is based on a lack
of an understanding of computer programming.
When HHH is unable to simulate the input correctly up to its
specified end, it simply fails, where other simulators have no
problem to reach the final halt state specified in exactly the
same input.
This proves that the INPUT specifies a halting program.
When HHH fails to see that, that is in no way a proof that the
input changed to a non-input.
Talking about NON-INPUTS is irrelevant here.
On 18/08/2025 10:27, Mikko wrote:
On 2025-08-17 15:39:31 +0000, olcott said:
<snip>
DD correctly and completely simulated by HHH would be infinitely long.
The input to HHH(DD) specifies an input that halts after a finite
number of steps.
For that to be true, HHH (which is part of the behaviour encoded in DD)
is required to abort its simulation before being able to fully explore
the behaviour encoded by DD.
Inspection of DD shows that DD cannot terminate until HHH returns, and
that its behaviour thereafter depends entirely on the value that HHH
yields.
On 8/18/2025 4:06 PM, joes wrote:Proving nothing, since that means that either H does abort, or H doesn't answer.
Am Mon, 18 Aug 2025 12:18:24 -0500 schrieb olcott:
On 8/18/2025 5:07 AM, Richard Heathfield wrote:You mean HHH_n and lower can’t simulate DDD_n and up, even though
On 18/08/2025 10:27, Mikko wrote:
When 0 to ∞ instructions of DD are correctly simulated by HHH no DDThe input to HHH(DD) specifies an input that halts after a finite
number of steps.
For that to be true, HHH (which is part of the behaviour encoded in DD) >>>> is required to abort its simulation before being able to fully explore >>>> the behaviour encoded by DD.
Inspection of DD shows that DD cannot terminate until HHH returns, and >>>> that its behaviour thereafter depends entirely on the value that HHH
yields.
reaches its own simulated "return" statement final halt state.
the infinitely many larger HHH_n’s can.
Thus the differences between these different simulations has noTrue, but then we’re comparing the simulation of different programs
consequence on whether or not the DD of this DD/HHH pair correctly
simulated by its HHH reaches its own simulated "return" statement final
halt state.
DDD_n, which call the corresponding HHH_n that aborts after n levels
of nesting, and those are clearly not the same. But you don’t get that,
thinking DDD is a magic box that (contrary to your claim) can find out
its caller and call it in turn. If you change HHH, you change DDD.
M contains simulating halt decider H
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
(b) M invokes M.H ⟨M⟩ ⟨M⟩
(c) M.H simulates ⟨M⟩ ⟨M⟩
making each M.H ⟨M⟩ ⟨M⟩ transitioning to M.qn
on the basis that its correctly simulated
input cannot possibly reach its own ⟨M.qn⟩
necessarily correct.
On 8/18/2025 5:07 AM, Richard Heathfield wrote:
On 18/08/2025 10:27, Mikko wrote:
On 2025-08-17 15:39:31 +0000, olcott said:
<snip>
DD correctly and completely simulated by HHH would be infinitely long.
The input to HHH(DD) specifies an input that halts after a finite
number of steps.
For that to be true, HHH (which is part of the behaviour encoded in
DD) is required to abort its simulation before being able to fully
explore the behaviour encoded by DD.
Inspection of DD shows that DD cannot terminate until HHH returns, and
that its behaviour thereafter depends entirely on the value that HHH
yields.
When 0 to ∞ instructions of DD are correctly
simulated by HHH no DD reaches its own simulated
"return" statement final halt state.
Thus the differences between these different simulations
has no consequence on whether or not the DD of this
DD/HHH pair correctly simulated by its HHH reaches
its own simulated "return" statement final halt state.
Deceptive people here have been arguing that the
differences are consequential knowing full well
that they are not.
A correct simulation must take this tail behaviour into account, which
HHH singularly fails to do. It has been argued that HHH is unable to
simulate that behaviour, which demonstrates beyond a shadow of a doubt
that HHH is not fit for purpose as a simulator. That doesn't
necessarily mean that simulation cannot be used for the purpose, but a
better simulator than HHH is clearly required.
I don't care if Heathfield disagrees with himself,
My quote of him does agree with me and all five LLM systems.
On 8/19/2025 6:35 PM, Richard Heathfield wrote:
On 19/08/2025 23:08, olcott wrote:
<snip>
I don't care if Heathfield disagrees with himself,
Where have I done so?
My quote of him does agree with me and all five LLM systems.
Everything that you say that contradicts this
is taken to be trollish nonsense:
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
On 8/19/2025 7:16 PM, Richard Heathfield wrote:
On 20/08/2025 00:48, olcott wrote:
On 8/19/2025 6:35 PM, Richard Heathfield wrote:
On 19/08/2025 23:08, olcott wrote:
<snip>
I don't care if Heathfield disagrees with himself,
Where have I done so?
My quote of him does agree with me and all five LLM systems.
Yes, it shows that you can correctly simulate HHH by replacing
it with a macro: #define HHH(x) 0
That is a jackass stupid idea
because it breaks
HHH reporting on halting inputs
you f-cking nitwit.
On 8/19/2025 6:08 PM, olcott wrote:
On 8/19/2025 5:06 PM, dbush wrote:
[decider spec]It's funny when you post something to support you which
clearly states that HHH will always be wrong.
I don't care if Heathfield disagrees with himself,
My quote of him does agree with me and all five LLM systems.
His FULL quote which you dishonestly trim shows that no HHH
exists that satisfies the following requirements:
On 8/19/2025 7:42 PM, Richard Heathfield wrote:^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On 19/08/2025 23:12, dbush wrote:
On 8/19/2025 6:08 PM, olcott wrote:
On 8/19/2025 5:06 PM, dbush wrote:
<snip>
[decider spec]It's funny when you post something to support you which
clearly states that HHH will always be wrong.
I don't care if Heathfield disagrees with himself,
My quote of him does agree with me and all five LLM systems.
His FULL quote which you dishonestly trim shows that no HHH
exists that satisfies the following requirements:
Yes, Mr Olcott excels at selective quotation. It isn't normally
a problem because you can just look back through the thread for
the original, but comp.theory threads do tend to place an
intolerable burden on a newsreader's presentation skills.
Suffice it to say that I *do* disagree with myself whenever I
think I may have nosed down a wrong path and feel the need to
180. Only a fool never acknowledges that he may have made a
mistake.
But yes, I have shown several times (as have others before me,
of course) that HHH gets the wrong answer for DD, and it does
seem odd for Mr Olcott (who is /not/ noted for changing his
mind when shown to be mistaken) to agree that HHH is broken.
I should clarify, because he's going to read this.
HHH MUST NOT return 0.
(It does, and I don't dispute that it does. But it mustn't.)
If HHH returns 0, it proves that it fails to be either a
decider or a simulator. That's not a good note on which to end
HHH's career.
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
*The essence of the above that you have repeatedly denied*
"if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally"
On 8/19/2025 7:48 PM, Richard Heathfield wrote:
On 20/08/2025 01:38, olcott wrote:Not simulating a f-cking thing is not a correct
On 8/19/2025 7:16 PM, Richard Heathfield wrote:
On 20/08/2025 00:48, olcott wrote:
On 8/19/2025 6:35 PM, Richard Heathfield wrote:
On 19/08/2025 23:08, olcott wrote:
<snip>
I don't care if Heathfield disagrees with himself,
Where have I done so?
My quote of him does agree with me and all five LLM systems.
Yes, it shows that you can correctly simulate HHH by replacing
it with a macro: #define HHH(x) 0
That is a jackass stupid idea
No, I don't think so.
because it breaks
HHH reporting on halting inputs
It's already broken.
Besides, it's correct simulation. HHH /does/ return 0.
simulation jackass. I want you to feel my anger.
On 8/19/2025 8:12 PM, Richard Heathfield wrote:
On 20/08/2025 01:54, olcott wrote:
On 8/19/2025 7:42 PM, Richard Heathfield wrote:^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On 19/08/2025 23:12, dbush wrote:
On 8/19/2025 6:08 PM, olcott wrote:
On 8/19/2025 5:06 PM, dbush wrote:
<snip>
[decider spec]It's funny when you post something to support you which
clearly states that HHH will always be wrong.
I don't care if Heathfield disagrees with himself,
My quote of him does agree with me and all five LLM systems.
His FULL quote which you dishonestly trim shows that no HHH
exists that satisfies the following requirements:
Yes, Mr Olcott excels at selective quotation. It isn't
normally a problem because you can just look back through the
thread for the original, but comp.theory threads do tend to
place an intolerable burden on a newsreader's presentation
skills.
Suffice it to say that I *do* disagree with myself whenever I
think I may have nosed down a wrong path and feel the need to
180. Only a fool never acknowledges that he may have made a
mistake.
But yes, I have shown several times (as have others before
me, of course) that HHH gets the wrong answer for DD, and it
does seem odd for Mr Olcott (who is /not/ noted for changing
his mind when shown to be mistaken) to agree that HHH is broken.
I should clarify, because he's going to read this.
HHH MUST NOT return 0.
(It does, and I don't dispute that it does. But it mustn't.)
If HHH returns 0, it proves that it fails to be either a
decider or a simulator. That's not a good note on which to
end HHH's career.
On 8/18/2025 6:05 PM, Richard Heathfield wrote:
It is an easily verified fact, as you love to say,
that if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally, so it will have
to abort the recursion and report its result as 0
- didn't halt.
;
*The essence of the above that you have repeatedly denied*
I'm not denying it. I will cheerfully accept that HHH aborts
the simulation and returns 0.
I will even accept that there's a good case for so doing.
Nevertheless, it mustn't.
"if DD calls HHH (as it does) and HHH calls DD
(as, through simulation, it effectively does) that
HHH(DD) can never halt naturally"
Yes, so HHH must abort to report.
And yes, there is a case for your choice of reporting 0.
But it's the wrong choice.
Liars would say that telling the truth is the wrong choice
is that what you mean?
On Tue, 2025-08-19 at 21:11 -0500, olcott wrote:
On 8/19/2025 8:12 PM, Richard Heathfield wrote:
Yes, so HHH must abort to report.
And yes, there is a case for your choice of reporting 0.
But it's the wrong choice.
Liars would say that telling the truth is the wrong choice
is that what you mean?
Who is the liar?
You cannot even correctly rephrase the definition of the Halting Problem !
On 8/19/2025 8:15 PM, Richard Heathfield wrote:
On 20/08/2025 01:56, olcott wrote:
On 8/19/2025 7:48 PM, Richard Heathfield wrote:
Besides, it's correct simulation. HHH /does/ return 0.Not simulating a f-cking thing is not a correct
simulation jackass. I want you to feel my anger.
Only you can feel your anger. What I see is your childishness.
Wake me when you grow up, because in the meantime #define
HHH(x) 0 is correct simulation.
Of course, it ignores HHH's source code, but I have precedent
to tell me that that's okay when correctly simulating.
Saying that not doing any simulation is the correct
way to do a simulation
in ridiculously incorrect
On 8/19/2025 2:44 AM, Mikko wrote:
On 2025-08-18 10:07:17 +0000, Richard Heathfield said:
On 18/08/2025 10:27, Mikko wrote:
On 2025-08-17 15:39:31 +0000, olcott said:
<snip>
DD correctly and completely simulated by HHH would be infinitely long. >>>>The input to HHH(DD) specifies an input that halts after a finite
number of steps.
For that to be true, HHH (which is part of the behaviour encoded in
DD) is required to abort its simulation before being able to fully
explore the behaviour encoded by DD.
Inspection of DD shows that DD cannot terminate until HHH returns,
and that its behaviour thereafter depends entirely on the value that
HHH yields.
True. But the actual implementation can be seen in GitHub. That code
shows that the simulation is aborted and value 0 (which by C rules means
'false' when used as a condition) is returned. Olcott has said that
whenever he uses the name "HHH" it always means that particular code.
(He has also said otherwise.)
*The HHH code on GitHub is one instance of this generic HHH*
<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>
On 8/19/2025 5:28 PM, Chris M. Thomasson wrote:
On 8/19/2025 3:19 PM, olcott wrote:
On 8/19/2025 5:12 PM, Chris M. Thomasson wrote:
On 8/19/2025 3:08 PM, olcott wrote:
[...]
I don't care if Heathfield disagrees with himself,
My quote of him does agree with me and all five LLM systems.
Stunning! ;^o
I don't give trolling any academic weight.
Have you tried DeepSeek yet?
I don't trust the Chinese government so I have
not tried DeepSeek.
ChatGPT 4.0, 5.0 Claude AI, Grok and Gemini
all figured out on their own what the
*recursive simulation non-halting behavior pattern*
is and that on that basis HHH(DD)==0 is correct.
ChatGPT 5.0 now must be explicitly told DON'T GUESS !!!
As its default it guesses what the answer is because
this saves processing time and thus money.
On 8/19/2025 8:15 PM, Richard Heathfield wrote:They don’t halt when simulated by {return 0;}.
On 20/08/2025 01:56, olcott wrote:
On 8/19/2025 7:48 PM, Richard Heathfield wrote:
On 20/08/2025 01:38, olcott wrote:
On 8/19/2025 7:16 PM, Richard Heathfield wrote:
On 20/08/2025 00:48, olcott wrote:
On 8/19/2025 6:35 PM, Richard Heathfield wrote:
On 19/08/2025 23:08, olcott wrote:
No, I don't think so.That is a jackass stupid ideaYes, it shows that you can correctly simulate HHH by replacing itMy quote of him does agree with me and all five LLM systems.
with a macro: #define HHH(x) 0
because it breaks HHH reporting on halting inputs
OK, let’s have it simulate one instruction then. Where’s the cutoff?Saying that not doing any simulation is the correct way to do aOnly you can feel your anger. What I see is your childishness. Wake meBesides, it's correct simulation. HHH /does/ return 0.Not simulating a f-cking thing is not a correct simulation jackass. I
want you to feel my anger.
when you grow up, because in the meantime #define HHH(x) 0 is correct
simulation.
Of course, it ignores HHH's source code, but I have precedent to tell
me that that's okay when correctly simulating.
simulation in ridiculously incorrect and you know it.
On 8/19/2025 4:42 PM, dbush wrote:Please clarify what is wrong and what would be correct.
On 8/19/2025 4:59 PM, Chris M. Thomasson wrote:
On 8/18/2025 3:46 PM, olcott wrote:
His argument is that the decision that X(Y) is making is not "doesYes.
algorithm Y halt", but basically "does there exist an implementation of
function X that can simulate function call Y() to completion?"
This happens to coincide with the halting function in cases whereYou are wrong about this.
function Y does not call function X at some point, but not in cases
where it does.
QFTHe's saying "this is the mapping that the HHH I've implemented is
computing, therefore this mapping is actually the correct one."
Am Tue, 19 Aug 2025 21:17:50 -0500 schrieb olcott:
On 8/19/2025 8:15 PM, Richard Heathfield wrote:
OK, let’s have it simulate one instruction then. Where’s the cutoff?Of course, it ignores HHH's source code, but I have precedent to tellSaying that not doing any simulation is the correct way to do a
me that that's okay when correctly simulating.
simulation in ridiculously incorrect and you know it.
Op 20.aug.2025 om 00:35 schreef olcott:
ChatGPT 4.0, 5.0 Claude AI, Grok and Gemini
all figured out on their own what the
*recursive simulation non-halting behavior pattern*
is and that on that basis HHH(DD)==0 is correct.
Based on the incorrect assumption that HHH detects a non-termination behaviour.
On 8/19/2025 2:44 AM, Mikko wrote:
On 2025-08-18 10:07:17 +0000, Richard Heathfield said:
On 18/08/2025 10:27, Mikko wrote:
On 2025-08-17 15:39:31 +0000, olcott said:
<snip>
DD correctly and completely simulated by HHH would be infinitely long. >>>>The input to HHH(DD) specifies an input that halts after a finite
number of steps.
For that to be true, HHH (which is part of the behaviour encoded in DD)
is required to abort its simulation before being able to fully explore
the behaviour encoded by DD.
Inspection of DD shows that DD cannot terminate until HHH returns, and
that its behaviour thereafter depends entirely on the value that HHH
yields.
True. But the actual implementation can be seen in GitHub. That code
shows that the simulation is aborted and value 0 (which by C rules means
'false' when used as a condition) is returned. Olcott has said that
whenever he uses the name "HHH" it always means that particular code.
(He has also said otherwise.)
*The HHH code on GitHub is one instance of this generic HHH*
On 2025-08-18 10:07:17 +0000, Richard Heathfield said:
Inspection of DD shows that DD cannot terminate until HHH
returns, and that its behaviour thereafter depends entirely on
the value that HHH yields.
True. But the actual implementation can be seen in GitHub. That code
shows that the simulation is aborted and value 0 (which by C
rules means
'false' when used as a condition) is returned. Olcott has said that
whenever he uses the name "HHH" it always means that particular
code.
(He has also said otherwise.)
On 8/26/2025 4:14 AM, Mikko wrote:
On 2025-08-19 15:06:50 +0000, olcott said:
On 8/19/2025 2:44 AM, Mikko wrote:
On 2025-08-18 10:07:17 +0000, Richard Heathfield said:
On 18/08/2025 10:27, Mikko wrote:
On 2025-08-17 15:39:31 +0000, olcott said:
<snip>
DD correctly and completely simulated by HHH would be infinitely long. >>>>>>The input to HHH(DD) specifies an input that halts after a finite
number of steps.
For that to be true, HHH (which is part of the behaviour encoded in DD) >>>>> is required to abort its simulation before being able to fully explore >>>>> the behaviour encoded by DD.
Inspection of DD shows that DD cannot terminate until HHH returns, and >>>>> that its behaviour thereafter depends entirely on the value that HHH >>>>> yields.
True. But the actual implementation can be seen in GitHub. That code
shows that the simulation is aborted and value 0 (which by C rules means >>>> 'false' when used as a condition) is returned. Olcott has said that
whenever he uses the name "HHH" it always means that particular code.
(He has also said otherwise.)
*The HHH code on GitHub is one instance of this generic HHH*
The "generic HHH" is undefined. Therefore statements about "generic HHH"
often have no truth value.
<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.
The above generic HHH has been defined dozens and dozens of times.
On 8/27/2025 2:30 AM, Mikko wrote:
On 2025-08-26 16:20:57 +0000, olcott said:
On 8/26/2025 4:14 AM, Mikko wrote:
On 2025-08-19 15:06:50 +0000, olcott said:
On 8/19/2025 2:44 AM, Mikko wrote:
On 2025-08-18 10:07:17 +0000, Richard Heathfield said:
On 18/08/2025 10:27, Mikko wrote:
On 2025-08-17 15:39:31 +0000, olcott said:
<snip>
DD correctly and completely simulated by HHH would be
infinitely long.
The input to HHH(DD) specifies an input that halts after a finite >>>>>>>> number of steps.
For that to be true, HHH (which is part of the behaviour encoded >>>>>>> in DD) is required to abort its simulation before being able to
fully explore the behaviour encoded by DD.
Inspection of DD shows that DD cannot terminate until HHH
returns, and that its behaviour thereafter depends entirely on
the value that HHH yields.
True. But the actual implementation can be seen in GitHub. That code >>>>>> shows that the simulation is aborted and value 0 (which by C rules >>>>>> means
'false' when used as a condition) is returned. Olcott has said that >>>>>> whenever he uses the name "HHH" it always means that particular code. >>>>>> (He has also said otherwise.)
*The HHH code on GitHub is one instance of this generic HHH*
The "generic HHH" is undefined. Therefore statements about "generic
HHH"
often have no truth value.
<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.
The above generic HHH has been defined dozens and dozens of times.
The above generic HHH is still undefined.
The above generic HHH is sufficiently defined to
correctly analyze the behavior of DD correctly
simulated by HHH.
On 8/27/2025 2:30 AM, Mikko wrote:
On 2025-08-26 16:20:57 +0000, olcott said:
On 8/26/2025 4:14 AM, Mikko wrote:
On 2025-08-19 15:06:50 +0000, olcott said:
On 8/19/2025 2:44 AM, Mikko wrote:
On 2025-08-18 10:07:17 +0000, Richard Heathfield said:
On 18/08/2025 10:27, Mikko wrote:
On 2025-08-17 15:39:31 +0000, olcott said:
<snip>
DD correctly and completely simulated by HHH would be infinitely long.
The input to HHH(DD) specifies an input that halts after a finite >>>>>>>> number of steps.
For that to be true, HHH (which is part of the behaviour encoded in DD) >>>>>>> is required to abort its simulation before being able to fully explore >>>>>>> the behaviour encoded by DD.
Inspection of DD shows that DD cannot terminate until HHH returns, and >>>>>>> that its behaviour thereafter depends entirely on the value that HHH >>>>>>> yields.
True. But the actual implementation can be seen in GitHub. That code >>>>>> shows that the simulation is aborted and value 0 (which by C rules means >>>>>> 'false' when used as a condition) is returned. Olcott has said that >>>>>> whenever he uses the name "HHH" it always means that particular code. >>>>>> (He has also said otherwise.)
*The HHH code on GitHub is one instance of this generic HHH*
The "generic HHH" is undefined. Therefore statements about "generic HHH" >>>> often have no truth value.
<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.
The above generic HHH has been defined dozens and dozens of times.
The above generic HHH is still undefined.
The above generic HHH is sufficiently defined to
correctly analyze the behavior of DD correctly
simulated by HHH.
On 8/28/2025 1:48 AM, Mikko wrote:
On 2025-08-27 14:39:11 +0000, olcott said:
On 8/27/2025 2:30 AM, Mikko wrote:
On 2025-08-26 16:20:57 +0000, olcott said:
On 8/26/2025 4:14 AM, Mikko wrote:
On 2025-08-19 15:06:50 +0000, olcott said:
On 8/19/2025 2:44 AM, Mikko wrote:
On 2025-08-18 10:07:17 +0000, Richard Heathfield said:
On 18/08/2025 10:27, Mikko wrote:
On 2025-08-17 15:39:31 +0000, olcott said:
<snip>
DD correctly and completely simulated by HHH would be infinitely long.
The input to HHH(DD) specifies an input that halts after a finite >>>>>>>>>> number of steps.
For that to be true, HHH (which is part of the behaviour encoded in DD)
is required to abort its simulation before being able to fully explore
the behaviour encoded by DD.
Inspection of DD shows that DD cannot terminate until HHH returns, and
that its behaviour thereafter depends entirely on the value that HHH >>>>>>>>> yields.
True. But the actual implementation can be seen in GitHub. That code >>>>>>>> shows that the simulation is aborted and value 0 (which by C rules means
'false' when used as a condition) is returned. Olcott has said that >>>>>>>> whenever he uses the name "HHH" it always means that particular code. >>>>>>>> (He has also said otherwise.)
*The HHH code on GitHub is one instance of this generic HHH*
The "generic HHH" is undefined. Therefore statements about "generic HHH" >>>>>> often have no truth value.
<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.
The above generic HHH has been defined dozens and dozens of times.
The above generic HHH is still undefined.
The above generic HHH is sufficiently defined to
correctly analyze the behavior of DD correctly
simulated by HHH.
No, it is not. You have not defined it at all.
That I have defined it for human minds does
not mean that I have not defined it at all.
Here is not defining it at all: HHH is ""
On 8/28/2025 2:14 PM, Chris M. Thomasson wrote:
On 8/28/2025 7:13 AM, olcott wrote:
On 8/28/2025 1:48 AM, Mikko wrote:
On 2025-08-27 14:39:11 +0000, olcott said:
On 8/27/2025 2:30 AM, Mikko wrote:
On 2025-08-26 16:20:57 +0000, olcott said:
On 8/26/2025 4:14 AM, Mikko wrote:The above generic HHH is still undefined.
On 2025-08-19 15:06:50 +0000, olcott said:
On 8/19/2025 2:44 AM, Mikko wrote:
On 2025-08-18 10:07:17 +0000, Richard Heathfield said:
On 18/08/2025 10:27, Mikko wrote:
On 2025-08-17 15:39:31 +0000, olcott said:
<snip>
DD correctly and completely simulated by HHH would be >>>>>>>>>>>>> infinitely long.
The input to HHH(DD) specifies an input that halts after a >>>>>>>>>>>> finite
number of steps.
For that to be true, HHH (which is part of the behaviour >>>>>>>>>>> encoded in DD) is required to abort its simulation before >>>>>>>>>>> being able to fully explore the behaviour encoded by DD. >>>>>>>>>>>
Inspection of DD shows that DD cannot terminate until HHH >>>>>>>>>>> returns, and that its behaviour thereafter depends entirely >>>>>>>>>>> on the value that HHH yields.
True. But the actual implementation can be seen in GitHub. >>>>>>>>>> That code
shows that the simulation is aborted and value 0 (which by C >>>>>>>>>> rules means
'false' when used as a condition) is returned. Olcott has said >>>>>>>>>> that
whenever he uses the name "HHH" it always means that
particular code.
(He has also said otherwise.)
*The HHH code on GitHub is one instance of this generic HHH*
The "generic HHH" is undefined. Therefore statements about
"generic HHH"
often have no truth value.
<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.
The above generic HHH has been defined dozens and dozens of times. >>>>>>
The above generic HHH is sufficiently defined to
correctly analyze the behavior of DD correctly
simulated by HHH.
No, it is not. You have not defined it at all.
That I have defined it for human minds does
not mean that I have not defined it at all.
Oh wow. Don't tell me that olcott thinks he is not a human?
The it is undefined as a C program for machines
does not entail that the notion of HHH is undefined.
It is defined for humans and LLM systems.
Here is not defining it at all: HHH is ""
On 8/28/2025 1:48 AM, Mikko wrote:
On 2025-08-27 14:39:11 +0000, olcott said:
On 8/27/2025 2:30 AM, Mikko wrote:
On 2025-08-26 16:20:57 +0000, olcott said:
On 8/26/2025 4:14 AM, Mikko wrote:
On 2025-08-19 15:06:50 +0000, olcott said:
On 8/19/2025 2:44 AM, Mikko wrote:
On 2025-08-18 10:07:17 +0000, Richard Heathfield said:
On 18/08/2025 10:27, Mikko wrote:
On 2025-08-17 15:39:31 +0000, olcott said:
<snip>
DD correctly and completely simulated by HHH would be
infinitely long.
The input to HHH(DD) specifies an input that halts after a finite >>>>>>>>>> number of steps.
For that to be true, HHH (which is part of the behaviour
encoded in DD) is required to abort its simulation before being >>>>>>>>> able to fully explore the behaviour encoded by DD.
Inspection of DD shows that DD cannot terminate until HHH
returns, and that its behaviour thereafter depends entirely on >>>>>>>>> the value that HHH yields.
True. But the actual implementation can be seen in GitHub. That >>>>>>>> code
shows that the simulation is aborted and value 0 (which by C
rules means
'false' when used as a condition) is returned. Olcott has said that >>>>>>>> whenever he uses the name "HHH" it always means that particular >>>>>>>> code.
(He has also said otherwise.)
*The HHH code on GitHub is one instance of this generic HHH*
The "generic HHH" is undefined. Therefore statements about
"generic HHH"
often have no truth value.
<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.
The above generic HHH has been defined dozens and dozens of times.
The above generic HHH is still undefined.
The above generic HHH is sufficiently defined to
correctly analyze the behavior of DD correctly
simulated by HHH.
No, it is not. You have not defined it at all.
That I have defined it for human minds does
not mean that I have not defined it at all.
Here is not defining it at all: HHH is ""
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 157:06:00 |
| Calls: | 10,384 |
| Calls today: | 1 |
| Files: | 14,056 |
| Messages: | 6,416,475 |