The Sipser diagonalization proof forms its conclusion as a preface to
this proof: “Thus neither TM D nor TM H can exist.” (Sipser:1997:165)
The diagonalization portion of this proof merely shows the there is no
machine D that always outputs the opposite of what H outputs.

#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);
}

A simulating halt decider that never stops simulating its input is
simply a simulator on this input.

If H() never stopped simulating D() then it can be seen that the halting
behavior of D() would be the same as if D() invoked Simulate() instead
of H(), thus D() would never terminate.

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.

Sipser, Michael 1997. Introduction to the Theory of Computation. Boston:
PWS Publishing Company (165-167)

--
Copyright 2021 Pete Olcott

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

On 5/31/2021 9:02 PM, Richard Damon wrote:
> On 5/31/21 9:28 PM, olcott wrote:
>> The Sipser diagonalization proof forms its conclusion as a preface to
>> this proof: “Thus neither TM D nor TM H can exist.” (Sipser:1997:165)
>> The diagonalization portion of this proof merely shows the there is no
>> machine D that always outputs the opposite of what H outputs.
>
> And since we can ALWAYS for such a D for any H that does exist, the
> non-existance of D proves 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);
>> }
>>
>> A simulating halt decider that never stops simulating its input is
>> simply a simulator on this input.
>>
>> If H() never stopped simulating D() then it can be seen that the halting
>> behavior of D() would be the same as if D() invoked Simulate() instead
>> of H(), thus D() would never terminate.
>
> But if H() never stopped simulating D() then H() fails to be the needed
> decider. In that case it doesn't matter if D() is non-halting, H already
> has failed to meet its requirements.

This is the point where your lack of comprehension of basic software
engineering principles makes your comprehension impossible.

Because D() is calling H() in infinitely nested simulation H() must
abort this simulation or H() will not be a decider.

The nutty idea that you are proposing is that H() must get stuck in
infinite execution or H() is not a decider. That is a very nutty idea.

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

--
Copyright 2021 Pete Olcott

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

On 6/1/2021 6:50 AM, Richard Damon wrote:
> On 5/31/21 11:38 PM, olcott wrote:
>> On 5/31/2021 9:02 PM, Richard Damon wrote:
>>> On 5/31/21 9:28 PM, olcott wrote:
>>>> The Sipser diagonalization proof forms its conclusion as a preface to
>>>> this proof: “Thus neither TM D nor TM H can exist.” (Sipser:1997:165)
>>>> The diagonalization portion of this proof merely shows the there is no
>>>> machine D that always outputs the opposite of what H outputs.
>>>
>>> And since we can ALWAYS for such a D for any H that does exist, the
>>> non-existance of D proves 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);
>>>> }
>>>>
>>>> A simulating halt decider that never stops simulating its input is
>>>> simply a simulator on this input.
>>>>
>>>> If H() never stopped simulating D() then it can be seen that the halting
>>>> behavior of D() would be the same as if D() invoked Simulate() instead
>>>> of H(), thus D() would never terminate.
>>>
>>> But if H() never stopped simulating D() then H() fails to be the needed
>>> decider. In that case it doesn't matter if D() is non-halting, H already
>>> has failed to meet its requirements.
>>
>> This is the point where your lack of comprehension of basic software
>> engineering principles makes your comprehension impossible.
>>
>> Because D() is calling H() in infinitely nested simulation H() must
>> abort this simulation or H() will not be a decider.
>>
>> The nutty idea that you are proposing is that H() must get stuck in
>> infinite execution or H() is not a decider. That is a very nutty idea.
>>
>>
>> https://www.researchgate.net/publication/351947980_Refuting_the_Sipser_Halting_Problem_Proof
>>
>
> I suggest YOU look at the REAL principles of REAL Software Engineering.
> In particular, look at what ACTUALLY happens, not what you think happens.
>
> D() is NOT actually calling H() in an infinitely nested simulation,
> because if it was, then H() could NEVER return to ANYBODY. This is only
> a potentially infinite recursion that H() break, but it is the H() that
> is part of D(), so D() gets credit for it.
>
> Since H() does stop the otherwise potentially infinite recursion (so it
> can meet its requirements) it IS able to return to the D() that called it.
>

Not exactly

(1) The first line of main() detects an infinitely repeating non
halting pattern on the first line of D. This line must be aborted before
ever returning any value to D. The first line of main() returns 0 for
reject.

(2) The second line of main() returns 1 accept on the basis that H
detects an infinitely repeating non-halting pattern and returns 0 for
reject.

#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()
{ u32 HDD_Acceptance = H((u32)D, (u32)D); // reject
u32 DD_Acceptance = D((u32)D); // accept
Output("H(D,D) Would_Halt = ", HDD_Acceptance);
Output("D(D) Would_Halt = ", DD_Acceptance);
}

A simulating halt decider that never stops simulating its input is
simply a simulator on this input. If H() never stopped simulating D()
then it can be seen that the halting behavior of D() would be the same
as if D() invoked Simulate() instead of H(), thus D() would never
terminate. The above analysis is confirmed by actual execution of the
above function in the x86utm operating system:

> I will point out that YOU have even posted traces showing this to
> happen. It is a sad mind that will not even believe what they produce
> themselves.
>
> I will note, I have NEVER said that H() (in any of its various forms you
> have made it) needs to avoid terminating its simulation, as it is clear
> that a decider based on simulation must do this when it has determined
> that the machine it is simulating is infinite, or it won't be able to
> answer in finite time. What I have been saying is that it needs to make
> its decision on PROPER logic, not just made up rules, if it wants to be
> accurate.

Now that I have simplified my words they should be able to be verified
as clearly correct.

> The second point is to accept that you are attempting to do the
> impossible, it has been PROVED that it is impossible to perform 100%
> accurate Halt Deciding on Turing Machines. This says that any algorithm
> you can imagine is going to end up in some cases either getting the
> answer wrong, failing to decide, or possible know that it can't handle
> this case.
>

On the other hand even the simplified words that I posted above do show
that my H correctly decides this impossible case. The correct halting
decision of line one of main() is 0 for reject.

Because everyone really believes that halting is undecidable even when
they see halting being correctly decided their belief overrides the
verified facts.

> The only way out of the 'problem', which you seem to be trying, is to
> redefine the problem in some way, the key is you must accept that you
> ARE redefining the problem and accept that you are working on a
> different problem.

u32 HDD_Acceptance = H((u32)D, (u32)D);
is correctly decided as reject (not-halting).

> I suppose the one issue with that for you is that I
> don't think you are actually concerned about the Halting Problem itself,
> but that the Halting Problem is one of the core proofs used to tarnish
> your concept of Truth. For that, you just really need to accept that the
> concept of all Truth being Provable is a limited concept, you CAN define
> systems that work with that definition, but they are limited to what
> they can show, and in particular, the full field of Mathematics is
> outside that logic system.
>
> You aren't alone in that pursuit, many Mathematicians, even some great
> ones, have worked to see if a theory of Mathematics could be developed
> that worked within a logic system like that, and only in the last
> Century has the nails been put into the coffin to show that Mathematics
> is just too rich of a field to be contained by that type of Logic.
>
> Yes, fundamentally Maths ability to create self-referential and infinite
> statements breaks it out of the bounds of such simple logics.
>
> You seem SO intent on trying to prove that Math can be constrained to
> follow these limited logics that you are blinding yourself to any
> evidence to the contrary. Maybe that puts you in good company, but it
> does put you about a century behind in what is actually known in the field.
>
> If you REALLY are that intent on writing this paper to 'prove' what you
> claim, even though you have been shown the holes in it, you only real

Bullshit on that! My code speaks for itself.

> option is to just write it and submit it and get it rejected for the
> craziness it is. If you will not listen to our reasoning, why do you
> ask. Remember, YOU are the one trying to make a BIG claim. If you want
> to be persuasive in a technical audience, you need to be prepared to
> make a REAL argument, for REAL basises.
>
> Look for example at the claim you made here, you referenced what you
> called "Basic Software Engineering Principles", but you made NO
> reference to a reputable source of a REAL principle that is firmly
> established, just a general adage being misused. No 'source' for the

The key software engineering principle that seems to remain beyond your
comprehension is that any function calling another function in infinite
recursion never receives any return value from this function that it
called. This applies to: u32 HDD_Acceptance = H((u32)D, (u32)D);

> adage to allow checking if it is being quoted right and used according
> to its principles. Yes, a function that is REALLY caught in an infinite
> loop will never return to its caller, but such a function NEVER returns,
> it doesn't matter about its caller. The higher principle that you are
> ignoring is that a true function acts independent of how it is called.
>
> By NOT actually referring to the source of your 'basic principles' you
> show a lack of real understanding of them. Like so many pieces of your
> arguments, you show that you have just a passing understanding of them,
> and that you won't let actual Facts get in the way of your own ideas of
> how things should be.
>