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

When we do run D as a machine, If H() does terminate its simulation of
its copy of D and returns its answer to the D that is built on that H,
it will then return the opposite answer, thus H() if it exsits, will be
wrong.

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

Except you never do check by running D as a top level machine, to see
that D will halt (as long as H does give an answer to confound).
>
> Sipser, Michael 1997. Introduction to the Theory of Computation. Boston:
> PWS Publishing Company (165-167)
>

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

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.

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.

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

You CLAIM, that you believe that all Truth is actually provable, but you
seem to be unable to actually PROVE anything going to true basic
principles. Maybe you should study what it really means to prove (or
disprove) something before you go on. Everything you have done is really
just Rhetorical Arguments, arguments based on making things SEEM right,
even if you can't really prove them.

You yourself a long time ago made the claim that we needed to put aside
what our 'intuition' was telling us and go by the real logic. You should
follow your own advice. The only problem was to you, 'Intuition' was the
basic principles of logic and definition, while Logic was your
Rhetorical arguemnts based on what SEEMED to be 'obvious' truths. Follow
that ACTUAL saying. LOOK at what ACTUALLY happens in the system, and
believe it.

For example, you SAY that H() won't return to D(), but that is because
you only are willing to look at the system when H simulated D calling
H(), and that inner H() gets aborted so it never returns to D. You
refuse to look at the reality case when D is run as the machine and
calls H(), in THAT case, H must and will return to D, and THAT is the
case the definitions are based on. You get stuck in the 'fake' world of
the simulations, and fail to look at the true reality.

As I said, if you won't listen to use, burn your bridges and submit the
paper and get laughed at in the real academic community. I think in the
back of your mind you know that will happen, and you have been trying to
improve your 'scam' by seeing what holes we can poke in it so you can
improve those. The problem is you arguement is more of a net than a
wall, so there are just too many holes to plug.

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

On 6/1/21 10:03 AM, olcott wrote:
> 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:

Problem is that you output is wrong.

The question is NOT did D Halt, it was did D accept its input.

IF H says that D rejected its input, the D will accept it, as you have
noted.

That says that H was WRONG.

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

H said Reject
D said Accept

How can that not be wrong? H, to be right MUST say the same as D.

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

Reject is NOT Accept. IF you think they are the same, your mind is
caught in a inconsistency.

> 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).

But D when Run says Accept!!

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