On Monday, February 7, 2022 at 7:52:39 PM UTC-6, olcott wrote:
On 2/7/2022 7:26 PM, Richard Damon wrote:
On 2/7/22 8:08 PM, olcott wrote:
On 2/7/2022 5:46 PM, Richard Damon wrote:
On 2/7/22 9:59 AM, olcott wrote:
On 2/7/2022 5:47 AM, Richard Damon wrote:
On 2/6/22 11:30 PM, olcott wrote:
On 2/6/2022 10:05 PM, Richard Damon wrote:
When embedded_H matches this infinite pattern in the same three >>>>>>>> iterations:
On 2/6/22 10:04 PM, olcott wrote:
On 2/6/2022 3:39 PM, Richard Damon wrote:
On 2/6/22 3:53 PM, olcott wrote:
On 2/6/2022 2:33 PM, Richard Damon wrote:
On 2/6/22 3:15 PM, olcott wrote:
On 2/6/2022 1:43 PM, dklei...@gmail.com wrote:
On Sunday, February 6, 2022 at 8:31:41 AM UTC-8, olcott wrote: >>>>>>>>>>>>>>>>
H determines [halting] on the basis of matching infinite >>>>>>>>>>>>>>>> behavior patterns.This is incomplete because it does not cover the case where >>>>>>>>>>>>>>> the
When an infinite behavior pattern is matched H aborts its >>>>>>>>>>>>>>>> simulation and
transitions to its final reject state. Otherwise H >>>>>>>>>>>>>>>> transitions to its
accept state when its simulation ends.
machine neither halts nor matches an "infinite behavior >>>>>>>>>>>>>>> pattern".
It covers the case that had previously been considered to be >>>>>>>>>>>>>> proof that the halting problem is undecidable. That is all >>>>>>>>>>>>>> that I need to refute these proofs.
You need to prove a theorem: There is a finite set of >>>>>>>>>>>>>>> patterns such
that every Turing machine either halts or matches one of these >>>>>>>>>>>>>>> patterns.
But I feel sure that theorem is not true.
To solve the halting problem my program must be all knowing. >>>>>>>>>>>>>> To refute the proofs I merely need to show that their >>>>>>>>>>>>>> counter-example can be proved to never halt.
And you just ignore the fact that if H applied to <H^> <H^> >>>>>>>>>>>>> goes to H.Qn, then by construction H^ <H^> goes to H^.Qn, and >>>>>>>>>>>>> halts, and since H, to be an accurate Halt Decider, must only >>>>>>>>>>>>> go to H,Qn if the machine its input represents will never >>>>>>>>>>>>> halt. They you also don't seem to understand that the >>>>>>>>>>>>> computaton that <H^> <H^> represents IS H^ applied to <H^>. >>>>>>>>>>>>> So, H was just wrong.
So, you haven't actually proved the thing you claim youhave, >>>>>>>>>>>>> but only that you have amassed an amazing pile of unsound >>>>>>>>>>>>> logic based on wrong definitions that have hoodwinked >>>>>>>>>>>>> yourself into thinking you have shown something useful. >>>>>>>>>>>>>
You are so good at doing this that you have gaslighted >>>>>>>>>>>>> yourself so you can't actually understand what actual Truth is. >>>>>>>>>>>>>
You simply do know know enough computer science to understand >>>>>>>>>>>> that you are wrong and never will because you believe that you >>>>>>>>>>>> are right.
And you clearly don't know enough Computation Theory to talk >>>>>>>>>>> about it.
Since the is a Theorm in Computation Theory, using Computation >>>>>>>>>>> Theory Deffinitions, that is your problem.
And if you are working on the Halting Problem of Computation >>>>>>>>>>> Theory, BY DEFINITION, the meaning of 'correcty simulted' is >>>>>>>>>>> simulation by a REAL UTM which BY DEFINITION exactly matches >>>>>>>>>>> the behavior of Computation that it is representation of, which >>>>>>>>>>> for <H^> <H^> is H^ applied to <H^>
Because all simulating halt deciders are deciders they are >>>>>>>>>>>> only accountable for computing the mapping from their input >>>>>>>>>>>> finite strings to an accept or reject state on the basis of >>>>>>>>>>>> whether or not their correctly simulated input could ever >>>>>>>>>>>> reach its final state: ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ⟨Ĥ⟩.qn. >>>>>>>>>>>
If an infinite number is steps is not enough steps for the >>>>>>>>>> correct simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H to transition to
⟨Ĥ⟩.qn then the input to embedded_H meets the Linz definition of
a sequence of configurations that never halts.
WRONG.
If embedded_H DOES an infinite number of steps and doesn't reach >>>>>>>>> a final state, then it shows its input never halts.
Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩
⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩
⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩
⟨Ĥ5⟩...
that you agreed show the simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H will
never reach ⟨Ĥ⟩.qn in any number of steps, which proves that this >>>>>>>> input cannot possibly meet the Linz definition of halting:
computation that halts … the Turing machine will halt whenever it >>>>>>>> enters a final state. (Linz:1990:234)
OK, so the only computatiopn that you show that does not halt is H, >>>>>>> so H can not be a decider.
In the above example embedded_H simulates three iterations of nested >>>>>> simulation to match the infinitely nested simulation pattern.
In reality it needs less than this to match this pattern.
And if it doesn't do an infinite number, the H^ that is using it will >>>>> Halt,
embedded_H only examines the actual behavior of its inputs as if its
was a guard assigned to watch the front. If someone comes in the back
door (non-inputs) embedded_H is not even allowed to pay attention.
If the 'actual behavior' of the input <H^> <H^> is not the behavior of
H^ applied to <H^> you are lying about doing the Halting Problem.
If it is true that the simulated input to embedded_H cannot possibly
ever reach its final state of ⟨Ĥ⟩.qn, then nothing in the universe can >> possibly contradict the fact that the input specifies a non-halting
sequences of configurations. If God himself said otherwise then God
himself would be a liar.
If we know that we have a black cat then we know that we have a cat.
If we know that we have a sequence of configurations that cannot
possibly ever reach its final state then we know that we have a
non-halting sequence of configurations.
--
Copyright 2021 Pete Olcott
Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer
If someone is obsessed with halting how do you ever halt them?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 366 |
Nodes: | 16 (2 / 14) |
Uptime: | 03:07:57 |
Calls: | 7,812 |
Calls today: | 15 |
Files: | 12,924 |
Messages: | 5,749,460 |