https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument

--
Copyright 2021 Pete Olcott

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

On 5/30/2021 2:24 PM, olcott wrote:
>
> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
>
>
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.

When machine D is inserted into both Figure 4.4 and Figure 4.5 correctly
then the contradiction goes away. Since Sipser implicitly assumes that
every blank entry of Figure 4.4 is a ~halt entry Figure 4.7a makes this
explicit.

    <M1>     <M2>     <M3>     <M4> ... <D>
M1  accept   ~halt    accept   ~halt    reject
M2  accept   accept   accept   accept   reject
M3  ~halt    ~halt    ~halt    ~halt    accept
M4  accept   accept   ~halt    ~halt    accept
....
D   reject   reject   accept   accept   reject

Figure 4.7a (corrected figure 4.6, inserting D into figure 4.4)

    <M1>     <M2>     <M3>     <M4> ... <D>
M1  accept   reject   accept   reject   accept
M2  accept   accept   accept   accept   accept
M3  reject   reject   reject   reject   accept
M4  accept   accept   reject   reject   accept
....
D   accept   accept   accept   accept   accept

Figure 4.7b (corrected figure 4.6, inserting D into figure 4.5)

--
Copyright 2021 Pete Olcott

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

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.

When machine D is inserted into both Figure 4.4 and Figure 4.5 correctly
then the contradiction goes away. Since Sipser implicitly assumes that
every blank entry of Figure 4.4 is a ~halt entry Figure 4.7a makes this
explicit.

<M1> <M2> <M3> <M4> ... <D>
M1 accept ~halt accept ~halt reject
M2 accept accept accept accept reject
M3 ~halt ~halt ~halt ~halt accept
M4 accept accept ~halt ~halt accept
....
D reject reject accept accept reject

Figure 4.7a (corrected figure 4.6, inserting D into figure 4.4)

<M1> <M2> <M3> <M4> ... <D>
M1 accept reject accept reject accept
M2 accept accept accept accept accept
M3 reject reject reject reject accept
M4 accept accept reject reject accept
....
D accept accept accept accept accept

Figure 4.7b (corrected figure 4.6, inserting D into figure 4.5)

https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument

--
Copyright 2021 Pete Olcott

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

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.

--
Copyright 2021 Pete Olcott

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

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.

--
Copyright 2021 Pete Olcott

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

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/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 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