Google [x86utm operating system]
provides an excellent overview of my work.
The "x86utm operating system" is a project primarily focused on
exploring the philosophical and practical implications of the Halting
Problem in computer science, specifically at a lower level of
abstraction than traditional proofs.
Key aspects Emulation-based: It is built on an x86 emulator, allowing it
to simulate the execution of other programs, like C functions, at a low
level (machine language).
Halting Problem Research: The x86utm operating system acts as a testbed
for studying the Halting Problem, particularly for analyzing the
behavior of programs with paradoxical relationships to their simulators (e.g., programs designed to do the opposite of what a halting program
would report).
Termination Analysis: The project focuses on "simulating termination analyzers" (like function HHH mentioned in search results) that can
observe and detect non-halting behavior patterns in simulated programs,
like infinite loops or recursion, and then abort the simulation,
reporting that the program would not halt.
Relevance: The x86utm project contributes to a deeper understanding of
the Halting Problem by examining it through concrete examples and the behavior of programs within an emulated environment.
In essence The x86utm operating system is a specialized environment for investigating the nuances of the Halting Problem. It's not a
general-purpose operating system in the sense of Windows or Linux, but
rather a tool to explore fundamental computer science concepts at a
concrete level, using emulation and termination analysis to observe and understand program behavior, particularly in the context of halting and non-halting computations.
On Fri, 08 Aug 2025 11:08:33 -0500, olcott wrote:
Google [x86utm operating system]
provides an excellent overview of my work.
The "x86utm operating system" is a project primarily focused on
exploring the philosophical and practical implications of the Halting
Problem in computer science, specifically at a lower level of
abstraction than traditional proofs.
Key aspects Emulation-based: It is built on an x86 emulator, allowing it
to simulate the execution of other programs, like C functions, at a low
level (machine language).
Halting Problem Research: The x86utm operating system acts as a testbed
for studying the Halting Problem, particularly for analyzing the
behavior of programs with paradoxical relationships to their simulators
(e.g., programs designed to do the opposite of what a halting program
would report).
Termination Analysis: The project focuses on "simulating termination
analyzers" (like function HHH mentioned in search results) that can
observe and detect non-halting behavior patterns in simulated programs,
like infinite loops or recursion, and then abort the simulation,
reporting that the program would not halt.
Relevance: The x86utm project contributes to a deeper understanding of
the Halting Problem by examining it through concrete examples and the
behavior of programs within an emulated environment.
In essence The x86utm operating system is a specialized environment for
investigating the nuances of the Halting Problem. It's not a
general-purpose operating system in the sense of Windows or Linux, but
rather a tool to explore fundamental computer science concepts at a
concrete level, using emulation and termination analysis to observe and
understand program behavior, particularly in the context of halting and
non-halting computations.
Your work? You mean your 22 years of time wasting? x86utm has nothing to
do with the Halting Problem as it only consists of a partial decider
rather than the total decider required for the Halting Problem.
On 8/10/2025 2:58 AM, Mikko wrote:
On 2025-08-08 16:18:42 +0000, Mr Flibble said:Claude AI proved why HHH(DD)==0 is correct in terms that any expert C programmer can understand. https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
On Fri, 08 Aug 2025 11:08:33 -0500, olcott wrote:
Google [x86utm operating system]
provides an excellent overview of my work.
The "x86utm operating system" is a project primarily focused on
exploring the philosophical and practical implications of the Halting
Problem in computer science, specifically at a lower level of
abstraction than traditional proofs.
Key aspects Emulation-based: It is built on an x86 emulator, allowing
it to simulate the execution of other programs, like C functions, at
a low level (machine language).
Halting Problem Research: The x86utm operating system acts as a
testbed for studying the Halting Problem, particularly for analyzing
the behavior of programs with paradoxical relationships to their
simulators (e.g., programs designed to do the opposite of what a
halting program would report).
Termination Analysis: The project focuses on "simulating termination
analyzers" (like function HHH mentioned in search results) that can
observe and detect non-halting behavior patterns in simulated
programs, like infinite loops or recursion, and then abort the
simulation, reporting that the program would not halt.
Relevance: The x86utm project contributes to a deeper understanding
of the Halting Problem by examining it through concrete examples and
the behavior of programs within an emulated environment.
In essence The x86utm operating system is a specialized environment
for investigating the nuances of the Halting Problem. It's not a
general-purpose operating system in the sense of Windows or Linux,
but rather a tool to explore fundamental computer science concepts at
a concrete level, using emulation and termination analysis to observe
and understand program behavior, particularly in the context of
halting and non-halting computations.
Your work? You mean your 22 years of time wasting? x86utm has nothing
to do with the Halting Problem as it only consists of a partial
decider rather than the total decider required for the Halting
Problem.
It does illustrate the insolvability of the halting problem, in
particular the failure of the simulation approach, which might look
promising.
Claude AI proved why HHH(DD)==0 is correct in terms that any expert C programmer can understand. https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
On 8/10/2025 2:58 AM, Mikko wrote:
On 2025-08-08 16:18:42 +0000, Mr Flibble said:
On Fri, 08 Aug 2025 11:08:33 -0500, olcott wrote:
Google [x86utm operating system]
provides an excellent overview of my work.
The "x86utm operating system" is a project primarily focused on
exploring the philosophical and practical implications of the Halting
Problem in computer science, specifically at a lower level of
abstraction than traditional proofs.
Key aspects Emulation-based: It is built on an x86 emulator, allowing it >>>> to simulate the execution of other programs, like C functions, at a low >>>> level (machine language).
Halting Problem Research: The x86utm operating system acts as a testbed >>>> for studying the Halting Problem, particularly for analyzing the
behavior of programs with paradoxical relationships to their simulators >>>> (e.g., programs designed to do the opposite of what a halting program
would report).
Termination Analysis: The project focuses on "simulating termination
analyzers" (like function HHH mentioned in search results) that can
observe and detect non-halting behavior patterns in simulated programs, >>>> like infinite loops or recursion, and then abort the simulation,
reporting that the program would not halt.
Relevance: The x86utm project contributes to a deeper understanding of >>>> the Halting Problem by examining it through concrete examples and the
behavior of programs within an emulated environment.
In essence The x86utm operating system is a specialized environment for >>>> investigating the nuances of the Halting Problem. It's not a
general-purpose operating system in the sense of Windows or Linux, but >>>> rather a tool to explore fundamental computer science concepts at a
concrete level, using emulation and termination analysis to observe and >>>> understand program behavior, particularly in the context of halting and >>>> non-halting computations.
Your work? You mean your 22 years of time wasting? x86utm has nothing to >>> do with the Halting Problem as it only consists of a partial decider
rather than the total decider required for the Halting Problem.
It does illustrate the insolvability of the halting problem, in particular >> the failure of the simulation approach, which might look promising.
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand. https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Also
https://philpapers.org/archive/OLCHPS.pdf
As soon as you understand that the above page is
entirely correct we can proceed to the last step
of my proof.
On 8/11/2025 10:04 AM, dbush wrote:
On 8/11/2025 10:33 AM, olcott wrote:
The halting specification has always been wrong.
In your own words, what does it mean for the specification to
be "wrong"?
The halting problem specification requires a halt
decider
On 8/11/2025 10:04 AM, dbush wrote:
On 8/11/2025 10:33 AM, olcott wrote:
On 8/11/2025 1:44 AM, Mikko wrote:
On 2025-08-10 14:15:12 +0000, olcott said:
On 8/10/2025 2:58 AM, Mikko wrote:
Irrelevant as long as the meaning of "correct" is not 'as required byThe halting specification has always been wrong.
the halting problem specification'.
In your own words, what does it mean for the specification to be
"wrong"?
The halting problem specification requires a halt decider to report on
the behavior of the underlying Turing machine under the false assumption
that input DD correctly simulated by halt decider HHH must have the same behavior as the directly executed DD().
When I prove otherwise people here go on and on and on making sure to
ignore this proof for months and months over years and years.
When they finally pay attention they say this proves that the simulation
is wrong.
When I prove that the simulation is correct they baselessly disagree. We
fail to make progress because people will not look at the proof that the simulation is correct.
On 8/11/2025 11:05 AM, dbush wrote:
On 8/11/2025 12:04 PM, olcott wrote:
On 8/11/2025 10:49 AM, dbush wrote:
On 8/11/2025 11:48 AM, olcott wrote:
On 8/11/2025 10:43 AM, dbush wrote:
*Counter-factual*
i.e. it doesn't correctly simulate its input.
If that was true then the exact error could be found.No that is merely your attention deficit disorder failing to payYou cannot show that DD emulated by HH according to the definition
of the x86 language
Does not occur as you have admitted on the record:
attention to the definition of HHH
Simulating Termination Analyzer HHH correctly simulates its input
until:
i.e. it doesn't correctly simulate its input
On 8/11/2025 10:46 AM, Richard Heathfield wrote:
On 11/08/2025 16:21, olcott wrote:
On 8/11/2025 10:04 AM, dbush wrote:
On 8/11/2025 10:33 AM, olcott wrote:
<snip>
The halting specification has always been wrong.
In your own words, what does it mean for the specification to
be "wrong"?
Good question.
The halting problem specification requires a halt
decider
On the contrary, the halting problem demonstrates that such a
decider cannot be built. Turing no more requires you to
construct a halt decider than Zeno requires you to train a
tortoise.
<snip>
Yes when you assume that I am wrong
and then make
sure to ignore what I said
the false assumption
cannot be shown to be false.
Good job you used zero reasoning to affirm a false
assumption. You know that this false assumption is
true entirely on the basis of an incorrect guess.
On 8/11/2025 10:49 AM, joes wrote:That is the error.
You have no proof that the simulation is correct other than redefiningThe categorical impossibility of finding a specific an error is this
it.
proof.
You cannot show that DD emulated by HH according to the definition of
the x86 language can possibly reach its own correctly emulated "ret" instruction because it cannot.
I have proven that DD correctly simulated by HHH
cannot possibly reach its own "return" statement
final halt state and you baselessly disagree.
On 8/11/2025 12:31 PM, olcott wrote:
On 8/11/2025 11:13 AM, dbush wrote:
On 8/11/2025 12:12 PM, olcott wrote:
On 8/11/2025 11:05 AM, dbush wrote:
On 8/11/2025 12:04 PM, olcott wrote:
On 8/11/2025 10:49 AM, dbush wrote:
On 8/11/2025 11:48 AM, olcott wrote:
On 8/11/2025 10:43 AM, dbush wrote:
i.e. it doesn't correctly simulate its input.
*Counter-factual*
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 et
Size in bytes:(0035) [00002184]
You cannot show that DD emulated by HH according
to the definition of the x86 language
Does not occur as you have admitted on the record:
No that is merely your attention deficit disorder failing
to pay attention to the definition of HHH
Simulating Termination Analyzer HHH correctly simulates its
input until:
i.e. it doesn't correctly simulate its input
If that was true then the exact error could be found.
The error is that HHH aborts in violation of the x86 language
spec.
*That is not an error within the generic HHH spec*
So you acknowledge that HHH does not correctly simulate DD
according to the definition of the x86 language.
On 8/11/2025 11:35 AM, joes wrote:The fact that HH can't reach DD's return is an error.
Am Mon, 11 Aug 2025 11:00:18 -0500 schrieb olcott:It is incorrect to call proven fact errors.
On 8/11/2025 10:49 AM, joes wrote:That is the error.
You have no proof that the simulation is correct other thanThe categorical impossibility of finding a specific an error is this
redefining it.
proof.
You cannot show that DD emulated by HH according to the definition of
the x86 language can possibly reach its own correctly emulated "ret"
instruction because it cannot.
Not at all. It is ridiculously stupid to require
a simulating termination analyzer to simulate a
non-terminating input to its non-existent completion.
On 8/11/2025 11:42 AM, Richard Heathfield wrote:
On 11/08/2025 17:29, olcott wrote:
<snip>
I have proven that DD correctly simulated by HHH
No, you haven't. You have asserted that the simulation is
correct, but we all know that it derives a different result
from that produced by direct execution, and therefore we all
know that the simulation is not correct.
You can only fully know that your assumption is incorrect
when you notice that no specific error exists.
You cannot show that DD emulated by HH according
to the definition of the x86 language can possibly
reach its own correctly emulated "ret" instruction
because it cannot.
On 8/11/2025 11:35 AM, joes wrote:
Am Mon, 11 Aug 2025 11:00:18 -0500 schrieb olcott:
On 8/11/2025 10:49 AM, joes wrote:That is the error.
You have no proof that the simulation is correct other thanThe categorical impossibility of finding a specific an error
redefining
it.
is this
proof.
You cannot show that DD emulated by HH according to the
definition of
the x86 language can possibly reach its own correctly emulated
"ret"
instruction because it cannot.
It is incorrect to call proven fact errors.
On 8/11/2025 12:59 PM, Richard Heathfield wrote:
On 11/08/2025 18:25, olcott wrote:
Not at all. It is ridiculously stupid to require
a simulating termination analyzer to simulate a
non-terminating input to its non-existent completion.
Indeed, because it's not possible. That's precisely the point.
It can't be done. Non-terminating processes cannot be simulated
to termination. If your job is to work out /purely by
simulation whether they halt, your best bet is to take a guess
and accept that you might get it wrong.
And if you get it right, you got lucky.
If you bother to carefully examine this single page
your key misconception will be fully addressed. https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
HHH(DD)==0 is correct when the behavior of DD
is measured by DD correctly simulated by HHH.
Correctly is not completely. One not need to count
to infinity to prove that they can count to ten.
On 8/11/2025 1:33 PM, Richard Heathfield wrote:
On 11/08/2025 18:48, olcott wrote:It is incorrect to say it *is* a wrong answer until after
On 8/11/2025 11:42 AM, Richard Heathfield wrote:
On 11/08/2025 17:29, olcott wrote:
<snip>
I have proven that DD correctly simulated by HHH
No, you haven't. You have asserted that the simulation is
correct, but we all know that it derives a different result
from that produced by direct execution, and therefore we all
know that the simulation is not correct.
You can only fully know that your assumption is incorrect
when you notice that no specific error exists.
The specific error is that you get the wrong answer.
a specific error in the basis of this answer is found.
Until that time it can be at most
"seems like a wrong answer to me"
extending beyond this is inaccurate thus untruthful.
On 8/11/2025 1:44 AM, Mikko wrote:
On 2025-08-10 14:15:12 +0000, olcott said:
On 8/10/2025 2:58 AM, Mikko wrote:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Irrelevant as long as the meaning of "correct" is not 'as required
by the halting problem specification'.
The halting specification has always been wrong.
You won't be able to understand why the halting
specification has always been wrong until after
you understand that the actual input to HHH(DD)
specifies the non-halting behavior of recursive
emulation.
Apparently you don't understand what Claude AI said as you can only
refer to it but cannot prove the same.
Also
https://philpapers.org/archive/OLCHPS.pdf
As soon as you understand that the above page is
entirely correct we can proceed to the last step
of my proof.
That paper is not entirely correct. It starts with an ill-posed question
"What value should HHH(DD) correctly return?" where the exact meanings
of "should" and "correctly" are not defined and cannot be inferred from
the context.
Later in the text there is the pharase "according to the specification"
that does not identify any specification.
In the "Answer" section there is the phrase "correctly identifies" where
the norm for correctness is not identified. What is correct by one norm
is incorrect by another norm. In this case the answer claimed "correct"
is incorrect by the meanings of "termination analyzer" and "halting
decider".
That you hadn't noticed any error doesn't mean that there are none.
Besidss, the text should have a title. And numbers in the text should
be set with upper case digits.
On 8/11/2025 10:46 AM, Richard Heathfield wrote:
On 11/08/2025 16:21, olcott wrote:
On 8/11/2025 10:04 AM, dbush wrote:
On 8/11/2025 10:33 AM, olcott wrote:
<snip>
The halting specification has always been wrong.
In your own words, what does it mean for the specification to be
"wrong"?
Good question.
The halting problem specification requires a halt
decider
On the contrary, the halting problem demonstrates that such a decider
cannot be built. Turing no more requires you to construct a halt
decider than Zeno requires you to train a tortoise.
<snip>
Yes when you assume that I am wrong and then make
sure to ignore what I said the false assumption
cannot be shown to be false.
Good job you used zero reasoning to affirm a false
assumption. You know that this false assumption is
true entirely on the basis of an incorrect guess.
On 8/11/2025 10:04 AM, dbush wrote:
On 8/11/2025 10:33 AM, olcott wrote:
On 8/11/2025 1:44 AM, Mikko wrote:
On 2025-08-10 14:15:12 +0000, olcott said:
On 8/10/2025 2:58 AM, Mikko wrote:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Irrelevant as long as the meaning of "correct" is not 'as required
by the halting problem specification'.
The halting specification has always been wrong.
In your own words, what does it mean for the specification to be "wrong"?
The halting problem specification requires a halt
decider to report on the behavior of the underlying
Turing machine under the false assumption that input
DD correctly simulated by halt decider HHH must have
the same behavior as the directly executed DD().
When I prove otherwise people here go on and on and
on making sure to ignore this proof for months and
months over years and years.
When they finally pay attention they say this proves
that the simulation is wrong.
When I prove that the simulation is correct they baselessly
disagree. We fail to make progress because people will not
look at the proof that the simulation is correct.
On 8/11/2025 10:30 AM, dbush wrote:
On 8/11/2025 11:21 AM, olcott wrote:
On 8/11/2025 10:04 AM, dbush wrote:
On 8/11/2025 10:33 AM, olcott wrote:
On 8/11/2025 1:44 AM, Mikko wrote:
On 2025-08-10 14:15:12 +0000, olcott said:
On 8/10/2025 2:58 AM, Mikko wrote:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Irrelevant as long as the meaning of "correct" is not 'as required >>>>>> by the halting problem specification'.
The halting specification has always been wrong.
In your own words, what does it mean for the specification to be
"wrong"?
The halting problem specification requires a halt
decider to report on the behavior of the underlying
Turing machine under the false assumption that input
DD correctly simulated by halt decider HHH must have
the same behavior as the directly executed DD().
But DD is not correctly simulated by HHH as you have admitted on the
record:
*Anything that I said previously lacked this generic definition*
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.
as its basis for analysis.
On 8/11/2025 11:18 AM, Richard Heathfield wrote:
On 11/08/2025 16:55, olcott wrote:
On 8/11/2025 10:46 AM, Richard Heathfield wrote:
On 11/08/2025 16:21, olcott wrote:
On 8/11/2025 10:04 AM, dbush wrote:
On 8/11/2025 10:33 AM, olcott wrote:
<snip>
The halting specification has always been wrong.
In your own words, what does it mean for the specification to be
"wrong"?
Good question.
The halting problem specification requires a halt
decider
On the contrary, the halting problem demonstrates that such a
decider cannot be built. Turing no more requires you to construct a
halt decider than Zeno requires you to train a tortoise.
<snip>
Yes when you assume that I am wrong
It's not an assumption. I have a proof.
and then make
sure to ignore what I said
When you say something worth reading, let me know. It hasn't happened
yet.
To date, all you've written are assertions masquerading as proofs -
proofs that hold less water than a colander. You have an emulator that
fails to emulate, a single-stepper that ignores 75% of what it's
supposed to be single-stepping, a master's degree in rude buggeriness,
and a complete inability to tell the difference between a thought
experiment and an engineering project. You're the man who thought if
only Icarus had used better glue.
the false assumption
cannot be shown to be false.
Feel free to try. If you make a serious stab, I'll listen. But if you
just say "first you must accept this list of falsehoods", I won't. You
don't have a licence to demand that people accept bullshit in place of
logic.
Good job you used zero reasoning to affirm a false
assumption. You know that this false assumption is
true entirely on the basis of an incorrect guess.
The only assumption I'm making is that you are right - Icarus can fly
higher still, and a universal halt decider can be built. Having made
that assumption, I can walk in Turing's footprints and derive a
contradiction that proves the assumption to be false. No guessing
involved.
I have proven that DD correctly simulated by HHH
cannot possibly reach its own "return" statement
final halt state and you baselessly disagree.
All the while your disagreements remain baseless
you really seem to be a troll. The only way to
correct this is to provide a complete basis for
your disagreement.
On 8/11/2025 1:44 AM, Mikko wrote:
On 2025-08-10 14:15:12 +0000, olcott said:
On 8/10/2025 2:58 AM, Mikko wrote:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Irrelevant as long as the meaning of "correct" is not 'as required
by the halting problem specification'.
The halting specification has always been wrong.
On 8/11/2025 10:04 AM, dbush wrote:
On 8/11/2025 10:33 AM, olcott wrote:
On 8/11/2025 1:44 AM, Mikko wrote:
On 2025-08-10 14:15:12 +0000, olcott said:
On 8/10/2025 2:58 AM, Mikko wrote:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Irrelevant as long as the meaning of "correct" is not 'as required
by the halting problem specification'.
The halting specification has always been wrong.
In your own words, what does it mean for the specification to be "wrong"?
The halting problem specification requires a halt
decider to report on the behavior of the underlying
Turing machine under the false assumption that input
DD correctly simulated by halt decider HHH must have
the same behavior as the directly executed DD().
On 8/11/2025 12:51 PM, joes wrote:
Am Mon, 11 Aug 2025 12:49:22 -0500 schrieb olcott:
On 8/11/2025 11:35 AM, joes wrote:
Am Mon, 11 Aug 2025 11:00:18 -0500 schrieb olcott:It is incorrect to call proven fact errors.
On 8/11/2025 10:49 AM, joes wrote:That is the error.
You have no proof that the simulation is correct other thanThe categorical impossibility of finding a specific an error is this >>>>> proof.
redefining it.
You cannot show that DD emulated by HH according to the definition of >>>>> the x86 language can possibly reach its own correctly emulated "ret" >>>>> instruction because it cannot.
The fact that HH can't reach DD's return is an error.
The fact that DD correctly simulated by HHH cannot
possibly reach the simulated "return" statement of
DD is a direct result of DD calling HHH(DD) in recursive
simulation.
It is like no one here has ever had a slight clue
about what recursion is.
On 8/12/2025 4:37 AM, Chris M. Thomasson wrote:
On 8/12/2025 2:02 AM, Mikko wrote:
On 2025-08-11 14:33:24 +0000, olcott said:
On 8/11/2025 1:44 AM, Mikko wrote:
On 2025-08-10 14:15:12 +0000, olcott said:
On 8/10/2025 2:58 AM, Mikko wrote:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Irrelevant as long as the meaning of "correct" is not 'as required
by the halting problem specification'.
The halting specification has always been wrong.
Doesn't matter. It is what it is. You needn't talk about it if you
don't want but you can't delete or change it.
your reason is most likely futile. shit happens?
The halting problem itself has always been wrong
when it requires a Turing machine to directly
report on the behavior of another directly executed
Turing machine because no Turing machine can take
another directly executed Turing machine as an input.
The conventional proofs talk about a halt decider H
reporting on the behavior of machine M on input P yet
H is not given machine M it is only given machine
description ⟨M⟩.
This assumes that the behavior of machine M on input P
will be identical to the correct simulation of ⟨M⟩ on P.
This is axiomatically true except in one specific case:
Machine M contains simulating halt decider H
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qy
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/12/2025 4:02 AM, Mikko wrote:
On 2025-08-11 14:33:24 +0000, olcott said:
On 8/11/2025 1:44 AM, Mikko wrote:
On 2025-08-10 14:15:12 +0000, olcott said:
On 8/10/2025 2:58 AM, Mikko wrote:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Irrelevant as long as the meaning of "correct" is not 'as required
by the halting problem specification'.
The halting specification has always been wrong.
Doesn't matter. It is what it is. You needn't talk about it if you
don't want but you can't delete or change it.
The halting specification ignores that the way that
Turing machines actually work this is like trying to
bake a cake in your washing machine.
On 8/12/2025 5:41 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 19:57 schreef olcott:
On 8/11/2025 12:51 PM, joes wrote:
Am Mon, 11 Aug 2025 12:49:22 -0500 schrieb olcott:
On 8/11/2025 11:35 AM, joes wrote:
Am Mon, 11 Aug 2025 11:00:18 -0500 schrieb olcott:It is incorrect to call proven fact errors.
On 8/11/2025 10:49 AM, joes wrote:That is the error.
You have no proof that the simulation is correct other thanThe categorical impossibility of finding a specific an error is this >>>>>>> proof.
redefining it.
You cannot show that DD emulated by HH according to the
definition of
the x86 language can possibly reach its own correctly emulated "ret" >>>>>>> instruction because it cannot.
The fact that HH can't reach DD's return is an error.
The fact that DD correctly simulated by HHH cannot
possibly reach the simulated "return" statement of
DD is a direct result of DD calling HHH(DD) in recursive
simulation.
Which proves that
The actual behavior of the actual input is not-halting.
The actual behavior of a non-input does not contradict
this because halt deciders are not accountable for the
behavior of non-inputs.
It is common knowledge that Turing machines do
not take other Turing machines as inputs.
On 8/13/2025 11:22 AM, Richard Heathfield wrote:
On 13/08/2025 16:58, olcott wrote:
It is common knowledge that Turing machines do
not take other Turing machines as inputs.
Are you gonna fix Wikipedia, or shall I?
One of my two most credible sources must understand
what I say before such a fix can be made.
On 8/13/2025 4:03 AM, Fred. Zwarts wrote:
Op 12.aug.2025 om 18:56 schreef olcott:
On 8/12/2025 5:41 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 19:57 schreef olcott:
On 8/11/2025 12:51 PM, joes wrote:
Am Mon, 11 Aug 2025 12:49:22 -0500 schrieb olcott:
On 8/11/2025 11:35 AM, joes wrote:
Am Mon, 11 Aug 2025 11:00:18 -0500 schrieb olcott:It is incorrect to call proven fact errors.
On 8/11/2025 10:49 AM, joes wrote:That is the error.
You have no proof that the simulation is correct other than >>>>>>>>>> redefining it.The categorical impossibility of finding a specific an error is >>>>>>>>> this
proof.
You cannot show that DD emulated by HH according to the
definition of
the x86 language can possibly reach its own correctly emulated >>>>>>>>> "ret"
instruction because it cannot.
The fact that HH can't reach DD's return is an error.
The fact that DD correctly simulated by HHH cannot
possibly reach the simulated "return" statement of
DD is a direct result of DD calling HHH(DD) in recursive
simulation.
Which proves that
The actual behavior of the actual input is not-halting.
The actual behavior of a non-input does not contradict
this because halt deciders are not accountable for the
behavior of non-inputs.
As usual incorrect claims without evidence.
It is common knowledge that Turing machines do
not take other Turing machines as inputs. That
you did not know this is not any lack of evidence.
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
Is proven by the semantics of the C programming
language.
It proves that a simulator is not the right tool for this purpose,
because there are inputs for which it fails to reach the specified
final halt state. Using a simulator to analyse the input causes
recursive simulation, which the simulator cannot handle correctly.
Correct simulations of exactly the same input show that the final halt
state can be reached.
A correct simulation should acknowledge that and not assume a
hypothetical non-input that does not halt.
You seem to fail to understand that many recursions are not infinite.
Stopping running and halting are not the same thing.
When N instructions of DD are correctly simulated
by any HHH this correctly simulated DD cannot possibly
reach its own final halt state because it calls HHH(DD)
in recursive simulation.
You have built a simulator that forgets to analyse the conditional
branch instructions during the recursion, so that a finite recursion
is incorrectly seen as a non-termination behaviour pattern.
If we were looking at whether or not DD simulated
by HHH ever stops running you would be correct.
We are not looking at that.
You do not prove that the conditions for these branch instruction will
never be met. You only prove that they are not met in the first two
recursions.
On 13/08/2025 18:10, olcott wrote:
On 8/13/2025 11:22 AM, Richard Heathfield wrote:
On 13/08/2025 16:58, olcott wrote:
It is common knowledge that Turing machines do
not take other Turing machines as inputs.
Are you gonna fix Wikipedia, or shall I?
One of my two most credible sources must understand
what I say before such a fix can be made.
Good luck persuading the Wiki gang. They won't argue with you for 22
years; they'll just ban you as soon as you undo their first undo.
On 8/13/2025 3:13 AM, Mikko wrote:
On 2025-08-12 16:42:24 +0000, olcott said:
On 8/12/2025 4:02 AM, Mikko wrote:
On 2025-08-11 14:33:24 +0000, olcott said:
On 8/11/2025 1:44 AM, Mikko wrote:
On 2025-08-10 14:15:12 +0000, olcott said:
On 8/10/2025 2:58 AM, Mikko wrote:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Irrelevant as long as the meaning of "correct" is not 'as required >>>>>> by the halting problem specification'.
The halting specification has always been wrong.
Doesn't matter. It is what it is. You needn't talk about it if you
don't want but you can't delete or change it.
The halting specification ignores that the way that
Turing machines actually work this is like trying to
bake a cake in your washing machine.
Of course. That need not be considered when evaluating the correctness
of an answer to a halting question or the correctness of a candiate
halt decider.
Likewise: "What time is it (yes or no)?
is not Turing computable.
Does your input specify a sequence of move that halts?
Is proven for HHH(DD).
On 8/13/2025 4:03 AM, Fred. Zwarts wrote:
Op 12.aug.2025 om 18:56 schreef olcott:
On 8/12/2025 5:41 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 19:57 schreef olcott:
On 8/11/2025 12:51 PM, joes wrote:
Am Mon, 11 Aug 2025 12:49:22 -0500 schrieb olcott:
On 8/11/2025 11:35 AM, joes wrote:
Am Mon, 11 Aug 2025 11:00:18 -0500 schrieb olcott:It is incorrect to call proven fact errors.
On 8/11/2025 10:49 AM, joes wrote:That is the error.
You have no proof that the simulation is correct other than >>>>>>>>>> redefining it.The categorical impossibility of finding a specific an error is >>>>>>>>> this
proof.
You cannot show that DD emulated by HH according to the
definition of
the x86 language can possibly reach its own correctly emulated >>>>>>>>> "ret"
instruction because it cannot.
The fact that HH can't reach DD's return is an error.
The fact that DD correctly simulated by HHH cannot
possibly reach the simulated "return" statement of
DD is a direct result of DD calling HHH(DD) in recursive
simulation.
Which proves that
The actual behavior of the actual input is not-halting.
The actual behavior of a non-input does not contradict
this because halt deciders are not accountable for the
behavior of non-inputs.
As usual incorrect claims without evidence.
It is common knowledge that Turing machines do
not take other Turing machines as inputs. That
you did not know this is not any lack of evidence.
When HHH(DD) is executed that this begins simulating
DD that calls HHH(DD) that begins simulating DD that
calls HHH(DD) again.
Is proven by the semantics of the C programming
language.
It proves that a simulator is not the right tool for this purpose,
because there are inputs for which it fails to reach the specified
final halt state. Using a simulator to analyse the input causes
recursive simulation, which the simulator cannot handle correctly.
Correct simulations of exactly the same input show that the final halt
state can be reached.
A correct simulation should acknowledge that and not assume a
hypothetical non-input that does not halt.
You seem to fail to understand that many recursions are not infinite.
Stopping running and halting are not the same thing.
When N instructions of DD are correctly simulated
by any HHH this correctly simulated DD cannot possibly
reach its own final halt state because it calls HHH(DD)
in recursive simulation.
You have built a simulator that forgets to analyse the conditional
branch instructions during the recursion, so that a finite recursion
is incorrectly seen as a non-termination behaviour pattern.
If we were looking at whether or not DD simulated
by HHH ever stops running you would be correct.
We are not looking at that.
You do not prove that the conditions for these branch instruction will
never be met. You only prove that they are not met in the first two
recursions.
On 8/13/2025 3:13 AM, Mikko wrote:
On 2025-08-12 16:42:24 +0000, olcott said:
On 8/12/2025 4:02 AM, Mikko wrote:
On 2025-08-11 14:33:24 +0000, olcott said:
On 8/11/2025 1:44 AM, Mikko wrote:
On 2025-08-10 14:15:12 +0000, olcott said:
On 8/10/2025 2:58 AM, Mikko wrote:
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
Irrelevant as long as the meaning of "correct" is not 'as required >>>>>> by the halting problem specification'.
The halting specification has always been wrong.
Doesn't matter. It is what it is. You needn't talk about it if you
don't want but you can't delete or change it.
The halting specification ignores that the way that
Turing machines actually work this is like trying to
bake a cake in your washing machine.
Of course. That need not be considered when evaluating the correctness
of an answer to a halting question or the correctness of a candiate
halt decider.
Likewise: "What time is it (yes or no)?
is not Turing computable.
Does your input specify a sequence of move that halts?
Is proven for HHH(DD).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 150:55:36 |
| Calls: | 12,091 |
| Calls today: | 4 |
| Files: | 15,000 |
| Messages: | 6,517,598 |