On 2025-07-29 20:53:54 +0000, olcott said:
On 7/29/2025 1:37 AM, Mikko wrote:
On 2025-07-28 12:42:24 +0000, olcott said:
On 7/28/2025 2:50 AM, Mikko wrote:
On 2025-07-27 14:39:45 +0000, olcott said:
On 7/27/2025 2:36 AM, Mikko wrote:
On 2025-07-26 16:21:19 +0000, olcott said:
On 7/26/2025 2:28 AM, Mikko wrote:
On 2025-07-25 15:54:06 +0000, olcott said:
On 7/25/2025 2:43 AM, Mikko wrote:
On 2025-07-24 21:18:32 +0000, olcott said:
On 7/24/2025 4:02 PM, joes wrote:
Am Thu, 24 Jul 2025 09:11:44 -0500 schrieb olcott:
On 7/24/2025 5:07 AM, joes wrote:Yes, it is. And that can obviously be computed by a >>>>>>>>>>>>> processor, a UTM
Am Wed, 23 Jul 2025 16:08:51 -0500 schrieb olcott: >>>>>>>>>>>>>>>> On 7/23/2025 3:56 PM, joes wrote:
int Simulate(ptr x)If HHH (which aborts) was given to a UTM/pure simulator, >>>>>>>>>>>>>>> it would stopOf course, and then it incorrectly assumes that an >>>>>>>>>>>>>>>>> unabortedIf HHH(DDD) never aborts its simulation then this HHH >>>>>>>>>>>>>>>> never stops
simulation *of this HHH*, which does in fact abort, >>>>>>>>>>>>>>>>> wouldn't abort.
running.
running.
{
x(); return 1;
}
It is the behavior of the input to HHH(DDD) that HHH is >>>>>>>>>>>>>> supposed to
measure.
It is not the behavior of the input to Simulate(DDD) that >>>>>>>>>>>>>> HHH is
supposed to measure.
It is also not the behavior of the directly executed DDD() >>>>>>>>>>>>>> that HHH is
supposed to measure.
or any simulator that doesn't abort before the HHH called >>>>>>>>>>>>> by DDD does -
which HHH logically cannot do.
HHH(DDD) is only supposed to measure the behavior of its >>>>>>>>>>>>>> own input.Do you understand that it trivially produces the same >>>>>>>>>>>>> result as the
value that it returns?
It has been three years and still not one person has >>>>>>>>>>>>>> understood that theIt is well understood that HHH does not simulate DDD the >>>>>>>>>>>>> same way as the
behavior of an input that calls its own simulator is not >>>>>>>>>>>>>> the same as the
behavior of an input that does not call its own simulator. >>>>>>>>>>>>
direct execution. DDD doesn't even have an "own simulator", >>>>>>>>>>>>> it is just
a program that you want to simulate using the simulator it >>>>>>>>>>>>> happens to
call.
What has never been understood (even now) is that
Simulate(DDD) is presented with a different sequence
of x86 instructions than HHH(DDD) is presented with.
That you don't understand something does not mean that it is not >>>>>>>>>>> understood. Everyone other than you understand that if DDD in >>>>>>>>>>> Simulate(DDD) is not the same as DDD in HHH(DDD) then one of >>>>>>>>>>> them
was given a false name (and perhaps the other, too).
*Correctly emulated is defined as*
Emulated according to the rules of the x86 language.
This includes DDD emulated by HHH and HHH emulating
itself emulating DDD one or more times.
Irrelevant. The meaning of "DDD" in a C expresssion does not >>>>>>>>> depend on its
immediate context.
The meaning of a C function translated into x86
machine code is the meaning of this x86 machine code.
Only because the C compiler attempts to preserve the meaning. The >>>>>>> definitions of the meanings are distinct (except for assembly code >>>>>>> insertinos that the compiler permits as a lnaguage extension).
But the meaning of DDD in the C expression does not depend on its >>>>>>> immediate context. The x86 codes pointed to in the two calls are >>>>>>> identical or at least semantically equivalent so they specify the >>>>>>> same behaviour.
Independently of above considerations the meaning of DDD is the same >>>>>>> in Simulate(DDD) and HHH(DDD).
This ChatGPT analysis of its input below
correctly derives both of our views.
Whatever ChatGPT says is irrelevant. If you can't defend your claims >>>>> then your claims are undefencible.
I can and have proven my claims are verified facts:
https://github.com/plolcott/x86utm/blob/master/Halt7.c
and people disagreed anyway.
No, you have not. You have claimed that you have prooven but that is
not the same. Perhaps you don't know what a proof is but it certainly
is very different from anything you have ever presented.
*A proof is any sequence of steps deriving a necessary result*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
No, it is not. There are additional requirements for each step. The
sequence is a proof only if those additional requirements are satisfied.
From a practical point of view, the purpose of a proof is to convince,
so what does not convince is not a proof.
Proves that HHH does correctly emulate DDD then correctly
emulates itself emulating DDD.
No, it does not. The presentation is not convincing about anything
and does not satisfy the requirements ot a proof.
On 7/30/2025 1:50 AM, Mikko wrote:
On 2025-07-29 20:53:54 +0000, olcott said:
On 7/29/2025 1:37 AM, Mikko wrote:
On 2025-07-28 12:42:24 +0000, olcott said:
On 7/28/2025 2:50 AM, Mikko wrote:
On 2025-07-27 14:39:45 +0000, olcott said:
On 7/27/2025 2:36 AM, Mikko wrote:
On 2025-07-26 16:21:19 +0000, olcott said:
On 7/26/2025 2:28 AM, Mikko wrote:
On 2025-07-25 15:54:06 +0000, olcott said:
On 7/25/2025 2:43 AM, Mikko wrote:
On 2025-07-24 21:18:32 +0000, olcott said:
On 7/24/2025 4:02 PM, joes wrote:
Am Thu, 24 Jul 2025 09:11:44 -0500 schrieb olcott: >>>>>>>>>>>>>>> On 7/24/2025 5:07 AM, joes wrote:
Yes, it is. And that can obviously be computed by a >>>>>>>>>>>>>> processor, a UTMAm Wed, 23 Jul 2025 16:08:51 -0500 schrieb olcott: >>>>>>>>>>>>>>>>> On 7/23/2025 3:56 PM, joes wrote:
int Simulate(ptr x)If HHH (which aborts) was given to a UTM/pure simulator, >>>>>>>>>>>>>>>> it would stopOf course, and then it incorrectly assumes that an >>>>>>>>>>>>>>>>>> unabortedIf HHH(DDD) never aborts its simulation then this HHH >>>>>>>>>>>>>>>>> never stops
simulation *of this HHH*, which does in fact abort, >>>>>>>>>>>>>>>>>> wouldn't abort.
running.
running.
{
x(); return 1;
}
It is the behavior of the input to HHH(DDD) that HHH is >>>>>>>>>>>>>>> supposed to
measure.
It is not the behavior of the input to Simulate(DDD) that >>>>>>>>>>>>>>> HHH is
supposed to measure.
It is also not the behavior of the directly executed >>>>>>>>>>>>>>> DDD() that HHH is
supposed to measure.
or any simulator that doesn't abort before the HHH called >>>>>>>>>>>>>> by DDD does -
which HHH logically cannot do.
HHH(DDD) is only supposed to measure the behavior of its >>>>>>>>>>>>>>> own input.Do you understand that it trivially produces the same >>>>>>>>>>>>>> result as the
value that it returns?
It has been three years and still not one person has >>>>>>>>>>>>>>> understood that theIt is well understood that HHH does not simulate DDD the >>>>>>>>>>>>>> same way as the
behavior of an input that calls its own simulator is not >>>>>>>>>>>>>>> the same as the
behavior of an input that does not call its own simulator. >>>>>>>>>>>>>
direct execution. DDD doesn't even have an "own
simulator", it is just
a program that you want to simulate using the simulator it >>>>>>>>>>>>>> happens to
call.
What has never been understood (even now) is that
Simulate(DDD) is presented with a different sequence >>>>>>>>>>>>> of x86 instructions than HHH(DDD) is presented with.
That you don't understand something does not mean that it is >>>>>>>>>>>> not
understood. Everyone other than you understand that if DDD in >>>>>>>>>>>> Simulate(DDD) is not the same as DDD in HHH(DDD) then one of >>>>>>>>>>>> them
was given a false name (and perhaps the other, too).
*Correctly emulated is defined as*
Emulated according to the rules of the x86 language.
This includes DDD emulated by HHH and HHH emulating
itself emulating DDD one or more times.
Irrelevant. The meaning of "DDD" in a C expresssion does not >>>>>>>>>> depend on its
immediate context.
The meaning of a C function translated into x86
machine code is the meaning of this x86 machine code.
Only because the C compiler attempts to preserve the meaning. The >>>>>>>> definitions of the meanings are distinct (except for assembly code >>>>>>>> insertinos that the compiler permits as a lnaguage extension). >>>>>>>>
But the meaning of DDD in the C expression does not depend on its >>>>>>>> immediate context. The x86 codes pointed to in the two calls are >>>>>>>> identical or at least semantically equivalent so they specify the >>>>>>>> same behaviour.
Independently of above considerations the meaning of DDD is the >>>>>>>> same
in Simulate(DDD) and HHH(DDD).
This ChatGPT analysis of its input below
correctly derives both of our views.
Whatever ChatGPT says is irrelevant. If you can't defend your claims >>>>>> then your claims are undefencible.
I can and have proven my claims are verified facts:
https://github.com/plolcott/x86utm/blob/master/Halt7.c
and people disagreed anyway.
No, you have not. You have claimed that you have prooven but that is
not the same. Perhaps you don't know what a proof is but it certainly
is very different from anything you have ever presented.
*A proof is any sequence of steps deriving a necessary result*
https://github.com/plolcott/x86utm/blob/master/Halt7.c
No, it is not. There are additional requirements for each step. The
sequence is a proof only if those additional requirements are satisfied.
From a practical point of view, the purpose of a proof is to convince,
so what does not convince is not a proof.
Proves that HHH does correctly emulate DDD then correctly
emulates itself emulating DDD.
No, it does not. The presentation is not convincing about anything
and does not satisfy the requirements ot a proof.
The actual execution trace of DDD emulated by HHH
and DDD emulated by an emulated HHH does prove that
DDD has been correctly emulated by an emulated HHH.
_DDD()And this is *NOT* the correcxt simulaiton of a call HHH instrucitons.
[0000219e] 55 push ebp
[0000219f] 8bec mov ebp,esp
[000021a1] 689e210000 push 0000219e
[000021a6] e843f4ffff call 000015ee
[000021ab] 83c404 add esp,+04
[000021ae] 5d pop ebp
[000021af] c3 ret
Size in bytes:(0018) [000021af]
_main()
[000021be] 55 push ebp
[000021bf] 8bec mov ebp,esp
[000021c1] 689e210000 push 0000219e
[000021c6] e823f4ffff call 000015ee
[000021cb] 83c404 add esp,+04
[000021ce] 50 push eax
[000021cf] 685f070000 push 0000075f
[000021d4] e8a5e5ffff call 0000077e
[000021d9] 83c408 add esp,+08
[000021dc] 33c0 xor eax,eax
[000021de] 5d pop ebp
[000021df] c3 ret
Size in bytes:(0034) [000021df]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========== ============= [000021be][00103872][00000000] 55 push ebp [000021bf][00103872][00000000] 8bec mov ebp,esp [000021c1][0010386e][0000219e] 689e210000 push 0000219e // push DDD [000021c6][0010386a][000021cb] e823f4ffff call 000015ee // call HHH
New slave_stack at:103916
Begin Local Halt Decider Simulation Execution Trace Stored at:11391e [0000219e][0011390e][00113912] 55 push ebp [0000219f][0011390e][00113912] 8bec mov ebp,esp [000021a1][0011390a][0000219e] 689e210000 push 0000219e // push DDD [000021a6][00113906][000021ab] e843f4ffff call 000015ee // call HHH
New slave_stack at:14e33e
[0000219e][0015e336][0015e33a] 55 push ebp [0000219f][0015e336][0015e33a] 8bec mov ebp,esp [000021a1][0015e332][0000219e] 689e210000 push 0000219e // push DDD [000021a6][0015e32e][000021ab] e843f4ffff call 000015ee // call HHH
On 8/1/25 12:33 PM, olcott wrote:This has always been counter-factual even if
On 8/1/2025 11:29 AM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people make >>>>> sure to fail to notice the key elements of my keyWhen I tell Richard the exact same thing 500 times he continues to
points it has been proven that these key elements must be repeated >>>>>> until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
respond as it I never said it.
I kept telling Richard the HHH does simulate an instance itself
emulating an instance of DDD and can do this because HHH and DDD are in >>>> the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of itself
because it does not have access to this memory. I corrected him 20
times
on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through simulation >>> or some other means do the opposite of what HHH' decides (given HHH'
must
halt with a decision because HHH must halt with a decision).
/Flibble
Yet that makes the details more difficult to understand.
We must do that in the Linz proof. Whereas with my DDD/HHH
proof any C programmer knowing what recursion is can
see the repeating pattern.
Only too difficult for YOU to understand.
And changing definitions is just LYING>
But the criteria isn't based on the simulation of the decider, but of
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
the behavior of the program the input represents,
On 8/1/2025 12:17 PM, Richard Damon wrote:
On 8/1/25 12:33 PM, olcott wrote:This has always been counter-factual even if
On 8/1/2025 11:29 AM, Mr Flibble wrote:
On Fri, 01 Aug 2025 11:22:45 -0500, olcott wrote:
On 8/1/2025 11:03 AM, joes wrote:
Am Fri, 01 Aug 2025 10:54:52 -0500 schrieb olcott>> When people make >>>>>> sure to fail to notice the key elements of my keyWhen I tell Richard the exact same thing 500 times he continues to
points it has been proven that these key elements must be repeated >>>>>>> until someone bothers to pay attention.
That's not how it works. I skim over repetitions.
respond as it I never said it.
I kept telling Richard the HHH does simulate an instance itself
emulating an instance of DDD and can do this because HHH and DDD
are in
the same global memory space of Halt7.obj.
Richard keeps saying That HHH cannot simulate an instance of itself
because it does not have access to this memory. I corrected him 20
times
on this and he still does not get it.
DDD can analyse a COPY of HHH, lets call it HHH', and through
simulation
or some other means do the opposite of what HHH' decides (given HHH'
must
halt with a decision because HHH must halt with a decision).
/Flibble
Yet that makes the details more difficult to understand.
We must do that in the Linz proof. Whereas with my DDD/HHH
proof any C programmer knowing what recursion is can
see the repeating pattern.
Only too difficult for YOU to understand.
And changing definitions is just LYING>
But the criteria isn't based on the simulation of the decider, but of
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
the behavior of the program the input represents,
the authors of computer science textbooks never
noticed that it has always been counter-factual.
Saying that decider H is required report on the behavior
of machine M is a category error.
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.
Thus the behavior specified by the input finite string
overrules and supersedes the behavior of the direct
execution.
When machine description ⟨M⟩ correctly simulated
by H cannot possibly reach its own simulated final
halt state this proves that the ⟨M⟩ input to H specifies
a non-terminating sequence of configurations.
On 8/1/25 1:37 PM, olcott wrote:
On 8/1/2025 12:17 PM, Richard Damon wrote:
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.
Sure they can, since they CAN be given it as the representation.
On 8/1/2025 1:36 PM, Richard Damon wrote:
On 8/1/25 1:37 PM, olcott wrote:
On 8/1/2025 12:17 PM, Richard Damon wrote:
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.
Sure they can, since they CAN be given it as the representation.
Do you understand that a finite string machine description
is not itself a directly executing Turing machine?
You keep missing nuances of meaning in my above paragraph
because you don't actually read my words you only glance at them.
This is probably because of your attention deficit disorder.
What I find that I must do to avoid missing important semantic
meanings is that I have to read the same words over and over
a few times.
On 8/1/25 2:49 PM, olcott wrote:
On 8/1/2025 1:36 PM, Richard Damon wrote:
On 8/1/25 1:37 PM, olcott wrote:
On 8/1/2025 12:17 PM, Richard Damon wrote:
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.
Sure they can, since they CAN be given it as the representation.
Do you understand that a finite string machine description
is not itself a directly executing Turing machine?
But it can represent one.
You don't seem to understand how representations work.
A properly encoded representation of a Turing Machine fully defines the behavior of that machine, and that behavior becomes the MEANING of that string.
On 8/1/2025 2:49 PM, Richard Damon wrote:
On 8/1/25 2:49 PM, olcott wrote:
On 8/1/2025 1:36 PM, Richard Damon wrote:
On 8/1/25 1:37 PM, olcott wrote:
On 8/1/2025 12:17 PM, Richard Damon wrote:
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.
Sure they can, since they CAN be given it as the representation.
Do you understand that a finite string machine description
is not itself a directly executing Turing machine?
But it can represent one.
You don't seem to understand how representations work.
A properly encoded representation of a Turing Machine fully defines
the behavior of that machine, and that behavior becomes the MEANING of
that string.
That would intuitively seem to be impossibly false
until we see a counter-example that refutes it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
When ⟨Ĥ⟩ ⟨Ĥ⟩ is correctly simulated by Ĥ.embedded_H
even Mike was fooled into thinking that the simulated
⟨Ĥ⟩ would reach its simulated final state of ⟨Ĥ.qn⟩ if
we just waited long enough.
On 8/1/25 4:08 PM, olcott wrote:
On 8/1/2025 2:49 PM, Richard Damon wrote:
On 8/1/25 2:49 PM, olcott wrote:
On 8/1/2025 1:36 PM, Richard Damon wrote:
On 8/1/25 1:37 PM, olcott wrote:
On 8/1/2025 12:17 PM, Richard Damon wrote:
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.
Sure they can, since they CAN be given it as the representation.
Do you understand that a finite string machine description
is not itself a directly executing Turing machine?
But it can represent one.
You don't seem to understand how representations work.
A properly encoded representation of a Turing Machine fully defines
the behavior of that machine, and that behavior becomes the MEANING
of that string.
That would intuitively seem to be impossibly false
until we see a counter-example that refutes it.
No, it is a definition
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
When ⟨Ĥ⟩ ⟨Ĥ⟩ is correctly simulated by Ĥ.embedded_H
even Mike was fooled into thinking that the simulated
⟨Ĥ⟩ would reach its simulated final state of ⟨Ĥ.qn⟩ if
we just waited long enough.
No, if ⟨Ĥ⟩ ⟨Ĥ⟩ is actually correctly emulated by H/Ĥ.embedded_H it runs
forever because neither H or Ĥ.embedded_H will abort their simulation
and that emulation doesn't reach a final state and H fails to be a decider.
On 8/1/2025 3:23 PM, Richard Damon wrote:
On 8/1/25 4:08 PM, olcott wrote:
On 8/1/2025 2:49 PM, Richard Damon wrote:
On 8/1/25 2:49 PM, olcott wrote:
On 8/1/2025 1:36 PM, Richard Damon wrote:
On 8/1/25 1:37 PM, olcott wrote:
On 8/1/2025 12:17 PM, Richard Damon wrote:
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.
Sure they can, since they CAN be given it as the representation.
Do you understand that a finite string machine description
is not itself a directly executing Turing machine?
But it can represent one.
You don't seem to understand how representations work.
A properly encoded representation of a Turing Machine fully defines
the behavior of that machine, and that behavior becomes the MEANING
of that string.
That would intuitively seem to be impossibly false
until we see a counter-example that refutes it.
No, it is a definition
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
When ⟨Ĥ⟩ ⟨Ĥ⟩ is correctly simulated by Ĥ.embedded_H
even Mike was fooled into thinking that the simulated
⟨Ĥ⟩ would reach its simulated final state of ⟨Ĥ.qn⟩ if
we just waited long enough.
No, if ⟨Ĥ⟩ ⟨Ĥ⟩ is actually correctly emulated by H/Ĥ.embedded_H it
runs forever because neither H or Ĥ.embedded_H will abort their
simulation and that emulation doesn't reach a final state and H fails
to be a decider.
In other words neither Ĥ nor any human being
could possibly see the repeating sequence even
after it has repeated 100 million times?
On 8/1/25 4:33 PM, olcott wrote:
On 8/1/2025 3:23 PM, Richard Damon wrote:
On 8/1/25 4:08 PM, olcott wrote:
On 8/1/2025 2:49 PM, Richard Damon wrote:
On 8/1/25 2:49 PM, olcott wrote:
On 8/1/2025 1:36 PM, Richard Damon wrote:
On 8/1/25 1:37 PM, olcott wrote:
On 8/1/2025 12:17 PM, Richard Damon wrote:
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.
Sure they can, since they CAN be given it as the representation. >>>>>>>
Do you understand that a finite string machine description
is not itself a directly executing Turing machine?
But it can represent one.
You don't seem to understand how representations work.
A properly encoded representation of a Turing Machine fully defines >>>>> the behavior of that machine, and that behavior becomes the MEANING >>>>> of that string.
That would intuitively seem to be impossibly false
until we see a counter-example that refutes it.
No, it is a definition
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
When ⟨Ĥ⟩ ⟨Ĥ⟩ is correctly simulated by Ĥ.embedded_H
even Mike was fooled into thinking that the simulated
⟨Ĥ⟩ would reach its simulated final state of ⟨Ĥ.qn⟩ if
we just waited long enough.
No, if ⟨Ĥ⟩ ⟨Ĥ⟩ is actually correctly emulated by H/Ĥ.embedded_H it
runs forever because neither H or Ĥ.embedded_H will abort their
simulation and that emulation doesn't reach a final state and H fails
to be a decider.
In other words neither Ĥ nor any human being
could possibly see the repeating sequence even
after it has repeated 100 million times?
Doesn't matter if is can determine what will happen, to correctly
simulate the behavior, you have to do it.
On 8/1/2025 3:48 PM, Richard Damon wrote:
On 8/1/25 4:33 PM, olcott wrote:
On 8/1/2025 3:23 PM, Richard Damon wrote:
On 8/1/25 4:08 PM, olcott wrote:
On 8/1/2025 2:49 PM, Richard Damon wrote:
On 8/1/25 2:49 PM, olcott wrote:
On 8/1/2025 1:36 PM, Richard Damon wrote:
On 8/1/25 1:37 PM, olcott wrote:
On 8/1/2025 12:17 PM, Richard Damon wrote:
Turing machines cannot directly report on the behavior
of other Turing machines they can at best indirectly
report on the behavior of Turing machines through the
proxy of finite string machine descriptions such as ⟨M⟩.
Sure they can, since they CAN be given it as the representation. >>>>>>>>
Do you understand that a finite string machine description
is not itself a directly executing Turing machine?
But it can represent one.
You don't seem to understand how representations work.
A properly encoded representation of a Turing Machine fully
defines the behavior of that machine, and that behavior becomes
the MEANING of that string.
That would intuitively seem to be impossibly false
until we see a counter-example that refutes it.
No, it is a definition
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
When ⟨Ĥ⟩ ⟨Ĥ⟩ is correctly simulated by Ĥ.embedded_H
even Mike was fooled into thinking that the simulated
⟨Ĥ⟩ would reach its simulated final state of ⟨Ĥ.qn⟩ if
we just waited long enough.
No, if ⟨Ĥ⟩ ⟨Ĥ⟩ is actually correctly emulated by H/Ĥ.embedded_H it
runs forever because neither H or Ĥ.embedded_H will abort their
simulation and that emulation doesn't reach a final state and H
fails to be a decider.
In other words neither Ĥ nor any human being
could possibly see the repeating sequence even
after it has repeated 100 million times?
Doesn't matter if is can determine what will happen, to correctly
simulate the behavior, you have to do it.
It seems that even after hundreds of corrections
you still do not understand that this infinite
sequence can be correctly detected in finite steps.
On 8/1/25 5:08 PM, olcott wrote:
On 8/1/2025 3:48 PM, Richard Damon wrote:
On 8/1/25 4:33 PM, olcott wrote:
In other words neither Ĥ nor any human being
could possibly see the repeating sequence even
after it has repeated 100 million times?
Doesn't matter if is can determine what will happen, to correctly
simulate the behavior, you have to do it.
It seems that even after hundreds of corrections
you still do not understand that this infinite
sequence can be correctly detected in finite steps.
And you don't get that BY detecting that pattern, and putting that code
into HHH, you put it into the code of the DDD that you are simulating,
and it is no longer a non-halting pattern. It is only a non-hatling
pattern if the HHH in the pattern will never abort its simulation.
On 8/1/2025 4:30 PM, Richard Damon wrote:
On 8/1/25 5:08 PM, olcott wrote:
On 8/1/2025 3:48 PM, Richard Damon wrote:
On 8/1/25 4:33 PM, olcott wrote:
In other words neither Ĥ nor any human being
could possibly see the repeating sequence even
after it has repeated 100 million times?
Doesn't matter if is can determine what will happen, to correctly
simulate the behavior, you have to do it.
It seems that even after hundreds of corrections
you still do not understand that this infinite
sequence can be correctly detected in finite steps.
And you don't get that BY detecting that pattern, and putting that
code into HHH, you put it into the code of the DDD that you are
simulating, and it is no longer a non-halting pattern. It is only a
non-hatling pattern if the HHH in the pattern will never abort its
simulation.
When you intentionally define halting as stops running
for any reason this would be correct.
Since you know that this is not the correct way to
define halting, why do you define it that way?
On 8/1/25 5:47 PM, olcott wrote:
On 8/1/2025 4:30 PM, Richard Damon wrote:
On 8/1/25 5:08 PM, olcott wrote:
On 8/1/2025 3:48 PM, Richard Damon wrote:
On 8/1/25 4:33 PM, olcott wrote:
In other words neither Ĥ nor any human being
could possibly see the repeating sequence even
after it has repeated 100 million times?
Doesn't matter if is can determine what will happen, to correctly
simulate the behavior, you have to do it.
It seems that even after hundreds of corrections
you still do not understand that this infinite
sequence can be correctly detected in finite steps.
And you don't get that BY detecting that pattern, and putting that
code into HHH, you put it into the code of the DDD that you are
simulating, and it is no longer a non-halting pattern. It is only a
non-hatling pattern if the HHH in the pattern will never abort its
simulation.
When you intentionally define halting as stops running
for any reason this would be correct.
But I don't, as the only way that the PROGRAM/MACHINE CAN "stop running"
is by reaching a final state.
You can't "abort" or "shut down" a machine, only a simulation of it.
On 8/1/2025 5:01 PM, Richard Damon wrote:
On 8/1/25 5:47 PM, olcott wrote:
On 8/1/2025 4:30 PM, Richard Damon wrote:
On 8/1/25 5:08 PM, olcott wrote:
On 8/1/2025 3:48 PM, Richard Damon wrote:
On 8/1/25 4:33 PM, olcott wrote:
In other words neither Ĥ nor any human being
could possibly see the repeating sequence even
after it has repeated 100 million times?
Doesn't matter if is can determine what will happen, to correctly >>>>>> simulate the behavior, you have to do it.
It seems that even after hundreds of corrections
you still do not understand that this infinite
sequence can be correctly detected in finite steps.
And you don't get that BY detecting that pattern, and putting that
code into HHH, you put it into the code of the DDD that you are
simulating, and it is no longer a non-halting pattern. It is only a
non-hatling pattern if the HHH in the pattern will never abort its
simulation.
When you intentionally define halting as stops running
for any reason this would be correct.
But I don't, as the only way that the PROGRAM/MACHINE CAN "stop
running" is by reaching a final state.
You can't "abort" or "shut down" a machine, only a simulation of it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Thus unless you want to be disagreeable at all
possible costs you would agree that ⟨Ĥ⟩ ⟨Ĥ⟩
simulated by embedded_H cannot possibly reach
its own simulated final state of ⟨Ĥ.qn⟩ no
matter what.
On 8/1/25 6:22 PM, olcott wrote:
On 8/1/2025 5:01 PM, Richard Damon wrote:
On 8/1/25 5:47 PM, olcott wrote:
On 8/1/2025 4:30 PM, Richard Damon wrote:
On 8/1/25 5:08 PM, olcott wrote:
On 8/1/2025 3:48 PM, Richard Damon wrote:
On 8/1/25 4:33 PM, olcott wrote:
In other words neither Ĥ nor any human being
could possibly see the repeating sequence even
after it has repeated 100 million times?
Doesn't matter if is can determine what will happen, to correctly >>>>>>> simulate the behavior, you have to do it.
It seems that even after hundreds of corrections
you still do not understand that this infinite
sequence can be correctly detected in finite steps.
And you don't get that BY detecting that pattern, and putting that
code into HHH, you put it into the code of the DDD that you are
simulating, and it is no longer a non-halting pattern. It is only a >>>>> non-hatling pattern if the HHH in the pattern will never abort its
simulation.
When you intentionally define halting as stops running
for any reason this would be correct.
But I don't, as the only way that the PROGRAM/MACHINE CAN "stop
running" is by reaching a final state.
You can't "abort" or "shut down" a machine, only a simulation of it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Thus unless you want to be disagreeable at all
possible costs you would agree that ⟨Ĥ⟩ ⟨Ĥ⟩
simulated by embedded_H cannot possibly reach
its own simulated final state of ⟨Ĥ.qn⟩ no
matter what.
Which doesn't matter, dispite you wanting to focus on it.
On 8/1/2025 5:45 PM, Richard Damon wrote:
On 8/1/25 6:22 PM, olcott wrote:
On 8/1/2025 5:01 PM, Richard Damon wrote:
On 8/1/25 5:47 PM, olcott wrote:
On 8/1/2025 4:30 PM, Richard Damon wrote:
On 8/1/25 5:08 PM, olcott wrote:
On 8/1/2025 3:48 PM, Richard Damon wrote:
On 8/1/25 4:33 PM, olcott wrote:
In other words neither Ĥ nor any human being
could possibly see the repeating sequence even
after it has repeated 100 million times?
Doesn't matter if is can determine what will happen, to
correctly simulate the behavior, you have to do it.
It seems that even after hundreds of corrections
you still do not understand that this infinite
sequence can be correctly detected in finite steps.
And you don't get that BY detecting that pattern, and putting that >>>>>> code into HHH, you put it into the code of the DDD that you are
simulating, and it is no longer a non-halting pattern. It is only >>>>>> a non-hatling pattern if the HHH in the pattern will never abort
its simulation.
When you intentionally define halting as stops running
for any reason this would be correct.
But I don't, as the only way that the PROGRAM/MACHINE CAN "stop
running" is by reaching a final state.
You can't "abort" or "shut down" a machine, only a simulation of it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Thus unless you want to be disagreeable at all
possible costs you would agree that ⟨Ĥ⟩ ⟨Ĥ⟩
simulated by embedded_H cannot possibly reach
its own simulated final state of ⟨Ĥ.qn⟩ no
matter what.
Which doesn't matter, dispite you wanting to focus on it.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the
behavior that *THE ACTUAL INPUT* to embedded_H
specifies. Ĥ ⟨Ĥ⟩ is not and cannot possibly be
*AN ACTUAL INPUT* to embedded_H so its differing
behavior *DOES NOT COUNT*.
On 8/1/25 6:54 PM, olcott wrote:>>
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the
behavior that *THE ACTUAL INPUT* to embedded_H
specifies. Ĥ ⟨Ĥ⟩ is not and cannot possibly be
*AN ACTUAL INPUT* to embedded_H so its differing
behavior *DOES NOT COUNT*.
NO!!!!
By that standard, any input could mean anything becuase the machine it
is being given can do whatever it wants with it.
But then, that IS how you consider logic to work, so it makes sense that
is what you would think.
The *DEFINITION* of the "behavior of this input", for a halting decider,
is the behavior of the machine that input represent.
Anything else is just an admission of lying, as the problem statement isI don't worship textbook authors as infallible Gods.
to decide on the behavior of the machine that input represents.
Sorry, you just admitted you are just a blantant liar that doesn't
respect definitions, and thus NOTHING you say should be considered usable.
On 8/1/2025 6:15 PM, Richard Damon wrote:
On 8/1/25 6:54 PM, olcott wrote:>>
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the
behavior that *THE ACTUAL INPUT* to embedded_H
specifies. Ĥ ⟨Ĥ⟩ is not and cannot possibly be
*AN ACTUAL INPUT* to embedded_H so its differing
behavior *DOES NOT COUNT*.
NO!!!!
By that standard, any input could mean anything becuase the machine it
is being given can do whatever it wants with it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Yes if you ignore that I said that Ĥ.embedded_H
is based on a UTM and ignore the above is the
definition of machine Ĥ that could be true.
But then, that IS how you consider logic to work, so it makes sense
that is what you would think.
The *DEFINITION* of the "behavior of this input", for a halting
decider, is the behavior of the machine that input represent.
"Represents" is a vague weasel word that has been
used historically. "Specifies" is what has always
been meant.
Anything else is just an admission of lying, as the problem statementI don't worship textbook authors as infallible Gods.
is to decide on the behavior of the machine that input represents.
Sorry, you just admitted you are just a blantant liar that doesn't
respect definitions, and thus NOTHING you say should be considered
usable.
Even definitions can be proved wrong when they are
proved to contradict other definitions.
On 8/1/25 7:38 PM, olcott wrote:
On 8/1/2025 6:15 PM, Richard Damon wrote:
On 8/1/25 6:54 PM, olcott wrote:>>
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the
behavior that *THE ACTUAL INPUT* to embedded_H
specifies. Ĥ ⟨Ĥ⟩ is not and cannot possibly be
*AN ACTUAL INPUT* to embedded_H so its differing
behavior *DOES NOT COUNT*.
NO!!!!
By that standard, any input could mean anything becuase the machine
it is being given can do whatever it wants with it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Yes if you ignore that I said that Ĥ.embedded_H
is based on a UTM and ignore the above is the
definition of machine Ĥ that could be true.
"Based on" does not mean *IS*
If you add code to the original UTM, then it no longer is a UTM, and its partial simulation is not determative.
On 8/1/2025 6:57 PM, Richard Damon wrote:input ⟨Ĥ⟩
On 8/1/25 7:38 PM, olcott wrote:
On 8/1/2025 6:15 PM, Richard Damon wrote:
On 8/1/25 6:54 PM, olcott wrote:>>Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the behavior that *THENO!!!!
ACTUAL INPUT* to embedded_H specifies. Ĥ ⟨Ĥ⟩ is not and cannot >>>>> possibly be *AN ACTUAL INPUT* to embedded_H so its differing
behavior *DOES NOT COUNT*.
By that standard, any input could mean anything becuase the machine
it is being given can do whatever it wants with it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn (a) Ĥ copies its
*That is your one huge mistake*(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Yes if you ignore that I said that Ĥ.embedded_H is based on a UTM and
ignore the above is the definition of machine Ĥ that could be true.
"Based on" does not mean *IS*
If you add code to the original UTM, then it no longer is a UTM, and
its partial simulation is not determative.
As soon as the repeating pattern emerges then this repeating pattern
*is* determinative.
On Fri, 01 Aug 2025 19:07:44 -0500, olcott wrote:
On 8/1/2025 6:57 PM, Richard Damon wrote:*THE
On 8/1/25 7:38 PM, olcott wrote:
On 8/1/2025 6:15 PM, Richard Damon wrote:
On 8/1/25 6:54 PM, olcott wrote:>>
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the behavior that
input ⟨Ĥ⟩Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ACTUAL INPUT* to embedded_H specifies. Ĥ ⟨Ĥ⟩ is not and cannot >>>>>> possibly be *AN ACTUAL INPUT* to embedded_H so its differingNO!!!!
behavior *DOES NOT COUNT*.
By that standard, any input could mean anything becuase the machine
it is being given can do whatever it wants with it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn (a) Ĥ copies its
*That is your one huge mistake*(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Yes if you ignore that I said that Ĥ.embedded_H is based on a UTM and >>>> ignore the above is the definition of machine Ĥ that could be true.
"Based on" does not mean *IS*
If you add code to the original UTM, then it no longer is a UTM, and
its partial simulation is not determative.
As soon as the repeating pattern emerges then this repeating pattern
*is* determinative.
Recognising such a repeating pattern is no different to recognising
repeated state in a finite state machine however such a recogniser, a simulating halt decider, is only a partial decider so of little interest
as far as the Halting Problem is concerned.
/Flibble
On 8/1/2025 7:13 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 19:07:44 -0500, olcott wrote:
On 8/1/2025 6:57 PM, Richard Damon wrote:input ⟨Ĥ⟩
On 8/1/25 7:38 PM, olcott wrote:
On 8/1/2025 6:15 PM, Richard Damon wrote:
On 8/1/25 6:54 PM, olcott wrote:>>Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the behavior that >> *THENO!!!!
ACTUAL INPUT* to embedded_H specifies. Ĥ ⟨Ĥ⟩ is not and cannot >>>>>>> possibly be *AN ACTUAL INPUT* to embedded_H so its differing
behavior *DOES NOT COUNT*.
By that standard, any input could mean anything becuase the machine >>>>>> it is being given can do whatever it wants with it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn (a) Ĥ copies its
*That is your one huge mistake*(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Yes if you ignore that I said that Ĥ.embedded_H is based on a UTM
and ignore the above is the definition of machine Ĥ that could be
true.
"Based on" does not mean *IS*
If you add code to the original UTM, then it no longer is a UTM, and
its partial simulation is not determative.
As soon as the repeating pattern emerges then this repeating pattern
*is* determinative.
Recognising such a repeating pattern is no different to recognising
repeated state in a finite state machine however such a recogniser, a
simulating halt decider, is only a partial decider so of little
interest as far as the Halting Problem is concerned.
/Flibble
My sole purpose is to show that the conventional HP proofs do not prove undecidability. I have done that.
On 8/1/2025 6:57 PM, Richard Damon wrote:
On 8/1/25 7:38 PM, olcott wrote:
On 8/1/2025 6:15 PM, Richard Damon wrote:
On 8/1/25 6:54 PM, olcott wrote:>>
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the
behavior that *THE ACTUAL INPUT* to embedded_H
specifies. Ĥ ⟨Ĥ⟩ is not and cannot possibly be
*AN ACTUAL INPUT* to embedded_H so its differing
behavior *DOES NOT COUNT*.
NO!!!!
By that standard, any input could mean anything becuase the machine
it is being given can do whatever it wants with it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Yes if you ignore that I said that Ĥ.embedded_H
is based on a UTM and ignore the above is the
definition of machine Ĥ that could be true.
"Based on" does not mean *IS*
If you add code to the original UTM, then it no longer is a UTM, and
its partial simulation is not determative.
*That is your one huge mistake*
As soon as the repeating pattern emerges then
this repeating pattern *is* determinative.
On 8/1/2025 7:13 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 19:07:44 -0500, olcott wrote:
On 8/1/2025 6:57 PM, Richard Damon wrote:input ⟨Ĥ⟩
On 8/1/25 7:38 PM, olcott wrote:
On 8/1/2025 6:15 PM, Richard Damon wrote:
On 8/1/25 6:54 PM, olcott wrote:>>Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the behavior that >> *THENO!!!!
ACTUAL INPUT* to embedded_H specifies. Ĥ ⟨Ĥ⟩ is not and cannot >>>>>>> possibly be *AN ACTUAL INPUT* to embedded_H so its differing
behavior *DOES NOT COUNT*.
By that standard, any input could mean anything becuase the machine >>>>>> it is being given can do whatever it wants with it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn (a) Ĥ copies its
*That is your one huge mistake*(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Yes if you ignore that I said that Ĥ.embedded_H is based on a UTM and >>>>> ignore the above is the definition of machine Ĥ that could be true.
"Based on" does not mean *IS*
If you add code to the original UTM, then it no longer is a UTM, and
its partial simulation is not determative.
As soon as the repeating pattern emerges then this repeating pattern
*is* determinative.
Recognising such a repeating pattern is no different to recognising
repeated state in a finite state machine however such a recogniser, a
simulating halt decider, is only a partial decider so of little interest
as far as the Halting Problem is concerned.
/Flibble
My sole purpose is to show that the conventional HP proofs
do not prove undecidability. I have done that.
On Fri, 01 Aug 2025 19:25:54 -0500, olcott wrote:
On 8/1/2025 7:13 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 19:07:44 -0500, olcott wrote:
On 8/1/2025 6:57 PM, Richard Damon wrote:input ⟨Ĥ⟩
On 8/1/25 7:38 PM, olcott wrote:
On 8/1/2025 6:15 PM, Richard Damon wrote:
On 8/1/25 6:54 PM, olcott wrote:>>Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the behavior that >>> *THENO!!!!
ACTUAL INPUT* to embedded_H specifies. Ĥ ⟨Ĥ⟩ is not and cannot >>>>>>>> possibly be *AN ACTUAL INPUT* to embedded_H so its differing
behavior *DOES NOT COUNT*.
By that standard, any input could mean anything becuase the machine >>>>>>> it is being given can do whatever it wants with it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn (a) Ĥ copies its
*That is your one huge mistake*(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Yes if you ignore that I said that Ĥ.embedded_H is based on a UTM >>>>>> and ignore the above is the definition of machine Ĥ that could be >>>>>> true.
"Based on" does not mean *IS*
If you add code to the original UTM, then it no longer is a UTM, and >>>>> its partial simulation is not determative.
As soon as the repeating pattern emerges then this repeating pattern
*is* determinative.
Recognising such a repeating pattern is no different to recognising
repeated state in a finite state machine however such a recogniser, a
simulating halt decider, is only a partial decider so of little
interest as far as the Halting Problem is concerned.
/Flibble
My sole purpose is to show that the conventional HP proofs do not prove
undecidability. I have done that.
No you haven't as what you are trying to show has nothing to do with the Halting Problem which is only concerned with total deciders not partial deciders.
/Flibble
On 8/1/25 8:07 PM, olcott wrote:
On 8/1/2025 6:57 PM, Richard Damon wrote:
On 8/1/25 7:38 PM, olcott wrote:
On 8/1/2025 6:15 PM, Richard Damon wrote:
On 8/1/25 6:54 PM, olcott wrote:>>
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the
behavior that *THE ACTUAL INPUT* to embedded_H
specifies. Ĥ ⟨Ĥ⟩ is not and cannot possibly be
*AN ACTUAL INPUT* to embedded_H so its differing
behavior *DOES NOT COUNT*.
NO!!!!
By that standard, any input could mean anything becuase the machine >>>>> it is being given can do whatever it wants with it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Yes if you ignore that I said that Ĥ.embedded_H
is based on a UTM and ignore the above is the
definition of machine Ĥ that could be true.
"Based on" does not mean *IS*
If you add code to the original UTM, then it no longer is a UTM, and
its partial simulation is not determative.
*That is your one huge mistake*
As soon as the repeating pattern emerges then
this repeating pattern *is* determinative.
But there is no finite pattern that shows non-halting in the simulation
of DDD.
On 8/1/25 8:25 PM, olcott wrote:No this is counter-factual.
On 8/1/2025 7:13 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 19:07:44 -0500, olcott wrote:
On 8/1/2025 6:57 PM, Richard Damon wrote:input ⟨Ĥ⟩
On 8/1/25 7:38 PM, olcott wrote:
On 8/1/2025 6:15 PM, Richard Damon wrote:
On 8/1/25 6:54 PM, olcott wrote:>>Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the behavior that >>> *THENO!!!!
ACTUAL INPUT* to embedded_H specifies. Ĥ ⟨Ĥ⟩ is not and cannot >>>>>>>> possibly be *AN ACTUAL INPUT* to embedded_H so its differing
behavior *DOES NOT COUNT*.
By that standard, any input could mean anything becuase the machine >>>>>>> it is being given can do whatever it wants with it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn (a) Ĥ copies its
*That is your one huge mistake*(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩"Based on" does not mean *IS*
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Yes if you ignore that I said that Ĥ.embedded_H is based on a UTM and >>>>>> ignore the above is the definition of machine Ĥ that could be true. >>>>>
If you add code to the original UTM, then it no longer is a UTM, and >>>>> its partial simulation is not determative.
As soon as the repeating pattern emerges then this repeating pattern
*is* determinative.
Recognising such a repeating pattern is no different to recognising
repeated state in a finite state machine however such a recogniser, a
simulating halt decider, is only a partial decider so of little interest >>> as far as the Halting Problem is concerned.
/Flibble
My sole purpose is to show that the conventional HP proofs
do not prove undecidability. I have done that.
And you ignore that it has been shown that any finite pattern you try to detect becomes wrong,
On 8/1/2025 7:29 PM, Richard Damon wrote:
On 8/1/25 8:07 PM, olcott wrote:
On 8/1/2025 6:57 PM, Richard Damon wrote:
On 8/1/25 7:38 PM, olcott wrote:
On 8/1/2025 6:15 PM, Richard Damon wrote:
On 8/1/25 6:54 PM, olcott wrote:>>
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the
behavior that *THE ACTUAL INPUT* to embedded_H
specifies. Ĥ ⟨Ĥ⟩ is not and cannot possibly be
*AN ACTUAL INPUT* to embedded_H so its differing
behavior *DOES NOT COUNT*.
NO!!!!
By that standard, any input could mean anything becuase the
machine it is being given can do whatever it wants with it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Yes if you ignore that I said that Ĥ.embedded_H
is based on a UTM and ignore the above is the
definition of machine Ĥ that could be true.
"Based on" does not mean *IS*
If you add code to the original UTM, then it no longer is a UTM, and
its partial simulation is not determative.
*That is your one huge mistake*
As soon as the repeating pattern emerges then
this repeating pattern *is* determinative.
But there is no finite pattern that shows non-halting in the
simulation of DDD.
void DDD()
{
HHH(DDD);
return;
}
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
This is stipulated by the basic structure
of the relationship between DDD and each HHH.
On 8/1/2025 7:32 PM, Richard Damon wrote:
On 8/1/25 8:25 PM, olcott wrote:No this is counter-factual.
On 8/1/2025 7:13 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 19:07:44 -0500, olcott wrote:
On 8/1/2025 6:57 PM, Richard Damon wrote:*THE
On 8/1/25 7:38 PM, olcott wrote:
On 8/1/2025 6:15 PM, Richard Damon wrote:
On 8/1/25 6:54 PM, olcott wrote:>>
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the behavior that
input ⟨Ĥ⟩Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ACTUAL INPUT* to embedded_H specifies. Ĥ ⟨Ĥ⟩ is not and cannot >>>>>>>>> possibly be *AN ACTUAL INPUT* to embedded_H so its differing >>>>>>>>> behavior *DOES NOT COUNT*.NO!!!!
By that standard, any input could mean anything becuase the machine >>>>>>>> it is being given can do whatever it wants with it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn (a) Ĥ copies its
*That is your one huge mistake*(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩"Based on" does not mean *IS*
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Yes if you ignore that I said that Ĥ.embedded_H is based on a UTM >>>>>>> and
ignore the above is the definition of machine Ĥ that could be true. >>>>>>
If you add code to the original UTM, then it no longer is a UTM, and >>>>>> its partial simulation is not determative.
As soon as the repeating pattern emerges then this repeating pattern >>>>> *is* determinative.
Recognising such a repeating pattern is no different to recognising
repeated state in a finite state machine however such a recogniser, a
simulating halt decider, is only a partial decider so of little
interest
as far as the Halting Problem is concerned.
/Flibble
My sole purpose is to show that the conventional HP proofs
do not prove undecidability. I have done that.
And you ignore that it has been shown that any finite pattern you try
to detect becomes wrong,
A pattern cannot possibly become wrong.
void DDD()
{
HHH(DDD);
return;
}
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
This is stipulated by the basic structure
of the relationship between DDD and each HHH.
On 8/1/2025 7:29 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 19:25:54 -0500, olcott wrote:
On 8/1/2025 7:13 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 19:07:44 -0500, olcott wrote:
On 8/1/2025 6:57 PM, Richard Damon wrote:*THE
On 8/1/25 7:38 PM, olcott wrote:
On 8/1/2025 6:15 PM, Richard Damon wrote:
On 8/1/25 6:54 PM, olcott wrote:>>
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the behavior that
input ⟨Ĥ⟩Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ACTUAL INPUT* to embedded_H specifies. Ĥ ⟨Ĥ⟩ is not and cannot >>>>>>>>> possibly be *AN ACTUAL INPUT* to embedded_H so its differing >>>>>>>>> behavior *DOES NOT COUNT*.NO!!!!
By that standard, any input could mean anything becuase the machine >>>>>>>> it is being given can do whatever it wants with it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn (a) Ĥ copies its
*That is your one huge mistake*(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Yes if you ignore that I said that Ĥ.embedded_H is based on a UTM >>>>>>> and ignore the above is the definition of machine Ĥ that could be >>>>>>> true.
"Based on" does not mean *IS*
If you add code to the original UTM, then it no longer is a UTM, and >>>>>> its partial simulation is not determative.
As soon as the repeating pattern emerges then this repeating pattern >>>>> *is* determinative.
Recognising such a repeating pattern is no different to recognising
repeated state in a finite state machine however such a recogniser, a
simulating halt decider, is only a partial decider so of little
interest as far as the Halting Problem is concerned.
/Flibble
My sole purpose is to show that the conventional HP proofs do not prove
undecidability. I have done that.
No you haven't as what you are trying to show has nothing to do with the
Halting Problem which is only concerned with total deciders not partial
deciders.
/Flibble
I have showed that the conventional proofs of the halting problem
do not prove undecidability. It is reported that there are other unconventional proofs. Ben mentioned one of them.
int Sipser_D()
{
if (HHH(Sipser_D) == 1)
return 0;
return 1;
}
The proof that recursively enumerable languages are not
recursive seems to fall into the same trap that I derived.
On 8/1/25 9:49 PM, olcott wrote:
On 8/1/2025 7:29 PM, Richard Damon wrote:
On 8/1/25 8:07 PM, olcott wrote:
On 8/1/2025 6:57 PM, Richard Damon wrote:
On 8/1/25 7:38 PM, olcott wrote:
On 8/1/2025 6:15 PM, Richard Damon wrote:
On 8/1/25 6:54 PM, olcott wrote:>>
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the
behavior that *THE ACTUAL INPUT* to embedded_H
specifies. Ĥ ⟨Ĥ⟩ is not and cannot possibly be
*AN ACTUAL INPUT* to embedded_H so its differing
behavior *DOES NOT COUNT*.
NO!!!!
By that standard, any input could mean anything becuase the
machine it is being given can do whatever it wants with it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Yes if you ignore that I said that Ĥ.embedded_H
is based on a UTM and ignore the above is the
definition of machine Ĥ that could be true.
"Based on" does not mean *IS*
If you add code to the original UTM, then it no longer is a UTM,
and its partial simulation is not determative.
*That is your one huge mistake*
As soon as the repeating pattern emerges then
this repeating pattern *is* determinative.
But there is no finite pattern that shows non-halting in the
simulation of DDD.
void DDD()
{
HHH(DDD);
return;
}
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
This is stipulated by the basic structure
of the relationship between DDD and each HHH.
Then HHH can never abort its simulation to return 0
On 8/1/25 9:52 PM, olcott wrote:
On 8/1/2025 7:32 PM, Richard Damon wrote:
On 8/1/25 8:25 PM, olcott wrote:No this is counter-factual.
My sole purpose is to show that the conventional HP proofs
do not prove undecidability. I have done that.
And you ignore that it has been shown that any finite pattern you try
to detect becomes wrong,
A pattern cannot possibly become wrong.
It was always wrong.
Just because a pattern is found in a non-halting program doesn't mean
that the pattern proves non-halting behavior.
void DDD()
{
HHH(DDD);
return;
}
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
This is stipulated by the basic structure
of the relationship between DDD and each HHH.
Only if HHH is stipulated to always do a correct simulation, which means
it can not abort.
On 8/1/25 9:43 PM, olcott wrote:
On 8/1/2025 7:29 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 19:25:54 -0500, olcott wrote:
On 8/1/2025 7:13 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 19:07:44 -0500, olcott wrote:
On 8/1/2025 6:57 PM, Richard Damon wrote:*THE
On 8/1/25 7:38 PM, olcott wrote:
On 8/1/2025 6:15 PM, Richard Damon wrote:
On 8/1/25 6:54 PM, olcott wrote:>>
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the behavior that
input ⟨Ĥ⟩Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ >>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn (a) Ĥ copies itsACTUAL INPUT* to embedded_H specifies. Ĥ ⟨Ĥ⟩ is not and cannot >>>>>>>>>> possibly be *AN ACTUAL INPUT* to embedded_H so its differing >>>>>>>>>> behavior *DOES NOT COUNT*.NO!!!!
By that standard, any input could mean anything becuase the >>>>>>>>> machine
it is being given can do whatever it wants with it.
*That is your one huge mistake*(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Yes if you ignore that I said that Ĥ.embedded_H is based on a UTM >>>>>>>> and ignore the above is the definition of machine Ĥ that could be >>>>>>>> true.
"Based on" does not mean *IS*
If you add code to the original UTM, then it no longer is a UTM, and >>>>>>> its partial simulation is not determative.
As soon as the repeating pattern emerges then this repeating pattern >>>>>> *is* determinative.
Recognising such a repeating pattern is no different to recognising
repeated state in a finite state machine however such a recogniser, a >>>>> simulating halt decider, is only a partial decider so of little
interest as far as the Halting Problem is concerned.
/Flibble
My sole purpose is to show that the conventional HP proofs do not prove >>>> undecidability. I have done that.
No you haven't as what you are trying to show has nothing to do with the >>> Halting Problem which is only concerned with total deciders not partial
deciders.
/Flibble
I have showed that the conventional proofs of the halting problem
do not prove undecidability. It is reported that there are other
unconventional proofs. Ben mentioned one of them.
No, you have not, you have claimed that, but you lie by using the wrong meaning of words.
int Sipser_D()
{
if (HHH(Sipser_D) == 1)
return 0;
return 1;
}
The proof that recursively enumerable languages are not
recursive seems to fall into the same trap that I derived.
And what is your problem here? Nothing in the problem talks about
recursion,
On 8/2/2025 8:07 AM, Richard Damon wrote:
On 8/1/25 9:49 PM, olcott wrote:
On 8/1/2025 7:29 PM, Richard Damon wrote:
On 8/1/25 8:07 PM, olcott wrote:
On 8/1/2025 6:57 PM, Richard Damon wrote:
On 8/1/25 7:38 PM, olcott wrote:
On 8/1/2025 6:15 PM, Richard Damon wrote:
On 8/1/25 6:54 PM, olcott wrote:>>
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the
behavior that *THE ACTUAL INPUT* to embedded_H
specifies. Ĥ ⟨Ĥ⟩ is not and cannot possibly be
*AN ACTUAL INPUT* to embedded_H so its differing
behavior *DOES NOT COUNT*.
NO!!!!
By that standard, any input could mean anything becuase the
machine it is being given can do whatever it wants with it.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Yes if you ignore that I said that Ĥ.embedded_H
is based on a UTM and ignore the above is the
definition of machine Ĥ that could be true.
"Based on" does not mean *IS*
If you add code to the original UTM, then it no longer is a UTM,
and its partial simulation is not determative.
*That is your one huge mistake*
As soon as the repeating pattern emerges then
this repeating pattern *is* determinative.
But there is no finite pattern that shows non-halting in the
simulation of DDD.
void DDD()
{
HHH(DDD);
return;
}
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
This is stipulated by the basic structure
of the relationship between DDD and each HHH.
Then HHH can never abort its simulation to return 0
As soon as HHH recognizes the repeating pattern it can
kill the entire simulated process and reject DDD. There
is no stack unrolling because the process that would do
that has been killed.
On 8/2/2025 8:07 AM, Richard Damon wrote:
On 8/1/25 9:52 PM, olcott wrote:
On 8/1/2025 7:32 PM, Richard Damon wrote:
On 8/1/25 8:25 PM, olcott wrote:No this is counter-factual.
My sole purpose is to show that the conventional HP proofs
do not prove undecidability. I have done that.
And you ignore that it has been shown that any finite pattern you
try to detect becomes wrong,
A pattern cannot possibly become wrong.
It was always wrong.
Just because a pattern is found in a non-halting program doesn't mean
that the pattern proves non-halting behavior.
void DDD()
{
HHH(DDD);
return;
}
HHH simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
that simulates DDD that calls HHH(DDD)
This is stipulated by the basic structure
of the relationship between DDD and each HHH.
Only if HHH is stipulated to always do a correct simulation, which
means it can not abort.
A correct simulation of 2 statements of DDD proves
a repeating pattern that cannot possibly reach any
simulated final halt state.
I showed a correct simulation of 10 statements of DDD
so that you would look foolish denying that any repeating
pattern exists.
int Simulate(ptr x)
{
x();
return 1;
}
void Infinite_Recursion()
{
Simulate(Infinite_Recursion);
return;
}
A correct simulation of 2 statements of Infinite_Recursion
proves a repeating pattern that cannot possibly reach any
simulated final halt state.
On 8/2/2025 8:08 AM, Richard Damon wrote:
On 8/1/25 9:43 PM, olcott wrote:
On 8/1/2025 7:29 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 19:25:54 -0500, olcott wrote:
On 8/1/2025 7:13 PM, Mr Flibble wrote:
On Fri, 01 Aug 2025 19:07:44 -0500, olcott wrote:
On 8/1/2025 6:57 PM, Richard Damon wrote:*THE
On 8/1/25 7:38 PM, olcott wrote:
On 8/1/2025 6:15 PM, Richard Damon wrote:
On 8/1/25 6:54 PM, olcott wrote:>>
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by embedded_H determines the behavior that
input ⟨Ĥ⟩Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ >>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn (a) Ĥ copies itsACTUAL INPUT* to embedded_H specifies. Ĥ ⟨Ĥ⟩ is not and cannotNO!!!!
possibly be *AN ACTUAL INPUT* to embedded_H so its differing >>>>>>>>>>> behavior *DOES NOT COUNT*.
By that standard, any input could mean anything becuase the >>>>>>>>>> machine
it is being given can do whatever it wants with it.
*That is your one huge mistake*(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
Yes if you ignore that I said that Ĥ.embedded_H is based on a UTM >>>>>>>>> and ignore the above is the definition of machine Ĥ that could be >>>>>>>>> true.
"Based on" does not mean *IS*
If you add code to the original UTM, then it no longer is a UTM, >>>>>>>> and
its partial simulation is not determative.
As soon as the repeating pattern emerges then this repeating pattern >>>>>>> *is* determinative.
Recognising such a repeating pattern is no different to recognising >>>>>> repeated state in a finite state machine however such a recogniser, a >>>>>> simulating halt decider, is only a partial decider so of little
interest as far as the Halting Problem is concerned.
/Flibble
My sole purpose is to show that the conventional HP proofs do not
prove
undecidability. I have done that.
No you haven't as what you are trying to show has nothing to do with
the
Halting Problem which is only concerned with total deciders not partial >>>> deciders.
/Flibble
I have showed that the conventional proofs of the halting problem
do not prove undecidability. It is reported that there are other
unconventional proofs. Ben mentioned one of them.
No, you have not, you have claimed that, but you lie by using the
wrong meaning of words.
int Sipser_D()
{
if (HHH(Sipser_D) == 1)
return 0;
return 1;
}
The proof that recursively enumerable languages are not
recursive seems to fall into the same trap that I derived.
And what is your problem here? Nothing in the problem talks about
recursion,
int Sipser_D()
{
if (HHH(Sipser_D) == 1)
return 0;
return 1;
}
_Sipser_D()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 6862210000 push 00002162 // push Sipser_D
[0000216a] e863f4ffff call 000015d2 // call HHH
[0000216f] 83c404 add esp,+04
[00002172] 83f801 cmp eax,+01
[00002175] 7504 jnz 0000217b
[00002177] 33c0 xor eax,eax
[00002179] eb05 jmp 00002180
[0000217b] b801000000 mov eax,00000001
[00002180] 5d pop ebp
[00002181] c3 ret
Size in bytes:(0032) [00002181]
Sipser_D correctly emulated by HHH remains stuck in
recursive emulation until HHH aborts its emulation
and then kills the whole Sipser_D process before it
ever reaches the "if" statement. The HHH is correct
to return 0 rejecting Sipser_D() as non halting.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,064 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 150:09:51 |
| Calls: | 13,691 |
| Calls today: | 1 |
| Files: | 186,936 |
| D/L today: |
438 files (115M bytes) |
| Messages: | 2,410,975 |