On 2/9/2022 6:13 AM, Richard Damon wrote:
> On 2/8/22 9:19 PM, olcott wrote:
>> On 2/8/2022 7:39 PM, Richard Damon wrote:
>>> On 2/8/22 7:31 PM, olcott wrote:
>>>> On 2/8/2022 6:04 PM, Richard Damon wrote:
>>>>> On 2/8/22 10:35 AM, olcott wrote:
>>>>>> On 2/8/2022 5:56 AM, Richard Damon wrote:
>>>>>>> On 2/8/22 12:28 AM, olcott wrote:
>>>>>>>> On 2/7/2022 8:03 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 2/7/22 8:52 PM, 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:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> This is incomplete because it does not cover the
>>>>>>>>>>>>>>>>>>>>>>> case where the
>>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 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^>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>> When embedded_H matches this infinite pattern in the
>>>>>>>>>>>>>>>> same three iterations:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Except that if H/embedded_H aborts its simulation and goes to
>>>>>>>>> H.Qn, then the CORRECT simulation of its input (that done by a
>>>>>>>>> REAL UTM) will show that it will go to H^.Qn.
>>>>>>>>>
>>>>>>>>> All you have proven is that if H doesn't abort, and thus
>>>>>>>>> doesn't go to H.Qn, and thus fails to be a correct decider,
>>>>>>>>> then H^ applied to <H^> is non-halting.
>>>>>>>>>
>>>>>>>>> You keep on thinking that a simulation that aborts its
>>>>>>>>> simulation is a 'correct' simulation. By the definition in
>>>>>>>>> Computation Theory, this is not true. If you think it is, it
>>>>>>>>> just proves that you don't understand the field.
>>>>>>>>>
>>>>>>>>> FAIL.
>>>>>>>>>
>>>>>>>>>> If we know that we have a black cat then we know that we have
>>>>>>>>>> a cat.
>>>>>>>>>
>>>>>>>>> Except that if you DON'T have a black cat but think you do then
>>>>>>>>> you are wrong. If H aborts its simulation, it isn't a UTM and
>>>>>>>>> doesn't 'correctly' simulate.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Except that is has been PROVEN that if H -> H.Qn then the
>>>>>>>>> pattern WILL reach the final state.
>>>>>>>>>
>>>>>>>>> The fact that H can't ever reach that state proves just proves
>>>>>>>>> that if H is a UTM, which don't abort, then H^ will be
>>>>>>>>> non-halting, but H is still wrong for not answering. If H does
>>>>>>>>> abort, then it hasn't proven anything, and it has been proven
>>>>>>>>> that it is wrong.
>>>>>>>>>
>>>>>>>>> FAIL
>>>>>>>>
>>>>>>>> You are either not bright enough to get this or dishonest.
>>>>>>>> I don't care which, I need to up my game to computer scientists.
>>>>>>>>
>>>>>>>
>>>>>>> So, can't refute what I say so you go to arguing by insults,
>>>>>>> classic Olcott logical fallicy.
>>>>>>>
>>>>>>
>>>>>> Fundamentally you seem to lack the intellectual capacity to
>>>>>> understand what I am saying. This is proven on the basis that what
>>>>>> I am saying can be verified as true entirely on the basis of the
>>>>>> meaning of its words.
>>>>>
>>>>> Except that it has been shown that you keep on using the WRONG
>>>>> definitions of the words.
>>>>>
>>>>> A UTM can NEVER abort its simulation as BY DEFINITION, a UTM
>>>>> EXACTLY repoduces the behavior of its input (so if it is
>>>>> non-halting, so will the UTM). Also you think that there can be a
>>>>> 'Correct Simulation' by something that is NOT actully a UTM.
>>>>>
>>>>> Care to show anywhere where your misdefinitions are support in the
>>>>> field fo Computation Theory.
>>>>>
>>>>> That just PROVES that you aren't actually working on the Halting
>>>>> Problem of Computation Theory.
>>>>>
>>>>>>
>>>>>>> Face it, you are just WRONG about your assertions, maybe because
>>>>>>> you just don't know the field, so don't have any idea what is
>>>>>>> legal or not.
>>>>>>>
>>>>>>> Also note, you keep talking about needing 'Computer Scientists'
>>>>>>> to understand, that is really incorrect, you need to be able to
>>>>>>> explain it to someone who understands Computation Theory, which
>>>>>>> is a fairly specialized branch of Mathematics. Yes, it is part of
>>>>>>> the foundation of Computer Science, but isn't the sort of thing
>>>>>>> that a normal Computer Scientist will deal with day to day.
>>>>>>
>>>>>> I need someone to analyze what I am saying on the deep meaning of
>>>>>> what I am saying instead of mere rote memorized meanings from
>>>>>> textbooks.
>>>>>
>>>>> No, you need to learn that words have PRECISE meanings, and you
>>>>> aren't allowed to change them, no mwtter how much it 'makes sense'
>>>>> to do so.
>>>>>
>>>>>>
>>>>>> The key mistake that my reviewers are making is that they believe
>>>>>> that the halt decider is supposed to evaluate its input on the
>>>>>> basis of some proxy for the actual behavior of this actual input
>>>>>> rather than the actual behavior specified by this actual input.
>>>>>>
>>>>>
>>>>>
>>>>> Just proves you aren't working on the Halting Problem, as the
>>>>> DEFINITION of the Halting problems says that it is, because you
>>>>> don't actually understand the meaning of 'actual behavior'.
>>>>>
>>>>> From Linz, H applied to wM w needs to go to H.Qy IFF M applied to w
>>>>> halts, and to H,Qn if M applied to w will never halt.
>>>>>
>>>>
>>>> If you are supposed to report when Bill arrives at your house and
>>>> Sam arrives at you house and you really really believe that Sam's
>>>> arrival is a valid proxy for Bill's arrival then when I ask you did
>>>> Bill arrive at your house? you say "yes" even though correct the
>>>> answer is "no".
>>>
>>> You really like to make you Herrings Red, don't you.
>>>
>>> REMEMBER, the DEFINTION of a Halt Decider is that H applied to wM w
>>> is based on the behavior of M applied to w.
>>>
>>> YOU are the one making the wrong report.
>>
>> When anyone in the universe defines something besides the actual
>> behavior specified by the input to embedded_H as the only correct halt
>> status criterion measure that might as well say that cats are not
>> animals.
>>
>>
>
> Just shows your problem in comprehension, doesn't it. You just refuse to
> accept the definition because it doesn't match your idea of what you need.
>
> Note, 'The Actual Behavior specifeid by the input' IS precisly defined,
> and it IS the behavior that the input specifes, The input to the decider
> is the description of a computation, and the actual behavior sepecified
> by the input is by defintion the behavior of that computation that the
> input describes.
>
> YOU are the one that wants to change it to not be the behavior specified
> by the input, but the behavior of the program that is processing the
> input. YOUR definition of the behavior has the problem that the behavior
> is no longer just specified by 'the input' but is also a function of
> what program you give that input to.
>
> Your logic is just not sound, and sometimes I wonder how sound your mind
> is.
>
> This statement of your just shows how you have lost touch with the
> reality of the situation. You seem to think the Univese must be wrong
> because it doesn't match your expectations. THAT is a sign of mental
> illness.
>
> FAIL.

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

If embedded_H correctly matches this pattern
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⟩...

In three iterations or less then this indicates that a UTM at Ĥ.qx
simulating ⟨Ĥ⟩ ⟨Ĥ⟩ would never reach ⟨Ĥ⟩.qn.

This means that a correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ never reaches its
final state of ⟨Ĥ⟩.qn thus ⟨Ĥ⟩ ⟨Ĥ⟩ specifies a sequence of
configurations that never halt.

At this point after the above infinite behavior pattern has been matched
in a finite number of steps then embedded_H stops its simulation and
transitions to Ĥ.qn.

--
Copyright 2021 Pete Olcott

Talent hits a target no one else can hit;
Genius hits a target no one else can see.
Arthur Schopenhauer