On 5/31/2021 12:06 PM, Richard Damon wrote:
> On 5/31/21 11:46 AM, olcott wrote:
>> On 5/31/2021 10:29 AM, Richard Damon wrote:
>>> On 5/31/21 10:55 AM, olcott wrote:
>>>> On 5/31/2021 9:27 AM, Richard Damon wrote:
>>>>> On 5/31/21 9:41 AM, olcott wrote:
>>>>>> On 5/31/2021 7:12 AM, Richard Damon wrote:
>>>>>>> On 5/30/21 11:04 PM, olcott wrote:
>>>>>>>> On 5/30/2021 9:20 PM, Richard Damon wrote:
>>>>>>>>> On 5/30/21 9:53 PM, olcott wrote:
>>>>>>>>>> On 5/30/2021 8:42 PM, Richard Damon wrote:
>>>>>>>>>>> On 5/30/21 8:51 PM, olcott wrote:
>>>>>>>>>>>> On 5/30/2021 7:19 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 5/30/21 7:59 PM, olcott wrote:
>>>>>>>>>>>>>> On 5/30/2021 5:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 5/30/21 4:37 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 5/30/2021 2:24 PM, olcott wrote:
>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You DON'T, and in fact CAN'T 'add' D to the end of the chart,
>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>> there is no end to the chart. The chart is a listing of EVERY
>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>> Machine, ordered by some rule.
>>>>>>>>>>>>>> I have rewritten the whole thing to make it more clear.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please read the complete Sipser proof on the last page so
>>>>>>>>>>>>>> that you
>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>> mistake what I am saying for what Sipser is saying.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All that I am doing is correcting Sipser's Figure 4.6 with my
>>>>>>>>>>>>>> figure
>>>>>>>>>>>>>> 4.4b and 4.5a. This one change refutes all of the halting
>>>>>>>>>>>>>> problem
>>>>>>>>>>>>>> diagonal proofs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> I don't think you read what I wrote.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The list M1, M2, M3, M4 ... is the INFINITE list of ALL
>>>>>>>>>>>>> Machines.
>>>>>>>>>>>>> There
>>>>>>>>>>>>> is no 'end' to it to add something after it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If D IS a real Turing Machine, there is no reason to add it
>>>>>>>>>>>>> to the
>>>>>>>>>>>>> 'end'
>>>>>>>>>>>>> as it will already be in there somewhere, as it is the listing
>>>>>>>>>>>>> of ALL
>>>>>>>>>>>>> Turing Machines.
>>>>>>>>>>>>>
>>>>>>>>>>>> I am merely using the Sipser convention of ellipses.
>>>>>>>>>>> No, you are not. There is one convention of ellipses for a finite
>>>>>>>>>>> omission, where you do something like 1, 2, 3, 4, ... 99, 100.
>>>>>>>>>>>
>>>>>>>>>>> With a terminal at the end, you can of course add more.
>>>>>>>>>>>
>>>>>>>>>>> Sometimes, even if there is a finite number, the last element
>>>>>>>>>>> might not
>>>>>>>>>>> be listed, and in that case, you could properly add something
>>>>>>>>>>> at the
>>>>>>>>>>> end.
>>>>>>>>>>>
>>>>>>>>>>> But, in this case, the ellipses are pointing to an INFINITE
>>>>>>>>>>> sequence. It
>>>>>>>>>>> is like: The counting numbers are: 1, 2, 3, 4, ...
>>>>>>>>>>>
>>>>>>>>>>> There is NO implied end to the list, and you can't just 'add'
>>>>>>>>>>> something
>>>>>>>>>>> to the end of the infinite sequence. The IS no number you
>>>>>>>>>>> could give
>>>>>>>>>>> that item.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> It is logically incorrect to both say you NEED to add D to
>>>>>>>>>>>>> the list
>>>>>>>>>>>>> (since if D is a Turing Machine, it will be already an element
>>>>>>>>>>>>> in the
>>>>>>>>>>>>> list) or that you CAN add it to the list, since that says
>>>>>>>>>>>>> that it
>>>>>>>>>>>>> has a
>>>>>>>>>>>>> ordinal number higher than any possible ordinal number.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe your source of the description of Sipser's argument is
>>>>>>>>>>>>> incomplete,
>>>>>>>>>>>> I provided a scanned image of his actual proof on page 4.
>>>>>>>>>>>> Go back and do what I said and read what Sipser said on my page
>>>>>>>>>>>> four.
>>>>>>>>>>>>
>>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Yes, and he said:
>>>>>>>>>>>
>>>>>>>>>>> In these tables we list all TMs down the rows, M1, M2, ... and
>>>>>>>>>>> all
>>>>>>>>>>> their
>>>>>>>>>>> descriptions across the columns, (MI ), (M2 ), ...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Let me ask you, how many TMs are their? Is their number finite or
>>>>>>>>>>> infinite?
>>>>>>>>>>>
>>>>>>>>>>> If it is infinite, is there a space at the end of the table to
>>>>>>>>>>> add
>>>>>>>>>>> something.
>>>>>>>>>>>
>>>>>>>>>>> If it is a listing of *ALL* Turing Machines, why isn't D
>>>>>>>>>>> listed in
>>>>>>>>>>> it?
>>>>>>>>>> It seems that you have set your mind on being disagreeable I
>>>>>>>>>> will go
>>>>>>>>>> back to ignoring you. My Sipser diagonalization proof is clear
>>>>>>>>>> enough
>>>>>>>>>> that I can start discussing it with actual computer scientists.
>>>>>>>>>> Feel
>>>>>>>>>> free to disagree I won't be paying attention.
>>>>>>>>>>
>>>>>>>>> If may be clear to you, but it is still wrong. Seems your typical
>>>>>>>>> problem of not understanding infinities.
>>>>>>>>>
>>>>>>>>> You CAN'T add something to the end of an infinity long sequence.
>>>>>>>>>
>>>>>>>> You are telling me that when I use the same convention that
>>>>>>>> Sipser uses
>>>>>>>> to specify infinite sets that I am wrong only because you insist on
>>>>>>>> being disagreeable.
>>>>>>>>
>>>>>>> But Sipser never does what you did. He uses the notation of M1,
>>>>>>> M2, ...
>>>>>>> to denote the infinite set of ALL Turing Machines. As such, if D
>>>>>>> was a
>>>>>>> Turing Machine, it would already be in the set, no need to add it.
>>>>>>>
>>>>>> He does add it in his Figure 4.6 nitwit and he does add it
>>>>>> incorrectly.
>>>>>> I already told you before you point out my errors read his freaking
>>>>>> proof. The mistakes that you say I am making is what he is doing.
>>>>> No, he is doing something different here.
>>>>>
>>>>> You went M1, M2, ... D
>>>> *Corrections to Sipser's Figure 4.6 when he attempts
>>>> **to insert machine D into his figure 4.5
>>>> *
>>>>
>>>>      ⟨M1⟩      ⟨M2⟩      ⟨M3⟩       ⟨M4⟩ ... ⟨D⟩ ...
>>>> M1  accept   ~halt    accept   ~halt    DC
>>>> M2  accept   accept   accept   accept   DC
>>>> M3  ~halt    ~halt    ~halt    ~halt    DC
>>>> M4  accept   accept   ~halt    ~halt    DC
>>>> .
>>>> .
>>>> .
>>>> D   reject   reject   accept   accept   reject
>>>> .
>>>> .
>>>> .
>>>> *   Figure 4.4b (Insert D into Figure 4.4a adapted from Sipser 4.4) *
>>>>
>>>>
>>>>      ⟨M1⟩      ⟨M2⟩      ⟨M3⟩      ⟨M4⟩ ...  ⟨D⟩ ...
>>>> M1  _accept_   reject   accept   reject   DC
>>>> M2  accept   _accept_   accept   accept   DC
>>>> M3  reject   reject   _reject_   reject   DC
>>>> M4  accept   accept   reject   _reject_   DC
>>>> .
>>>> .
>>>> .
>>>> D   accept   accept   accept   accept   _accept_
>>>> .
>>>> .
>>>> .
>>>> *Figure 4.5a (Insert D into Figure 4.5) *
>>>>
>>>> *
>>>> *
>>>>
>>>> *Refuting the Sipser Halting Problem Diagonalization Argument*
>>>>
>>>> https://www.researchgate.net/publication/351947980_Refuting_the_Sipser_Halting_Problem_Diagonalization_Argument
>>>>
>>>>
>>>>
>>>
>>> So your answer to the evidence that D can't be a Turing Machine is to
>>> just change the requirements on the machines. Right, That really works.
>>>
>>>
>>> Since by your 4.4b D rejects <D>, then the value that H must produce is
>>> *reject*, so you have just shown that H now fails at its job of Deciding.
>>>
>>
>> What part of opposite of the diagonal do you not understand?
>>
>>      In the following figure, we added D to Figure 4.5.
>>      By our assumption, H is a TM and so is D. Therefore
>>      it must occur on the list M 1 , M2, ... of all TMs.
>>      Note that D computes the opposite of the diagonal
>>      entries... (Sipser:1997:167)
>>
>> Sipser, Michael 1997. Introduction to the Theory of Computation. Boston:
>> PWS Publishing
>>
>
> The problem is that H is supposed to compute the Decision of P,I but
> accept is the wrong answer of D(<D>) is reject.

On 5/31/21 12:21 PM, olcott wrote:
> On 5/31/2021 10:53 AM, Mike Terry wrote:
>> On 30/05/2021 21:37, olcott wrote:
>>> On 5/30/2021 2:24 PM, olcott wrote:
>>>>
>>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>>>
>>
>> tldr;  just the usual "PO totally failing to understand what he is
>> reading, and as a result confidently spouting nonsense as a result"...
>>
>> FTR, PO is pretty much incapable of following abstract reasoning or
>> understanding abstact concepts.  "Arguing" with him is totally
>> pointless.  Do not assume that because he replies to a post and nobody
>> responds, that means he has said anything coherent or logical, or that
>> anybody else implicitly agrees with what he said.
>>
>>>>
>>> Refuting the Halting Problem Diagonalization Argument
>>>
>>> Every machine that halts in a reject state is a halting computation.
>>> At least two proofs ignore this when constructing Sipser's Figure
>>> 4.5. Because these two proofs ignore this when they insert machine D
>>> into Sipser's Figure 4.5 they do so incorrectly.
>>
>> Dude... Sipser explicitly says blank entries are "either non-halting
>> or reject" entries.  He is not ignoring anything.  You just can't
>> follow his argument.
>>
>
> When he inserts D into his figure 4.5 as his figure 4.6 he needed to
> insert D into figure 4.4 first. When we insert D into figure 4.4 then we
> have the correct basis for inserting D into Figure 4.5.
>
> When we insert D into Figure 4.5 we must translate the reject values
> from Figure 4.4 (with D inserted) into accept values because halting in
> a reject state is a halting computation. In his figure 4.6 at ⟨D,⟨M1⟩⟩
> and ⟨D,⟨M2⟩⟩ he makes the mistake of not translating reject values into
> accept values.
>
>

But H isn't a Halt Decider, it is the Hypothetical Acceptance Decider.

H is supposed to answer 'accept' if the TM in question accepted its
input, but halting in the 'accept' state, and answer 'reject' if the TM
in question rejected its input either by going to the 'reject' state or
by not halting in either of the 'accept' or 'reject' state.

Thus if D(<D>) is Reject, then H(D, <D>) must say Reject.

But then D(<D>) should have said Accept, but then H(D,<D>) must say Accept.

Thus, if we claim we can make the machine H, is WILL be wrong for at
least the case of D(<D>), since it is clearly possible to make a D meet
its requirements given a machine H.

This shows that H can't exist that fully meets its requirements.

On 5/31/2021 12:15 PM, Richard Damon wrote:
> On 5/31/21 12:21 PM, olcott wrote:
>> On 5/31/2021 10:53 AM, Mike Terry wrote:
>>> On 30/05/2021 21:37, olcott wrote:
>>>> On 5/30/2021 2:24 PM, olcott wrote:
>>>>>
>>>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>>>>
>>>
>>> tldr;  just the usual "PO totally failing to understand what he is
>>> reading, and as a result confidently spouting nonsense as a result"...
>>>
>>> FTR, PO is pretty much incapable of following abstract reasoning or
>>> understanding abstact concepts.  "Arguing" with him is totally
>>> pointless.  Do not assume that because he replies to a post and nobody
>>> responds, that means he has said anything coherent or logical, or that
>>> anybody else implicitly agrees with what he said.
>>>
>>>>>
>>>> Refuting the Halting Problem Diagonalization Argument
>>>>
>>>> Every machine that halts in a reject state is a halting computation.
>>>> At least two proofs ignore this when constructing Sipser's Figure
>>>> 4.5. Because these two proofs ignore this when they insert machine D
>>>> into Sipser's Figure 4.5 they do so incorrectly.
>>>
>>> Dude... Sipser explicitly says blank entries are "either non-halting
>>> or reject" entries.  He is not ignoring anything.  You just can't
>>> follow his argument.
>>>
>>
>> When he inserts D into his figure 4.5 as his figure 4.6 he needed to
>> insert D into figure 4.4 first. When we insert D into figure 4.4 then we
>> have the correct basis for inserting D into Figure 4.5.
>>
>> When we insert D into Figure 4.5 we must translate the reject values
>> from Figure 4.4 (with D inserted) into accept values because halting in
>> a reject state is a halting computation. In his figure 4.6 at ⟨D,⟨M1⟩⟩
>> and ⟨D,⟨M2⟩⟩ he makes the mistake of not translating reject values into
>> accept values.
>>
>>
>
>
> But H isn't a Halt Decider, it is the Hypothetical Acceptance Decider.
>

That is not how Professor Dan Gusfield of UC Davis explains it.
L15: Proof by Diagonalization that ATM (Halting Problem) is Not
Decidable Dec 12, 2012 https://www.youtube.com/watch?v=jM6osxSX9GA

In his proof he has accept, reject, and ~halts in his table T.

> H is supposed to answer 'accept' if the TM in question accepted its
> input, but halting in the 'accept' state, and answer 'reject' if the TM
> in question rejected its input either by going to the 'reject' state or
> by not halting in either of the 'accept' or 'reject' state.
>
> Thus if D(<D>) is Reject, then H(D, <D>) must say Reject.

H(D, <D>) must say the opposite of what D(<D>) says.

>
> But then D(<D>) should have said Accept, but then H(D,<D>) must say Accept.
>

We are simply back to the requirement for a full glass of water that
contains no water at all, error of requiring an object with mutually
exclusive attributes.

I can make it impossible for you to touch the top of your own head by
stipulating the you must touch your head without touching your head.

> Thus, if we claim we can make the machine H, is WILL be wrong for at
> least the case of D(<D>), since it is clearly possible to make a D meet
> its requirements given a machine H.
>
> This shows that H can't exist that fully meets its requirements.
>

In the exact same way that you cannot possibly touch the top of your
head without touching your head at all.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 5/31/21 1:13 PM, olcott wrote:
> On 5/31/2021 12:06 PM, Richard Damon wrote:
>> On 5/31/21 11:46 AM, olcott wrote:
>>> On 5/31/2021 10:29 AM, Richard Damon wrote:
>>>> On 5/31/21 10:55 AM, olcott wrote:
>>>>> On 5/31/2021 9:27 AM, Richard Damon wrote:
>>>>>> On 5/31/21 9:41 AM, olcott wrote:
>>>>>>> On 5/31/2021 7:12 AM, Richard Damon wrote:
>>>>>>>> On 5/30/21 11:04 PM, olcott wrote:
>>>>>>>>> On 5/30/2021 9:20 PM, Richard Damon wrote:
>>>>>>>>>> On 5/30/21 9:53 PM, olcott wrote:
>>>>>>>>>>> On 5/30/2021 8:42 PM, Richard Damon wrote:
>>>>>>>>>>>> On 5/30/21 8:51 PM, olcott wrote:
>>>>>>>>>>>>> On 5/30/2021 7:19 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 5/30/21 7:59 PM, olcott wrote:
>>>>>>>>>>>>>>> On 5/30/2021 5:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 5/30/21 4:37 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 5/30/2021 2:24 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You DON'T, and in fact CAN'T 'add' D to the end of the
>>>>>>>>>>>>>>>> chart,
>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>> there is no end to the chart. The chart is a listing of
>>>>>>>>>>>>>>>> EVERY
>>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>>> Machine, ordered by some rule.
>>>>>>>>>>>>>>> I have rewritten the whole thing to make it more clear.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please read the complete Sipser proof on the last page so
>>>>>>>>>>>>>>> that you
>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>> mistake what I am saying for what Sipser is saying.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> All that I am doing is correcting Sipser's Figure 4.6
>>>>>>>>>>>>>>> with my
>>>>>>>>>>>>>>> figure
>>>>>>>>>>>>>>> 4.4b and 4.5a. This one change refutes all of the halting
>>>>>>>>>>>>>>> problem
>>>>>>>>>>>>>>> diagonal proofs.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't think you read what I wrote.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The list M1, M2, M3, M4 ... is the INFINITE list of ALL
>>>>>>>>>>>>>> Machines.
>>>>>>>>>>>>>> There
>>>>>>>>>>>>>> is no 'end' to it to add something after it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If D IS a real Turing Machine, there is no reason to add it
>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>> 'end'
>>>>>>>>>>>>>> as it will already be in there somewhere, as it is the
>>>>>>>>>>>>>> listing
>>>>>>>>>>>>>> of ALL
>>>>>>>>>>>>>> Turing Machines.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> I am merely using the Sipser convention of ellipses.
>>>>>>>>>>>> No, you are not. There is one convention of ellipses for a
>>>>>>>>>>>> finite
>>>>>>>>>>>> omission, where you do something like 1, 2, 3, 4, ... 99, 100.
>>>>>>>>>>>>
>>>>>>>>>>>> With a terminal at the end, you can of course add more.
>>>>>>>>>>>>
>>>>>>>>>>>> Sometimes, even if there is a finite number, the last element
>>>>>>>>>>>> might not
>>>>>>>>>>>> be listed, and in that case, you could properly add something
>>>>>>>>>>>> at the
>>>>>>>>>>>> end.
>>>>>>>>>>>>
>>>>>>>>>>>> But, in this case, the ellipses are pointing to an INFINITE
>>>>>>>>>>>> sequence. It
>>>>>>>>>>>> is like: The counting numbers are: 1, 2, 3, 4, ...
>>>>>>>>>>>>
>>>>>>>>>>>> There is NO implied end to the list, and you can't just 'add'
>>>>>>>>>>>> something
>>>>>>>>>>>> to the end of the infinite sequence. The IS no number you
>>>>>>>>>>>> could give
>>>>>>>>>>>> that item.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>> It is logically incorrect to both say you NEED to add D to
>>>>>>>>>>>>>> the list
>>>>>>>>>>>>>> (since if D is a Turing Machine, it will be already an
>>>>>>>>>>>>>> element
>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>> list) or that you CAN add it to the list, since that says
>>>>>>>>>>>>>> that it
>>>>>>>>>>>>>> has a
>>>>>>>>>>>>>> ordinal number higher than any possible ordinal number.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Maybe your source of the description of Sipser's argument is
>>>>>>>>>>>>>> incomplete,
>>>>>>>>>>>>> I provided a scanned image of his actual proof on page 4.
>>>>>>>>>>>>> Go back and do what I said and read what Sipser said on my
>>>>>>>>>>>>> page
>>>>>>>>>>>>> four.
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> Yes, and he said:
>>>>>>>>>>>>
>>>>>>>>>>>> In these tables we list all TMs down the rows, M1, M2, ... and
>>>>>>>>>>>> all
>>>>>>>>>>>> their
>>>>>>>>>>>> descriptions across the columns, (MI ), (M2 ), ...
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Let me ask you, how many TMs are their? Is their number
>>>>>>>>>>>> finite or
>>>>>>>>>>>> infinite?
>>>>>>>>>>>>
>>>>>>>>>>>> If it is infinite, is there a space at the end of the table to
>>>>>>>>>>>> add
>>>>>>>>>>>> something.
>>>>>>>>>>>>
>>>>>>>>>>>> If it is a listing of *ALL* Turing Machines, why isn't D
>>>>>>>>>>>> listed in
>>>>>>>>>>>> it?
>>>>>>>>>>> It seems that you have set your mind on being disagreeable I
>>>>>>>>>>> will go
>>>>>>>>>>> back to ignoring you. My Sipser diagonalization proof is clear
>>>>>>>>>>> enough
>>>>>>>>>>> that I can start discussing it with actual computer scientists.
>>>>>>>>>>> Feel
>>>>>>>>>>> free to disagree I won't be paying attention.
>>>>>>>>>>>
>>>>>>>>>> If may be clear to you, but it is still wrong. Seems your typical
>>>>>>>>>> problem of not understanding infinities.
>>>>>>>>>>
>>>>>>>>>> You CAN'T add something to the end of an infinity long sequence.
>>>>>>>>>>
>>>>>>>>> You are telling me that when I use the same convention that
>>>>>>>>> Sipser uses
>>>>>>>>> to specify infinite sets that I am wrong only because you
>>>>>>>>> insist on
>>>>>>>>> being disagreeable.
>>>>>>>>>
>>>>>>>> But Sipser never does what you did. He uses the notation of M1,
>>>>>>>> M2, ...
>>>>>>>> to denote the infinite set of ALL Turing Machines. As such, if D
>>>>>>>> was a
>>>>>>>> Turing Machine, it would already be in the set, no need to add it.
>>>>>>>>
>>>>>>> He does add it in his Figure 4.6 nitwit and he does add it
>>>>>>> incorrectly.
>>>>>>> I already told you before you point out my errors read his freaking
>>>>>>> proof. The mistakes that you say I am making is what he is doing.
>>>>>> No, he is doing something different here.
>>>>>>
>>>>>> You went M1, M2, ... D
>>>>> *Corrections to Sipser's Figure 4.6 when he attempts
>>>>> **to insert machine D into his figure 4.5
>>>>> *
>>>>>
>>>>>       ⟨M1⟩      ⟨M2⟩      ⟨M3⟩       ⟨M4⟩ ... ⟨D⟩ ...
>>>>> M1  accept   ~halt    accept   ~halt    DC
>>>>> M2  accept   accept   accept   accept   DC
>>>>> M3  ~halt    ~halt    ~halt    ~halt    DC
>>>>> M4  accept   accept   ~halt    ~halt    DC
>>>>> .
>>>>> .
>>>>> .
>>>>> D   reject   reject   accept   accept   reject
>>>>> .
>>>>> .
>>>>> .
>>>>> *   Figure 4.4b (Insert D into Figure 4.4a adapted from Sipser 4.4) *
>>>>>
>>>>>
>>>>>       ⟨M1⟩      ⟨M2⟩      ⟨M3⟩      ⟨M4⟩ ...  ⟨D⟩ ...
>>>>> M1  _accept_   reject   accept   reject   DC
>>>>> M2  accept   _accept_   accept   accept   DC
>>>>> M3  reject   reject   _reject_   reject   DC
>>>>> M4  accept   accept   reject   _reject_   DC
>>>>> .
>>>>> .
>>>>> .
>>>>> D   accept   accept   accept   accept   _accept_
>>>>> .
>>>>> .
>>>>> .
>>>>> *Figure 4.5a (Insert D into Figure 4.5) *
>>>>>
>>>>> *
>>>>> *
>>>>>
>>>>> *Refuting the Sipser Halting Problem Diagonalization Argument*
>>>>>
>>>>> https://www.researchgate.net/publication/351947980_Refuting_the_Sipser_Halting_Problem_Diagonalization_Argument
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> So your answer to the evidence that D can't be a Turing Machine is to
>>>> just change the requirements on the machines. Right, That really works.
>>>>
>>>>
>>>> Since by your 4.4b D rejects <D>, then the value that H must produce is
>>>> *reject*, so you have just shown that H now fails at its job of
>>>> Deciding.
>>>>
>>>
>>> What part of opposite of the diagonal do you not understand?
>>>
>>>       In the following figure, we added D to Figure 4.5.
>>>       By our assumption, H is a TM and so is D. Therefore
>>>       it must occur on the list M 1 , M2, ... of all TMs.
>>>       Note that D computes the opposite of the diagonal
>>>       entries... (Sipser:1997:167)
>>>
>>> Sipser, Michael 1997. Introduction to the Theory of Computation. Boston:
>>> PWS Publishing
>>>
>>
>> The problem is that H is supposed to compute the Decision of P,I but
>> accept is the wrong answer of D(<D>) is reject.
>
> You are supposed to freaking read that Sipser proof first and then
> examine my rebuttal of his diagonalization argument as it pertains to
> this proof. There is no freaking P,I in any of this.
>

On 5/31/2021 10:53 AM, Mike Terry wrote:
> On 30/05/2021 21:37, olcott wrote:
>> On 5/30/2021 2:24 PM, olcott wrote:
>>>
>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>>
>
> tldr;  just the usual "PO totally failing to understand what he is
> reading, and as a result confidently spouting nonsense as a result"...
>
> FTR, PO is pretty much incapable of following abstract reasoning or
> understanding abstact concepts.  "Arguing" with him is totally
> pointless.  Do not assume that because he replies to a post and nobody
> responds, that means he has said anything coherent or logical, or that
> anybody else implicitly agrees with what he said.
>
>>>
>> Refuting the Halting Problem Diagonalization Argument
>>
>> Every machine that halts in a reject state is a halting computation.
>> At least two proofs ignore this when constructing Sipser's Figure 4.5.
>> Because these two proofs ignore this when they insert machine D into
>> Sipser's Figure 4.5 they do so incorrectly.
>
> Dude... Sipser explicitly says blank entries are "either non-halting or
> reject" entries.  He is not ignoring anything.  You just can't follow
> his argument.
>
> I think you are confused at what you're looking at in Sipser. You
> reference Sipser's Theorem 4.9, and it's clear you think that is a proof
> of the undecidability of the Halting Problem.  IT IS NOT - it's a proof
> of the undecidability of the *Accepting* TM problem.  The clue for you
> should have been in the name ATM (rather than HTM).  Didn't you wonder
> What the A stood for?

Ah, so then we are back to this, when we translate the abstraction into
concrete code then nothing slips through the cracks unnoticed:

#define u32 uint32_t

int Simulate(u32 P, u32 I)
{ ((void(*)(u32))P)(I);
return 1;
}

// When D attempts to return a value that is the opposite of
// the value that H returns, it still gets stuck in infinitely
// nested simulation.
int D(u32 P) // P is a machine address
{ if ( H(P, P) )
return 0 // reject when H accepts
return 1; // accept when H rejects
}

int main()
{ H((u32)D, (u32)D);
}

If H is not a simulating halt decider if it is a simulating acceptance
decider then both H and D get stuck in infinitely nested simulation.

If H is a simulating halt decider then H must stop simulating its input
because if H did not stop simulating its input then D would have the
same halting behavior as if D called Simulate instead of H.

The above analysis is confirmed by actual execution of the above
function in the x86utm operating system. H detects an infinitely
repeating non-halting pattern that never reaches the second line of D.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 5/31/2021 12:47 PM, Richard Damon wrote:
> On 5/31/21 1:13 PM, olcott wrote:
>> On 5/31/2021 12:06 PM, Richard Damon wrote:
>>> On 5/31/21 11:46 AM, olcott wrote:
>>>> On 5/31/2021 10:29 AM, Richard Damon wrote:
>>>>> On 5/31/21 10:55 AM, olcott wrote:
>>>>>> On 5/31/2021 9:27 AM, Richard Damon wrote:
>>>>>>> On 5/31/21 9:41 AM, olcott wrote:
>>>>>>>> On 5/31/2021 7:12 AM, Richard Damon wrote:
>>>>>>>>> On 5/30/21 11:04 PM, olcott wrote:
>>>>>>>>>> On 5/30/2021 9:20 PM, Richard Damon wrote:
>>>>>>>>>>> On 5/30/21 9:53 PM, olcott wrote:
>>>>>>>>>>>> On 5/30/2021 8:42 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 5/30/21 8:51 PM, olcott wrote:
>>>>>>>>>>>>>> On 5/30/2021 7:19 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 5/30/21 7:59 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 5/30/2021 5:57 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 5/30/21 4:37 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 5/30/2021 2:24 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You DON'T, and in fact CAN'T 'add' D to the end of the
>>>>>>>>>>>>>>>>> chart,
>>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>> there is no end to the chart. The chart is a listing of
>>>>>>>>>>>>>>>>> EVERY
>>>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>>>> Machine, ordered by some rule.
>>>>>>>>>>>>>>>> I have rewritten the whole thing to make it more clear.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please read the complete Sipser proof on the last page so
>>>>>>>>>>>>>>>> that you
>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>> mistake what I am saying for what Sipser is saying.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All that I am doing is correcting Sipser's Figure 4.6
>>>>>>>>>>>>>>>> with my
>>>>>>>>>>>>>>>> figure
>>>>>>>>>>>>>>>> 4.4b and 4.5a. This one change refutes all of the halting
>>>>>>>>>>>>>>>> problem
>>>>>>>>>>>>>>>> diagonal proofs.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't think you read what I wrote.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The list M1, M2, M3, M4 ... is the INFINITE list of ALL
>>>>>>>>>>>>>>> Machines.
>>>>>>>>>>>>>>> There
>>>>>>>>>>>>>>> is no 'end' to it to add something after it.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If D IS a real Turing Machine, there is no reason to add it
>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>> 'end'
>>>>>>>>>>>>>>> as it will already be in there somewhere, as it is the
>>>>>>>>>>>>>>> listing
>>>>>>>>>>>>>>> of ALL
>>>>>>>>>>>>>>> Turing Machines.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am merely using the Sipser convention of ellipses.
>>>>>>>>>>>>> No, you are not. There is one convention of ellipses for a
>>>>>>>>>>>>> finite
>>>>>>>>>>>>> omission, where you do something like 1, 2, 3, 4, ... 99, 100.
>>>>>>>>>>>>>
>>>>>>>>>>>>> With a terminal at the end, you can of course add more.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sometimes, even if there is a finite number, the last element
>>>>>>>>>>>>> might not
>>>>>>>>>>>>> be listed, and in that case, you could properly add something
>>>>>>>>>>>>> at the
>>>>>>>>>>>>> end.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But, in this case, the ellipses are pointing to an INFINITE
>>>>>>>>>>>>> sequence. It
>>>>>>>>>>>>> is like: The counting numbers are: 1, 2, 3, 4, ...
>>>>>>>>>>>>>
>>>>>>>>>>>>> There is NO implied end to the list, and you can't just 'add'
>>>>>>>>>>>>> something
>>>>>>>>>>>>> to the end of the infinite sequence. The IS no number you
>>>>>>>>>>>>> could give
>>>>>>>>>>>>> that item.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is logically incorrect to both say you NEED to add D to
>>>>>>>>>>>>>>> the list
>>>>>>>>>>>>>>> (since if D is a Turing Machine, it will be already an
>>>>>>>>>>>>>>> element
>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>> list) or that you CAN add it to the list, since that says
>>>>>>>>>>>>>>> that it
>>>>>>>>>>>>>>> has a
>>>>>>>>>>>>>>> ordinal number higher than any possible ordinal number.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Maybe your source of the description of Sipser's argument is
>>>>>>>>>>>>>>> incomplete,
>>>>>>>>>>>>>> I provided a scanned image of his actual proof on page 4.
>>>>>>>>>>>>>> Go back and do what I said and read what Sipser said on my
>>>>>>>>>>>>>> page
>>>>>>>>>>>>>> four.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, and he said:
>>>>>>>>>>>>>
>>>>>>>>>>>>> In these tables we list all TMs down the rows, M1, M2, ... and
>>>>>>>>>>>>> all
>>>>>>>>>>>>> their
>>>>>>>>>>>>> descriptions across the columns, (MI ), (M2 ), ...
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Let me ask you, how many TMs are their? Is their number
>>>>>>>>>>>>> finite or
>>>>>>>>>>>>> infinite?
>>>>>>>>>>>>>
>>>>>>>>>>>>> If it is infinite, is there a space at the end of the table to
>>>>>>>>>>>>> add
>>>>>>>>>>>>> something.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If it is a listing of *ALL* Turing Machines, why isn't D
>>>>>>>>>>>>> listed in
>>>>>>>>>>>>> it?
>>>>>>>>>>>> It seems that you have set your mind on being disagreeable I
>>>>>>>>>>>> will go
>>>>>>>>>>>> back to ignoring you. My Sipser diagonalization proof is clear
>>>>>>>>>>>> enough
>>>>>>>>>>>> that I can start discussing it with actual computer scientists.
>>>>>>>>>>>> Feel
>>>>>>>>>>>> free to disagree I won't be paying attention.
>>>>>>>>>>>>
>>>>>>>>>>> If may be clear to you, but it is still wrong. Seems your typical
>>>>>>>>>>> problem of not understanding infinities.
>>>>>>>>>>>
>>>>>>>>>>> You CAN'T add something to the end of an infinity long sequence.
>>>>>>>>>>>
>>>>>>>>>> You are telling me that when I use the same convention that
>>>>>>>>>> Sipser uses
>>>>>>>>>> to specify infinite sets that I am wrong only because you
>>>>>>>>>> insist on
>>>>>>>>>> being disagreeable.
>>>>>>>>>>
>>>>>>>>> But Sipser never does what you did. He uses the notation of M1,
>>>>>>>>> M2, ...
>>>>>>>>> to denote the infinite set of ALL Turing Machines. As such, if D
>>>>>>>>> was a
>>>>>>>>> Turing Machine, it would already be in the set, no need to add it.
>>>>>>>>>
>>>>>>>> He does add it in his Figure 4.6 nitwit and he does add it
>>>>>>>> incorrectly.
>>>>>>>> I already told you before you point out my errors read his freaking
>>>>>>>> proof. The mistakes that you say I am making is what he is doing.
>>>>>>> No, he is doing something different here.
>>>>>>>
>>>>>>> You went M1, M2, ... D
>>>>>> *Corrections to Sipser's Figure 4.6 when he attempts
>>>>>> **to insert machine D into his figure 4.5
>>>>>> *
>>>>>>
>>>>>>       ⟨M1⟩      ⟨M2⟩      ⟨M3⟩       ⟨M4⟩ ... ⟨D⟩ ...
>>>>>> M1  accept   ~halt    accept   ~halt    DC
>>>>>> M2  accept   accept   accept   accept   DC
>>>>>> M3  ~halt    ~halt    ~halt    ~halt    DC
>>>>>> M4  accept   accept   ~halt    ~halt    DC
>>>>>> .
>>>>>> .
>>>>>> .
>>>>>> D   reject   reject   accept   accept   reject
>>>>>> .
>>>>>> .
>>>>>> .
>>>>>> *   Figure 4.4b (Insert D into Figure 4.4a adapted from Sipser 4.4) *
>>>>>>
>>>>>>
>>>>>>       ⟨M1⟩      ⟨M2⟩      ⟨M3⟩      ⟨M4⟩ ...  ⟨D⟩ ...
>>>>>> M1  _accept_   reject   accept   reject   DC
>>>>>> M2  accept   _accept_   accept   accept   DC
>>>>>> M3  reject   reject   _reject_   reject   DC
>>>>>> M4  accept   accept   reject   _reject_   DC
>>>>>> .
>>>>>> .
>>>>>> .
>>>>>> D   accept   accept   accept   accept   _accept_
>>>>>> .
>>>>>> .
>>>>>> .
>>>>>> *Figure 4.5a (Insert D into Figure 4.5) *
>>>>>>
>>>>>> *
>>>>>> *
>>>>>>
>>>>>> *Refuting the Sipser Halting Problem Diagonalization Argument*
>>>>>>
>>>>>> https://www.researchgate.net/publication/351947980_Refuting_the_Sipser_Halting_Problem_Diagonalization_Argument
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> So your answer to the evidence that D can't be a Turing Machine is to
>>>>> just change the requirements on the machines. Right, That really works.
>>>>>
>>>>>
>>>>> Since by your 4.4b D rejects <D>, then the value that H must produce is
>>>>> *reject*, so you have just shown that H now fails at its job of
>>>>> Deciding.
>>>>>
>>>>
>>>> What part of opposite of the diagonal do you not understand?
>>>>
>>>>       In the following figure, we added D to Figure 4.5.
>>>>       By our assumption, H is a TM and so is D. Therefore
>>>>       it must occur on the list M 1 , M2, ... of all TMs.
>>>>       Note that D computes the opposite of the diagonal
>>>>       entries... (Sipser:1997:167)
>>>>
>>>> Sipser, Michael 1997. Introduction to the Theory of Computation. Boston:
>>>> PWS Publishing
>>>>
>>>
>>> The problem is that H is supposed to compute the Decision of P,I but
>>> accept is the wrong answer of D(<D>) is reject.
>>
>> You are supposed to freaking read that Sipser proof first and then
>> examine my rebuttal of his diagonalization argument as it pertains to
>> this proof. There is no freaking P,I in any of this.
>>
>
> Maybe if you actually understood the paper you would understand the
> alternate conventional symbology.
>
> Sipser defines a machine H that will be a Acceptance Turing Machine. It
> will take as its input a Turing Machine provided as a description, and
> the input to that Turing Machine. In classical Turing Theory, we will
> often call these inputs P, and I. Sipser instead numbers the machines,
> calling them like M1, but the 1 needs to be a subscript. Since Usenet
> doesn't handle this sort of notation, and thus needing to adapt to more
> verbose notations like M[i], if not needed just get clumsy.
>
> The key is that H has a requirement on it that if the machine given as
> its input actually makes a decision, H must produce that exact same
> decision, and if that machine doesn't make any decision, then H must
> decide 'reject'.
>
> Since in your example, D(<D>) was 'Reject', then so must H(D,<D>) be
> also 'Reject'. It isn't in your table, thus H has failed to be the
> needed decider.
>

On 5/31/21 1:31 PM, olcott wrote:
> On 5/31/2021 12:15 PM, Richard Damon wrote:
>> On 5/31/21 12:21 PM, olcott wrote:
>>> On 5/31/2021 10:53 AM, Mike Terry wrote:
>>>> On 30/05/2021 21:37, olcott wrote:
>>>>> On 5/30/2021 2:24 PM, olcott wrote:
>>>>>>
>>>>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>>>>>
>>>>>>
>>>>
>>>> tldr;  just the usual "PO totally failing to understand what he is
>>>> reading, and as a result confidently spouting nonsense as a result"...
>>>>
>>>> FTR, PO is pretty much incapable of following abstract reasoning or
>>>> understanding abstact concepts.  "Arguing" with him is totally
>>>> pointless.  Do not assume that because he replies to a post and nobody
>>>> responds, that means he has said anything coherent or logical, or that
>>>> anybody else implicitly agrees with what he said.
>>>>
>>>>>>
>>>>> Refuting the Halting Problem Diagonalization Argument
>>>>>
>>>>> Every machine that halts in a reject state is a halting computation.
>>>>> At least two proofs ignore this when constructing Sipser's Figure
>>>>> 4.5. Because these two proofs ignore this when they insert machine D
>>>>> into Sipser's Figure 4.5 they do so incorrectly.
>>>>
>>>> Dude... Sipser explicitly says blank entries are "either non-halting
>>>> or reject" entries.  He is not ignoring anything.  You just can't
>>>> follow his argument.
>>>>
>>>
>>> When he inserts D into his figure 4.5 as his figure 4.6 he needed to
>>> insert D into figure 4.4 first. When we insert D into figure 4.4 then we
>>> have the correct basis for inserting D into Figure 4.5.
>>>
>>> When we insert D into Figure 4.5 we must translate the reject values
>>> from Figure 4.4 (with D inserted) into accept values because halting in
>>> a reject state is a halting computation. In his figure 4.6 at ⟨D,⟨M1⟩⟩
>>> and ⟨D,⟨M2⟩⟩ he makes the mistake of not translating reject values into
>>> accept values.
>>>
>>>
>>
>>
>> But H isn't a Halt Decider, it is the Hypothetical Acceptance Decider.
>>
>
> That is not how Professor Dan Gusfield of UC Davis explains it.
> L15: Proof by Diagonalization that ATM (Halting Problem) is Not
> Decidable Dec 12, 2012  https://www.youtube.com/watch?v=jM6osxSX9GA
>
> In his proof he has accept, reject, and ~halts in his table T.

ATM is NOT "The Halting Problem", The ATM proof is another way to show
the indecidability of the Halting Problem. If an answer exists to the
Halting Problem, then an answer must also exist for ATM, as then the ATM
decider just needs to use the Halting Decider first, and if it says
non-halting answer reject, else just run the input machine and relay its
answer.

Listen again to how he defines H at about 5 minutes in. H decides the
ATM problem, and its outputs are Accept or Reject, Accept if its input
accepts its inputs, or reject of it rejects or doesn't halt.

>
>> H is supposed to answer 'accept' if the TM in question accepted its
>> input, but halting in the 'accept' state, and answer 'reject' if the TM
>> in question rejected its input either by going to the 'reject' state or
>> by not halting in either of the 'accept' or 'reject' state.
>>
>> Thus if D(<D>) is Reject, then H(D, <D>) must say Reject.
>
> H(D, <D>) must say the opposite of what D(<D>) says.

NO, H must answer the same answer as the machine given as its input, or
reject if that machine doesn't Halt. THAT is the definition of H.

D<x> is to answer the opposite of H(x, x)

You are mixing your requirements.

H is defined first, and the D from it.

The fact that we get the contradiction is the proof that H can't exist,
because if it did.

>
>>
>> But then D(<D>) should have said Accept, but then H(D,<D>) must say
>> Accept.
>>
>
> We are simply back to the requirement for a full glass of water that
> contains no water at all, error of requiring an object with mutually
> exclusive attributes.
>
> I can make it impossible for you to touch the top of your own head by
> stipulating the you must touch your head without touching your head.

Yes, some things are impossible. Note, the definition of H does NOT
include any mutually exclusive attributes. H is defined purely on the
behavior of the machine it is given. That behavior is FULLY defined.

It is only in the requirement that H work on ALL machines, and that
since it is a machine itself, we can define machines based on it as
machines that it needs to process.

>
>> Thus, if we claim we can make the machine H, is WILL be wrong for at
>> least the case of D(<D>), since it is clearly possible to make a D meet
>> its requirements given a machine H.
>>
>> This shows that H can't exist that fully meets its requirements.
>>
>
> In the exact same way that you cannot possibly touch the top of your
> head without touching your head at all.

But the problem doesn't state such a contradiction.

It is only that the system we are working in is descriptive enough that
define inputs to our deciders based on those deciders that we need to
come to the conclusion that some things are undecidable.

All the questions have answers. Every possible P(I) does have a results,
that is either a finite computation with a definite answer, or is an
unending computation which never comes to an answer. It is true that we
might not be able to know or find out that answer, but we do know that
it has one. It isn't the case like the truth value of the statement like
"This statement is false", because P(I) for any existing P and I does
have an answer.

We only get these contradictions when we assume that a machine (like the
universal decider) exist when they don't. It is a different class of issues.

On 5/31/2021 11:15 AM, Richard Damon wrote:
> On 5/31/21 12:21 PM, olcott wrote:
>> On 5/31/2021 10:53 AM, Mike Terry wrote:
>>> On 30/05/2021 21:37, olcott wrote:
>>>> On 5/30/2021 2:24 PM, olcott wrote:
>>>>>
>>>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>>>>
>>>
>>> tldr;  just the usual "PO totally failing to understand what he is
>>> reading, and as a result confidently spouting nonsense as a result"...
>>>
>>> FTR, PO is pretty much incapable of following abstract reasoning or
>>> understanding abstact concepts.  "Arguing" with him is totally
>>> pointless.  Do not assume that because he replies to a post and nobody
>>> responds, that means he has said anything coherent or logical, or that
>>> anybody else implicitly agrees with what he said.
>>>
>>>>>
>>>> Refuting the Halting Problem Diagonalization Argument
>>>>
>>>> Every machine that halts in a reject state is a halting computation.
>>>> At least two proofs ignore this when constructing Sipser's Figure
>>>> 4.5. Because these two proofs ignore this when they insert machine D
>>>> into Sipser's Figure 4.5 they do so incorrectly.
>>>
>>> Dude... Sipser explicitly says blank entries are "either non-halting
>>> or reject" entries.  He is not ignoring anything.  You just can't
>>> follow his argument.
>>>
>>
>> When he inserts D into his figure 4.5 as his figure 4.6 he needed to
>> insert D into figure 4.4 first. When we insert D into figure 4.4 then we
>> have the correct basis for inserting D into Figure 4.5.
>>
>> When we insert D into Figure 4.5 we must translate the reject values
>> from Figure 4.4 (with D inserted) into accept values because halting in
>> a reject state is a halting computation. In his figure 4.6 at ⟨D,⟨M1⟩⟩
>> and ⟨D,⟨M2⟩⟩ he makes the mistake of not translating reject values into
>> accept values.
>>
>>
>
>
> But H isn't a Halt Decider, it is the Hypothetical Acceptance Decider.
>
> H is supposed to answer 'accept' if the TM in question accepted its
> input, but halting in the 'accept' state, and answer 'reject' if the TM
> in question rejected its input either by going to the 'reject' state or
> by not halting in either of the 'accept' or 'reject' state.
>
> Thus if D(<D>) is Reject, then H(D, <D>) must say Reject.
>
> But then D(<D>) should have said Accept, but then H(D,<D>) must say Accept.
>
> Thus, if we claim we can make the machine H, is WILL be wrong for at
> least the case of D(<D>), since it is clearly possible to make a D meet
> its requirements given a machine H.
>
> This shows that H can't exist that fully meets its requirements.

Richard, I went to state something to you then ask simple questions.

Statement: You've repeated yourself - much of your comments in this
message have appeared in literally 100s in prior messages. Further, none
of those times has resulted in PO changing what s/he does.

Questions: Do you believe s/he is a troll or a proud ignoramus? Why do
you believe, in either case, that your continued efforts to "educate"
and/or correct her/him will be successful this time? Or the next? Or the
next?

We all have assumed PO has no life other than this nonsense - no job, no
family, no relations - so he's here for the long haul. Are you too?
--
Jeff Barnett

On 5/31/21 1:52 PM, olcott wrote:
> On 5/31/2021 10:53 AM, Mike Terry wrote:
>> On 30/05/2021 21:37, olcott wrote:
>>> On 5/30/2021 2:24 PM, olcott wrote:
>>>>
>>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>>>
>>
>> tldr;  just the usual "PO totally failing to understand what he is
>> reading, and as a result confidently spouting nonsense as a result"...
>>
>> FTR, PO is pretty much incapable of following abstract reasoning or
>> understanding abstact concepts.  "Arguing" with him is totally
>> pointless.  Do not assume that because he replies to a post and nobody
>> responds, that means he has said anything coherent or logical, or that
>> anybody else implicitly agrees with what he said.
>>
>>>>
>>> Refuting the Halting Problem Diagonalization Argument
>>>
>>> Every machine that halts in a reject state is a halting computation.
>>> At least two proofs ignore this when constructing Sipser's Figure
>>> 4.5. Because these two proofs ignore this when they insert machine D
>>> into Sipser's Figure 4.5 they do so incorrectly.
>>
>> Dude... Sipser explicitly says blank entries are "either non-halting
>> or reject" entries.  He is not ignoring anything.  You just can't
>> follow his argument.
>>
>> I think you are confused at what you're looking at in Sipser. You
>> reference Sipser's Theorem 4.9, and it's clear you think that is a
>> proof of the undecidability of the Halting Problem.  IT IS NOT - it's
>> a proof of the undecidability of the *Accepting* TM problem.  The clue
>> for you should have been in the name ATM (rather than HTM).  Didn't
>> you wonder What the A stood for?
>
> Ah, so then we are back to this, when we translate the abstraction into
> concrete code then nothing slips through the cracks unnoticed:
>
> #define u32 uint32_t
>
> int Simulate(u32 P, u32 I)
> {
>   ((void(*)(u32))P)(I);
>   return 1;
> }
>
> // When D attempts to return a value that is the opposite of
> // the value that H returns, it still gets stuck in infinitely
> // nested simulation.
> int D(u32 P)   // P is a machine address
> {
>   if ( H(P, P) )
>     return 0   // reject when H accepts
>   return 1;    // accept when H rejects
> }
>
> int main()
> {
>   H((u32)D, (u32)D);
> }
>
>
> If H is not a simulating halt decider if it is a simulating acceptance
> decider then both H and D get stuck in infinitely nested simulation.
>
> If H is a simulating halt decider then H must stop simulating its input
> because if H did not stop simulating its input then D would have the
> same halting behavior as if D called Simulate instead of H.
>
> The above analysis is confirmed by actual execution of the above
> function in the x86utm operating system. H detects an infinitely
> repeating non-halting pattern that never reaches the second line of D.
>
>

No Turing Machines here.

Note, that the Acceptance decider needs to be able to convert
non-halting machines into reject answers, so it does need to be able to
detect this non-halting behavior.

And, just like before, it isn't given any special permission to answer
with a non-conforming answer just because the machine it is given uses
itself.

If the computation it has been given halts, then ATM must give the same
answer as that machine. If the computation it has been given does not
halt, it gives the answer reject.

PERIOD. Definition the machine needs to meet.

Since this must always be a halting computation, D which returns the
opposite answer of this ATM decider will also always be a Halting
Computation.

The problem is this ATM decider will never be able to give the right
answer for the machine D.

On 5/31/21 1:57 PM, olcott wrote:

> Although it is true that I mistook an acceptance decider for a halt
> decider we still have a problem.
>
> If H(D,<D>) is required to have the same value as D(<D>) and H(D,<D>) is
> simultaneously required to have the opposite value as D(<D>) then the
> error is only in the requirements and no where else.
>

No, you have your logic wrong.

H(<P,I>) is required to have the same output value as P(<I>) when P(<I>)
is a halting computation, and the value of 'reject' if P(<I>) is
non-halting.

That is the ONLY requirement on H.

The issue is that if H does exist, then we can define the machine D to
be contrary to it, and that is a simple operation.

This means that when we look at the computation H(<D,D>) we find that
whatever answer H was programmed to give for that input, it will be wrong.

It is too late to ask what 'should' H give here, as we have past the
point when we said H was an existing computation. The only answer to
what 'should' H give is what was it programmed to give. The fact that in
working on the design of H we need to consider the case of a machine
that gives the opposite answer to what we would give tells us that we
can't design such a machine.

The error is NOT in the requirements, as the requirements are actually
asking if it is possible to do this. The requirement give the problem
that is wanted to be solved, and EXACTLY the problem that needs to be
solved. The key is that the answer 'We can't make such a machine' is a
perfectly valid answer to the problem. YOU just won't accept it, because
it shows that Mathematics is beyond the reach of your logic system.

On 5/31/2021 1:17 PM, Richard Damon wrote:
> On 5/31/21 1:52 PM, olcott wrote:
> Note, that the Acceptance decider needs to be able to convert
> non-halting machines into reject answers, so it does need to be able to
> detect this non-halting behavior.
>

OK, great this is the very first time that one of your clarifications
made sense. Your clarification reminded me of this superb video lecture
about the Sipser proof saying the same thing.

The Sipser proof was the basis for this superb lecture by
Professor Dan Gusfield of UC Davis:

L15: Proof by Diagonalization that ATM (Halting Problem) is Not
Decidable Dec 12, 2012 https://www.youtube.com/watch?v=jM6osxSX9GA

> And, just like before, it isn't given any special permission to answer
> with a non-conforming answer just because the machine it is given uses
> itself.
>

If H(D,<D>) is required to have the same value as D(<D>) and H(D,<D>) is
simultaneously required to have the opposite value as D(<D>) then the
error is only in the requirements and no where else.

> If the computation it has been given halts, then ATM must give the same
> answer as that machine. If the computation it has been given does not
> halt, it gives the answer reject.
>
> PERIOD. Definition the machine needs to meet.
>
> Since this must always be a halting computation, D which returns the
> opposite answer of this ATM decider will also always be a Halting
> Computation.
>

H is always a halting computation. When we make sure to fully encode D
concretely so that zero details can possibly slip through the cracks of
abstractions we find that D specifies infinitely nested simulation on
its first line, thus H(D ⟨D⟩) rejects its input.

When H(D, ⟨D⟩) it resolves to reject, yet D never resolves to any value.
When D(⟨D⟩) is executed it resolves to accept.

int D(u32 P) // P is a machine address
{ if ( H(P, P) )
return 0 // reject when H accepts
return 1; // accept when H rejects
}

We can know that simulating halt decider H must stop simulating its D
input because if H did not stop simulating its input then D would have
the same halting behavior as if D called Simulate(D,D) instead of H.

The above analysis is confirmed by actual execution of the above
function in the x86utm operating system. H detects an infinitely
repeating non-halting pattern that never reaches the second line of D.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 5/31/2021 1:30 PM, Richard Damon wrote:
> On 5/31/21 1:57 PM, olcott wrote:
>
>> Although it is true that I mistook an acceptance decider for a halt
>> decider we still have a problem.
>>
>> If H(D,<D>) is required to have the same value as D(<D>) and H(D,<D>) is
>> simultaneously required to have the opposite value as D(<D>) then the
>> error is only in the requirements and no where else.
>>
>
> No, you have your logic wrong.
>
> H(<P,I>) is required to have the same output value as P(<I>) when P(<I>)
> is a halting computation, and the value of 'reject' if P(<I>) is
> non-halting.

The key detail that everyone but Ben ignores is that if P(<I>) only
halts because some aspect of it was forced to halt then this does not
count as a halting computation.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 5/31/2021 1:30 PM, Richard Damon wrote:
> On 5/31/21 1:57 PM, olcott wrote:
>
>> Although it is true that I mistook an acceptance decider for a halt
>> decider we still have a problem.
>>
>> If H(D,<D>) is required to have the same value as D(<D>) and H(D,<D>) is
>> simultaneously required to have the opposite value as D(<D>) then the
>> error is only in the requirements and no where else.
>>
>
> No, you have your logic wrong.
>
> H(<P,I>) is required to have the same output value as P(<I>) when P(<I>)
> is a halting computation, and the value of 'reject' if P(<I>) is
> non-halting.
>
> That is the ONLY requirement on H.
>
> The issue is that if H does exist, then we can define the machine D to
> be contrary to it, and that is a simple operation.
>

What if we can't define D to be contrary to it? In that case we did not
prove that H does not exist we only proved that D doesn't exist.

In the case of H(D,<D>), D can't be contrary to H because D is aborted
before D does anything.

int D(u32 P) // P is a machine address
{ if ( H(P, P) )
return 0 // reject when H accepts
return 1; // accept when H rejects
}

When we make this concrete so that no details leak through the cracks of
abstractions we see that in the computation H(D,<D>), D must be aborted
before it ever does anything.

That you simply keep ignoring this or denying the verified fact of the
truth of this is actually no rebuttal at all.

People realized that they could not prove me wrong <because I am not
wrong> and gave up because they only cared about proving me wrong and <I
am not wrong>.

> This means that when we look at the computation H(<D,D>) we find that
> whatever answer H was programmed to give for that input, it will be wrong.
>
> It is too late to ask what 'should' H give here, as we have past the
> point when we said H was an existing computation. The only answer to
> what 'should' H give is what was it programmed to give. The fact that in
> working on the design of H we need to consider the case of a machine
> that gives the opposite answer to what we would give tells us that we
> can't design such a machine.
>
> The error is NOT in the requirements, as the requirements are actually
> asking if it is possible to do this. The requirement give the problem
> that is wanted to be solved, and EXACTLY the problem that needs to be
> solved. The key is that the answer 'We can't make such a machine' is a
> perfectly valid answer to the problem. YOU just won't accept it, because
> it shows that Mathematics is beyond the reach of your logic system.
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 5/31/21 3:22 PM, olcott wrote:
> On 5/31/2021 1:30 PM, Richard Damon wrote:
>> On 5/31/21 1:57 PM, olcott wrote:
>>
>>> Although it is true that I mistook an acceptance decider for a halt
>>> decider we still have a problem.
>>>
>>> If H(D,<D>) is required to have the same value as D(<D>) and H(D,<D>) is
>>> simultaneously required to have the opposite value as D(<D>) then the
>>> error is only in the requirements and no where else.
>>>
>>
>> No, you have your logic wrong.
>>
>> H(<P,I>) is required to have the same output value as P(<I>) when P(<I>)
>> is a halting computation, and the value of 'reject' if P(<I>) is
>> non-halting.
>
> The key detail that everyone but Ben ignores is that if P(<I>) only
> halts because some aspect of it was forced to halt then this does not
> count as a halting computation.
>

But, if P(I) halts because its algorithm includes the decisions, then it
does count.

The ONLY thing that matters to the halting of P(I) is will the machine
P, when processing the input I will the processing come to its results
or keep on running.

That is the classical definition of Halting, and is the definition that
other proofs using the Halting Theorem use. It is with this definition
that it can be shown that it is impossible to create a universal halt
decider, and with this definition you have actually agreed with the
theorem, that you can't make such a halt decider.

But that is all with the Halting Problem.

For the Diagonalization ATM proof, what matters is the machines answer,
or that it doesn't answer. It doesn't matter HOW that answer came about.

If P(I) stops at acceptance, it is accepted, and the ATM decider needs
to say acceptance. If P(I) stops at rejected, it is rejected, and the
ATM decider needs to say rejected, if P(I) is non-halting, the ATM
decider needs to say rejected in finite time.

Since D is an always Halting Computation (if it exists because H exists)
then this simplifies to H must always answer what D says. The fact that
H needs to be a computation and that D will always answer the opposite
of what H says, makes it impossible for H to give a answer that meets
its requirements, so it can't exists as a correct decider.

On 5/31/21 3:55 PM, olcott wrote:
> On 5/31/2021 1:30 PM, Richard Damon wrote:
>> On 5/31/21 1:57 PM, olcott wrote:
>>
>>> Although it is true that I mistook an acceptance decider for a halt
>>> decider we still have a problem.
>>>
>>> If H(D,<D>) is required to have the same value as D(<D>) and H(D,<D>) is
>>> simultaneously required to have the opposite value as D(<D>) then the
>>> error is only in the requirements and no where else.
>>>
>>
>> No, you have your logic wrong.
>>
>> H(<P,I>) is required to have the same output value as P(<I>) when P(<I>)
>> is a halting computation, and the value of 'reject' if P(<I>) is
>> non-halting.
>>
>> That is the ONLY requirement on H.
>>
>> The issue is that if H does exist, then we can define the machine D to
>> be contrary to it, and that is a simple operation.
>>
>
> What if we can't define D to be contrary to it? In that case we did not
> prove that H does not exist we only proved that D doesn't exist.

But we can show that we CAN construct the D given an H. It is a TRIVIAL
modification of the machine H.

>
> In the case of H(D,<D>), D can't be contrary to H because D is aborted
> before D does anything.

H doesn't abort its caller. The only way to do that is to not answer,
and thus it has failed to meet its requirements.

>
> int D(u32 P)   // P is a machine address
> {
>   if ( H(P, P) )
>     return 0   // reject when H accepts
>   return 1;    // accept when H rejects
> }
>
> When we make this concrete so that no details leak through the cracks of
> abstractions we see that in the computation H(D,<D>), D must be aborted
> before it ever does anything.
>
> That you simply keep ignoring this or denying the verified fact of the
> truth of this is actually no rebuttal at all.

The problem that you haven't ever shown code for H that actually IS a
Turing Equivalent.

For instance, H(P, P) isn't passing a 'tape' with two copies of P, so we
are strying from a simple equivalency model.

But even with all these problems, it is still impossible to build an H
that meets the requirements for being a computation of a decider, which
include:

1) Always returns the same answer for ALL calls to it with the same
parameter

2) To be a decider, must always return an answer

3) To be a correct decider, must always return the RIGHT answer based on
the ACTUAL CLASSICAL definitions.

H will fail these requirements, so it is not a proper decider.

>
> People realized that they could not prove me wrong <because I am not
> wrong> and gave up because they only cared about proving me wrong and <I
> am not wrong>.

Who gave up? Who is ignoring the proofs?

YOU ARE WRONG.

YOU REFUESE TO LOOK AT LOGIC.

On 5/31/21 3:19 PM, olcott wrote:
> On 5/31/2021 1:17 PM, Richard Damon wrote:
>> On 5/31/21 1:52 PM, olcott wrote:
>> Note, that the Acceptance decider needs to be able to convert
>> non-halting machines into reject answers, so it does need to be able to
>> detect this non-halting behavior.
>>
>
> OK, great this is the very first time that one of your clarifications
> made sense. Your clarification reminded me of this superb video lecture
> about the Sipser proof saying the same thing.
>
> The Sipser proof was the basis for this superb lecture by
> Professor Dan Gusfield of UC Davis:
>
> L15: Proof by Diagonalization that ATM (Halting Problem) is Not
> Decidable Dec 12, 2012  https://www.youtube.com/watch?v=jM6osxSX9GA

Yes, you posted this same video several times. It still is correct in
proving that ATM is not decidable.

>
>> And, just like before, it isn't given any special permission to answer
>> with a non-conforming answer just because the machine it is given uses
>> itself.
>>
>
> If H(D,<D>) is required to have the same value as D(<D>) and H(D,<D>) is
> simultaneously required to have the opposite value as D(<D>) then the
> error is only in the requirements and no where else.

You have the requirements wrong.

H is only required to have the same value as the machine if the machine
halts, and is required to have the value reject if that machine doesn't
halt.

The is no 'requirement' that H have the opposite value of D. The
requirement is always that H has the same value as a Halting Computation.

The issue is that H MUST be a computation, a definite algorithm that is
fixed in answer for any given input given to it. It is also possible to
create another computation, named D in this example that CAN use H and
return to its caller the opposite answer from H. When we look at this
example, it is clear that whatever computation H does, there is no
answer it can give that is right, therefore H can't exist as a
universally correct decider. This isn't an error in the requirements, it
is just a case that there is algorithm that can solve the puzzle.

This is just like the problem of making an algorithm that will always
WIN at Tic-Tac-Toe. There is no such algorithm.

>
>> If the computation it has been given halts, then ATM must give the same
>> answer as that machine. If the computation it has been given does not
>> halt, it gives the answer reject.
>>
>> PERIOD. Definition the machine needs to meet.
>>
>> Since this must always be a halting computation, D which returns the
>> opposite answer of this ATM decider will also always be a Halting
>> Computation.
>>
>
> H is always a halting computation. When we make sure to fully encode D
> concretely so that zero details can possibly slip through the cracks of
> abstractions we find that D specifies infinitely nested simulation on
> its first line, thus H(D ⟨D⟩) rejects its input.

Nope. Since H is a halting computation, by inspection D must be too.

The issue is that because D knows the behavior of H (since H must come
first) it can act to defeat H. It is sort of like H and D are playing
Rock-Paper-Scissors, but D gets to see what H puts out before it needs to.

>
> When H(D, ⟨D⟩) it resolves to reject, yet D never resolves to any value.
> When D(⟨D⟩) is executed it resolves to accept.

Right, D(<D>) is accept, H(<D,D>) by your logic resolves to reject
because it doesn't see that D(<D>) did resolve to accept, and thus it
gives the wrong answer of reject.

H was WRONG, because D(<D>) does accept, but it isn't 'smart' enough to
resolve the apparent infinite recursion that it MUST resolve or be
non-answering.

>
> int D(u32 P)   // P is a machine address
> {
>   if ( H(P, P) )
>     return 0   // reject when H accepts
>   return 1;    // accept when H rejects
> }
>
> We can know that simulating halt decider H must stop simulating its D
> input because if H did not stop simulating its input then D would have
> the same halting behavior as if D called Simulate(D,D) instead of H.
>
> The above analysis is confirmed by actual execution of the above
> function in the x86utm operating system.  H detects an infinitely
> repeating non-halting pattern that never reaches the second line of D.
>
>

Yes, H stops its simulation of D and thus, by your logic returns rejected.

When we look at what D will do (not the simulation of D inside H, but D
as an actual machine) we see that BECAUSE H say reject, it will say
accept in finite time.

This is where you ALWAYS seem to fail. You look at the simulation and
see that the D in there was terminated, so you assume the D is
non-halting, but when we actually run D, it isn't being simulated, so
nothing CAN terminate it, so it gets the answer from H and counterdics
it. You refuse to look at the ACTUAL REALITY of the machine. THAT is
where the TRUTH is.

You make the FALSE assumption that you program is correct. IT ISN'T.

You have even admitted that the actual behavior of the machines is
different than you machine determined, but you have gas-lighted yourself
so bad you refuse to look at that reality.

On 5/31/2021 10:53 AM, Mike Terry wrote:
> On 30/05/2021 21:37, olcott wrote:
>> On 5/30/2021 2:24 PM, olcott wrote:
>>>
>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>>
>
> tldr;  just the usual "PO totally failing to understand what he is
> reading, and as a result confidently spouting nonsense as a result"...
>
> FTR, PO is pretty much incapable of following abstract reasoning or
> understanding abstact concepts.  "Arguing" with him is totally
> pointless.  Do not assume that because he replies to a post and nobody
> responds, that means he has said anything coherent or logical, or that
> anybody else implicitly agrees with what he said.
>
>>>
>> Refuting the Halting Problem Diagonalization Argument
>>
>> Every machine that halts in a reject state is a halting computation.
>> At least two proofs ignore this when constructing Sipser's Figure 4.5.
>> Because these two proofs ignore this when they insert machine D into
>> Sipser's Figure 4.5 they do so incorrectly.
>
> Dude... Sipser explicitly says blank entries are "either non-halting or
> reject" entries.  He is not ignoring anything.  You just can't follow
> his argument.
>
> I think you are confused at what you're looking at in Sipser. You
> reference Sipser's Theorem 4.9, and it's clear you think that is a proof
> of the undecidability of the Halting Problem.  IT IS NOT - it's a proof
> of the undecidability of the *Accepting* TM problem.  The clue for you
> should have been in the name ATM (rather than HTM).  Didn't you wonder
> What the A stood for?

Thanks for your correction.
Without corrections it is much harder to get on the right track.

The diagonal proof merely shows that at least one of H and D do not exist.

#define u32 uint32_t

int Simulate(u32 P, u32 I)
{ ((void(*)(u32))P)(I);
return 1;
}

int D(u32 P) // P is a machine address
{ if ( H(P, P) )
return 0 // reject when H accepts
return 1; // accept when H rejects
}

int main()
{ H((u32)D, (u32)D);
}

We can know that simulating halt decider H must stop simulating its
input because if H did not stop simulating its input then D would have
the same halting behavior as if D called Simulate instead of H.

The above analysis is confirmed by actual execution of the above
function in the x86utm operating system. H detects an infinitely
repeating non-halting pattern that never reaches the second line of D.

Therefore no D exists that always has an accept/reject value that is the
opposite of H. In the above case D is aborted before it ever has any
accept/reject value.

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 5/31/21 9:07 PM, olcott wrote:
> On 5/31/2021 10:53 AM, Mike Terry wrote:
>> On 30/05/2021 21:37, olcott wrote:
>>> On 5/30/2021 2:24 PM, olcott wrote:
>>>>
>>>> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>>>>
>>
>> tldr;  just the usual "PO totally failing to understand what he is
>> reading, and as a result confidently spouting nonsense as a result"...
>>
>> FTR, PO is pretty much incapable of following abstract reasoning or
>> understanding abstact concepts.  "Arguing" with him is totally
>> pointless.  Do not assume that because he replies to a post and nobody
>> responds, that means he has said anything coherent or logical, or that
>> anybody else implicitly agrees with what he said.
>>
>>>>
>>> Refuting the Halting Problem Diagonalization Argument
>>>
>>> Every machine that halts in a reject state is a halting computation.
>>> At least two proofs ignore this when constructing Sipser's Figure
>>> 4.5. Because these two proofs ignore this when they insert machine D
>>> into Sipser's Figure 4.5 they do so incorrectly.
>>
>> Dude... Sipser explicitly says blank entries are "either non-halting
>> or reject" entries.  He is not ignoring anything.  You just can't
>> follow his argument.
>>
>> I think you are confused at what you're looking at in Sipser. You
>> reference Sipser's Theorem 4.9, and it's clear you think that is a
>> proof of the undecidability of the Halting Problem.  IT IS NOT - it's
>> a proof of the undecidability of the *Accepting* TM problem.  The clue
>> for you should have been in the name ATM (rather than HTM).  Didn't
>> you wonder What the A stood for?
>
> Thanks for your correction.
> Without corrections it is much harder to get on the right track.
>
> The diagonal proof merely shows that at least one of H and D do not exist.

Right, and since if H does exist, we can provavly construct D, it means
that H does not exist.
>
> #define u32 uint32_t
>
> int Simulate(u32 P, u32 I)
> {
>   ((void(*)(u32))P)(I);
>   return 1;
> }
>
> int D(u32 P)   // P is a machine address
> {
>   if ( H(P, P) )
>     return 0   // reject when H accepts
>   return 1;    // accept when H rejects
> }
>
> int main()
> {
>   H((u32)D, (u32)D);
> }
>
> We can know that simulating halt decider H must stop simulating its
> input because if H did not stop simulating its input then D would have
> the same halting behavior as if D called Simulate instead of H.
>
> The above analysis is confirmed by actual execution of the above
> function in the x86utm operating system.  H detects an infinitely
> repeating non-halting pattern that never reaches the second line of D.
>
> Therefore no D exists that always has an accept/reject value that is the
> opposite of H. In the above case D is aborted before it ever has any
> accept/reject value.
>

But, the only way that D can not exist is for H to not exist, as the
construction of D from H is provably possible if H does exist.

Thus if we prove that D doesn't exist, we have proven that H doesn't exist.