On 1/22/22 10:48 AM, olcott wrote:
Halting problem undecidability and infinitely nested simulation (V3)
Take FIFTY TWO, I think you are stuck in an apparent infinite loop.
You keep on repeating the same basic mistakes.
We define Linz H to base its halt status decision on the behavior of
its pure simulation of N steps of its input. N is either the number of
steps that it takes for its simulated input to reach its final state
or the number of steps required for H to match an infinite behavior
pattern proving that the simulated input would never reach its own
final state. In this case H aborts the simulation of this input and
transitions to H.qn.
Such a pattern NOT existing for the <H^> <H^> pattern, thus your H can't correctly abort and becomes non-answering and thus FAILS to be a decider.
The non-existance has been proven and you have ignored that proof,
showing you have no counter for the proof.
If you want to claim such a pattern exists, you MUST provide it or
accept that your logic is just plain flawed as you are claiming the
existance of something that is impossible.
In effect, you are saying that if you have a halt decider for you halt decider to use, you can write a halt decider.
FAIL.
The following simplifies the syntax for the definition of the Linz
Turing machine Ĥ, it is now a single machine with a single start
state. A copy of Linz H is embedded at Ĥ.qx.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Because it is known that the UTM simulation of a machine is
computationally equivalent to the direct execution of this same
machine H can always form its halt status decision on the basis of
what the behavior of the UTM simulation of its inputs would be.
When Ĥ applied to ⟨Ĥ⟩ has embedded_H simulate ⟨Ĥ⟩ ⟨Ĥ⟩ these steps
would keep repeating:
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
But only if H never aborts, if H does abort, then the pattern is broken.
computation that halts … the Turing machine will halt whenever it
enters a final state. (Linz:1990:234)
This shows that the simulated input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ would never
reach its final state conclusively proving that this simulated input
never halts. This enables embedded_H to abort the simulation of its
input and correctly transition to Ĥ.qn.
No, it doesn't, it shows that the H^ built on an H that doesn't abort
will not halt, but that H doesn't answer. If H does abort, and thus can
give the answer, the logic is incorrect.
FAIL.
if embedded_H does correctly recognize an infinitely repeating
behavior pattern in the behavior of its simulated input: ⟨Ĥ⟩ applied
to ⟨Ĥ⟩ then embedded_H is necessarily correct to abort the simulation >> of its input and transition to Ĥ.qn.
Which it can not do, as shown to be impossible.
Because a halt decider is a decider embedded_H is only accountable for
computing the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or Ĥ.qn on the basis of the
behavior specified by these inputs. embedded_H is not accountable for
the behavior of the computation that it is contained within: Ĥ applied
to ⟨Ĥ⟩ because this is not an actual input to embedded_H.
As mentioned before, for the input <H^> <H^> when H^ is based on the H
that claims to correctly go to H.Qn, then UTM(<H^>,<H^>) is shown to
also go to H^.Qn and Halt, so the input that H IS accountable for
doesn't match the behavior that H assigns to it.
FAIL.
Halting problem undecidability and infinitely nested simulation (V3)
https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3
You are still using Fairy Dust powered Unicorns as the basis of your proof.
FAIL.
On 1/22/22 11:47 AM, olcott wrote:
On 1/22/2022 10:39 AM, Richard Damon wrote:
On 1/22/22 11:29 AM, olcott wrote:
On 1/22/2022 10:23 AM, Richard Damon wrote:
On 1/22/22 10:48 AM, olcott wrote:
Halting problem undecidability and infinitely nested simulation (V3) >>>>>Take FIFTY TWO, I think you are stuck in an apparent infinite loop.
You keep on repeating the same basic mistakes.
We define Linz H to base its halt status decision on the behavior
of its pure simulation of N steps of its input. N is either the
number of steps that it takes for its simulated input to reach its >>>>>> final state or the number of steps required for H to match an
infinite behavior pattern proving that the simulated input would
never reach its own final state. In this case H aborts the
simulation of this input and transitions to H.qn.
Such a pattern NOT existing for the <H^> <H^> pattern, thus your H
can't correctly abort and becomes non-answering and thus FAILS to
be a decider.
The non-existance has been proven and you have ignored that proof,
showing you have no counter for the proof.
If you want to claim such a pattern exists, you MUST provide it or
accept that your logic is just plain flawed as you are claiming the
existance of something that is impossible.
In effect, you are saying that if you have a halt decider for you
halt decider to use, you can write a halt decider.
FAIL.
The following simplifies the syntax for the definition of the Linz >>>>>> Turing machine Ĥ, it is now a single machine with a single start
state. A copy of Linz H is embedded at Ĥ.qx.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Because it is known that the UTM simulation of a machine is
computationally equivalent to the direct execution of this same
machine H can always form its halt status decision on the basis of >>>>>> what the behavior of the UTM simulation of its inputs would be.
When Ĥ applied to ⟨Ĥ⟩ has embedded_H simulate ⟨Ĥ⟩ ⟨Ĥ⟩ these steps
would keep repeating:
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
But only if H never aborts, if H does abort, then the pattern is
broken.
YOU ARE EITHER TOO IGNORANT OR DISHONEST TO ACKNOWLEDGE THE TRUTH OF
THIS:
The fact that there are no finite number of steps that the simulated
input to embedded_H would ever reach its final state conclusively
proves that embedded_H is correct to abort its simulation of this
input and transition to Ĥ.qn.
The problem is that any H that aborts after a finite number of steps,
gives the wrong answer because it only looked to see if the input
doesn't halt at some specific finite number.
OK IGNORANT it is. When there exists no finite (or infinite) number of
steps such that the simulated input to embedded_H reaches its final
state then we know that this simulated input does not halt.
And the only case when that happens is when H does not abort its
simulation,
On 1/22/22 12:19 PM, olcott wrote:
On 1/22/2022 11:13 AM, Richard Damon wrote:
On 1/22/22 11:47 AM, olcott wrote:WRONG !!! That happens in every possible case. The simulated input to
On 1/22/2022 10:39 AM, Richard Damon wrote:
On 1/22/22 11:29 AM, olcott wrote:
On 1/22/2022 10:23 AM, Richard Damon wrote:
On 1/22/22 10:48 AM, olcott wrote:
Halting problem undecidability and infinitely nested simulation >>>>>>>> (V3)
Take FIFTY TWO, I think you are stuck in an apparent infinite loop. >>>>>>>
You keep on repeating the same basic mistakes.
We define Linz H to base its halt status decision on the
behavior of its pure simulation of N steps of its input. N is
either the number of steps that it takes for its simulated input >>>>>>>> to reach its final state or the number of steps required for H >>>>>>>> to match an infinite behavior pattern proving that the simulated >>>>>>>> input would never reach its own final state. In this case H
aborts the simulation of this input and transitions to H.qn.
Such a pattern NOT existing for the <H^> <H^> pattern, thus your >>>>>>> H can't correctly abort and becomes non-answering and thus FAILS >>>>>>> to be a decider.
The non-existance has been proven and you have ignored that
proof, showing you have no counter for the proof.
If you want to claim such a pattern exists, you MUST provide it
or accept that your logic is just plain flawed as you are
claiming the existance of something that is impossible.
In effect, you are saying that if you have a halt decider for you >>>>>>> halt decider to use, you can write a halt decider.
FAIL.
The following simplifies the syntax for the definition of the
Linz Turing machine Ĥ, it is now a single machine with a single >>>>>>>> start state. A copy of Linz H is embedded at Ĥ.qx.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Because it is known that the UTM simulation of a machine is
computationally equivalent to the direct execution of this same >>>>>>>> machine H can always form its halt status decision on the basis >>>>>>>> of what the behavior of the UTM simulation of its inputs would be. >>>>>>>>
When Ĥ applied to ⟨Ĥ⟩ has embedded_H simulate ⟨Ĥ⟩ ⟨Ĥ⟩ these
steps would keep repeating:
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩...
But only if H never aborts, if H does abort, then the pattern is >>>>>>> broken.
YOU ARE EITHER TOO IGNORANT OR DISHONEST TO ACKNOWLEDGE THE TRUTH
OF THIS:
The fact that there are no finite number of steps that the
simulated input to embedded_H would ever reach its final state
conclusively proves that embedded_H is correct to abort its
simulation of this input and transition to Ĥ.qn.
The problem is that any H that aborts after a finite number of
steps, gives the wrong answer because it only looked to see if the
input doesn't halt at some specific finite number.
OK IGNORANT it is. When there exists no finite (or infinite) number
of steps such that the simulated input to embedded_H reaches its
final state then we know that this simulated input does not halt.
And the only case when that happens is when H does not abort its
simulation,
embedded_H cannot possibly ever reach its final state NO MATTER WHAT !!!
But if H/embedded_H aborts its simulation, it doesn't matter if IT sees
it or not, as it isn't then a UTM any longer.
If H aborts its simulation and goes to H.Qn then H^ applied to <H^> and
the UTM Simulation of <H^> <H^> will go to H^.Qn and Halt.
THAT is what matters, and shows that H was wromg.
You keep on believing a false source of 'truth'.
FAIL.
Halting problem undecidability and infinitely nested simulation (V3)
https://www.researchgate.net/publication/358009319_Halting_problem_undecidability_and_infinitely_nested_simulation_V3
On 1/22/22 3:42 PM, olcott wrote:
On 1/22/2022 2:27 PM, Richard Damon wrote:
On 1/22/22 1:53 PM, olcott wrote:
On 1/22/2022 12:42 PM, Richard Damon wrote:
On 1/22/22 1:26 PM, olcott wrote:
On 1/22/2022 12:21 PM, Richard Damon wrote:But it does. embeddd_H can't simuate to that point,
On 1/22/22 12:53 PM, olcott wrote:
On 1/22/2022 11:33 AM, Richard Damon wrote:
On 1/22/22 12:19 PM, olcott wrote:
On 1/22/2022 11:13 AM, Richard Damon wrote:
On 1/22/22 11:47 AM, olcott wrote:WRONG !!! That happens in every possible case. The simulated >>>>>>>>>> input to embedded_H cannot possibly ever reach its final state >>>>>>>>>> NO MATTER WHAT !!!
On 1/22/2022 10:39 AM, Richard Damon wrote:
On 1/22/22 11:29 AM, olcott wrote:OK IGNORANT it is. When there exists no finite (or infinite) >>>>>>>>>>>> number of steps such that the simulated input to embedded_H >>>>>>>>>>>> reaches its final state then we know that this simulated >>>>>>>>>>>> input does not halt.
On 1/22/2022 10:23 AM, Richard Damon wrote:
On 1/22/22 10:48 AM, olcott wrote:
Halting problem undecidability and infinitely nested >>>>>>>>>>>>>>>> simulation (V3)
Take FIFTY TWO, I think you are stuck in an apparent >>>>>>>>>>>>>>> infinite loop.
You keep on repeating the same basic mistakes.
Such a pattern NOT existing for the <H^> <H^> pattern, >>>>>>>>>>>>>>> thus your H can't correctly abort and becomes
We define Linz H to base its halt status decision on the >>>>>>>>>>>>>>>> behavior of its pure simulation of N steps of its input. >>>>>>>>>>>>>>>> N is either the number of steps that it takes for its >>>>>>>>>>>>>>>> simulated input to reach its final state or the number >>>>>>>>>>>>>>>> of steps required for H to match an infinite behavior >>>>>>>>>>>>>>>> pattern proving that the simulated input would never >>>>>>>>>>>>>>>> reach its own final state. In this case H aborts the >>>>>>>>>>>>>>>> simulation of this input and transitions to H.qn. >>>>>>>>>>>>>>>
non-answering and thus FAILS to be a decider.
The non-existance has been proven and you have ignored >>>>>>>>>>>>>>> that proof, showing you have no counter for the proof. >>>>>>>>>>>>>>>
If you want to claim such a pattern exists, you MUST >>>>>>>>>>>>>>> provide it or accept that your logic is just plain flawed >>>>>>>>>>>>>>> as you are claiming the existance of something that is >>>>>>>>>>>>>>> impossible.
In effect, you are saying that if you have a halt decider >>>>>>>>>>>>>>> for you halt decider to use, you can write a halt decider. >>>>>>>>>>>>>>>
FAIL.
The following simplifies the syntax for the definition >>>>>>>>>>>>>>>> of the Linz Turing machine Ĥ, it is now a single machine >>>>>>>>>>>>>>>> with a single start state. A copy of Linz H is embedded >>>>>>>>>>>>>>>> at Ĥ.qx.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>>>>>>>>>>>>>>>
Because it is known that the UTM simulation of a machine >>>>>>>>>>>>>>>> is computationally equivalent to the direct execution of >>>>>>>>>>>>>>>> this same machine H can always form its halt status >>>>>>>>>>>>>>>> decision on the basis of what the behavior of the UTM >>>>>>>>>>>>>>>> simulation of its inputs would be.
When Ĥ applied to ⟨Ĥ⟩ has embedded_H simulate ⟨Ĥ⟩ ⟨Ĥ⟩
these steps would keep repeating:
Ĥ copies its input ⟨Ĥ⟩ to ⟨Ĥ⟩ then embedded_H simulates
⟨Ĥ⟩ ⟨Ĥ⟩...
But only if H never aborts, if H does abort, then the >>>>>>>>>>>>>>> pattern is broken.
YOU ARE EITHER TOO IGNORANT OR DISHONEST TO ACKNOWLEDGE >>>>>>>>>>>>>> THE TRUTH OF THIS:
The fact that there are no finite number of steps that the >>>>>>>>>>>>>> simulated input to embedded_H would ever reach its final >>>>>>>>>>>>>> state conclusively proves that embedded_H is correct to >>>>>>>>>>>>>> abort its simulation of this input and transition to Ĥ.qn. >>>>>>>>>>>>>>
The problem is that any H that aborts after a finite number >>>>>>>>>>>>> of steps, gives the wrong answer because it only looked to >>>>>>>>>>>>> see if the input doesn't halt at some specific finite number. >>>>>>>>>>>>
And the only case when that happens is when H does not abort >>>>>>>>>>> its simulation,
But if H/embedded_H aborts its simulation, it doesn't matter if >>>>>>>>> IT sees it or not, as it isn't then a UTM any longer.
It remains true (invariant) that the simulated input to
embedded_H cannot possibly ever reach its final state no matter >>>>>>>> what embedded_H does, thus conclusively proving that this input >>>>>>>> never halts.
If H aborts its simulation and goes to H.Qn then H^ applied to >>>>>>>>> <H^> and the UTM Simulation of <H^> <H^> will go to H^.Qn and >>>>>>>>> Halt.
Because a halt decider is a decider embedded_H is only
accountable for computing the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qy or
Ĥ.qn on the basis of the behavior specified by these inputs.
embedded_H is not accountable for the behavior of the
computation that it is contained within: Ĥ applied to ⟨Ĥ⟩ >>>>>>>> because this is not an actual input to embedded_H.
Right, and if H(<H^>,<H^>) -> H.Qn then the proper simulation by >>>>>>> the computation UTM(<H^>,<H^>) will show that H^ also go to H^.Qn >>>>>>> and Halt.
THAT is the defined behavior of the actual input to H.
You can define that a cat is a dog, yet the actual simulated input >>>>>> to embedded_H cannot possibly reach its final state NO MATTER WHAT. >>>>>
If the simulated input cannot possibly every reach its final state
no matter what embedded_H does then this simulated input is
correctly determined to meet the Linz definition of never halting.
Except that the simulated input DOES reach its final state if
H/embeded_H goes to H.Qn.
Before embedded_H transitions to Ĥ.qn it has already aborted its
simulated input making it utterly impossible for any aspect of this
simulated input to do anything at all.
Then you are just talking POOP and not halting.
Remember, the definition of Halting is based on what a UTM does with the exact same input, and the UTM WON'T (in fact CAN'T) abort the simulation
at that point but continues on, and that H^ will continue on to use a
copy of H that will do that exact same simulation and abort its
simulation (but not the running of its 'caller'), and transition to H.Qn which means H^ goes to H^.Qn and Halts.
FAIL.
It is just like unplugging your computer, zero more steps are executed.
Except Halting isn't based on what a particular copy does, but what any
copy would do if allowed to run.
FAIL
Seems to me to be just more POOP.
CLEANUP ON AISLE 52, someone has left POOP all over the floor.
On 1/22/22 11:34 PM, olcott wrote:
On 1/22/2022 3:36 PM, Richard Damon wrote:
On 1/22/22 4:25 PM, olcott wrote:
On 1/22/2022 3:20 PM, Richard Damon wrote:
This is true for infinite loops, infinite recursion, infinitely
nested simulation and all other non halting inputs:
When-so-ever any simulated input to any simulating halt decider
would never reach the final state of this simulated input in any
finite number of steps it is always correct for the simulating halt
decider to abort its simulation and transition to its reject state.
Can you PROVE that statement, or is this just one of your false 'self
evident truth'.
Anyone that knows that x86 language can tell that its easy to match
the infinite loop pattern:
_Infinite_Loop()
[000015fa](01) 55 push ebp
[000015fb](02) 8bec mov ebp,esp
[000015fd](02) ebfe jmp 000015fd
[000015ff](01) 5d pop ebp
[00001600](01) c3 ret
Size in bytes:(0007) [00001600]
---[000015fa][002126f0][002126f4] 55 push ebp
---[000015fb][002126f0][002126f4] 8bec mov ebp,esp
---[000015fd][002126f0][002126f4] ebfe jmp 000015fd
---[000015fd][002126f0][002126f4] ebfe jmp 000015fd
Showing that you can do one case does not prove that the same method
works on all, particularly harder methods.
That is just you serving Red Herring.
And that pattern does NOT show up in the simulation by H of H^
Which makes it MORE lies by Red Herring.
FAIL.
Total lack of proof.
Does the proof include the posibility that the input includes a copy
of the decider?
It is always the case that a simulating halt decider can correctly
base its halt status decision on the behavior pure simulation of its
input.
LIE.
Proven incorrect.
If H -> H.Qn then H^ -> H^.Qn and Halts and for H^ <H^> proves H wrong.
We know that this must be true because we know that the pure UTM
simulation of an Turing Machine description is defined to have
equivalent behavior to that of the direct execution of the same machine
Right, but that does't prove what you sy.
You are just LYING out of your POOP.
The problem is that IF the simulating halt decider does abort its
input based on some condition, then it is no longer a source of truth
for the halting status of that input.
It is not answering the question: Does the input stop running?
YOU need to answer, which H are you using?
If H doesn't abort, then H^ is non-halting, but H will never answer.
If H does abort and go to H.Qn, then the pure simulation of the input
WILL halt at H^.Qn, so H was wrong.
FAIL.
It is answering the question:
Would the pure simulation of the input ever stop running?
Right, and if H -> H.Qn it will.
FAIL.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 121:51:10 |
| Calls: | 6,662 |
| Files: | 12,212 |
| Messages: | 5,334,491 |