Because my writing style is not in the ballpark of academic quality and
and computer scientists are loath to even consider evaluating computer
science in terms of software engineering my paper would be rejected
out-of-hand without any review at all entirely on the basis of style
over substance.

The way around this is to make my software engineering proof so clear
that every very well qualified software engineer can validate it
entirely on the basis of its software engineering.

The furthest that this can get me is that the software engineering of my
proof does correctly show:

void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{ P((u32)P);
}

(1) The above computation does specify an infinite chain of invocations
that is computationally equivalent to infinite recursion.

(2) Partial halt decider H correctly recognizes this infinite behavior
pattern, correctly aborts its simulation of P and correctly reports that
P(P) never halts.

As soon as it is clear enough that a very competent software engineer
can confirm the above (I think that it is finally there now) then a
computer scientist that knows software engineering would be able help me
transform what I am saying into academic journal quality.

Halting problem undecidability and infinitely nested simulation

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

--
Copyright 2021 Pete Olcott

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

On Monday, 28 June 2021 at 07:05:49 UTC+8, olcott wrote:
> Because my writing style is not in the ballpark of academic quality and
> and computer scientists are loath to even consider evaluating computer
> science in terms of software engineering my paper would be rejected
> out-of-hand without any review at all entirely on the basis of style
> over substance.
>
> The way around this is to make my software engineering proof so clear
> that every very well qualified software engineer can validate it
> entirely on the basis of its software engineering.
>
> The furthest that this can get me is that the software engineering of my
> proof does correctly show:
>
> void P(u32 x)
> {
> u32 Input_Halts = H(x, x);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
> int main()
> {
> P((u32)P);
> }
>
> (1) The above computation does specify an infinite chain of invocations
> that is computationally equivalent to infinite recursion.
>
> (2) Partial halt decider H correctly recognizes this infinite behavior
> pattern, correctly aborts its simulation of P and correctly reports that
> P(P) never halts.
>
> As soon as it is clear enough that a very competent software engineer
> can confirm the above (I think that it is finally there now) then a
> computer scientist that knows software engineering would be able help me
> transform what I am saying into academic journal quality.
>
>
> Halting problem undecidability and infinitely nested simulation
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein

Let say, in the most extreme case, H is a black box program on a remote server,
probably created by alien (how H works inside is irrelevant).

SYNOPSIS: H <prog>
EXIT STATUS: 0 iff <prog> does not return

/*
Program: P.c

Build: gcc -o P P.c
*/
#include <stdlib.h>

void P() {
int r=system("H P");

if(r) {
for(;;) {}; // halt here
}
};

int main() {
P();
};

-----
It can be shown that H will always be wrong, a impossibly correct program.
+------------+
| Conclusion |
+------------+
There is nothing to do with (infinitely nested) simulation or self-reference.
Any program H that tries to decide the property of P is doomed to fail if P can
deny that property H predicts.
(The chance left unexplored for a correct HP is on a less powerful machine than TM.)

On 6/28/2021 1:48 AM, David Brown wrote:
> On 28/06/2021 01:05, olcott wrote:
>> Because my writing style is not in the ballpark of academic quality and
>> and computer scientists are loath to even consider evaluating computer
>> science in terms of software engineering my paper would be rejected
>> out-of-hand without any review at all entirely on the basis of style
>> over substance.
>>
>
> No, academics will likely reject your ideas out of hand because they are
> wrong.
>
> Endlessly repeating the same misunderstandings and misconceptions does
> not convince anyone in the academic world. It does not convince any
> programmers either, or anyone at all with a remotely logical and
> rational mind.
>
> You have been making off-topic posts in many newsgroups for about 2
> years, and there has been /zero/ progress on your part. This is not
> surprising - the halting problem was proven unsolvable some hundred-odd
> years ago, and reality has not changed since. The proof is simple
> enough that any student doing theoretical computing or mathematics at
> university could duplicate it, and any high-school pupil with a good
> level of mathematics could understand it.
>
> For your own sanity, I would urge you to stop. For other people's
> sanity, I would urge you to stop posting to off-topic groups. Even
> better, start a blog and post only there.
>

One of the smartest software engineers here said that he provided a
complete rebuttal of my work: Mike Terry, so I reviewed his review of my
work. He simply rejected my work out-of-hand without review entirely on
the basis that my sound deductive argument did not conform to the style
of a mathematical proof.

No one here has ever pointed out any actual error in the essence of my
work and it is a damned lie to say that they have.

I did make a huge mistake when I was discussing the diagonalization proof.

--
Copyright 2021 Pete Olcott

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

On 6/27/2021 11:41 PM, wij wrote:
> On Monday, 28 June 2021 at 07:05:49 UTC+8, olcott wrote:
>> Because my writing style is not in the ballpark of academic quality and
>> and computer scientists are loath to even consider evaluating computer
>> science in terms of software engineering my paper would be rejected
>> out-of-hand without any review at all entirely on the basis of style
>> over substance.
>>
>> The way around this is to make my software engineering proof so clear
>> that every very well qualified software engineer can validate it
>> entirely on the basis of its software engineering.
>>
>> The furthest that this can get me is that the software engineering of my
>> proof does correctly show:
>>
>> void P(u32 x)
>> {
>> u32 Input_Halts = H(x, x);
>> if (Input_Halts)
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> P((u32)P);
>> }
>>
>> (1) The above computation does specify an infinite chain of invocations
>> that is computationally equivalent to infinite recursion.
>>
>> (2) Partial halt decider H correctly recognizes this infinite behavior
>> pattern, correctly aborts its simulation of P and correctly reports that
>> P(P) never halts.
>>
>> As soon as it is clear enough that a very competent software engineer
>> can confirm the above (I think that it is finally there now) then a
>> computer scientist that knows software engineering would be able help me
>> transform what I am saying into academic journal quality.
>>
>>
>> Halting problem undecidability and infinitely nested simulation
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein
>
> Let say, in the most extreme case, H is a black box program on a remote server,
You have just left the subject of the halting problem.
The halt decider always has the complete source-code of its input.

--
Copyright 2021 Pete Olcott

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

On 28/06/2021 15:30, olcott wrote:
> On 6/28/2021 1:48 AM, David Brown wrote:
>> On 28/06/2021 01:05, olcott wrote:
>>> Because my writing style is not in the ballpark of academic quality and
>>> and computer scientists are loath to even consider evaluating computer
>>> science in terms of software engineering my paper would be rejected
>>> out-of-hand without any review at all entirely on the basis of style
>>> over substance.
>>>
>>
>> No, academics will likely reject your ideas out of hand because they are
>> wrong.
>>
>> Endlessly repeating the same misunderstandings and misconceptions does
>> not convince anyone in the academic world.  It does not convince any
>> programmers either, or anyone at all with a remotely logical and
>> rational mind.
>>
>> You have been making off-topic posts in many newsgroups for about 2
>> years, and there has been /zero/ progress on your part.  This is not
>> surprising - the halting problem was proven unsolvable some hundred-odd
>> years ago, and reality has not changed since.  The proof is simple
>> enough that any student doing theoretical computing or mathematics at
>> university could duplicate it, and any high-school pupil with a good
>> level of mathematics could understand it.
>>
>> For your own sanity, I would urge you to stop.  For other people's
>> sanity, I would urge you to stop posting to off-topic groups.  Even
>> better, start a blog and post only there.
>>
>
> One of the smartest software engineers here said that he provided a
> complete rebuttal of my work: Mike Terry, so I reviewed his review of my
> work. He simply rejected my work out-of-hand without review entirely on
> the basis that my sound deductive argument did not conform to the style
> of a mathematical proof.
>
> No one here has ever pointed out any actual error in the essence of my
> work and it is a damned lie to say that they have.
>
> I did make a huge mistake when I was discussing the diagonalization proof.
>

No one needs to read your arguments to know that you have made a
fundamental mistake. The same would apply if you claimed to have
trisected an angle, squared a circle, found an odd number divisible by
2, or any other problem that have been proven impossible.

The only questions are /where/ you have made a mistake, and whether it
is worth looking for it (or, more likely, them). Have no doubts here -
your argument is wrong, and you /have/ made at least one error. It is
/not/ sound.

If you had given any indication that you understand what you are trying
to do, or any indication that you really are interested in learning
about your mistakes, then maybe it might be worth someone spending their
time trying to teach you a bit and help you learn about this stuff. But
you are only interested in annoying people with re-posts of the same
junk, hiding the real errors in your argument behind insane simulation
choices, and rejecting anyone's counter-arguments without actually
looking at them, never mind understanding them.

I've seen people try to help you. I've seen them pointing out your
mistakes. I've tried to give a few helpful points myself. Since you
have decided in advance that you are correct, you automatically reject
anything that shows you are wrong - and then claim no one has shown your
mistakes. This is known as fanaticism. It is most commonly known in
the context of religion, but can be found pretty much anywhere. Until
you can accept that /you/ might be wrong and everyone else is right, you
cannot hope to make progress or learn anything.

On 6/28/2021 11:09 AM, David Brown wrote:
> On 28/06/2021 15:30, olcott wrote:
>> On 6/28/2021 1:48 AM, David Brown wrote:
>>> On 28/06/2021 01:05, olcott wrote:
>>>> Because my writing style is not in the ballpark of academic quality and
>>>> and computer scientists are loath to even consider evaluating computer
>>>> science in terms of software engineering my paper would be rejected
>>>> out-of-hand without any review at all entirely on the basis of style
>>>> over substance.
>>>>
>>>
>>> No, academics will likely reject your ideas out of hand because they are
>>> wrong.
>>>
>>> Endlessly repeating the same misunderstandings and misconceptions does
>>> not convince anyone in the academic world.  It does not convince any
>>> programmers either, or anyone at all with a remotely logical and
>>> rational mind.
>>>
>>> You have been making off-topic posts in many newsgroups for about 2
>>> years, and there has been /zero/ progress on your part.  This is not
>>> surprising - the halting problem was proven unsolvable some hundred-odd
>>> years ago, and reality has not changed since.  The proof is simple
>>> enough that any student doing theoretical computing or mathematics at
>>> university could duplicate it, and any high-school pupil with a good
>>> level of mathematics could understand it.
>>>
>>> For your own sanity, I would urge you to stop.  For other people's
>>> sanity, I would urge you to stop posting to off-topic groups.  Even
>>> better, start a blog and post only there.
>>>
>>
>> One of the smartest software engineers here said that he provided a
>> complete rebuttal of my work: Mike Terry, so I reviewed his review of my
>> work. He simply rejected my work out-of-hand without review entirely on
>> the basis that my sound deductive argument did not conform to the style
>> of a mathematical proof.
>>
>> No one here has ever pointed out any actual error in the essence of my
>> work and it is a damned lie to say that they have.
>>
>> I did make a huge mistake when I was discussing the diagonalization proof.
>>
>
> No one needs to read your arguments to know that you have made a
> fundamental mistake. The same would apply if you claimed to have
> trisected an angle, squared a circle, found an odd number divisible by
> 2, or any other problem that have been proven impossible.
>

// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{ u32 Input_Halts = H((u32)P, (u32)P);
Output("Input_Halts = ", Input_Halts);
}

Everyone knows that H cannot possibly return the correct halt status of
H(P,P) to P. No one has even considered that a simulating halt decider H
would abort its simulation of P and correctly report that P(P) never
halts on the basis that P(P) specifies infinitely nested simulation.

Halting problem undecidability and infinitely nested simulation

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

> The only questions are /where/ you have made a mistake, and whether it
> is worth looking for it (or, more likely, them). Have no doubts here -
> your argument is wrong, and you /have/ made at least one error. It is
> /not/ sound.
>
> If you had given any indication that you understand what you are trying
> to do, or any indication that you really are interested in learning
> about your mistakes, then maybe it might be worth someone spending their
> time trying to teach you a bit and help you learn about this stuff. But
> you are only interested in annoying people with re-posts of the same
> junk, hiding the real errors in your argument behind insane simulation
> choices, and rejecting anyone's counter-arguments without actually
> looking at them, never mind understanding them.
>
> I've seen people try to help you. I've seen them pointing out your
> mistakes. I've tried to give a few helpful points myself. Since you
> have decided in advance that you are correct, you automatically reject
> anything that shows you are wrong - and then claim no one has shown your
> mistakes. This is known as fanaticism. It is most commonly known in
> the context of religion, but can be found pretty much anywhere. Until
> you can accept that /you/ might be wrong and everyone else is right, you
> cannot hope to make progress or learn anything.

Mike Terry claimed to have pointed out a mistake.

When I read through his prior comments all that he did was reject sound
deductive inference out-of-hand without review entirely on the basis
that it did not conform to the style of a conventional mathematical proof.

--
Copyright 2021 Pete Olcott

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

David Brown <david.brown@hesbynett.no> writes:
> On 28/06/2021 15:30, olcott wrote:
<junk>
> No one needs to read your arguments to know that you have made a
> fundamental mistake.

Yet you copied them to four newsgroups! Please consider trimming the
newsgroups in future.

--
Ben.

On 28/06/2021 19:16, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 28/06/2021 15:30, olcott wrote:
> <junk>
>> No one needs to read your arguments to know that you have made a
>> fundamental mistake.
>
> Yet you copied them to four newsgroups! Please consider trimming the
> newsgroups in future.
>

Sorry, I had not noticed that someone had put the groups back onto the
follow-ups. They were removed from the follow-ups earlier.

On 28/06/2021 18:16, Ben Bacarisse wrote:
> Yet you copied them to four newsgroups! Please consider trimming the
> newsgroups in future.
By trimming make sure you also trim C or C++ newsgroup so that the
thread goes somewhere else. Use follow-up as well if necessary like I
did. There is no point in carrying on a thread that is of less interest
to C or C++ programmers. The OP's interest is purely academic so he can
go to "comp.theory" newsgroup.

On 6/28/2021 12:30 PM, Real Troll wrote:
> On 28/06/2021 18:16, Ben Bacarisse wrote:
>> Yet you copied them to four newsgroups! Please consider trimming the
>> newsgroups in future.
> By trimming make sure you also trim C or C++ newsgroup so that the
> thread goes somewhere else. Use follow-up as well if necessary like I
> did. There is no point in carrying on a thread that is of less interest
> to C or C++ programmers. The OP's interest is purely academic so he can
> go to "comp.theory" newsgroup.
>

Most of the people on comp.theory have given up on the basis that my
position is now irrefutable.

Mike Terry claimed to have refuted my position yet all that he actually
did was reject it out-of-hand without review.

Kaz also never refuted my position yet dismissed my work on the basis
that I did such a terrible job on the diagonalization form of the proof.
Kaz was my best reviewer.

My proof is pure software engineering and is only applied to computer
science as a last step after the software engineering has been fully
validated.

Anyone that is an expert C programmer can probably see that my proof is
correct. It is helpful to also understand the x86 language.

--
Copyright 2021 Pete Olcott

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

On 6/28/2021 6:14 PM, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
> (You might want to check the newsgroups again!)
>
>> You haven't done that. Your argument would work if your halting
>> function existed, but it does not. You have no way of taking an
>> arbitrary computation and deciding if it would halt.
>
> PO is running out of people to talk to so he's gone fishing for new
> interactions. This "one case/all cases" issue has been gone over many
> times.
>
> PO claimed, two and half years ago, to have an impossible TM -- one that
> gets the right answer for the input constructed from it according the
> "usual" construction. He didn't (of course) but the last 30 months have
> been about PO trying to justify having said this.
>
> The claim was never to have a halt decider, but only a partial one.
> These are ten-a-penny, but a TM M that gets the right correctly accept
> or rejects the input <[M^], [M^]> is impossible.
>
> Had he not been lying (or deluded) he could simply have posted the "two
> Turing machines" he claimed to have "fully encoded" in Dec 2018, but he
> never had them.
>
> He has, after months of waffling, settled on a simple plan. He rejects
> the most basic fact about the halting problem and declares false
> (i.e. "does not halt") to be the correct answer for a computation that
> halts. He has made the mistake of being absolutely clear about this.
> He does not dispute the facts:
>
> (a) His Halts function (which has had many names) has
> Halts(Confound_Halts, Confound_Halts) == false, yet
>
> (b) Confound_Halts(Confound_Halts) is a halting computation.
>
> The names change (and sometimes different functions are given the same
> name) but everything he's recently posted is all about a simple word
> game: how can he justify the wrong answer in the one case where everyone
> (including PO) knows that Halts can't give the right one?
>
> The solution is that the "correct answer" for some computations should
> be determined by the halting or non-halting of another computation. If
> the computation passed to Halts would not halt were it not stopped,
> halted or aborted then it's a non-halting computation!
>
> Confound_Halts(Confound_Halts) only halts because Halts (at some level
> of nesting) detects the pattern. Confound_Halts(Confound_Halts) is
> "forced" to halt, so it's not really a halting computation at all!
>
> Of course, being PO, there are dozens of technical errors alone the way.

I dare you to point to one:
Halting problem undecidability and infinitely nested simulation

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

> He regularly misuses technical terms, and often slips up and says that
> he really does have a halt decider, but the gist of his claim is one TM
> doing something impossible for one single input.
>
> [Confound_Halts was my version of the usual construction:
>
> void Confound_Halts(u32 P) { if (Halts(P, P)) while (1); }
>
> but that's not really significant.]
>

--
Copyright 2021 Pete Olcott

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

On 6/28/21 1:40 PM, olcott wrote:
> On 6/28/2021 12:30 PM, Real Troll wrote:
>> On 28/06/2021 18:16, Ben Bacarisse wrote:
>>> Yet you copied them to four newsgroups!  Please consider trimming the
>>> newsgroups in future.
>> By trimming make sure you also trim C or C++ newsgroup so that the
>> thread goes somewhere else. Use follow-up as well if necessary like I
>> did. There is no point in carrying on a thread that is of less interest
>> to C or C++ programmers. The OP's interest is purely academic so he can
>> go to "comp.theory" newsgroup.
>>
>
> Most of the people on comp.theory have given up on the basis that my
> position is now irrefutable.
>
> Mike Terry claimed to have refuted my position yet all that he actually
> did was reject it out-of-hand without review.
>
> Kaz also never refuted my position yet dismissed my work on the basis
> that I did such a terrible job on the diagonalization form of the proof.
> Kaz was my best reviewer.
>
> My proof is pure software engineering and is only applied to computer
> science as a last step after the software engineering has been fully
> validated.
>
> Anyone that is an expert C programmer can probably see that my proof is
> correct. It is helpful to also understand the x86 language.
>

Don't beleive him. Olcott may be giving up on comp.theory because he is
running out of excuses for how to justify his buggy logic.

His last statement show a key problem with his arguement, he is working
on a Theory that deals with core computation theory from mathematics,
which is part of the very theoretical base of computer science. It has
basically ZERO application to software engineering, so he is basically
being the Bull in the China shop and smashing everything and then say
this proves that it is impossible to wind a watch and have it work.

On 6/28/2021 6:55 PM, Richard Damon wrote:
> On 6/28/21 1:40 PM, olcott wrote:
>> On 6/28/2021 12:30 PM, Real Troll wrote:
>>> On 28/06/2021 18:16, Ben Bacarisse wrote:
>>>> Yet you copied them to four newsgroups!  Please consider trimming the
>>>> newsgroups in future.
>>> By trimming make sure you also trim C or C++ newsgroup so that the
>>> thread goes somewhere else. Use follow-up as well if necessary like I
>>> did. There is no point in carrying on a thread that is of less interest
>>> to C or C++ programmers. The OP's interest is purely academic so he can
>>> go to "comp.theory" newsgroup.
>>>
>>
>> Most of the people on comp.theory have given up on the basis that my
>> position is now irrefutable.
>>
>> Mike Terry claimed to have refuted my position yet all that he actually
>> did was reject it out-of-hand without review.
>>
>> Kaz also never refuted my position yet dismissed my work on the basis
>> that I did such a terrible job on the diagonalization form of the proof.
>> Kaz was my best reviewer.
>>
>> My proof is pure software engineering and is only applied to computer
>> science as a last step after the software engineering has been fully
>> validated.
>>
>> Anyone that is an expert C programmer can probably see that my proof is
>> correct. It is helpful to also understand the x86 language.
>>
>
> Don't beleive him. Olcott may be giving up on comp.theory because he is
> running out of excuses for how to justify his buggy logic.
>
> His last statement show a key problem with his arguement, he is working
> on a Theory that deals with core computation theory from mathematics,
> which is part of the very theoretical base of computer science. It has
> basically ZERO application to software engineering, so he is basically
> being the Bull in the China shop and smashing everything and then say
> this proves that it is impossible to wind a watch and have it work.
>

Apparently you and Ben and now even Mike only have bluster and rhetoric
as the entire basis of your whole ruse of a rebuttal.

--
Copyright 2021 Pete Olcott

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

On 6/28/2021 6:14 PM, Richard Damon wrote:
> On 6/28/21 9:30 AM, olcott wrote:
>> On 6/28/2021 1:48 AM, David Brown wrote:
>>> On 28/06/2021 01:05, olcott wrote:
>>>> Because my writing style is not in the ballpark of academic quality and
>>>> and computer scientists are loath to even consider evaluating computer
>>>> science in terms of software engineering my paper would be rejected
>>>> out-of-hand without any review at all entirely on the basis of style
>>>> over substance.
>>>>
>>>
>>> No, academics will likely reject your ideas out of hand because they are
>>> wrong.
>>>
>>> Endlessly repeating the same misunderstandings and misconceptions does
>>> not convince anyone in the academic world.  It does not convince any
>>> programmers either, or anyone at all with a remotely logical and
>>> rational mind.
>>>
>>> You have been making off-topic posts in many newsgroups for about 2
>>> years, and there has been /zero/ progress on your part.  This is not
>>> surprising - the halting problem was proven unsolvable some hundred-odd
>>> years ago, and reality has not changed since.  The proof is simple
>>> enough that any student doing theoretical computing or mathematics at
>>> university could duplicate it, and any high-school pupil with a good
>>> level of mathematics could understand it.
>>>
>>> For your own sanity, I would urge you to stop.  For other people's
>>> sanity, I would urge you to stop posting to off-topic groups.  Even
>>> better, start a blog and post only there.
>>>
>>
>> One of the smartest software engineers here said that he provided a
>> complete rebuttal of my work: Mike Terry, so I reviewed his review of my
>> work. He simply rejected my work out-of-hand without review entirely on
>> the basis that my sound deductive argument did not conform to the style
>> of a mathematical proof.
>>
>> No one here has ever pointed out any actual error in the essence of my
>> work and it is a damned lie to say that they have.
>>
>> I did make a huge mistake when I was discussing the diagonalization proof.
>>
>
> Except that LOTS of people have made rebuttals point out actual errors,
> so you are just showing how baddly you lie.
>

Point to one error in my H/P C/x86 sound deductive inference:

Halting problem undecidability and infinitely nested simulation
https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

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

On 6/30/2021 1:40 AM, wij wrote:
> On Wednesday, 30 June 2021 at 07:10:02 UTC+8, olcott wrote:
>> On 6/28/2021 6:14 PM, Richard Damon wrote:
>>> On 6/28/21 9:30 AM, olcott wrote:
>>>> On 6/28/2021 1:48 AM, David Brown wrote:
>>>>> On 28/06/2021 01:05, olcott wrote:
>>>>>> Because my writing style is not in the ballpark of academic quality and
>>>>>> and computer scientists are loath to even consider evaluating computer
>>>>>> science in terms of software engineering my paper would be rejected
>>>>>> out-of-hand without any review at all entirely on the basis of style
>>>>>> over substance.
>>>>>>
>>>>>
>>>>> No, academics will likely reject your ideas out of hand because they are
>>>>> wrong.
>>>>>
>>>>> Endlessly repeating the same misunderstandings and misconceptions does
>>>>> not convince anyone in the academic world. It does not convince any
>>>>> programmers either, or anyone at all with a remotely logical and
>>>>> rational mind.
>>>>>
>>>>> You have been making off-topic posts in many newsgroups for about 2
>>>>> years, and there has been /zero/ progress on your part. This is not
>>>>> surprising - the halting problem was proven unsolvable some hundred-odd
>>>>> years ago, and reality has not changed since. The proof is simple
>>>>> enough that any student doing theoretical computing or mathematics at
>>>>> university could duplicate it, and any high-school pupil with a good
>>>>> level of mathematics could understand it.
>>>>>
>>>>> For your own sanity, I would urge you to stop. For other people's
>>>>> sanity, I would urge you to stop posting to off-topic groups. Even
>>>>> better, start a blog and post only there.
>>>>>
>>>>
>>>> One of the smartest software engineers here said that he provided a
>>>> complete rebuttal of my work: Mike Terry, so I reviewed his review of my
>>>> work. He simply rejected my work out-of-hand without review entirely on
>>>> the basis that my sound deductive argument did not conform to the style
>>>> of a mathematical proof.
>>>>
>>>> No one here has ever pointed out any actual error in the essence of my
>>>> work and it is a damned lie to say that they have.
>>>>
>>>> I did make a huge mistake when I was discussing the diagonalization proof.
>>>>
>>>
>>> Except that LOTS of people have made rebuttals point out actual errors,
>>> so you are just showing how baddly you lie.
>>>
>> Point to one error in my H/P C/x86 sound deductive inference:
>> Halting problem undecidability and infinitely nested simulation
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein
>
> In computability theory, the halting problem is the problem of determining, fromal description
> of an arbitrary computer program and an input, whether the program will finish running, or
> continue to run forever...
> https://en.wikipedia.org/wiki/Halting_problem
>
> Your paper says from the beginning:
> When halting is defined as any computation that halts without ever having its
> simulation aborted then it can be understood that partial halt decider H
> correctly decides that its input does not halt on the simplified version of the Linz Ĥ...
>
> Conclusion:
> The paper is not talking about "the halting problem". The rebuttal in the paper
> is made to an assumption the author created in his mind. H proves itself nothing
> different from performing a function
> bool H(...) {
> return false; // or true
> };
> No real thing inside.
>
https://groups.google.com/g/sci.logic/c/4kIXI1kxmsI/m/hRroMoQZx2IJ

The Psychology of Self-Reference
Daryl McCullough
Jun 25, 2004, 6:30:39 PM

It is becoming increasingly clear that Peter Olcott and Herc have
no coherent mathematical argument for rejecting Godel's theorem
and Turing's proof of the unsolvability of the halting problem.
Their objections are really psychological---they feel that the
proofs are somehow a cheat, but they lack the mathematical ability
to say why.

I'd like to talk about the psychology of why people sometimes feel
that Godel's and Turing's proofs are somehow cheats. Partly, it is
the fault of informal intuitive expositions of the results.

Both Godel's proof and Turing's proof have the flavor of using
self-reference to force someone to make a mistake. Both cases
seem a little like the following paradox (call it the "Gotcha"
paradox).

You ask someone (we'll call him "Jack") to give a truthful
yes/no answer to the following question:

Will Jack's answer to this question be no?

Jack can't possibly give a correct yes/no answer to the question.

While the Gotcha paradox gives some of the flavor of Godel's
proof or Turing's proof, there is one big difference, and this
difference is what makes people feel like there is something
fishy going on: In the case of the Gotcha paradox, it
is possible for Jack to *know* the answer, but to be
prevented by the rules from *saying* the answer.

In other words, there is a gap between what Jack knows
and what he can say. He knows that the answer to the question
is "no", but he can't say that answer, because that would
make the answer incorrect. So this informal paradox doesn't
really reveal any limitations in Jack's knowledge---it's
just a quirk of the rules that prevents Jack from telling
the answer. It's a little like the following one-question
quiz:

---------------
| 5 5 5 5 |
| How many 5's |
| appear inside|
| this box? |
| Answer: ___ |
| |
---------------

If you write "5" in the space provided, then the correct answer
is "6", and if you write "6" the correct answer is "5". The fact
that you can't write the correct answer in the space provided
doesn't prove that you have problems counting.

Someone hearing some variant of the Gotcha paradox might be led
to think (as Peter Olcott and Herc do) that Godel's and Turing's
proofs might be cheats in a similar way.

Of course, the difference is that there is no "gap" involved in
Turing's or Godel's proofs. It makes no sense to suppose that
Peano Arithmetic really knows that the Godel statement is true,
but just can't say it, because there is no notion of PA "knowing"
something independently of what it can prove. In the case of Turing's
proof, given a purported solution H to the halting problem,
one comes up with a program Q(x) such that

Q halts on its own input if and only if H(Q,Q) = false

There is no sense in which H "knows" that the answer is true
but is unable to say it.

We could try to modify the Gotcha paradox to eliminate the gap
between what you know and what you can say. Let's consider the
following statement (called "U" for "Unbelievable").

U: Jack will never believe this statement.

Apparently, if Jack believes U, then U is false. So we are left
with two possibilities:

Either (A) Jack believes some false statement, or (B)
there is some true statement that Jack doesn't believe.

This is a lot like Godel's sentence G that shows that PA is
either inconsistent or incomplete. However, it still seems like
a joke, or a trick, rather than something that reveals any
limitations in Jack's knowledge. U doesn't seem to have any
real content, so who cares whether it is true or not, or whether
Jack believes it or not. It isn't a claim about anything tangible,
so who could ever tell if Jack believes it or not, or what it even
*means* for Jack to believe it?

Okay, let's try one more time to get something meaningful that
really reveals a gap in Jack's knowledge akin to Godel's
incompleteness. Suppose that at some future time, the mechanisms
behind the human mind are finally understood. Suppose that it is
possible to insert probes into a person's brain to discover what
the person is thinking, and what he believes.

So we take our subject, Jack, and hook him up with our brain scanning
machine. We give Jack a computer monitor on which we can display
statements for Jack to consider, and we connect his brain scanning
machine to a bell in such a way that if Jack agrees with the statement
on the screen (that is, if the scanning machine determines that Jack
believes the statement) then the bell will ring. Then we display
on the screen the following statement:

On 6/30/2021 11:01 AM, Peter wrote:
> olcott wrote:
>> Because my writing style is not in the ballpark of academic quality [...]
>
> Then fix it.
>

I didn't know where to begin on this except for asking for a computer
science professor to coach me.

Now I do know where to begin on this this paper seems to be a good
model: https://dl.acm.org/doi/abs/10.1145/24658.24665 No copy is
available online so I got one from my university.

The other issue doesn't seem to have much of an alternative. A key part
of the problem that allowed the halting problem to continue to exist is
that it was only analyzed using Turing machines.

When analyzed this way almost all of the details must simply be imagined
rather than explicitly specified. This left huge gaps in the reasoning
about the halting problem.

I cannot convert my proof to the Turing machine model of computation
away from the RASP equivalent model of c/x86 without losing the steps of
my sound deductive inference that prove that my analysis is correct.

Halting problem undecidability and infinitely nested simulation

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

--
Copyright 2021 Pete Olcott

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

On 6/30/2021 7:04 PM, wij wrote:
> On Wednesday, 30 June 2021 at 22:00:42 UTC+8, olcott wrote:
>> On 6/30/2021 1:40 AM, wij wrote:
>>> On Wednesday, 30 June 2021 at 07:10:02 UTC+8, olcott wrote:
>>>> On 6/28/2021 6:14 PM, Richard Damon wrote:
>>>>> On 6/28/21 9:30 AM, olcott wrote:
>>>>>> On 6/28/2021 1:48 AM, David Brown wrote:
>>>>>>> On 28/06/2021 01:05, olcott wrote:
>>>>>>>> Because my writing style is not in the ballpark of academic quality and
>>>>>>>> and computer scientists are loath to even consider evaluating computer
>>>>>>>> science in terms of software engineering my paper would be rejected
>>>>>>>> out-of-hand without any review at all entirely on the basis of style
>>>>>>>> over substance.
>>>>>>>>
>>>>>>>
>>>>>>> No, academics will likely reject your ideas out of hand because they are
>>>>>>> wrong.
>>>>>>>
>>>>>>> Endlessly repeating the same misunderstandings and misconceptions does
>>>>>>> not convince anyone in the academic world. It does not convince any
>>>>>>> programmers either, or anyone at all with a remotely logical and
>>>>>>> rational mind.
>>>>>>>
>>>>>>> You have been making off-topic posts in many newsgroups for about 2
>>>>>>> years, and there has been /zero/ progress on your part. This is not
>>>>>>> surprising - the halting problem was proven unsolvable some hundred-odd
>>>>>>> years ago, and reality has not changed since. The proof is simple
>>>>>>> enough that any student doing theoretical computing or mathematics at
>>>>>>> university could duplicate it, and any high-school pupil with a good
>>>>>>> level of mathematics could understand it.
>>>>>>>
>>>>>>> For your own sanity, I would urge you to stop. For other people's
>>>>>>> sanity, I would urge you to stop posting to off-topic groups. Even
>>>>>>> better, start a blog and post only there.
>>>>>>>
>>>>>>
>>>>>> One of the smartest software engineers here said that he provided a
>>>>>> complete rebuttal of my work: Mike Terry, so I reviewed his review of my
>>>>>> work. He simply rejected my work out-of-hand without review entirely on
>>>>>> the basis that my sound deductive argument did not conform to the style
>>>>>> of a mathematical proof.
>>>>>>
>>>>>> No one here has ever pointed out any actual error in the essence of my
>>>>>> work and it is a damned lie to say that they have.
>>>>>>
>>>>>> I did make a huge mistake when I was discussing the diagonalization proof.
>>>>>>
>>>>>
>>>>> Except that LOTS of people have made rebuttals point out actual errors,
>>>>> so you are just showing how baddly you lie.
>>>>>
>>>> Point to one error in my H/P C/x86 sound deductive inference:
>>>> Halting problem undecidability and infinitely nested simulation
>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>> --
>>>> Copyright 2021 Pete Olcott
>>>>
>>>> "Great spirits have always encountered violent opposition from mediocre
>>>> minds." Einstein
>>>
>>> In computability theory, the halting problem is the problem of determining, fromal description
>>> of an arbitrary computer program and an input, whether the program will finish running, or
>>> continue to run forever...
>>> https://en.wikipedia.org/wiki/Halting_problem
>>>
>>> Your paper says from the beginning:
>>> When halting is defined as any computation that halts without ever having its
>>> simulation aborted then it can be understood that partial halt decider H
>>> correctly decides that its input does not halt on the simplified version of the Linz Ĥ...
>>>
>>> Conclusion:
>>> The paper is not talking about "the halting problem". The rebuttal in the paper
>>> is made to an assumption the author created in his mind. H proves itself nothing
>>> different from performing a function
>>> bool H(...) {
>>> return false; // or true
>>> };
>>> No real thing inside.
>>>
>> https://groups.google.com/g/sci.logic/c/4kIXI1kxmsI/m/hRroMoQZx2IJ
>>
>> The Psychology of Self-Reference
>> Daryl McCullough
>> Jun 25, 2004, 6:30:39 PM
>>
>> It is becoming increasingly clear that Peter Olcott and Herc have
>> no coherent mathematical argument for rejecting Godel's theorem
>> and Turing's proof of the unsolvability of the halting problem.
>> Their objections are really psychological---they feel that the
>> proofs are somehow a cheat, but they lack the mathematical ability
>> to say why.
>>
>> I'd like to talk about the psychology of why people sometimes feel
>> that Godel's and Turing's proofs are somehow cheats. Partly, it is
>> the fault of informal intuitive expositions of the results.
>>
>> Both Godel's proof and Turing's proof have the flavor of using
>> self-reference to force someone to make a mistake. Both cases
>> seem a little like the following paradox (call it the "Gotcha"
>> paradox).
>>
>> You ask someone (we'll call him "Jack") to give a truthful
>> yes/no answer to the following question:
>>
>> Will Jack's answer to this question be no?
>>
>> Jack can't possibly give a correct yes/no answer to the question.
>>
>> While the Gotcha paradox gives some of the flavor of Godel's
>> proof or Turing's proof, there is one big difference, and this
>> difference is what makes people feel like there is something
>> fishy going on: In the case of the Gotcha paradox, it
>> is possible for Jack to *know* the answer, but to be
>> prevented by the rules from *saying* the answer.
>>
>> In other words, there is a gap between what Jack knows
>> and what he can say. He knows that the answer to the question
>> is "no", but he can't say that answer, because that would
>> make the answer incorrect. So this informal paradox doesn't
>> really reveal any limitations in Jack's knowledge---it's
>> just a quirk of the rules that prevents Jack from telling
>> the answer. It's a little like the following one-question
>> quiz:
>>
>> ---------------
>> | 5 5 5 5 |
>> | How many 5's |
>> | appear inside|
>> | this box? |
>> | Answer: ___ |
>> | |
>> ---------------
>>
>> If you write "5" in the space provided, then the correct answer
>> is "6", and if you write "6" the correct answer is "5". The fact
>> that you can't write the correct answer in the space provided
>> doesn't prove that you have problems counting.
>>
>> Someone hearing some variant of the Gotcha paradox might be led
>> to think (as Peter Olcott and Herc do) that Godel's and Turing's
>> proofs might be cheats in a similar way.
>>
>> Of course, the difference is that there is no "gap" involved in
>> Turing's or Godel's proofs. It makes no sense to suppose that
>> Peano Arithmetic really knows that the Godel statement is true,
>> but just can't say it, because there is no notion of PA "knowing"
>> something independently of what it can prove. In the case of Turing's
>> proof, given a purported solution H to the halting problem,
>> one comes up with a program Q(x) such that
>>
>> Q halts on its own input if and only if H(Q,Q) = false
>>
>> There is no sense in which H "knows" that the answer is true
>> but is unable to say it.
>>
>> We could try to modify the Gotcha paradox to eliminate the gap
>> between what you know and what you can say. Let's consider the
>> following statement (called "U" for "Unbelievable").
>>
>> U: Jack will never believe this statement.
>>
>> Apparently, if Jack believes U, then U is false. So we are left
>> with two possibilities:
>>
>> Either (A) Jack believes some false statement, or (B)
>> there is some true statement that Jack doesn't believe.
>>
>> This is a lot like Godel's sentence G that shows that PA is
>> either inconsistent or incomplete. However, it still seems like
>> a joke, or a trick, rather than something that reveals any
>> limitations in Jack's knowledge. U doesn't seem to have any
>> real content, so who cares whether it is true or not, or whether
>> Jack believes it or not. It isn't a claim about anything tangible,
>> so who could ever tell if Jack believes it or not, or what it even
>> *means* for Jack to believe it?
>>
>> Okay, let's try one more time to get something meaningful that
>> really reveals a gap in Jack's knowledge akin to Godel's
>> incompleteness. Suppose that at some future time, the mechanisms
>> behind the human mind are finally understood. Suppose that it is
>> possible to insert probes into a person's brain to discover what
>> the person is thinking, and what he believes.
>>
>> So we take our subject, Jack, and hook him up with our brain scanning
>> machine. We give Jack a computer monitor on which we can display
>> statements for Jack to consider, and we connect his brain scanning
>> machine to a bell in such a way that if Jack agrees with the statement
>> on the screen (that is, if the scanning machine determines that Jack
>> believes the statement) then the bell will ring. Then we display
>> on the screen the following statement:
>>
>> The bell will not ring.
>>
>> Now, there is no way out for Jack. The statement is now a completely
>> concrete claim---there is no ambiguity about what it means, and there
>> is no ambiguity about whether it is true or false. There is no "knowledge
>> gap" possible---either Jack believes that the statement is true, or
>> he doesn't.
>>
>> Does Jack believe the statement, or not? It seems to me that in this
>> circumstance, Jack is forced to doubt his own reasoning ability, or
>> to doubt the truth of the circumstances (that the brain scanning machine
>> works as advertised, or that it is connected to the bell as described).
>> If he *really* believes in the soundness of his own reasoning, and he
>> really believes in the truth of the claims about the scanning machine,
>> then it logically follows that the bell will not ring. But as soon as
>> he makes that inference, the bell will ring, showing that he made a
>> mistake, somewhere. So the only way for Jack to avoid making a mistake
>> is if he considers it *possible* that he or his information is mistaken.
>>
>> --
>> Daryl McCullough
>> Ithaca, NY
>> void P(u32 x)
>> {
>> u32 Input_Halts = H(x, x);
>> if (Input_Halts)
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> u32 Input_Halts = H((u32)P, (u32)P);
>> Output("Input_Halts = ", Input_Halts);
>> }
>> Neither return value from H to P is correct in the same way that Jack
>> cannot possibly provide a correct answer to the following question:
>>
>> You ask someone (we'll call him "Jack") to give a truthful
>> yes/no answer to the following question:
>>
>> Will Jack's answer to this question be no?
>>
>> Jack can't possibly give a correct yes/no answer to the question.
>>
>
> That is why 'undecidable' is called. Key point: Jack is not a function machine.
> https://en.wikipedia.org/wiki/Function_(mathematics)
> Gödel's theorems and Turing's halting problem proof are not talking about
> themselves. There is a subtle difference with liar paradox and many currently
> established theorems/misconceptions seem to relate to this, but I am not to
> address this too much (set theory, limit, irrational..., I refers this to as 'modern' Pythagorean).
>
> C++ can provide an analogy to the self-reference problem
> // t.cpp
> int main() {
> std::vector<int> vec(vec);
> std::string str(str);
> }
> ---
> Both "self-reference" ctors would not compile in the eaily days IIRC, but to
> provide an example to ponder. C++ seems to have changed behavior(bug IMO).
>
>> The solution to this problem is to use a simulating halt decider.
>> All inputs to a simulating halt decider always halt. They either
>> halt on their own or are forced to halt when the simulating halt
>> decider aborts the simulation of its input. It makes no sense to
>> simply provide the halt status of an input to a simulating halt
>> decider it would simply report that all of its inputs halt.
>>
>
> The traditional HP proof also 'indicates' that deciding whether or not two given
> programs are functionally the same is also a TM-computational undecidable problem.
> This means that H has no way to correctly decide whether instance of P is simulating
> H or not, thus, H's decision made on this basis can always be wrong.
>

On 6/30/2021 9:09 PM, Richard Damon wrote:
> On 6/29/21 7:14 PM, olcott wrote:
>> On 6/28/2021 6:19 PM, Richard Damon wrote:
>>> On 6/28/21 12:35 PM, olcott wrote:
>>>> On 6/28/2021 11:09 AM, David Brown wrote:
>>>>> On 28/06/2021 15:30, olcott wrote:
>>>>>> On 6/28/2021 1:48 AM, David Brown wrote:
>>>>>>> On 28/06/2021 01:05, olcott wrote:
>>>>>>>> Because my writing style is not in the ballpark of academic quality
>>>>>>>> and
>>>>>>>> and computer scientists are loath to even consider evaluating
>>>>>>>> computer
>>>>>>>> science in terms of software engineering my paper would be rejected
>>>>>>>> out-of-hand without any review at all entirely on the basis of style
>>>>>>>> over substance.
>>>>>>>>
>>>>>>>
>>>>>>> No, academics will likely reject your ideas out of hand because they
>>>>>>> are
>>>>>>> wrong.
>>>>>>>
>>>>>>> Endlessly repeating the same misunderstandings and misconceptions
>>>>>>> does
>>>>>>> not convince anyone in the academic world.  It does not convince any
>>>>>>> programmers either, or anyone at all with a remotely logical and
>>>>>>> rational mind.
>>>>>>>
>>>>>>> You have been making off-topic posts in many newsgroups for about 2
>>>>>>> years, and there has been /zero/ progress on your part.  This is not
>>>>>>> surprising - the halting problem was proven unsolvable some
>>>>>>> hundred-odd
>>>>>>> years ago, and reality has not changed since.  The proof is simple
>>>>>>> enough that any student doing theoretical computing or mathematics at
>>>>>>> university could duplicate it, and any high-school pupil with a good
>>>>>>> level of mathematics could understand it.
>>>>>>>
>>>>>>> For your own sanity, I would urge you to stop.  For other people's
>>>>>>> sanity, I would urge you to stop posting to off-topic groups.  Even
>>>>>>> better, start a blog and post only there.
>>>>>>>
>>>>>>
>>>>>> One of the smartest software engineers here said that he provided a
>>>>>> complete rebuttal of my work: Mike Terry, so I reviewed his review
>>>>>> of my
>>>>>> work. He simply rejected my work out-of-hand without review
>>>>>> entirely on
>>>>>> the basis that my sound deductive argument did not conform to the
>>>>>> style
>>>>>> of a mathematical proof.
>>>>>>
>>>>>> No one here has ever pointed out any actual error in the essence of my
>>>>>> work and it is a damned lie to say that they have.
>>>>>>
>>>>>> I did make a huge mistake when I was discussing the diagonalization
>>>>>> proof.
>>>>>>
>>>>>
>>>>> No one needs to read your arguments to know that you have made a
>>>>> fundamental mistake.  The same would apply if you claimed to have
>>>>> trisected an angle, squared a circle, found an odd number divisible by
>>>>> 2, or any other problem that have been proven impossible.
>>>>>
>>>>
>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>> void P(u32 x)
>>>> {
>>>>    u32 Input_Halts = H(x, x);
>>>>    if (Input_Halts)
>>>>      HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    u32 Input_Halts = H((u32)P, (u32)P);
>>>>    Output("Input_Halts = ", Input_Halts);
>>>> }
>>>>
>>>> Everyone knows that H cannot possibly return the correct halt status of
>>>> H(P,P) to P.
>>>
>>> THERE you just admitted you are wrong. H cannpt possible return the
>>> correct halt status.
>>>
>>
>> I did not say that nitwit.
>
> Your EXACT statement (as I quoted) was:
>
>>
>> Everyone knows that H cannot possibly return the correct halt status of H(P,P) to P.
>
> Which is exactly what I said.
>
>>
>> I said in the above computation H cannot return the correct halt status
>> to P because P is calling H in infinitely nested simulation and must
>> have its simulation aborted before H returns any value to it.
>
> That is NOT what you said. Read your words.
>
> This above statement is just illogical drivel.
>

As I have repeated many many times even though H cannot possibly return
a correct halt status to P.

IN THE ABOVE COMPUTATION NOT SOME OTHER DIFFERENT COMPUTATION
IN THE ABOVE COMPUTATION NOT SOME OTHER DIFFERENT COMPUTATION
IN THE ABOVE COMPUTATION NOT SOME OTHER DIFFERENT COMPUTATION
IN THE ABOVE COMPUTATION NOT SOME OTHER DIFFERENT COMPUTATION
IN THE ABOVE COMPUTATION NOT SOME OTHER DIFFERENT COMPUTATION

H does correctly abort the simulation of P and correct returns 0 (for
not halting) to main().

The halting problem proofs are wrong because they never freaking
bothered to examine all of the details of what happens when H is a
SIMULATING HALT DECIDER.

The halting problem proofs are wrong because they never freaking
bothered to examine all of the details of what happens when H is a
SIMULATING HALT DECIDER.

The halting problem proofs are wrong because they never freaking
bothered to examine all of the details of what happens when H is a
SIMULATING HALT DECIDER.

The halting problem proofs are wrong because they never freaking
bothered to examine all of the details of what happens when H is a
SIMULATING HALT DECIDER.

The halting problem proofs are wrong because they never freaking
bothered to examine all of the details of what happens when H is a
SIMULATING HALT DECIDER.

--
Copyright 2021 Pete Olcott

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

On 30/06/2021 19:15, olcott wrote:
> On 6/30/2021 11:01 AM, Peter wrote:
>> olcott wrote:
>>> Because my writing style is not in the ballpark of academic quality
>>> [...]
>>
>> Then fix it.
>>
>
> I didn't know where to begin on this except for asking for a computer
> science professor to coach me.
>

There is your answer - talk to a computer scientist at a university.
You need to /talk/ to someone, physically and directly. Posting stuff
on Usenet is not working for you.

On 01/07/2021 10:38, David Brown wrote:
<snip>

I forgot to check the newsgroups again. My apollogies to the off-topic
groups.

On 7/1/2021 4:51 AM, Malcolm McLean wrote:
> On Thursday, 1 July 2021 at 09:38:45 UTC+1, David Brown wrote:
>> On 30/06/2021 19:15, olcott wrote:
>>> On 6/30/2021 11:01 AM, Peter wrote:
>>>> olcott wrote:
>>>>> Because my writing style is not in the ballpark of academic quality
>>>>> [...]
>>>>
>>>> Then fix it.
>>>>
>>>
>>> I didn't know where to begin on this except for asking for a computer
>>> science professor to coach me.
>>>
>> There is your answer - talk to a computer scientist at a university.
>> You need to /talk/ to someone, physically and directly. Posting stuff
>> on Usenet is not working for you.
>>
> No, that's asking for trouble.
>

Since at this point I am obviously correct, why are people still
disagreeing?

--
Copyright 2021 Pete Olcott

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

On 7/1/2021 6:44 AM, Andy Walker wrote:
> On 01/07/2021 03:34, Richard Damon wrote:
>> On 6/30/21 1:15 PM, olcott wrote:
>>> The other issue doesn't seem to have much of an alternative. A key part
>>> of the problem that allowed the halting problem to continue to exist is
>>> that it was only analyzed using Turing machines.
>
>     There is no essential difference between TMs and real computers.
> The only actual difference is that a real computer allows for external
> connexions, such as people typing at a keyboard or clicking a mouse, or
> a clock interrupt, or a temperature sensor raising an alarm.
>
>> [...] It is totally possible to run very detailed models of Turing
>> Machines with a fairly simple program. When run on real hardware, the do
>> have the slight limitation that the tape isn't truely infinite in
>> capacity. but until you actually need more memory than you have you get
>> a perfet simulation.
>
>     The "infinite tape" is a distraction.  It suffices to buy a new
> memory stick from time to time, use this as auxiliary storage, and have
> the computer say "load next/previous stick" as necessary.  This conforms
> to Turing's original concept of a [human] computer with a stack of paper,
> except that the paper has been modernised.
>
>> The BIG advantage of Turing Machines is that due to there simple
>> structure, it is quite easy to actually write real PROOFS about the
>> behavior of the machine, [...].
>
>     Or, as an alternative view, that it is easy to strip away
> irrelevant parts of the computation.  To take a simple example, if
> you have a machine that can add, then it can also multiply [by
> repeated addition].  That is indeed what we used to have to do on
> the old hand calculators [and we learned all sorts of tricks of
> the trade to minimise the number of "rotations"].  Now you can go
> in either of two directions:  if you want to forecast the weather,
> then a computer, call it A, that is expensive but can do all sorts
> of arithmetic as basic instructions is better than one, B, that is
> cheap but can't multiply or divide except by repeated addition or
> subtraction.  OTOH, if you want to discuss what computers can do,
> then B is simpler to describe [tho' harder to write programs for]
> than A.  You can strip away addition too, and subroutines, and
> all sorts of other stuff that is there for efficiency, not for
> capability.  Exploring the limits of how simple B could possibly
> be is an interesting exercise in its own right.  The point then
> is that A and B are equally capable, but A is much faster, B is
> much easier to explore.
>
>     Whether A or B is a Turing machine is irrelevant;  they
> both are, apart from external influences such as clock interrupts
> [which are not part of what we /usually/ concern ourselves with
> when writing programs] and other interactions [which didn't
> really happen in the early days of computing, when "the input"
> was supplied as a paper tape or a deck of cards rather than by
> the programmer typing things in response to what the computer
> was doing], or they both aren't [if such interactions are
> important to your particular problem].
>
>>> I cannot convert my proof to the Turing machine model of computation
>>> away from the RASP equivalent model of c/x86 without losing the steps of
>>> my sound deductive inference that prove that my analysis is correct.
>
>     Then so much the worse for that proof.  If you [PO]
> can't supply it as either a state diagram or near equivalent,
> or alternatively as a C program or near equivalent, then no-one
> is going to be interested, and no reputable journal will want
> to publish it.

I do have it all as C/x86 programs.
The halt decider bases its halt status decision on the simulated
execution trace of the x86 machine language of P.

void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{ u32 Input_Halts = H((u32)P, (u32)P);
Output("Input_Halts = ", Input_Halts);
}

It is at about the point where any honest reviewer that carefully
studies my sound deductive inference will have to conclude that it is
correct. They must be experts in the C and x86 programming languages.
They need not know anything about the theory of computation.

As long as the software engineering is verified as correct then I have
refuted the conventional halting problem undecidability proofs. Software
engineer reviewers need not understand this. Software engineer reviewers
need not look past page 8 of my paper. Pages 9-10 apply the reasoning of
pages 1-8 to the Peter Linz Turing machine proof. The Linz proof itself
is on pages 11-13.

Halting problem undecidability and infinitely nested simulation

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

> If you're lucky, you will get a polite response
> from the editor -- "We regret that your submission is not in a
> form suitable for publication in this journal" -- and it won't
> even get to a referee.
>

I need to get it into proper form before I even ask computer science
professors to look at it.

--
Copyright 2021 Pete Olcott

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

On 7/1/2021 3:38 AM, David Brown wrote:
> On 30/06/2021 19:15, olcott wrote:
>> On 6/30/2021 11:01 AM, Peter wrote:
>>> olcott wrote:
>>>> Because my writing style is not in the ballpark of academic quality
>>>> [...]
>>>
>>> Then fix it.
>>>
>>
>> I didn't know where to begin on this except for asking for a computer
>> science professor to coach me.
>>
>
> There is your answer - talk to a computer scientist at a university.
> You need to /talk/ to someone, physically and directly. Posting stuff
> on Usenet is not working for you.
>
>

I did talk to the guy that taught theory of computation at my alma
mater. Because of covid he did not have office hours. He was so annoyed
that I called him at home that he denied that he was who he already
admitted that he is. I sent him an email of the link to my paper.

--
Copyright 2021 Pete Olcott

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

On 7/1/2021 6:08 AM, Richard Damon wrote:
> On 6/30/21 11:23 PM, olcott wrote:
>> On 6/30/2021 9:09 PM, Richard Damon wrote:
>>> On 6/29/21 7:14 PM, olcott wrote:
>>>> On 6/28/2021 6:19 PM, Richard Damon wrote:
>>>>> On 6/28/21 12:35 PM, olcott wrote:
>>>>>> On 6/28/2021 11:09 AM, David Brown wrote:
>>>>>>> On 28/06/2021 15:30, olcott wrote:
>>>>>>>> On 6/28/2021 1:48 AM, David Brown wrote:
>>>>>>>>> On 28/06/2021 01:05, olcott wrote:
>>>>>>>>>> Because my writing style is not in the ballpark of academic
>>>>>>>>>> quality
>>>>>>>>>> and
>>>>>>>>>> and computer scientists are loath to even consider evaluating
>>>>>>>>>> computer
>>>>>>>>>> science in terms of software engineering my paper would be
>>>>>>>>>> rejected
>>>>>>>>>> out-of-hand without any review at all entirely on the basis of
>>>>>>>>>> style
>>>>>>>>>> over substance.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, academics will likely reject your ideas out of hand because
>>>>>>>>> they
>>>>>>>>> are
>>>>>>>>> wrong.
>>>>>>>>>
>>>>>>>>> Endlessly repeating the same misunderstandings and misconceptions
>>>>>>>>> does
>>>>>>>>> not convince anyone in the academic world.  It does not convince
>>>>>>>>> any
>>>>>>>>> programmers either, or anyone at all with a remotely logical and
>>>>>>>>> rational mind.
>>>>>>>>>
>>>>>>>>> You have been making off-topic posts in many newsgroups for about 2
>>>>>>>>> years, and there has been /zero/ progress on your part.  This is
>>>>>>>>> not
>>>>>>>>> surprising - the halting problem was proven unsolvable some
>>>>>>>>> hundred-odd
>>>>>>>>> years ago, and reality has not changed since.  The proof is simple
>>>>>>>>> enough that any student doing theoretical computing or
>>>>>>>>> mathematics at
>>>>>>>>> university could duplicate it, and any high-school pupil with a
>>>>>>>>> good
>>>>>>>>> level of mathematics could understand it.
>>>>>>>>>
>>>>>>>>> For your own sanity, I would urge you to stop.  For other people's
>>>>>>>>> sanity, I would urge you to stop posting to off-topic groups.  Even
>>>>>>>>> better, start a blog and post only there.
>>>>>>>>>
>>>>>>>>
>>>>>>>> One of the smartest software engineers here said that he provided a
>>>>>>>> complete rebuttal of my work: Mike Terry, so I reviewed his review
>>>>>>>> of my
>>>>>>>> work. He simply rejected my work out-of-hand without review
>>>>>>>> entirely on
>>>>>>>> the basis that my sound deductive argument did not conform to the
>>>>>>>> style
>>>>>>>> of a mathematical proof.
>>>>>>>>
>>>>>>>> No one here has ever pointed out any actual error in the essence
>>>>>>>> of my
>>>>>>>> work and it is a damned lie to say that they have.
>>>>>>>>
>>>>>>>> I did make a huge mistake when I was discussing the diagonalization
>>>>>>>> proof.
>>>>>>>>
>>>>>>>
>>>>>>> No one needs to read your arguments to know that you have made a
>>>>>>> fundamental mistake.  The same would apply if you claimed to have
>>>>>>> trisected an angle, squared a circle, found an odd number
>>>>>>> divisible by
>>>>>>> 2, or any other problem that have been proven impossible.
>>>>>>>
>>>>>>
>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>> void P(u32 x)
>>>>>> {
>>>>>>     u32 Input_Halts = H(x, x);
>>>>>>     if (Input_Halts)
>>>>>>       HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>     u32 Input_Halts = H((u32)P, (u32)P);
>>>>>>     Output("Input_Halts = ", Input_Halts);
>>>>>> }
>>>>>>
>>>>>> Everyone knows that H cannot possibly return the correct halt
>>>>>> status of
>>>>>> H(P,P) to P.
>>>>>
>>>>> THERE you just admitted you are wrong. H cannpt possible return the
>>>>> correct halt status.
>>>>>
>>>>
>>>> I did not say that nitwit.
>>>
>>> Your EXACT statement (as I quoted) was:
>>>
>>>>
>>>> Everyone knows that H cannot possibly return the correct halt status
>>>> of H(P,P) to P.
>>>
>>> Which is exactly what I said.
>>>
>>>>
>>>> I said in the above computation H cannot return the correct halt status
>>>> to P because P is calling H in infinitely nested simulation and must
>>>> have its simulation aborted before H returns any value to it.
>>>
>>> That is NOT what you said. Read your words.
>>>
>>> This above statement is just illogical drivel.
>>>
>>
>> As I have repeated many many times even though H cannot possibly return
>> a correct halt status to P.
>
> Right, It is IMPOSSIBLE for H to return the correrct answer because
> whatever answer it returns will let P do the opposite.
>
>>
>> IN THE ABOVE COMPUTATION NOT SOME OTHER DIFFERENT COMPUTATION
>> IN THE ABOVE COMPUTATION NOT SOME OTHER DIFFERENT COMPUTATION
>> IN THE ABOVE COMPUTATION NOT SOME OTHER DIFFERENT COMPUTATION
>> IN THE ABOVE COMPUTATION NOT SOME OTHER DIFFERENT COMPUTATION
>> IN THE ABOVE COMPUTATION NOT SOME OTHER DIFFERENT COMPUTATION
>
> Yes, we are talking abot two computatons and the relationship between
> the results.
>
> We have H(P,P), which we have your claim that it will return non-Halting.
>
> We have P(P) which includes within it the computaton H(P,P), and if
> H(P,P) is non-Halting, then P(P) will be Halting.
>
> Thus the answer H gave was wrong.

We can make an undecidable problem by simply phrasing a question such
that correct answers are impossible.

When we ask a guy that has never been married
Have you stopped beating your wife?

The false presupposition of this question forces both answers to this
polar (yes/no) question to be incorrect.

When we transform this same question into an equivalent question that
does not have the false presupposition: Are you currently beating your
wife? then this correct question can be correctly answered.

When the first erroneous question is transformed into an equivalent
question having the error removed the "undecidable" problem becomes
decidable.

We can even do the same thing with the liar Paradox:
LP := This sentence is not true.
Is LP true, No. Then that makes it false? No.
The Liar Paradox is not a truth bearer.

We can do the same thing with the halting problem:
Because a simulating halt decider must always abort the simulation of
every input that never halts its halt deciding criteria must be adapted.

[ Does the input halt on its input? ] must become
[ Does the input halt without having its simulation aborted? ]

This change is required because every input to a simulating halt decider
either halts on its own or halts because its simulation has been aborted.

When this new criteria is understood to be necessarily true on the basis
of the meaning of its words then we have logically justified certainty
that H(P,P)==0 is correct.

Failing to comprehend this is not any rebuttal what-so-ever.
Failing to comprehend this is not any rebuttal what-so-ever.
Failing to comprehend this is not any rebuttal what-so-ever.
Failing to comprehend this is not any rebuttal what-so-ever.
Failing to comprehend this is not any rebuttal what-so-ever.

On 7/1/2021 10:49 AM, Malcolm McLean wrote:
> On Thursday, 1 July 2021 at 15:30:57 UTC+1, olcott wrote:
>> On 7/1/2021 3:38 AM, David Brown wrote:
>>> On 30/06/2021 19:15, olcott wrote:
>>>> On 6/30/2021 11:01 AM, Peter wrote:
>>>>> olcott wrote:
>>>>>> Because my writing style is not in the ballpark of academic quality
>>>>>> [...]
>>>>>
>>>>> Then fix it.
>>>>>
>>>>
>>>> I didn't know where to begin on this except for asking for a computer
>>>> science professor to coach me.
>>>>
>>>
>>> There is your answer - talk to a computer scientist at a university.
>>> You need to /talk/ to someone, physically and directly. Posting stuff
>>> on Usenet is not working for you.
>>>
>>>
>> I did talk to the guy that taught theory of computation at my alma
>> mater. Because of covid he did not have office hours. He was so annoyed
>> that I called him at home that he denied that he was who he already
>> admitted that he is. I sent him an email of the link to my paper.
>>
> Exactly. On comp.theory, anyone can post, and so people here accept that
> posts about halt deciders, proofs that P = NP, algorithms for quickly factoring
> large numbers, arguments that infinity is a real number, and so on go with
> the territory.
>
> However if you try to interest people outside of Usenet in the same types of
> things, you might get a much more hostile reaction.
>

The verifiable fact that I am correct should overcome the presumption
that I am not correct.

Halting problem undecidability and infinitely nested simulation

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

--
Copyright 2021 Pete Olcott

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