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 6/27/2021 7:08 PM, Richard Damon wrote:
> On 6/27/21 7:05 PM, 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.
>
> Then hire a editor to clean up your style.
>
>>
>> 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.
>
> GOOD LUCK wrapping you crappy logic in a way that anyone with any
> intelligence might take it serious. It seems you software engineer
> skills are about as bad as you knowledge of Turing Theory or Logic.
>>
>> 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.
>
> But this isn't true if H is smart enough to be able to break the chain
> so that it can answer. Once H can do that, then P is no longer in an
> infinite chain
>

Axiom(1) Every computation that never halts unless it is aborted at some
point is a computation that never halts.

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

is a computation that never halts unless it is aborted at some point
therefore it is a computation that never halts.

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/27/2021 7:46 PM, Richard Damon wrote:
> On 6/27/21 8:16 PM, olcott wrote:
>> On 6/27/2021 7:08 PM, Richard Damon wrote:
>
>>> But this isn't true if H is smart enough to be able to break the chain
>>> so that it can answer. Once H can do that, then P is no longer in an
>>> infinite chain
>>>
>>
>> Axiom(1) Every computation that never halts unless it is aborted at some
>> point is a computation that never halts.
>
> Olcott 'Axiom' == I want this true but can't prove it.
>
>
> This statement does happen to be true when you use the right meanings of
> the words, unfortunately you don't use that meaning.
>
> If 'unless it is aborted' means that THIS instance of the computation
> being simulated won't stop unless THIS instance of the simulation is
> stopped.
You are still too dumb to understand that when any invocation of an
infinite chain of invocations is terminated this terminates that whole
chain.

This means that it doesn't freaking matter one whit which dad burn
invocation is terminated. As long as at least one of them must be
terminated then this proves that the whole freaking chain really was
infinite.

--
Copyright 2021 Pete Olcott

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

On 6/27/2021 8:06 PM, Richard Damon wrote:
> On 6/27/21 8:54 PM, olcott wrote:
>> On 6/27/2021 7:46 PM, Richard Damon wrote:
>>> On 6/27/21 8:16 PM, olcott wrote:
>>>> On 6/27/2021 7:08 PM, Richard Damon wrote:
>>>
>>>>> But this isn't true if H is smart enough to be able to break the chain
>>>>> so that it can answer. Once H can do that, then P is no longer in an
>>>>> infinite chain
>>>>>
>>>>
>>>> Axiom(1) Every computation that never halts unless it is aborted at some
>>>> point is a computation that never halts.
>>>
>>> Olcott 'Axiom' == I want this true but can't prove it.
>>>
>>>
>>> This statement does happen to be true when you use the right meanings of
>>> the words, unfortunately you don't use that meaning.
>>>
>>> If 'unless it is aborted' means that THIS instance of the computation
>>> being simulated won't stop unless THIS instance of the simulation is
>>> stopped.
>> You are still too dumb to understand that when any invocation of an
>> infinite chain of invocations is terminated this terminates that whole
>> chain.
>>
>> This means that it doesn't freaking matter one whit which dad burn
>> invocation is terminated. As long as at least one of them must be
>> terminated then this proves that the whole freaking chain really was
>> infinite.
>>
>
> Then tell me what happens when the simulator aborts it simulation?
>
> What does the processor do next?
>

You must stay focused on one single point at a time.

Even when you do stay focused on one single point at a time it takes a
dialogue of at least fifty messages for you to understand this one
single point.

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

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

It took you a few months to understand that unless some H aborts some P
then main P(P) in main() never stops.

If you would have been interested in the actual truth it would not have
taken two months for you to understand this. I had to keep pounding away
at your perpetual rebuttal mode until you finally bothered to pay
attention.

When H terminates the infinite recursion at the third invocation of the
infinite invocation chain execution continues from this point forward.

That the first element of the infinite invocation chain receives a
return value from H does not freaking mean that this first element of
the infinite invocation chain is a finite computation.

--
Copyright 2021 Pete Olcott

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

On 6/27/2021 9:12 PM, Richard Damon wrote:
> On 6/27/21 9:24 PM, olcott wrote:
>> On 6/27/2021 8:06 PM, Richard Damon wrote:
>>> On 6/27/21 8:54 PM, olcott wrote:
>>>> On 6/27/2021 7:46 PM, Richard Damon wrote:
>>>>> On 6/27/21 8:16 PM, olcott wrote:
>>>>>> On 6/27/2021 7:08 PM, Richard Damon wrote:
>>>>>
>>>>>>> But this isn't true if H is smart enough to be able to break the
>>>>>>> chain
>>>>>>> so that it can answer. Once H can do that, then P is no longer in an
>>>>>>> infinite chain
>>>>>>>
>>>>>>
>>>>>> Axiom(1) Every computation that never halts unless it is aborted at
>>>>>> some
>>>>>> point is a computation that never halts.
>>>>>
>>>>> Olcott 'Axiom' == I want this true but can't prove it.
>>>>>
>>>>>
>>>>> This statement does happen to be true when you use the right
>>>>> meanings of
>>>>> the words, unfortunately you don't use that meaning.
>>>>>
>>>>> If 'unless it is aborted' means that THIS instance of the computation
>>>>> being simulated won't stop unless THIS instance of the simulation is
>>>>> stopped.
>>>> You are still too dumb to understand that when any invocation of an
>>>> infinite chain of invocations is terminated this terminates that whole
>>>> chain.
>>>>
>>>> This means that it doesn't freaking matter one whit which dad burn
>>>> invocation is terminated. As long as at least one of them must be
>>>> terminated then this proves that the whole freaking chain really was
>>>> infinite.
>>>>
>>>
>>> Then tell me what happens when the simulator aborts it simulation?
>>>
>>> What does the processor do next?
>>>
>>
>> You must stay focused on one single point at a time.
>
> Translation: Your Stuck and can't think of a good enough lie to cover
> yourself her.
>
>>
>> Even when you do stay focused on one single point at a time it takes a
>> dialogue of at least fifty messages for you to understand this one
>> single point.
>
> What is more focused than asking you to clarify a statement.
>
>
>>
>> void P(u32 x)
>> {
>>   u32 Input_Halts = H(x, x);
>>   if (Input_Halts)
>>     HERE: goto HERE;
>> }
>>
>> int main()
>> {
>>   P((u32)P);
>> }
>>
>> It took you a few months to understand that unless some H aborts some P
>> then main P(P) in main() never stops.
>
> LIE , I never rejected THAT statement,

It took you you a few months to acknowledge that it is true.
You continued to dodge this point over-and-over-and-over.

> only you using it as a scam to
> explain that H didn't need to answer P or that this statement with THAT
> wording actual has an proof the the ACTUAL P (where some H does abort)
> is a non-Halting computation, even if the decision to abort is part of
> the algorithm of P (as inhereted from H).
>
>>
>> If you would have been interested in the actual truth it would not have
>> taken two months for you to understand this. I had to keep pounding away
>> at your perpetual rebuttal mode until you finally bothered to pay
>> attention.
>>
>> When H terminates the infinite recursion at the third invocation of the
>> infinite invocation chain execution continues from this point forward.
>
> Ok, so the 'whole chain' didn't get terminated? Sounds like a pull back
> from your initial claim.

The infinity of the whole chain was totally terminated.
My prior wording was not very good.
I can only improve my wording by trial-and-error.

> So I guess you also take back the LIE that H doesn't return to P because
> something in infinite recursion can't return to its caller even if it
> abort it.
>

I told you that we were focusing on this computation. When you said that
H must return to P in this computation, you are wrong.

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

Once you totally understand that in the above computation H does
correctly decide that its input never halts, then nothing in the
universe can possibly contradict this.

> Also, by what grounds do you still have to say that it doesn't which
> invocation is aborted, since which invocation now affects where we are
> in the computation.
>

As long as the following computation never halts unless H aborts at
least one of its infinite chain of invocations then we know with
complete certainty that it really does specify an infinite chain of
invocations.

int main()
{ P(P);
}

It only specifies a finite computation if we never have to abort any of
its invocations.

> Or, do you NOT mean what you say and H isn't going to now continue and
> return its answer.
>
> Again, WHAT DOES THE MACHINE ACTUALLY DO AT THIS POINT.
>

After H aborts the third element of the infinite chain of invocations
specified by

int main()
{ P(P);
}

H correctly returns 0 to P.

> What does that mean for the actual Turing Machine that is the equivalent
> for this H.
>
> To focus, does the Turing Machine H go to that H's qn or not?
>

I will take that question as a dishonest dodge that is very diligently
striving with great vigor to make sure that I cannot make my point.

>>
>> That the first element of the infinite invocation chain receives a
>> return value from H does not freaking mean that this first element of
>> the infinite invocation chain is a finite computation.
>>
>
> It does if that first element of a supposed infinitie invocation then
> stops and make the computaiton halts.
>

No. The following does specify an infinite chain of invocations.
H terminates the third invocation of this chain:

int main()
{ P(P);
}

> It appears that you have someone created some magical system when a
> computaton that runs in a finite number of steps and Haltis is both a
> Non-Halting Computation and in the fintite time was able to create an
> infinte number of invocations.
>
> FAIL.
>

Every computation that never halts unless some aspect of it is aborted
at some point is a computation that never halts.

The following does specify an infinite chain of invocations.
H terminates the third invocation of this chain:

int main()
{ P(P);
}

--
Copyright 2021 Pete Olcott

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

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/28/2021 9:44 AM, André G. Isaak wrote:
> On 2021-06-28 07:38, olcott wrote:
>> On 6/28/2021 6:42 AM, Richard Damon wrote:
>>> On 6/27/21 11:09 PM, olcott wrote:
>>>> On 6/27/2021 9:12 PM, Richard Damon wrote:
>>>
>>>> After H aborts the third element of the infinite chain of invocations
>>>> specified by
>>>>
>>>> int main()
>>>> {
>>>>    P(P);
>>>> }
>>>>
>>>> H correctly returns 0 to P.
>>>
>>> And then P Halts showing that H was WRONG.
>>>
>>
>> When an infinite invocation chain halts because one of its invocations
>> was aborted this does not mean that an infinite invocation chain is
>> not an infinite invocation chain, nitwit.
>>
>>> The DEFINITION of a Halting Computation is a computation that comes to
>>> its end and Halts.
>>
>> A simulating halt decider must abort the execution of all inputs that
>> never halt, dumb bunny.
>
> P(P) isn't a 'simulating halt decider'. It's a modified 'simulating halt
> decider'.
>

P is neither a simulating halt decider nor a modified simulating halt
decider. P is merely the conventional "impossible" input that previously
"proved" that the halting problem is undecidable.

> And when you run H(P, P), it is being asked whether the outermost P
> (i.e. the simulator itself) comes to a halt.

Not at all, not in the least.

> It isn't being asked about
> the inputs to P at all. If the outermost P reaches a final state, then
> *by definition* it halts. It doesn't matter whether it had to abort
> whatever it is that it was simulating since H isn't being asked about that.
>
> André

You are totally confused, try reading the current version of my paper.
It is much clearer than it has ever been.

The most significant improvement is how and why this computation is
decided correctly.

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

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

On 6/28/2021 11:29 AM, Mike Terry wrote:
> On 28/06/2021 14: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.
>
> 1. You're in no position to judge peoples' relative smartness
>
> 2. I wouldn't consider myself a "software engineer", just a long-time
>    programmer with a maths background.  (Seems to me the term "software
>    engineer" is vastly overused.  Mostly it just seems to be people
>    fluffing up their CVs, or trying to con people into taking their
>    opinions more seriously than they deserve.  Hint: you are not a
>    software engineer...)
>
> 3. You seem to have just picked one of my previous posts at random,
>    expecting that it would contain my "complete rebuttal" of your
>    current document!  You would need to go back to the point where
>    it first became clear what you were actually saying.  Perhaps
>    around last October??  But I'd NOT recommend that - you'd be
>    wasting your time, not because I haven't pointed out your errors,
>    but because you're unable to understand my (or anyone else's)
>    explanations of your errors.  You didn't understand them last
>    year, so why would you do any better now?  Have you magically
>    become smarter since then?  You would just find a couple
>    of random posts and say "There, you didn't follow my reasoning,
>    told you so!"  (Which would be a complete waste of your time,
>    but feel free to do that if you want.)
>
> 4. You don't have a "sound deductive argument" or any argument at all.
>    You're ignoring the key factor here - you're not an unrecognised
>    genius, you're a Deluded Dumbo!  In place of actual
>    reasoned arguments, all you have is mistaken intuitions for what
>    you believe to be true, and your "reasoning" is just repeating those
>    intuitions over and over with slightly different wording, hoping
>    everybody will suddenly agree if you do it often enough!
>
>
> Mike.
>

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

Premise(1) (axiom) Every computation that never halts unless its
simulation is aborted is a computation that never halts. This verified
as true on the basis of the meaning of its words.

Premise(2) (verified fact) The simulation of the input to H(P,P) never
halts without being aborted is a verified fact on the basis of its x86
execution trace. (shown in my paper).

Conclusion(3) From the above true premises it necessarily follows that
simulating halt decider H correctly reports that its input: (P,P) never
halts.

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/28/2021 1:03 PM, David Brown wrote:
> On 28/06/2021 18:42, olcott wrote:
>> On 6/28/2021 11:29 AM, Mike Terry wrote:
>>> On 28/06/2021 14: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.
>>>
>>> 1. You're in no position to judge peoples' relative smartness
>>>
>>> 2. I wouldn't consider myself a "software engineer", just a long-time
>>>     programmer with a maths background.  (Seems to me the term "software
>>>     engineer" is vastly overused.  Mostly it just seems to be people
>>>     fluffing up their CVs, or trying to con people into taking their
>>>     opinions more seriously than they deserve.  Hint: you are not a
>>>     software engineer...)
>>>
>>> 3. You seem to have just picked one of my previous posts at random,
>>>     expecting that it would contain my "complete rebuttal" of your
>>>     current document!  You would need to go back to the point where
>>>     it first became clear what you were actually saying.  Perhaps
>>>     around last October??  But I'd NOT recommend that - you'd be
>>>     wasting your time, not because I haven't pointed out your errors,
>>>     but because you're unable to understand my (or anyone else's)
>>>     explanations of your errors.  You didn't understand them last
>>>     year, so why would you do any better now?  Have you magically
>>>     become smarter since then?  You would just find a couple
>>>     of random posts and say "There, you didn't follow my reasoning,
>>>     told you so!"  (Which would be a complete waste of your time,
>>>     but feel free to do that if you want.)
>>>
>>> 4. You don't have a "sound deductive argument" or any argument at all.
>>>     You're ignoring the key factor here - you're not an unrecognised
>>>     genius, you're a Deluded Dumbo!  In place of actual
>>>     reasoned arguments, all you have is mistaken intuitions for what
>>>     you believe to be true, and your "reasoning" is just repeating those
>>>     intuitions over and over with slightly different wording, hoping
>>>     everybody will suddenly agree if you do it often enough!
>>>
>>>
>>> Mike.
>>>
>>
>> // 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);
>> }
>>
>> Premise(1) (axiom) Every computation that never halts unless its
>> simulation is aborted is a computation that never halts. This verified
>> as true on the basis of the meaning of its words.
>
> If it was "true on the basis of the meaning of its words", it would be
> neither a premise nor an axiom.
>

If it is true on the basis of the meaning of its words then when it
plays the role of a premise in deductive inference then we know that
this premise is true.

> But it is not true.
>
> Either you consider the method of aborting to be part of the input to
> the computation, in which case it /does/ halt, or you do not consider it
> part of the input - in which case the abortable computation is not the
> original one.
>

We can know that it is true on the basis that
when the UTM simulation of Turing machine description of Turing Machine
M never halts then we know that the execution of TM M never halts.
UTM(⟨M⟩, I) == ∞ logically entails M(I) == ∞ // "== ∞" means never halts

The particular axiom is the key element of my proof that makes the
otherwise "impossible" inputs to a halt decider decidable.

>>
>> Premise(2) (verified fact) The simulation of the input to H(P,P) never
>> halts without being aborted is a verified fact on the basis of its x86
>> execution trace. (shown in my paper).
>
> A "verified fact" is not a premise either.
>

When A "verified fact" plays the role of a premise in deductive
inference then we have a the basis required to know that this premise is
true.

When we have a conclusion that logically follows from a pair of premises
that are known to be true then we know that we have a sound rather than
merely valid argument.

> The impossibility of the halting problem is not about identifying
> particular computation that do not halt. It is about the impossibility
> of defining an algorithm that will determine whether /any/ given
> computation will halt or not.

Yes.

> So a simulation here demonstrates nothing
> except for this /one/ single computation.

No. The one single input <is> the same essential pattern of all of the
counter-example inputs that are used to prove that the halting problem
is undecidable.

The pattern is (as Sipser puts it) an input that "does the opposite" of
whatever the halt decider decides.

> (Even then you are talking
> about one single compilation of the function. C compilers are allowed,
> in certain circumstances, to assume loops terminate. A smart enough
> compiler could do so here. It is for such reasons that no sane computer
> theorist would be using C and/or x86 for this kind of thing.)
>

I provide the disassembled machine code to utterly eliminate this
ambiguity.

Halting problem undecidability and infinitely nested simulation

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

>>
>> Conclusion(3) From the above true premises it necessarily follows that
>> simulating halt decider H correctly reports that its input: (P,P) never
>> halts.
>
> You can conclude that your program correctly reports that /one/ case.
> You have proved nothing of use or interest, because it shows nothing
> about any other program.
>

No. The one single input <is> the same essential pattern of all of the
counter-example inputs that are used to prove that the halting problem
is undecidable.

The pattern is (as Sipser puts it) an input that "does the opposite" of
whatever the halt decider decides.

When I show how this input is correctly decided then all of the
conventional halting problem proofs lose their entire basis and utterly
fail to prove their conclusion.

On 28/06/2021 20:29, olcott wrote:
> On 6/28/2021 1:03 PM, David Brown wrote:
>> On 28/06/2021 18:42, olcott wrote:

>>>
>>> // 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);
>>> }
>>>
>>> Premise(1) (axiom) Every computation that never halts unless its
>>> simulation is aborted is a computation that never halts. This verified
>>> as true on the basis of the meaning of its words.
>>
>> If it was "true on the basis of the meaning of its words", it would be
>> neither a premise nor an axiom.
>>
>
> If it is true on the basis of the meaning of its words then when it
> plays the role of a premise in deductive inference then we know that
> this premise is true.
>

That is called "begging the question" - in the original sense of the idiom.

>> But it is not true.
>>
>> Either you consider the method of aborting to be part of the input to
>> the computation, in which case it /does/ halt, or you do not consider it
>> part of the input - in which case the abortable computation is not the
>> original one.
>>
>
> We can know that it is true on the basis that
> when the UTM simulation of Turing machine description of Turing Machine
> M never halts then we know that the execution of TM M never halts.

You are not simulating UTMs. You are not simulating anything remotely
like a UTM - in particular, you are completely missing the "universal" part.

It is certainly correct that a valid simulation of a UTM will halt if
and only if the UTM would halt. Your simulation does not determine if a
general UTM halts.

> UTM(⟨M⟩, I) == ∞ logically entails M(I) == ∞ // "== ∞" means never halts
>
> The particular axiom is the key element of my proof that makes the
> otherwise "impossible" inputs to a halt decider decidable.
>

If it were an axiom, then it is not part of the proof. Axioms are
assumed to be true /without/ proof.

>>>
>>> Premise(2) (verified fact) The simulation of the input to H(P,P) never
>>> halts without being aborted is a verified fact on the basis of its x86
>>> execution trace. (shown in my paper).
>>
>> A "verified fact" is not a premise either.
>>
>
> When A "verified fact" plays the role of a premise in deductive
> inference then we have a the basis required to know that this premise is
> true.

No, it does not. Please stop trying to use big words that you don't
understand - that includes "premise", "verified", "fact", "proof", and
"deductive inference".

>
> When we have a conclusion that logically follows from a pair of premises
> that are known to be true then we know that we have a sound rather than
> merely valid argument.

Even if your conclusion is correct, it is still useless because it
applies to /one/ computation only.

>
>> The impossibility of the halting problem is not about identifying
>> particular computation that do not halt.  It is about the impossibility
>> of defining an algorithm that will determine whether /any/ given
>> computation will halt or not. 
>
> Yes.
>
>> So a simulation here demonstrates nothing
>> except for this /one/ single computation. 
>
> No. The one single input <is> the same essential pattern of all of the
> counter-example inputs that are used to prove that the halting problem
> is undecidable.
>

Perhaps this is a key to your misunderstandings.

There is no problem writing a halt decider that will correctly give the
expected result for a /given/ input (or (UTM, input) pair) - assuming
the expected result is known in advance. In your bizarre formulation,
this would suffice:

u32 H(u32 p, u32 i) {
return 0;
}

That would correctly evaluate H(P, P) to 0.

The challenge is to write a halt decider that gives the correct answer
for /any/ input. You can't do that.

The other key mistake is that you assume H exists and works as you want,
and use that assumption to "prove" that H exists and works.

> The pattern is (as Sipser puts it) an input that "does the opposite" of
> whatever the halt decider decides.
>
>> (Even then you are talking
>> about one single compilation of the function.  C compilers are allowed,
>> in certain circumstances, to assume loops terminate.  A smart enough
>> compiler could do so here.  It is for such reasons that no sane computer
>> theorist would be using C and/or x86 for this kind of thing.)
>>
>
> I provide the disassembled machine code to utterly eliminate this
> ambiguity.
>
> Halting problem undecidability and infinitely nested simulation
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
>>>
>>> Conclusion(3) From the above true premises it necessarily follows that
>>> simulating halt decider H correctly reports that its input: (P,P) never
>>> halts.
>>
>> You can conclude that your program correctly reports that /one/ case.
>> You have proved nothing of use or interest, because it shows nothing
>> about any other program.
>>
>
> No. The one single input <is> the same essential pattern of all of the
> counter-example inputs that are used to prove that the halting problem
> is undecidable.
>

That does not matter - even if you /had/ proved that you had made a halt
decider that worked here for that one input. You have to prove it works
for /all/ inputs - not just one case. And you have to do it without
assuming that your halt decider is a halt decider.

> The pattern is (as Sipser puts it) an input that "does the opposite" of
> whatever the halt decider decides.
>
> When I show how this input is correctly decided then all of the
> conventional halting problem proofs lose their entire basis and utterly
> fail to prove their conclusion.
>
>> Consider function foo :
>>
>> def is_perfect_number(x) :
>>      return x == sum([i for i in range(1, x) if x % i == 0])
>>
>> def foo() :
>>     x = 1
>>     while (True) :
>>         x = x + 2
>>         if is_perfect_number(x) :
>>             return x
>>
>>
>> We can't write this in simple C - any size limitations are artificial
>> and negate the argument (since with machines limited to a given finite
>> size of program or input, the set of all possible traces is finite,
>> albeit rather large).  So I've given it in Python.
>>
>> Can you write a function that will determine if the execution of "foo"
>> will halt or not?
>>
>>
>
>

On 6/28/2021 2:52 PM, David Brown wrote:
> On 28/06/2021 20:29, olcott wrote:
>> On 6/28/2021 1:03 PM, David Brown wrote:
>>> On 28/06/2021 18:42, olcott wrote:
>
>>>>
>>>> // 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);
>>>> }
>>>>
>>>> Premise(1) (axiom) Every computation that never halts unless its
>>>> simulation is aborted is a computation that never halts. This verified
>>>> as true on the basis of the meaning of its words.
>>>
>>> If it was "true on the basis of the meaning of its words", it would be
>>> neither a premise nor an axiom.
>>>
>>
>> If it is true on the basis of the meaning of its words then when it
>> plays the role of a premise in deductive inference then we know that
>> this premise is true.
>>
>
> That is called "begging the question" - in the original sense of the idiom.
>

What I am saying is that we need to have a way to verify the truth of
the premises to confirm that a deductive argument is sound rather than
merely valid.

If one of the premises is verified as true on the basis of the meaning
of its words and the other premise is verified as true because it is an
established fact and the argument only has two premises then we have the
required basis to know that all the premises are true.

>>> But it is not true.
>>>
>>> Either you consider the method of aborting to be part of the input to
>>> the computation, in which case it /does/ halt, or you do not consider it
>>> part of the input - in which case the abortable computation is not the
>>> original one.
>>>
>>
>> We can know that it is true on the basis that
>> when the UTM simulation of Turing machine description of Turing Machine
>> M never halts then we know that the execution of TM M never halts.
>
> You are not simulating UTMs. You are not simulating anything remotely
> like a UTM - in particular, you are completely missing the "universal" part.
>

An x86 emulator does perfectly simulate the execution of x86 code.
I am creating a halting problem proof rebuttal entirely on the basis of
software engineering.

> It is certainly correct that a valid simulation of a UTM will halt if
> and only if the UTM would halt. Your simulation does not determine if a
> general UTM halts.
>

The refute the conventional halting problem proofs I merely need to
create code that correctly decides the halt status of the computational
equivalent of the conventional halting problem undecidability proof
counter-examples.

>> UTM(⟨M⟩, I) == ∞ logically entails M(I) == ∞ // "== ∞" means never halts
>>
>> The particular axiom is the key element of my proof that makes the
>> otherwise "impossible" inputs to a halt decider decidable.
>>
>
> If it were an axiom, then it is not part of the proof. Axioms are
> assumed to be true /without/ proof.
>

Axioms are the basis for subsequent reasoning.

I am establishing it as an axiom that never previously existed. In order
for this establishment to be credible I must provide its basis. I could
call it by its more accurate name: self-evident truth, yet this name is
far too unconventional. Because of this I establish it as an axiom on
the basis that it is self-evidently true. (true on the basis of the
meaning of its words).

>>>>
>>>> Premise(2) (verified fact) The simulation of the input to H(P,P) never
>>>> halts without being aborted is a verified fact on the basis of its x86
>>>> execution trace. (shown in my paper).
>>>
>>> A "verified fact" is not a premise either.
>>>
>>
>> When A "verified fact" plays the role of a premise in deductive
>> inference then we have a the basis required to know that this premise is
>> true.
>
> No, it does not. Please stop trying to use big words that you don't
> understand - that includes "premise", "verified", "fact", "proof", and
> "deductive inference".
>

Validity and Soundness
A deductive argument is said to be valid if and only if it takes a form
that makes it impossible for the premises to be true and the conclusion
nevertheless to be false. Otherwise, a deductive argument is said to be
invalid.

A deductive argument is sound if and only if it is both valid, and all
of its premises are actually true. Otherwise, a deductive argument is
unsound. https://iep.utm.edu/val-snd/

>>
>> When we have a conclusion that logically follows from a pair of premises
>> that are known to be true then we know that we have a sound rather than
>> merely valid argument.
>
> Even if your conclusion is correct, it is still useless because it
> applies to /one/ computation only.
>

No you are incorrect. It generically applies to the standard halting
problem undecidability counter-example template.

>>
>>> The impossibility of the halting problem is not about identifying
>>> particular computation that do not halt.  It is about the impossibility
>>> of defining an algorithm that will determine whether /any/ given
>>> computation will halt or not.
>>
>> Yes.
>>
>>> So a simulation here demonstrates nothing
>>> except for this /one/ single computation.
>>
>> No. The one single input <is> the same essential pattern of all of the
>> counter-example inputs that are used to prove that the halting problem
>> is undecidable.
>>
>
> Perhaps this is a key to your misunderstandings.
>
> There is no problem writing a halt decider that will correctly give the
> expected result for a /given/ input (or (UTM, input) pair) - assuming
> the expected result is known in advance. In your bizarre formulation,
> this would suffice:

No you are incorrect. It generically applies to the standard halting
problem undecidability counter-example template.

Halting problem undecidability and infinitely nested simulation

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

On what is currently page 8 of my paper I show exactly how the halt
decider embedded in the Peter Linz Ĥ correctly decides the halt status
of its input: (⟨Ĥ⟩, ⟨Ĥ⟩).

>
> u32 H(u32 p, u32 i) {
> return 0;
> }
>
> That would correctly evaluate H(P, P) to 0.
>
> The challenge is to write a halt decider that gives the correct answer
> for /any/ input. You can't do that.
>
> The other key mistake is that you assume H exists and works as you want,
> and use that assumption to "prove" that H exists and works.
>
>> The pattern is (as Sipser puts it) an input that "does the opposite" of
>> whatever the halt decider decides.
>>
>>> (Even then you are talking
>>> about one single compilation of the function.  C compilers are allowed,
>>> in certain circumstances, to assume loops terminate.  A smart enough
>>> compiler could do so here.  It is for such reasons that no sane computer
>>> theorist would be using C and/or x86 for this kind of thing.)
>>>
>>
>> I provide the disassembled machine code to utterly eliminate this
>> ambiguity.
>>
>> Halting problem undecidability and infinitely nested simulation
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>>>>
>>>> Conclusion(3) From the above true premises it necessarily follows that
>>>> simulating halt decider H correctly reports that its input: (P,P) never
>>>> halts.
>>>
>>> You can conclude that your program correctly reports that /one/ case.
>>> You have proved nothing of use or interest, because it shows nothing
>>> about any other program.
>>>
>>
>> No. The one single input <is> the same essential pattern of all of the
>> counter-example inputs that are used to prove that the halting problem
>> is undecidable.
>>
>
> That does not matter - even if you /had/ proved that you had made a halt
> decider that worked here for that one input. You have to prove it works
> for /all/ inputs - not just one case. And you have to do it without
> assuming that your halt decider is a halt decider.
>

On 28/06/2021 22:21, olcott wrote:

>>
>> You are not simulating UTMs. You are not simulating anything
>> remotely like a UTM - in particular, you are completely missing the
>> "universal" part.
>>
>
> An x86 emulator does perfectly simulate the execution of x86 code.

Your code is not a UTM. It doesn't matter how accurately you simulate
x86 code, you are not simulating a UTM. Your emulator is limited in
size, a UTM is not.

> I am creating a halting problem proof rebuttal entirely on the basis
> of software engineering.
>

That's what you are trying to do, yes - but you have not done so. (Nor
can you.)

>
> Axioms are the basis for subsequent reasoning.
>
> I am establishing it as an axiom that never previously existed.

Right...

I shall take as an axiom "the moon is made of cheese". Then we can take
"the Apollo missions brought back rock, not cheese" as a "verified
fact". From which we conclude that the moon landings were faked. That
is as much of a sound, valid deduction as your reasoning.

If you make up "axioms" to suit what you want to prove, then you can
make a logical proof. But it doesn't help anyone.

>
> To solve the halting problem I have to prove that the halt decider works
> for all inputs.
>
> To refute the conventional halting problem undecidability proofs I only
> have to show that it works on their standard "impossible"
> counter-example template. I have done that.
>

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. A simulator cannot
tell if the computation will halt or not - for any given finite timestep
T, it cannot in general distinguish between "halts after time T" and
"does not halt". It might be able to do so in some cases, but not in
general.

And if you had a simulator that did what you think it does, that in
itself would refute /any/ halting problem undecidability proofs, because
you would have found a halting problem decider.

And even if you /had/ found a way to determine the halting behaviour of
the particular type of function you discuss, that would /still/ not
refute the "conventional proof" because actual proofs are a little more
advanced that you seem to imagine.

On 6/28/2021 5:07 PM, David Brown wrote:
> On 28/06/2021 22:21, olcott wrote:
>
>
>>>
>>> You are not simulating UTMs. You are not simulating anything
>>> remotely like a UTM - in particular, you are completely missing the
>>> "universal" part.
>>>
>>
>> An x86 emulator does perfectly simulate the execution of x86 code.
>
> Your code is not a UTM. It doesn't matter how accurately you simulate
> x86 code, you are not simulating a UTM. Your emulator is limited in
> size, a UTM is not.
>
>> I am creating a halting problem proof rebuttal entirely on the basis
>> of software engineering.
>>
>
> That's what you are trying to do, yes - but you have not done so. (Nor
> can you.)
>
>>
>> Axioms are the basis for subsequent reasoning.
>>
>> I am establishing it as an axiom that never previously existed.
>
> Right...
>
> I shall take as an axiom "the moon is made of cheese". Then we can take
> "the Apollo missions brought back rock, not cheese" as a "verified
> fact". From which we conclude that the moon landings were faked. That
> is as much of a sound, valid deduction as your reasoning.
>
> If you make up "axioms" to suit what you want to prove, then you can
> make a logical proof. But it doesn't help anyone.
>
>
>>
>> To solve the halting problem I have to prove that the halt decider works
>> for all inputs.
>>
>> To refute the conventional halting problem undecidability proofs I only
>> have to show that it works on their standard "impossible"
>> counter-example template. I have done that.
>>
>
> 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.

You keep missing the point on this. The scope of my project is to show
how that conventional halting problem undecidability template is
correctly decided.

> A simulator cannot
> tell if the computation will halt or not - for any given finite timestep
> T, it cannot in general distinguish between "halts after time T" and
> "does not halt". It might be able to do so in some cases, but not in
> general.
>
> And if you had a simulator that did what you think it does, that in
> itself would refute /any/ halting problem undecidability proofs, because
> you would have found a halting problem decider.
>
>
> And even if you /had/ found a way to determine the halting behaviour of
> the particular type of function you discuss, that would /still/ not
> refute the "conventional proof" because actual proofs are a little more
> advanced that you seem to imagine.

I have already shown how I apply this to the Peter Linz proof
on page 8. That you simply ignore this is not a rebuttal.

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