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,075 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 90:35:20 |
| Calls: | 13,798 |
| Calls today: | 1 |
| Files: | 186,989 |
| D/L today: |
5,332 files (1,536M bytes) |
| Messages: | 2,438,212 |