Refuting the halting problem pseudo-code proof

[olcott]

The standard pseudo-code halting problem template "proved" that the
halting problem could never be solved on the basis that neither value of
true (halting) nor false (not halting) could be correctly returned to
the confounding input.

This problem is overcome on the basis that the halt decider aborts its
simulation of this input before ever returning any value. It aborts the
simulation of its input on the basis that its input specifies what is
essentially infinite recursion to any simulating halt decider.

procedure compute_g(i):
if f(i, i) == 0 then
return 0
else
loop forever // (Wikipedia:Halting Problem)

https://en.wikipedia.org/wiki/Halting_problem

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

int main()
{
H_Hat((u32)H_Hat, (u32)H_Hat);
}

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

[Richard Damon]

On 6/10/21 10:56 PM, olcott wrote:
> The standard pseudo-code halting problem template "proved" that the
> halting problem could never be solved on the basis that neither value of
> true (halting) nor false (not halting) could be correctly returned to
> the confounding input.

SO you accept that Linz is RIGHT. That there IS no halt decider that can
always give a correct answer to the REAL halting problem definiton.

>
> This problem is overcome on the basis that the halt decider aborts its
> simulation of this input before ever returning any value. It aborts the
> simulation of its input on the basis that its input specifies what is
> essentially infinite recursion to any simulating halt decider.

But, aborting the simulation doesn't actually show anything about the
actual problem. Since the Simulating Halt Decider returns its answer to
its caller (or it fails to be a halt decider) it still is in the
cundundrum that whatever answer it gives will still be wrong.

You logic fails on that fact that the Halt Decider, by definition, must
always give the same answer to a given problem, and thus if it DOES
abort a given input, it will and has ALWAYS aborted that input and thus
it it NOT infinitely recursive on that input.

This is like the person looking for his lost keys under a street lamp,
and when the passer by asks how it lost them, and he points to the
nearby field and says he dropped them while crossing the field. When
asked why he is looking here instead of there, he says because the light
is here.

You are looking for an answer in the place without one. You can not find
an answer to the Halting Problem if you leave the definitions of the
Halting Problem behind. It just doesn't work.

Yes, you can claim that you can define Olcott-Halting in a way that one
proof against Halting doesn't apply to Olcott-Halting, but that doesn't
even mean that it is possible to always decide Olcott-Halting. It also
doesn't mean Olcott-Halting is useful for anything.

It definitely doesn't mean you have refuted the proofs that there is no
such thing as an actual universally correct Halt Decider, so it doesn't
prove anything like what you want to claim.

You can't prove a statement about black cats by using a white dog.

[olcott]

On 6/11/2021 5:27 AM, Richard Damon wrote:
> On 6/10/21 10:56 PM, olcott wrote:
>> The standard pseudo-code halting problem template "proved" that the
>> halting problem could never be solved on the basis that neither value of
>> true (halting) nor false (not halting) could be correctly returned to
>> the confounding input.
>
> SO you accept that Linz is RIGHT. That there IS no halt decider that can
> always give a correct answer to the REAL halting problem definiton.
>
>>
>> This problem is overcome on the basis that the halt decider aborts its
>> simulation of this input before ever returning any value. It aborts the
>> simulation of its input on the basis that its input specifies what is
>> essentially infinite recursion to any simulating halt decider.
>
>
> But, aborting the simulation doesn't actually show anything about the
> actual problem. Since the Simulating Halt Decider returns its answer to
> its caller (or it fails to be a halt decider) it still is in the
> cundundrum that whatever answer it gives will still be wrong.
>

void Infinite_Loop()
{
HERE: goto HERE;
}

int Infinite_Recursion(u32 N)
{
u32 M = Infinite_Recursion(N);
return M;

}

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

int main()
{

u32 Input_Would_Halt2 = H((u32)Infinite_Loop, (u32)Infinite_Loop);
Output("Input_Would_Halt2 = ", Input_Would_Halt2);

u32 Input_Would_Halt3 = H((u32)Infinite_Recursion, 3);
Output("Input_Would_Halt3 = ", Input_Would_Halt3);

u32 Input_Would_Halt6 = H((u32)H_Hat, (u32)H_Hat);
Output("Input_Would_Halt6 = ", Input_Would_Halt6);
}

In all three of the above cases H must abort the simulation
of its input and report that its input does not halt.

This is apparently beyond your intellectual capacity or ability to pay
attention.

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

[Richard Damon]

WRONG QUESTION.

In th 3rd case, yes, for H to be able to return an answer, it must abort
the simulation, but the answer of non-halting is wrong.

This is shown by running H_Ht with that same H, and we see that it will
run and halt.

Thus the answer of non-halting is wrong. PERIOD.

You have given ZERO PROOF that the answer should be considered right.

Part of the problem is that since H_Hat uses H, you need to use better
logic to include the fact that H might stop its simulation.

Yes, if H doesn't abort its simulation, then H_Hat will be non-halting,
but then that H won't be able to return an answer so it will also fail
to be a halt decider.

The right answer to the halting behavior MUST look at the right version
of that computation, so since an H that can answer will abort the
simulation, it needs to take that operation into account when it
determines what answer to give.

It turns out that an H that gives the right answer is impossible to
actually create, so you get strange logic when you begin by assuming
that it exists. Unicorns defy the laws of logic.

> This is apparently beyond your intellectual capacity or ability to pay
> attention.

No, just beyond yours. Your think is at least one step behind reality,
you don't think far enough to see that H does abort its simulation and
this actually allows the H_Hat that is using that H to return its answer
and be halting.

[olcott]

A computation that forced to halt because its simulation was aborted
does not count as a computation that halts, otherwise infinite loops
would be considered computations that halt.

This is either beyond your intellectual capacity or it is beyond your
ability to pay attention.

When-so-ever any input P to a simulating halt decider H would never halt
unless the simulation of P is aborted H stops simulating P and correctly
decides that P is not a computation that halts.

[Richard Damon]

But you are confusing the computations, and refusing to look at the case
referenced in the definition where we actually run H_Hat, not just
decide on it. THIS is the run that matters, and THIS run is NEVER
aborted by a simulation, since it is not being run as a simulation.

A computation that is forced to halt because its simulation was aborted
tells you NOTHING by itself if the computation was Halting or
Non-Halting, you just know it hasn't halted YET.

>
> This is either beyond your intellectual capacity or it is beyond your
> ability to pay attention.
>
> When-so-ever any input P to a simulating halt decider H would never halt
> unless the simulation of P is aborted H stops simulating P and correctly
> decides that P is not a computation that halts.
>

Except that it is shown that with your given definition of H, that H_Hat
WILL HALT if allowed to run to its completion, therefore H's decision to
halt and decide that H_Hat is non-halting is incorrect. A Correct
decider on H_Hat could continue to run the simulation of H_Hat and would
see it halting. Thus H was incorrect in its decision to abort.

Yes, H_Hat only halts because the copy of H it contains incorrectly
decides to terminate the simulation of its copy of H_Hat, but that is
the H that the H_Hat is built on. The fact that the H was wrong doesn't
affect the definition of Halting for H_Hat.

You seem to be intellectually unable to handle that deciders CAN be wrong.

Maybe the big issue is you can't keep enough things separate in your
mind. The biggest issue is that when testing if H has given the right
answer, the FULL code of H_Hat must be considered fixed, and that
includes its copy of H (and to be built right, it does have its own
copy). That copy of H is allowed to be (and in fact will always be)
wrong in its determination, as it will be what it is programmed to do.

A computation is ALWAYS defined as a methodical algorithm to get to the
answer. A definition like 'the right answer' is NOT acceptable. When
designing the computation that might be the question that you are trying
to answer, but the key is figuring out how to get there.

We have the basic software principle:

You start with a specification which often desribe what the answer
should be or the properties of that answer (like H should say if P(I) is
a halting computation or not).

It is the job of the programmer to figure out an algorithm to convert
that specification into actual code, and rarely is the specification
directly usable as actual code (if it was, they wouldn't need to hire you).

After the program is coded, you then need to test actually TEST the code
and make sure that the code always generates that right answer, and to
do that you need to go back to the specifications.

Unless you write real bad code, the code will always do what it is coded
to do, but the key is was it coded to do what it was supposed to.

Thus the real test is not does the code do what my algorithm said it
should do (though that is important) it is did it meet the specifications.

For the Halting Problem, the specifications refer to the running of the
code as an independent machine, NOT running it as an input to some halt
decider. Thus the test is ALWAYS to the original machine.

You also need to remember that not all problems are solvable, sometimes
people want somethng that can't be done. In this case, sometimes it can
make sense to figure out it there IS something that is doable that is
'good enough', but sometimes it is better to just admit that it can't be
done.

As an example, you make an algorithm to try to figure a betting stragy
to long term always win at roulette. We know that due to the house cut,
this can't be done. But many people lose their shirt because the come up
with an answer that maybe 90% of the time will win them $100, and the
ignore that 10% of the time they will lose $1500. Maybe they improve it
to win 99% of the time, but now 1% of the time they lose $20,000 and
they think they did better, but it actually got worse long term.

[olcott]

You have to go through the steps of my proof in mandatory prerequisite
order. At this point I find this to be simply dishonest.

> A computation that is forced to halt because its simulation was aborted
> tells you NOTHING by itself if the computation was Halting or
> Non-Halting, you just know it hasn't halted YET.

You can't even get my freaking words correctly. At this point I also
find that this is simply flat out dishonest.

When-so-ever any input P to a simulating halt decider H would never halt
unless the simulation of P is aborted H stops simulating P and correctly
decides that P is not a computation that halts.

[Malcolm McLean]

Yes, but the point is that the simulating halt decider is simulating a simulating
halt decider.

[olcott]

So what? The above halt deciding principle is correct under all possible
conditions as long as its criteria is met: (the input would never halt
unless its simulation is aborted).

[Richard Damon]

WHAT proof. We have been following and you just jumped and made the
claim that H is right on H_Hat by similarity to two very different
machines. A PROOF, starts with well accepted statements and definitions,
and show via logicial necessity that some other statement is true.

For example:
Black Cats are Black.
Felix is a Black Cat.
Therefore Felix is Black.

Is a proper (though somewhat trivial proof).

You just made a statement, and IT IS WRONG.

BY DEFINITION, A Halting Computation is a computation that finishes in
finite time. H_Hat(H_Hat) finishes in finite time, in part because the
copy of H it contains will abort a simulation of a copy of the
description of H_Hat(H_Hat), but that doesn't affect the actual
definition of halting, it doesn't matter why a computation completes,
just that it does. (NOTE, this is the MACHINE ITSELF, it does NOT say
that aborting a simulation means the simulated machine is halting, it
never finished its computation to its halt).

>
>> A computation that is forced to halt because its simulation was aborted
>> tells you NOTHING by itself if the computation was Halting or
>> Non-Halting, you just know it hasn't halted YET.
>
> You can't even get my freaking words correctly. At this point I also
> find that this is simply flat out dishonest.



>
> When-so-ever any input P to a simulating halt decider H would never halt
> unless the simulation of P is aborted H stops simulating P and correctly
> decides that P is not a computation that halts.
>

FALSE STATEMENT. Pulled out out thin air without proof.

Counter example showing it is wrong, H_Hat built on your H that does
decide to abort the simulation.

Even you have provided traces of this case, which clearly shows that
H_Hat(H_Hat) in this case, when run as the top level machine DOES finish
and come to a halt, and thus by the DEFINITION of Halting is a Halting
Computation. This statement says (at least by your interpretation) that
it is correctly decided as non-halting, and non-halting is NOT Halting,
and thus wrong.

Please correct what you claim to be a ACTUAL error in that statement.

Any statement claiming something to always be true that has at least one
counter example is a false statement, therefore this statement is false.

Reason it is false, under your interpretation of the operation you
conflate the fixed operation of the H included by copy inside H_Hat with
the testing of the decision process of the outer deciding H.

We can test the 'would never halt' clause of you statement by changing
the OUTER H to a pure simulator. When we do this we do NOT change the
copy of H that is inside H_Hat, as that is a different piece of code
that is part of the input, we want to test if H gave the right answer
for a GIVEN input, so we don't change it.

WHen we make that change, we see that the simulation will end, and thus
the requitment of would never halt unless the simulation of P is
aborted, is NOT true.

Note, a big part of your error is that you don't seem to understand that
the way Turing Machines are built, the machine H_Hat includes a COPY of
H, and is not defined to use the H that is calling it (and in fact, by
the rules of computations, you can NOT define such a machine as a
computation). Since H_Hat has its own copy of H, the change we make to H
to test if it actually needed to do the termination of the simulation
that it has been programmed to do, doesn't affect the copy in H_Hat.

You don't seem to be able to understand this basic principle of
computing. I don't think you really understand much about Turing
Machines, and have gotten in over your head.

[olcott]

The above statement can be known to be true entirely on the basis of the
meaning of its words. This is either beyond your intellectual capacity
or you are simply dishonest.

There is no case where the simulation of the input to H(H_Hat, H_Hat)
would ever halt unless this simulation is aborted.

[Richard Damon]

It can be show true with a PROPER definition of the words, the key is
that 'the simulation of P is aborted' applies only to that given
simulation, and doesn't include other copies. The fact that H_Hat
includes a copy of H that simulates a copy of H_Hat and aborts its
simulation (incorrectly deciding non-Halting) doesn't make H_Hat
non-halting.

As I have shown, it can be proved FALSE with YOUR (wrong) meaning of the
words.

If something can be shown to be FALSE, it can not be true, unless the
logic system can be shown inconsistent, which as I have pointed out
before, seems to be the state of the system under your definitions.

[olcott]

On 6/11/2021 12:52 PM, Richard Damon wrote:
> On 6/11/21 12:58 PM, olcott wrote:
>> On 6/11/2021 11:50 AM, Richard Damon wrote:
>>> On 6/11/21 11:58 AM, olcott wrote:
>>>>
>>>> When-so-ever any input P to a simulating halt decider H would never halt
>>>> unless the simulation of P is aborted H stops simulating P and correctly
>>>> decides that P is not a computation that halts.
>>>>
>>>
>>> FALSE STATEMENT. Pulled out out thin air without proof.
>>>
>>> Counter example showing it is wrong, H_Hat built on your H that does
>>> decide to abort the simulation.
>>>
>>
>> The above statement can be known to be true entirely on the basis of the
>> meaning of its words. This is either beyond your intellectual capacity
>> or you are simply dishonest.
>>
>> There is no case where the simulation of the input to H(H_Hat, H_Hat)
>> would ever halt unless this simulation is aborted.
>>
>
> It can be show true with a PROPER definition of the words, the key is
> that 'the simulation of P is aborted' applies only to that given
> simulation,

This is probably beyond your capacity to understand:

In the case of infinite recursion the entire invocation sequence is
infinitely recursive. When any single function invocation in this
infinite invocation call chain is terminated then the whole call chain
is terminated.

When the termination of one of these invocations is required to prevent
the infinite execution of this call chain then the entire call chain
represents a computation that does not halt.

[Richard Damon]

WRONG.

If the sequence WAS infinitly recursive, then it could NEVER end, as it
takes infinite time to actually reach infinite recursion.

What we have here is a POTENTIAL infinite recursion, only potential,
because something in the loop has the ability to break that otherwise
potentially infinite recursion, and does exercise that ability. Since it
does we do NOT have an actual infinite recursion and can follow the now
finite execution trace.

>
> When the termination of one of these invocations is required to prevent
> the infinite execution of this call chain then the entire call chain
> represents a computation that does not halt.
>

Wrong, when the actor that has the potential to break the infinite
recursion does act, then it can and does return and that call chain can
finish.

Your argument might apply if the thing terminating the sequence wasn't
part of the recursive loop, then it could possibly conclude (with the
right logic) that nothing in the recursive loop could break the loop and
thus that loop was truely infinitely recursive and thus non-halting.

The fact that in this case H WAS part of the loop, this logic doesn't
hold as we just showed that something in the loop has the power to break
the loop, so the loop was never infinite in the first place. The decider
does run into the issue that having decided to abort a simulation that
it was part of, it needs to figure out what answer it should return. The
trace up to the point of aborting does NOT have enough information to
answer that, as it knows that it has aborted a decider that would given
a bit more time would have aborted things itself, and thus this decide
needs to figure out what would happen after that happens.

The problem is that this is turns out to not be a finitely computable
result in all cases, including the one we are in. The self-reference in
the design of the situation makes it impossible for H to come up with an
answer to give that is consistant.

[olcott]

No sense talking to you anymore. You are either too stupid or dishonest
to understand or acknowledge that a simulating (at least partial) halt
decider does correctly decide that this function <is> infinitely recursive.

int Infinite_Recursion(u32 N)
{
u32 M = Infinite_Recursion(N);
return M;
}

[Richard Damon]

Never said THAT one wasn't. Where did I say THAT one wasn't. You seem to
have an issue with keeping to real facts.

Wrong rules can sometimes get right answers, just as right rules used
wronglycan sometimes get wrong answers.

The issue with your supposed definition is when the simulating halt
decider sees copies of itself, which doesn't happen in that machine.

Maybe YOU should learn to actually read what was said and not say such
dumb things.

[olcott]

I have been trying to get you to understand that H does correctly decide
that Infinite_Recursion() does not halt for about 15 messages now.

So are so damned evasive that this is getting to be more work than it is
worth.

[Richard Damon]

And I have NEVER said it didn't. When you quote the RULE, I object to it
as the rule can be wrong for cases like H_Hat, but a wrong rule can get
some cases right.

This whole thread started with your message
Message-ID: <C6Gdndon-KXY8F79...@giganews.com>
Date: Fri, 11 Jun 2021 09:03:52 -0500

where you stated:

>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }
>

> int Infinite_Recursion(u32 N)
> {
> u32 M = Infinite_Recursion(N);
> return M;
> }
>

> void H_Hat(u32 P)
> {
> u32 Input_Halts = H(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
> int main()
> {
> u32 Input_Would_Halt2 = H((u32)Infinite_Loop, (u32)Infinite_Loop);
> Output("Input_Would_Halt2 = ", Input_Would_Halt2);
>
> u32 Input_Would_Halt3 = H((u32)Infinite_Recursion, 3);
> Output("Input_Would_Halt3 = ", Input_Would_Halt3);
>
> u32 Input_Would_Halt6 = H((u32)H_Hat, (u32)H_Hat);
> Output("Input_Would_Halt6 = ", Input_Would_Halt6);
> }
>
> In all three of the above cases H must abort the simulation
> of its input and report that its input does not halt.

And I objected to your claim that the last was decided correctly as
non-halting since H_Hat(H_Hat) does halt and thus the non-halting answer
is incorrect.

If YOU can't keep straight what is being discussed, maybe you need to
see someone to have your meds adjusted.

The fact that you keep on defending ground that isn't being attacked is
signs that you aren't thinking well.

[olcott]

So you agree with this:
When-so-ever an input demonstrates an infinitely repeating pattern and
this repeating pattern is caused by an infinite loop or infinite
recursion then the simulating halt decider can stop simulating its input
and report that this input does not halt.

[Richard Damon]

If it si TRUELY an infinitely repeating pattern with no possible break,
then the decider can stop the simulation and report not-halitng.

Note, if it sees a decider in the loop, then it needs to allow for the
action of the decider. This is where you fail for H_Hat.

[olcott]

We can artificially contrive an undecidable problem depending on how we
frame the problem or we can remove this artificial contrivance.

It is self-evident that any computation that will never halt unless its
simulation is aborted is merely a computationally equivalent way to
define that a computation does not halt.

We know this on the basis that a UTM simulation of a TM description ⟨P⟩
that does not halt logically entails that the TM P does not halt.

A simulating halt decider applies this computationally equivalent
definition of non-halting does correctly decide that both the pseudo-code

procedure compute_g(i):
if f(i, i) == 0 then
return 0
else
loop forever // (Wikipedia:Halting Problem)

and the Linz Ĥ

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
if M applied to wM halts, and

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
if M applied to wM does not halt

counter-examples are merely computations that do not halt on their input.

[Richard Damon]

On 6/11/21 6:17 PM, olcott wrote:
> On 6/11/2021 4:38 PM, Richard Damon wrote:
>> On 6/11/21 5:07 PM, olcott wrote:
>>> On 6/11/2021 3:57 PM, Richard Damon wrote:
>>>>
>>>> And I have NEVER said it didn't. When you quote the RULE, I object
>>>> to it
>>>> as the rule can be wrong for cases like H_Hat, but a wrong rule can get
>>>> some cases right.
>>> So you agree with this:
>>> When-so-ever an input demonstrates an infinitely repeating pattern and
>>> this repeating pattern is caused by an infinite loop or infinite
>>> recursion then the simulating halt decider can stop simulating its input
>>> and report that this input does not halt.
>>>
>>
>> If it si TRUELY an infinitely repeating pattern with no possible break,
>> then the decider can stop the simulation and report not-halitng.
>>
>> Note, if it sees a decider in the loop, then it needs to allow for the
>> action of the decider. This is where you fail for H_Hat.
>>
>
> We can artificially contrive an undecidable problem depending on how we
> frame the problem or we can remove this artificial contrivance.

But the Halting Problme isn't 'artificially contrived', and as such
there is no artifical contrivances that can be removed. It has
legitimate applicability in mathematical theory which needs it exactly
as stated.

As I have said before, you are perfectly free to define you own version
of the halting problem with a different definition as long as you make
it clear that this is what you are doing. The one thing that this will
mean is that you alternate problem won't matter to all those other
proofs that derive themselves from the proof of the halting problem's
impossibility.

>
> It is self-evident that any computation that will never halt unless its
> simulation is aborted is merely a computationally equivalent way to
> define that a computation does not halt.

But ONLY with the right definition. The key difference between that and
the one you use is the right definition say that it must be the instance
of the decider that is making the actual decision that must stop the
simulation, it doesn't count if it is another copy that must.

>
> We know this on the basis that a UTM simulation of a TM description ⟨P⟩
> that does not halt logically entails that the TM P does not halt.

Right. And your interpretation where even if the input as given will
halt when given to a UTM but if the input is modified to have copies of
the decider replaced with a UTM and THAT makes it not halt, it is
correct to call it non-halting is wrong.

The rule is that H(P,I) should return Halting if, and only if UTM(P,I)
is a Halting Computation which by the definition of a UTM is if and only
if P(I) is a Halting Computation which is exactly the defintion.

>
> A simulating halt decider applies this computationally equivalent
> definition of non-halting does correctly decide that both the pseudo-code
>
> procedure compute_g(i):
>   if f(i, i) == 0 then
>     return 0
>   else
>     loop forever    // (Wikipedia:Halting Problem)
>
> and the Linz Ĥ
>
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
> if M applied to wM halts, and
>
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
> if M applied to wM does not halt
>
> counter-examples are merely computations that do not halt on their input.
>

Right, and since for your H it has been shown that it will answer
non-Halting for this input and H^ will then Halt that H gave the wrong
answer when feed the description of this machine.

[olcott]

This is the key part that you have persistently ignored:

There is no case where the simulation of the input to H(P, P) would ever

halt unless this simulation is aborted.

[Richard Damon]

But that doesn't matter. Even you just above agreed that the right
answer that H needs to produce is will UTM(P, P) halt or not, and for
your H the H^ based on it DOES, so the right answer is Halting, even
though H says non-Halting.

The key is H halted the simulation, but it turns out that in that
particular case it really didn't need to because H^ will halt because
the H inside it will stop the potential infinite recursion and let H^
come to a Halt. The fact that H made the mistake of deciding that H^ was
non-Halting allows H^ to BE Halting.

[olcott]

It is all that matters.

> Even you just above agreed that the right
> answer that H needs to produce is will UTM(P, P) halt or not, and for
> your H the H^ based on it DOES, so the right answer is Halting, even
> though H says non-Halting.
>

Forced to halt does not freaking count as halting.

> The key is H halted the simulation, but it turns out that in that
> particular case it really didn't need to because H^ will halt because
> the H inside it will stop the potential infinite recursion and let H^
> come to a Halt. The fact that H made the mistake of deciding that H^ was
> non-Halting allows H^ to BE Halting.
>

What-so-ever H that decided that its input would never halt unless it
aborted this input correctly decides that the entire infinitely
recursive chain is not a computation that halts.

[Richard Damon]

Why, the question that H is supposed to be answering is does P(P) halt
or not, so THAT is all that matters.

>
>> Even you just above agreed that the right
>> answer that H needs to produce is will UTM(P, P) halt or not, and for
>> your H the H^ based on it DOES, so the right answer is Halting, even
>> though H says non-Halting.
>>
>
> Forced to halt does not freaking count as halting.

WHO was forced to halt. UTM(P,P) will not force ANY machine to halt. In
this case inside H^ there will be ANOTHER simulation that will be
started and aborted, but this P(P) is not aborted.

>
>> The key is H halted the simulation, but it turns out that in that
>> particular case it really didn't need to because H^ will halt because
>> the H inside it will stop the potential infinite recursion and let H^
>> come to a Halt. The fact that H made the mistake of deciding that H^ was
>> non-Halting allows H^ to BE Halting.
>>
>
> What-so-ever H that decided that its input would never halt unless it
> aborted this input correctly decides that the entire infinitely
> recursive chain is not a computation that halts.
>
>

WRONG. H decided wrong as are you. H^(H^) IS a Halting Computation, you
have admitted it and even proved it. THAT is what the definition of the
right answer to the Halting problem refers to, so that is the right
answer, but not the answer that H produces, so it is wrong.

You got nothing.


As I have said, write your dumb paper and get your rejection over with.

Maybe try to submit to JIR or AIR and see if they will take it for laughs.

[olcott]

I finally had a discussion with someone that was able to directly verify
that the input to every H(P,P) must always be aborted on the basis of
examining the x86 execution trace of this input.

So my whole problem is that I was talking with people that did not know
the x86 language well enough to verify that I am definitely correct.

The linked paper has this x86 execution trace so anyone that knows the
x86 language can verify for themselves that every H(P,P) must always be
aborted.

void P(u32 x)
{
u32 Input_Halts = H(x, x);

if (Input_Halts)
HERE: goto HERE;
}

int main()
{

H((u32)P, (u32)P);
H((u32)P);

}

Halting problem undecidability and infinitely nested simulation

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

[Richard Damon]

So, I take you you found another idiot who doesn't know Turing Machines
and conmputation theory well enough to fall for your scam.

As I said, go ahead, write your paper and submit it and get rejected.

First, it doesn't matter what happens on x86 assembly since that is not
the machine structure that the theorems are based on.

Second, You are still asking the wrong question. The halting theory
doesn't care that the Decider H 'needed' to abort the simulation of
P(I), it cares if P(I) is a finite computation or will run forever, and
you program gets that answer wrong. PERIOD. If the structure of H is
such that finds it needs to abort some finite computations, that is the
deciders problem.

[olcott]

The halting problem proof was intentionally designed to have the
pathological self-reference (olcott 2004) error.

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

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

P was intentionally defined to do the opposite of whatever H decides on
itself as input.

It is self-evidently true that every computation that never halts unless
its simulation is aborted <is> a non-halting computation even after its
simulation has been aborted.

We know that the above is computationally equivalent to the conventional
definition of not halting on the basis that when the simulation of the
Turing machine description of P by universal Turing machine (UTM) U
never halts then we know that the execution of Turing machine P never
halts. (UTM(P,P) = ∞) ≡ (P(P) = ∞)

Anyone that knows the x86 language well enough can directly see for
themselves that P continues to invoke H(P,P) in an infinitely repeating
cycle. The x86 execution trace shows that P calls H with its own machine
address in an infinitely repeating cycle that has no escape, thus
perfectly meeting the above criteria.

The x86 execution trace of H(P,P) is provided in this paper:

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

[Richard Damon]

On 6/12/21 11:25 AM, olcott wrote:

> The halting problem proof was intentionally designed to have the
> pathological self-reference (olcott 2004) error.
>
> void P(u32 x)
> {
>   u32 Input_Halts = H(x, x);
>   if (Input_Halts)
>     HERE: goto HERE;
> }
>
> int main()
> {
>   H((u32)P, (u32)P);
> }
>
> P was intentionally defined to do the opposite of whatever H decides on
> itself as input.
>
> It is self-evidently true that every computation that never halts unless
> its simulation is aborted <is> a non-halting computation even after its
> simulation has been aborted.

WRONG. See H_Hat. YOU agree that it will halt on its own when run. PERIOD.

>
> We know that the above is computationally equivalent to the conventional
> definition of not halting on the basis that when the simulation of the
> Turing machine description of P by universal Turing machine (UTM) U
> never halts then we know that the execution of Turing machine P never
> halts. (UTM(P,P) = ∞) ≡ (P(P) = ∞)

WRONG. We KNOW that U(H^, H^) does halt, thus H(H^,H^) saying
non-halting is wrong. Saying that H^(H^) doesn't halt because H*H^,H^)
needed to abort is is wrong.

>
> Anyone that knows the x86 language well enough can directly see for
> themselves that P continues to invoke H(P,P) in an infinitely repeating
> cycle. The x86 execution trace shows that P calls H with its own machine
> address in an infinitely repeating cycle that has no escape, thus
> perfectly meeting the above criteria.
>
> The x86 execution trace of H(P,P) is provided in this paper:
>
> Halting problem undecidability and infinitely nested simulation
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
>

The Halting Problem Definitions:

A Halt Decider is a Turing Machine that can Correctly Decide in finite
time if a given Turing Machine run on a given in will run forever or
Halt in a finite number of Steps, that machine and input provided via
some description as the input tape to the Halt Decider Machine.

and the related question:

Is it possible to create a Halt Decider that will answer correctly for
every possible Turing Machine and every possible input?

Is a totally natural question that comes out of actual desires. This
question has absolutely ZERO 'pathological' self reference in it. Yes,
due to the nature of Turing Machines, we have the potential of
self-references, since we have a fundamental property that given any
Turing Machine we can define another Turing Machine based on it, so the
nature of the problem of making a Turing Machine that takes Turing
Machines Description as input does say the problem allows for
self-reference as a natural part of its nature.

This sort of behavior is common in mathematics (and is one thing that
causes the issue with your favorite rule that all Truth is Provable).

One this Problem was created, which has natural uses in Computation
Theory and application to much of Mathematics, people worked on that
second question, which has fundamental implication on the nature of
logic in Mathematics.

So then YES, a simple form of machine construction, which used a form of
self reference was figured out that creates a machine from any proposed
decider that by construction the decider can't correctly decide on. THIS
IS TOTALLY LEGAL. You seem to think that there must be something wrong
with making this machine. THERE ISN'T. The fact that Turing Machines can
be built from other Turing Machines allows this construction to be done.

The fact that this gives the halt decider a problem is the purpose of
it, is shows that there is a machine that it can not properly decide.

Thus we HAVE the answer to the second part of the problem, it is
impossible to make a Turing Machine to correctly decide on all Turing
Machines/Input combination.

To somehow say that this machine isn't allowed would be like saying that
we have to restrict the use of the division operation to only rations
that evenly divide because we have some pet theory that breaks if we
have non integral numbers, or we are limited in what numbers we can take
the root of as we desire that all numbers need to be rationals and want
to eliminate all the irrational numbers (but this doesn't quite do it,
but maybe it gets rid of the most obvious cases).

The fact that the PROOF that there exist computations that we can not
know if they halt or not, is one of the nails in the coffin of the
concept that ALL Truths are Provable, which may be why you are going so
crazy over it. You need to face the fact that this ship has sailed, at
least in the realm of Mathematics, the proposition that we have the
potential to prove all True statements and disprove all false statement
is dead. It just doesn't work.

You CAN develop limited logic systems based on this property, and even
limited version of Mathematics that allow for it, but it can not hold
for all Mathematics. This was settled about a century ago.

It seems your refusal to learn from the works of the field has condemned
you to make the exact same mistakes that many of the great
Mathematicians of that time were making, trying as hard as they could
try and define things in a way that could allow for the concept of
completeness, where all Truths could be provable.

Most of them accepted the results. Either they decided to remove
Mathematics from their logic system to allow them to keep the rule, or
they worked to make a limited Mathematics that allowed them keep the
rule, or they accepted that not everything would be provable and worked
on new mathematic forms.

Maybe you should study this enough to learn from those and not make a
fool of yourself rejecting a proven truth because it breaks your
preconceived ideas.

[olcott]

On 6/12/2021 1:44 PM, Richard Damon wrote:
> On 6/12/21 11:25 AM, olcott wrote:
>
>> The halting problem proof was intentionally designed to have the
>> pathological self-reference (olcott 2004) error.
>>
>> void P(u32 x)
>> {
>>   u32 Input_Halts = H(x, x);
>>   if (Input_Halts)
>>     HERE: goto HERE;
>> }
>>
>> int main()
>> {
>>   H((u32)P, (u32)P);
>> }
>>
>> P was intentionally defined to do the opposite of whatever H decides on
>> itself as input.
>>
>> It is self-evidently true that every computation that never halts unless
>> its simulation is aborted <is> a non-halting computation even after its
>> simulation has been aborted.
>
> WRONG. See H_Hat. YOU agree that it will halt on its own when run. PERIOD.

We can know with 100% perfect certainty that P would never halt unless H
aborts its simulation of P on the basis of the following x86 execution
trace of P.

Because of this we can know with 100% perfect certainty that H must
abort its simulation of P.

Columns
(1) Machine address of instruction
(2) Machine address of top of stack
(3) Value of top of stack after instruction executed
(4) Machine language bytes
(5) Assembly language text

Begin Halt Decider Simulation at Machine Address:b10
[00000b10][002115d3][002115d7] 55 push ebp
[00000b11][002115d3][002115d7] 8bec mov ebp,esp
[00000b13][002115cf][002015a3] 51 push ecx
[00000b14][002115cf][002015a3] 8b4508 mov eax,[ebp+08]
[00000b17][002115cb][00000b10] 50 push eax
[00000b18][002115cb][00000b10] 8b4d08 mov ecx,[ebp+08]
[00000b1b][002115c7][00000b10] 51 push ecx
[00000b1c][002115c3][00000b21] e81ffeffff call 00000940

[00000b10][0025bffb][0025bfff] 55 push ebp
[00000b11][0025bffb][0025bfff] 8bec mov ebp,esp
[00000b13][0025bff7][0024bfcb] 51 push ecx
[00000b14][0025bff7][0024bfcb] 8b4508 mov eax,[ebp+08]
[00000b17][0025bff3][00000b10] 50 push eax
[00000b18][0025bff3][00000b10] 8b4d08 mov ecx,[ebp+08]
[00000b1b][0025bfef][00000b10] 51 push ecx
[00000b1c][0025bfeb][00000b21] e81ffeffff call 00000940
Infinite Recursion Detected Simulation Stopped

In column 3 of the prior two push instructions we can see that P pushed
its own machine address 0xb10 onto the stack calling H(P,P) at 0x940 in
an infinitely repeating cycle of the first eight x86 instructions of P.

[Richard Damon]

We know that H_Hat DOES halt because YOU Published the following trace,
whch include the trace you omited feom teh above:


On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9...@giganews.com>
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);

> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {

> H_Hat((u32)H_Hat);
> }
>
>
> _H_Hat()
> [00000b98](01) 55 push ebp
> [00000b99](02) 8bec mov ebp,esp
>
[00000b9b](01) 51 push ecx
> [00000b9c](03) 8b4508 mov eax,[ebp+08]
> [00000b9f](01) 50 push eax
> [00000ba0](03) 8b4d08 mov ecx,[ebp+08]
> [00000ba3](01) 51 push ecx
> [00000ba4](05) e88ffdffff call 00000938
> [00000ba9](03) 83c408 add esp,+08
> [00000bac](03) 8945fc mov [ebp-04],eax
> [00000baf](04) 837dfc00 cmp dword [ebp-04],+00
> [00000bb3](02) 7402 jz 00000bb7
> [00000bb5](02) ebfe jmp 00000bb5
> [00000bb7](02) 8be5 mov esp,ebp
> [00000bb9](01) 5d pop ebp
> [00000bba](01) c3 ret
> Size in bytes:(0035) [00000bba]
>
> _main()
> [00000bc8](01) 55 push ebp
> [00000bc9](02) 8bec mov ebp,esp
> [00000bcb](05) 68980b0000 push 00000b98
> [00000bd0](05) e8c3ffffff call 00000b98
> [00000bd5](03) 83c404 add esp,+04
> [00000bd8](02) 33c0 xor eax,eax
> [00000bda](01) 5d pop ebp
> [00000bdb](01) c3 ret
> Size in bytes:(0020) [00000bdb]
>
> ===============================
> ...[00000bc8][001015d4][00000000](01) 55 push ebp
> ...[00000bc9][001015d4][00000000](02) 8bec mov ebp,esp
> ...[00000bcb][001015d0][00000b98](05) 68980b0000 push 00000b98
> ...[00000bd0][001015cc][00000bd5](05) e8c3ffffff call 00000b98
> ...[00000b98][001015c8][001015d4](01) 55 push ebp
> ...[00000b99][001015c8][001015d4](02) 8bec mov ebp,esp
> ...[00000b9b][001015c4][00000000](01) 51 push ecx
> ...[00000b9c][001015c4][00000000](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][001015c0][00000b98](01) 50 push eax
> ...[00000ba0][001015c0][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][001015bc][00000b98](01) 51 push ecx
> ...[00000ba4][001015b8][00000ba9](05) e88ffdffff call 00000938
> Begin Local Halt Decider Simulation at Machine Address:b98
> ...[00000b98][00211674][00211678](01) 55 push ebp
> ...[00000b99][00211674][00211678](02) 8bec mov ebp,esp
> ...[00000b9b][00211670][00201644](01) 51 push ecx
> ...[00000b9c][00211670][00201644](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0021166c][00000b98](01) 50 push eax
> ...[00000ba0][0021166c][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][00211668][00000b98](01) 51 push ecx
> ...[00000ba4][00211664][00000ba9](05) e88ffdffff call 00000938
> ...[00000b98][0025c09c][0025c0a0](01) 55 push ebp
> ...[00000b99][0025c09c][0025c0a0](02) 8bec mov ebp,esp
> ...[00000b9b][0025c098][0024c06c](01) 51 push ecx
> ...[00000b9c][0025c098][0024c06c](03) 8b4508 mov eax,[ebp+08]
> ...[00000b9f][0025c094][00000b98](01) 50 push eax
> ...[00000ba0][0025c094][00000b98](03) 8b4d08 mov ecx,[ebp+08]
> ...[00000ba3][0025c090][00000b98](01) 51 push ecx
> ...[00000ba4][0025c08c][00000ba9](05) e88ffdffff call 00000938
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

Above decision was from the call the Halts inside H_Hat, deciding that
H_Hat(H_Hat) seems to be non-halting, it then returns that answer and is
processed below:

> ...[00000ba9][001015c4][00000000](03) 83c408 add esp,+08
> ...[00000bac][001015c4][00000000](03) 8945fc mov [ebp-04],eax
> ...[00000baf][001015c4][00000000](04) 837dfc00 cmp dword [ebp-04],+00
> ...[00000bb3][001015c4][00000000](02) 7402 jz 00000bb7
> ...[00000bb7][001015c8][001015d4](02) 8be5 mov esp,ebp
> ...[00000bb9][001015cc][00000bd5](01) 5d pop ebp
> ...[00000bba][001015d0][00000b98](01) c3 ret
> ...[00000bd5][001015d4][00000000](03) 83c404 add esp,+04
> ...[00000bd8][001015d4][00000000](02) 33c0 xor eax,eax
> ...[00000bda][001015d8][00100000](01) 5d pop ebp
> ...[00000bdb][001015dc][00000098](01) c3 ret

SEE IT HALTED!

> Number_of_User_Instructions(39)
> Number of Instructions Executed(26567)

[olcott]

Don't be a damned liar, stay on the freaking topic. The topic is:

-We can know with 100% perfect certainty that P would never
-halt unless H aborts its simulation of P on the basis of
-the following x86 execution trace of P.

-Because of this we can know with 100% perfect certainty that
-H must abort its simulation of P.

[Richard Damon]

Whose the liar. Your P is just H_Hat by another name, so the trace fits.

You mind is kaput.

Also, by YOUR trace, Halts is not a decider because it was called to
decide P and the trace shows it never returned (or was edited out).

[olcott]

More dishonest dodges. The only way to seem like a valid rebuttal is
being presented is to make sure to change the subject every time that I
correctly prove my point.

The only point is whether or not H must abort its simulation of P.
The only point is whether or not H must abort its simulation of P.
The only point is whether or not H must abort its simulation of P.
The only point is whether or not H must abort its simulation of P.

It is 100% completely certain that H must Abort its simulation of P
It is 100% completely certain that H must Abort its simulation of P
It is 100% completely certain that H must Abort its simulation of P
It is 100% completely certain that H must Abort its simulation of P

[Richard Damon]

But that is the WRONG question to answer. We don't CARE what H has to do
to get its answer, it is just supposed to get the right answer.

H is supposed to answer the question of "Will P(I) Halt when it is run?"

If you want to answer questions about black cat with data gathered from
white dogs, thats your mistake.

[olcott]

If you endlessly want to disagree with whatever I say then it is the
wrong question because disagreeing with that looks far too foolish.

None-the-less understanding the truth of the answer to that question is
a mandatory prerequisite to understanding the rest of my proof.

If you really hate for me to be right and continue to dishonestly change
the subject I will call you out for the liar that you are.

[dklei...@gmail.com]

On Saturday, June 12, 2021 at 12:59:19 PM UTC-7, Richard Damon wrote:

> We know that H_Hat DOES halt because YOU Published the following trace,
> whch include the trace you omited feom teh above:

We know that H_Hat does halt because it is defined as a simple modification
of H which halts.

I see no reason for even looking at PO's nonsense.

[Richard Damon]

What is the problem you are claiming to be trying to solve?

What is the question of that problem?

If the answer to these are NOT the classical halting problem, with the
question being can you build a machine that can decide if the machine
P(I) will halt when run, then why do you say it has anything to do with
the theorems that talk about that problem.

You can't talk about showing the is an answer to a problem if you aren't
answering the question the problem is asking.

Someone ask you to make a machine to detect if a cat is black, and you
give them a machine that sees if Dogs are white. Really Useful and shows
how smart you are. (NOT)

You have paraded you ignorance of basic principles, shown that you have
perhaps negative understanding of the field, and you expect people to
just accept that you have a cockamamie solution that no one else has
seen to a problem that you can't even specify right.

As I have said, write your paper and submit it and get LAUGHED at.

[olcott]

How can {not halting} be correctly** defined such that the conventional
proofs that halting is undecidable cease to form their conclusion.

** computationally equivalent to the standard definition

[Ben Bacarisse]

"dklei...@gmail.com" <dklei...@gmail.com> writes:

> On Saturday, June 12, 2021 at 12:59:19 PM UTC-7, Richard Damon wrote:
>
>> We know that H_Hat DOES halt because YOU Published the following trace,
>> whch include the trace you omited feom teh above:
>
> We know that H_Hat does halt because it is defined as a simple modification
> of H which halts.

H halts on all inputs, but the simple modification that yields H_Hat
makes H_Hat /not/ halt on some inputs.

H_Hat(H_Hat) halts because H(H_Hat, H_Hat) says it does not.

> I see no reason for even looking at PO's nonsense.

I think it's worth looking at it long enough to know why it's nonsense.

--
Ben.

[olcott]

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

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

(1) Anyone that knows the x86 language well enough can know for sure
that simulating partial halt decider H must abort its simulation of P.

(2) Anyone that knows the theory of computation well enough knows that
any computation that never halts unless its simulation is aborted is a
non-halting computation.

(3) Putting (1) and (2) together proves that H stops its simulation of P
and correctly reports that P does not halt.

Begin Local Halt Decider Simulation at Machine Address:b10
...[00000b10][002115d3][002115d7](01) 55 push ebp
...[00000b11][002115d3][002115d7](02) 8bec mov ebp,esp
...[00000b13][002115cf][002015a3](01) 51 push ecx
...[00000b14][002115cf][002015a3](03) 8b4508 mov eax,[ebp+08]
...[00000b17][002115cb][00000b10](01) 50 push eax
...[00000b18][002115cb][00000b10](03) 8b4d08 mov ecx,[ebp+08]
...[00000b1b][002115c7][00000b10](01) 51 push ecx
...[00000b1c][002115c3][00000b21](05) e81ffeffff call 00000940

...[00000b10][0025bffb][0025bfff](01) 55 push ebp
...[00000b11][0025bffb][0025bfff](02) 8bec mov ebp,esp
...[00000b13][0025bff7][0024bfcb](01) 51 push ecx
...[00000b14][0025bff7][0024bfcb](03) 8b4508 mov eax,[ebp+08]
...[00000b17][0025bff3][00000b10](01) 50 push eax
...[00000b18][0025bff3][00000b10](03) 8b4d08 mov ecx,[ebp+08]
...[00000b1b][0025bfef][00000b10](01) 51 push ecx
...[00000b1c][0025bfeb][00000b21](05) e81ffeffff call 00000940

Local Halt Decider: Infinite Recursion Detected Simulation Stopped

In column 3 of the prior two push instructions we can see that P pushed

its own machine address 0xb10 onto the stack thus calling H(P,P) at

0x940 in an infinitely repeating cycle of the first eight x86
instructions of P.

[Richard Damon]

On 6/12/21 9:01 PM, olcott wrote:

> How can {not halting} be correctly** defined such that the conventional
> proofs that halting is undecidable cease to form their conclusion.
>
> ** computationally equivalent to the standard definition
>

THAT'S YOUR PROBLEM.

It really can't be done.

You have set before yourself the impossible task of trying to make
something that is impossible possible.

It is an actual fact that there are some problems which can not have
their answers proven. You can't just define that issue away.

The only thing that can be done is to add a limit to your system so tha
tou can't talk about the things that can't be proven, but that doesn't
really get around the problem, they are still unprovable, you just
define those problem to be outside your logic system.

The incompleteness proof show that at a minimum, you need to restrict
yourself so you can't express all the properties of the Natural Numbers.

I beleive it is also shown that you need to restrict your logic to only
using 1st order logic, and no higher order logic (which pretty much says
you can't express all the properties of the Natural Numbers).

[olcott]

On 6/12/2021 8:48 PM, Richard Damon wrote:
> On 6/12/21 9:01 PM, olcott wrote:
>
>> How can {not halting} be correctly** defined such that the conventional
>> proofs that halting is undecidable cease to form their conclusion.
>>
>> ** computationally equivalent to the standard definition
>>
>
> THAT'S YOUR PROBLEM.
>
> It really can't be done.

You are either too dumb, stubborn or dishonest to see this.

[R Kym Horsell]

It's kind of a cliche that un untalented student with big ambitions hasnt
"overturned" fundamental theories without appearing to have ever read
anything about them. If you've in comsci acedemia you've seen it every
couple of years your whole working life. :)

From the surface it seems the poster in question fits the mold.
The kreeping denial -- as they find out how fundamental their claimed
"discovery" is the further they have to push their ring of radical revisions --
is also a hallmark of something not really needing any time to assess.

There's a right way and a wrong way to overturn previous "proofs".

You *dont* do it by claiming you're a genius and the real value of pi
is not the irrational value we all know and love but some simple rational
number buried in a page of supplied self-contradicting prose.
But you *may* say something like on a quantum scale the ratio of the
diametre and circumfernece of a circle is something quite different from 3.1314....
If somone has "proved" the degree of parallelism extractable from
a piece of computer code is limited by the fraction of time spent
synchronizing you *dont* refute it by saying the other guy was a dummy
and their thorem is obviously false. You *can* say the limit imposed by
their theorem is simply an opportunity to establish a lower bound on
the size of a problem that parallelism can benefit.

Unfortunately OP comes across as a naive student of the kind that
insists pi is 4 because the length of the curve in a quarter-turn
of a unit circle is 1 by their simple and obvious proof that is
available for a small rental fee.

--
How Did The Universe Expand To 46 Billion Light-Years In Just 13.8
Billion Years?
www.forbes.com, 26 Feb 2019
In reality, if you were to look at the most distant thing of all you can
possibly see, and ask "how far away is it," the answer is much farther than
that: ...

[olcott]

Dishonest scumbags that refuse to pay attention can fool the gullible
into believing that they provided a rebuttal.

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

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

(1) Anyone that knows the x86 language well enough can know for sure
that simulating partial halt decider H must abort its simulation of P.

(2) Anyone that knows the theory of computation well enough knows that
any computation that never halts unless its simulation is aborted is a
non-halting computation.

(3) Putting (1) and (2) together proves that H stops its simulation of P
and correctly reports that P does not halt.

Begin Local Halt Decider Simulation at Machine Address:b10
...[00000b10][002115d3][002115d7](01) 55 push ebp
...[00000b11][002115d3][002115d7](02) 8bec mov ebp,esp
...[00000b13][002115cf][002015a3](01) 51 push ecx
...[00000b14][002115cf][002015a3](03) 8b4508 mov eax,[ebp+08]
...[00000b17][002115cb][00000b10](01) 50 push eax
...[00000b18][002115cb][00000b10](03) 8b4d08 mov ecx,[ebp+08]
...[00000b1b][002115c7][00000b10](01) 51 push ecx
...[00000b1c][002115c3][00000b21](05) e81ffeffff call 00000940

...[00000b10][0025bffb][0025bfff](01) 55 push ebp
...[00000b11][0025bffb][0025bfff](02) 8bec mov ebp,esp
...[00000b13][0025bff7][0024bfcb](01) 51 push ecx
...[00000b14][0025bff7][0024bfcb](03) 8b4508 mov eax,[ebp+08]
...[00000b17][0025bff3][00000b10](01) 50 push eax
...[00000b18][0025bff3][00000b10](03) 8b4d08 mov ecx,[ebp+08]
...[00000b1b][0025bfef][00000b10](01) 51 push ecx
...[00000b1c][0025bfeb][00000b21](05) e81ffeffff call 00000940

Local Halt Decider: Infinite Recursion Detected Simulation Stopped

In column 3 of the prior two push instructions we can see that P pushed

its own machine address 0xb10 onto the stack thus calling H(P,P) at

0x940 in an infinitely repeating cycle of the first eight x86
instructions of P.

[olcott]

Dishonest scumbags that refuse to pay attention can fool the gullible
into believing that they provided a rebuttal.

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

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

(1) Anyone that knows the x86 language well enough can know for sure
that simulating partial halt decider H must abort its simulation of P.

(2) Anyone that knows the theory of computation well enough knows that
any computation that never halts unless its simulation is aborted is a
non-halting computation.

(3) Putting (1) and (2) together proves that H stops its simulation of P
and correctly reports that P does not halt.

Begin Local Halt Decider Simulation at Machine Address:b10
...[00000b10][002115d3][002115d7](01) 55 push ebp
...[00000b11][002115d3][002115d7](02) 8bec mov ebp,esp
...[00000b13][002115cf][002015a3](01) 51 push ecx
...[00000b14][002115cf][002015a3](03) 8b4508 mov eax,[ebp+08]
...[00000b17][002115cb][00000b10](01) 50 push eax
...[00000b18][002115cb][00000b10](03) 8b4d08 mov ecx,[ebp+08]
...[00000b1b][002115c7][00000b10](01) 51 push ecx
...[00000b1c][002115c3][00000b21](05) e81ffeffff call 00000940

...[00000b10][0025bffb][0025bfff](01) 55 push ebp
...[00000b11][0025bffb][0025bfff](02) 8bec mov ebp,esp
...[00000b13][0025bff7][0024bfcb](01) 51 push ecx
...[00000b14][0025bff7][0024bfcb](03) 8b4508 mov eax,[ebp+08]
...[00000b17][0025bff3][00000b10](01) 50 push eax
...[00000b18][0025bff3][00000b10](03) 8b4d08 mov ecx,[ebp+08]
...[00000b1b][0025bfef][00000b10](01) 51 push ecx
...[00000b1c][0025bfeb][00000b21](05) e81ffeffff call 00000940

Local Halt Decider: Infinite Recursion Detected Simulation Stopped

In column 3 of the prior two push instructions we can see that P pushed

its own machine address 0xb10 onto the stack thus calling H(P,P) at

0x940 in an infinitely repeating cycle of the first eight x86
instructions of P.

[Richard Damon]

On 6/12/21 9:50 PM, olcott wrote:
> On 6/12/2021 8:48 PM, Richard Damon wrote:
>> On 6/12/21 9:01 PM, olcott wrote:
>>
>>> How can {not halting} be correctly** defined such that the conventional
>>> proofs that halting is undecidable cease to form their conclusion.
>>>
>>> ** computationally equivalent to the standard definition
>>>
>>
>> THAT'S YOUR PROBLEM.
>>
>> It really can't be done.
> You are either too dumb, stubborn or dishonest to see this.
>

Why are you asking me then to do what you have been trying to do?

That sounds totally stupid.

There IS a definition of Halting established by theory.

It is a FACT, that there are Machines/Input combinations that it is
IMPOSSIBLE to prove by any Turing Machine whether they will Halt or Not.

You want to make that machine which is impossible to do. You can't do
the impossible by just changing wording to something that means the same
thing, and you can't change the meaning to be something different and
have your machine apply to the problem.

Who is the one being too dumb, stubborn and dishonest?


You have admitted that you haven't done any real formal training in this
field, and it shows as you make the classicial errors off a century ago,
if you fail to learn from history you WILL repeat the mistakes.

You insist that things are 'obvious' from basic definitions, but refuse
to look at the REAL definitions and claim that they are just stuck thoughts.

You seem to have NO idea WHY any of this theory was developed, but seem
to assume that the whole thing was just created to be a perverse problem
for someone to try and solve.

You don't seem to have any REAL understanding of how to lay out a real
formal proof. I don't think I have seen you take two generally accepted
facts and put them together to make a new idea that advances your
arguement. All you seem to do is try to rearange words to try to say
something that sounds plausable and then claim it to be an obvious
truth. That isn't how proofs in mathematics work.

Maybe it is how some branches of Philosophy work, where they argue about
how one should do logic, but that isn't where Mathematics lives.
Mathemtics starts from some very formal rules that define things. Things
HAVE a firm definition. Yes, sometimes in the creation of a new branch
they need to play around a bit to find a set of definitions that work,
like what does infinity actually mean, and sometimes you get multiple
branches with different definitions.

Very occationally someone finds a problem with how things are working,
like the Russel Paradox that found an inconsistency is Set Theory, so
the great minds had to find what definition of operations allowed the
creation of the paradoxical set of the set of sets that don't contain
themselves, which must both contain itself and not.

I suppose if you really understood the theory, you could set yourself
out to try and find some similar paradox in computation theory, but my
first guess from what I know, you don't have the knoledge to do that,
this is NOT a 'first principles' sort of task, and the theory has
matured enough that it would be a BIG longshot to find such a hole.

Another option might be to discover a new method of computation that was
more powerful than Turing Machines, able to do everything that a Turing
Machine can do, but also do in finite time what a Turing Machine can't.
This also would likely require skills that you don't seem to have.

[olcott]

On 6/12/2021 9:39 PM, Richard Damon wrote:
> On 6/12/21 9:50 PM, olcott wrote:
>> On 6/12/2021 8:48 PM, Richard Damon wrote:
>>> On 6/12/21 9:01 PM, olcott wrote:
>>>
>>>> How can {not halting} be correctly** defined such that the conventional
>>>> proofs that halting is undecidable cease to form their conclusion.
>>>>
>>>> ** computationally equivalent to the standard definition
>>>>
>>>
>>> THAT'S YOUR PROBLEM.
>>>
>>> It really can't be done.
>> You are either too dumb, stubborn or dishonest to see this.
>>
>
> Why are you asking me then to do what you have been trying to do?

Dishonest scumbags that refuse to pay attention can fool the gullible
into believing that they provided a rebuttal.

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

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

(1) Anyone that knows the x86 language well enough can know for sure
that simulating partial halt decider H must abort its simulation of P.

(2) Anyone that knows the theory of computation well enough knows that
any computation that never halts unless its simulation is aborted is a
non-halting computation.

(3) Putting (1) and (2) together proves that H stops its simulation of P
and correctly reports that P does not halt.

Begin Local Halt Decider Simulation at Machine Address:b10
...[00000b10][002115d3][002115d7](01) 55 push ebp
...[00000b11][002115d3][002115d7](02) 8bec mov ebp,esp
...[00000b13][002115cf][002015a3](01) 51 push ecx
...[00000b14][002115cf][002015a3](03) 8b4508 mov eax,[ebp+08]
...[00000b17][002115cb][00000b10](01) 50 push eax
...[00000b18][002115cb][00000b10](03) 8b4d08 mov ecx,[ebp+08]
...[00000b1b][002115c7][00000b10](01) 51 push ecx
...[00000b1c][002115c3][00000b21](05) e81ffeffff call 00000940

...[00000b10][0025bffb][0025bfff](01) 55 push ebp
...[00000b11][0025bffb][0025bfff](02) 8bec mov ebp,esp
...[00000b13][0025bff7][0024bfcb](01) 51 push ecx
...[00000b14][0025bff7][0024bfcb](03) 8b4508 mov eax,[ebp+08]
...[00000b17][0025bff3][00000b10](01) 50 push eax
...[00000b18][0025bff3][00000b10](03) 8b4d08 mov ecx,[ebp+08]
...[00000b1b][0025bfef][00000b10](01) 51 push ecx
...[00000b1c][0025bfeb][00000b21](05) e81ffeffff call 00000940

Local Halt Decider: Infinite Recursion Detected Simulation Stopped

In column 3 of the prior two push instructions we can see that P pushed

its own machine address 0xb10 onto the stack thus calling H(P,P) at

[Richard Damon]

Who is being dishonest here? You have previously posted a longer trace
of this machine showing that it DOES halt, by including the trace from
the decider returning its answer (which it must do to be a decider)

Note, that message is from the embedded copy of Halts terminating its
copy of the description of the machine, and it will then return the answer.

On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9...@giganews.com>
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);

> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {

> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

[olcott]

You are.

The above proves beyond all possible doubt that H decides P correctly.
The above proves beyond all possible doubt that H decides P correctly.
The above proves beyond all possible doubt that H decides P correctly.

You can ignore this or change the subject, yet cannot refute this.
You can ignore this or change the subject, yet cannot refute this.
You can ignore this or change the subject, yet cannot refute this.

[Richard Damon]

HOW? What did I say that wasn't TRUE?

YOU are the one that Trims out relevent pieces of the conversation.

YOU are the one making wild claims without any real proof.

> The above proves beyond all possible doubt that H decides P correctly.
> The above proves beyond all possible doubt that H decides P correctly.
> The above proves beyond all possible doubt that H decides P correctly.
>
> You can ignore this or change the subject, yet cannot refute this.
> You can ignore this or change the subject, yet cannot refute this.
> You can ignore this or change the subject, yet cannot refute this.
>
>

No, it doesn't, and I can.

If that WAS the complete trace of this program, then it shows that H
rather than returning an answer just abort the whole program and halt,
thus is NOT a decider and didn't (and thus can't) return the answer
according to the requirements.

The actual complete trace which you dishonestly trimmed (and included
again below) shows that after this point, H (then called Halts) actually
returned the answer to H_Hat (which you now call P). and that it then
stopped on its own showing that it halts.

The P IS proved to be a halting computation, and thus as long as you are
honest that this decision is about the halting problem, H got the answer
wrong.

If you actually are intending H to just be answering this strange thing
that we should call Olcott-Halting, then maybe it is right, but then you
are being dishonest about what it is supposed to be answering.

On 4/27/21 12:55 AM, olcott wrote:
Message-ID: <Teudndbu59GVBBr9...@giganews.com>
> void H_Hat(u32 P)
> {
> u32 Input_Halts = Halts(P, P);

> if (Input_Halts)
> HERE: goto HERE;
> }
>
>
> int main()
> {

> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

[Richard Damon]

On 6/12/21 10:36 PM, olcott wrote:
>>
>
> Dishonest scumbags that refuse to pay attention can fool the gullible
> into believing that they provided a rebuttal.

Yes, you do that don't you. Fortunately there are too many gullible
people here.

[olcott]

∴ The fact that P halted does not contradict the above because the above
is impossibly false.

The fact that P halted can be explained in a way that does not
contradict the above only after enough attention is pay to fully
comprehend that the above is impossibly false.

If you want to continue to be a lying bastard that refuses to pay
attention I will continue to call you out on this.

[Richard Damon]

It doesn't need jack shit about x86, but I will admit that it is
possible to logically conclude that if a simulating decider sees a
recursive simulation of itself, under these conditions, it is possible
to conclude that if 'I' don't abort the simulation, 'I' will be
non-Halting, so for some values of 'need' I need to abort the simulation.

>
> (2) Anyone that knows the theory of computation well enough knows that
> any computation that never halts unless its simulation is aborted is a
> non-halting computation.

But this is a different 'need' and a different 'must halt', and the
recursion makes this difference important.

The first case is the algorithm must contain such code at SOME level of
its operation or it will find ITSELF stuck.

The second case is that simulation must do the abort at THIS level of
operation or it becomes non-halting because its input is.

>
> (3) Putting (1) and (2) together proves that H stops its simulation of P
> and correctly reports that P does not halt.
>

But since the two statements use slightly different meanings to the
words, this doesn't follow. (2) requires that the need be specifically
at this exact simulation. (1) just asserts that it needs to be done at
SOME level of simulation.

> ∴ The fact that P halted does not contradict the above because the above
> is impossibly false.
>
> The fact that P halted can be explained in a way that does not
> contradict the above only after enough attention is pay to fully
> comprehend that the above is impossibly false.

How? I would like to see you try to come up with words that make the
fact that when we actually run this machine and not just halt decide it,
it comes to a halt on its own. Note, the DEFINITION of Halting is
exactly that, so you can't just pass it off as somehow being 'needed'

All that shows is that you have added some definition into the system
that made it inconsistent, like how about how you twisted the definition
is (1) and (2) to make them say something they do not say?

[olcott]

Any human that knows the x86 language well enough can see the complete
certainty that H must abort P.

That is great. So talking with you is proving to be worthwhile.
This is out second big breakthrough.

>> (2) Anyone that knows the theory of computation well enough knows that
>> any computation that never halts unless its simulation is aborted is a
>> non-halting computation.
>
> But this is a different 'need' and a different 'must halt', and the
> recursion makes this difference important.
>
> The first case is the algorithm must contain such code at SOME level of
> its operation or it will find ITSELF stuck.
>
> The second case is that simulation must do the abort at THIS level of
> operation or it becomes non-halting because its input is.

I can't quite see what you are saying.

>>
>> (3) Putting (1) and (2) together proves that H stops its simulation of P
>> and correctly reports that P does not halt.
>>
>
> But since the two statements use slightly different meanings to the
> words, this doesn't follow. (2) requires that the need be specifically
> at this exact simulation. (1) just asserts that it needs to be done at
> SOME level of simulation.
>

{This} level of simulation <is> {some} level of simulation.

>> ∴ The fact that P halted does not contradict the above because the above
>> is impossibly false.
>>
>> The fact that P halted can be explained in a way that does not
>> contradict the above only after enough attention is pay to fully
>> comprehend that the above is impossibly false.
>
> How? I would like to see you try to come up with words that make the
> fact that when we actually run this machine and not just halt decide it,
> it comes to a halt on its own. Note, the DEFINITION of Halting is
> exactly that, so you can't just pass it off as somehow being 'needed'
>

The definition of halting has been adapted to become the computationally
equivalent definition of (2).

> All that shows is that you have added some definition into the system
> that made it inconsistent, like how about how you twisted the definition
> is (1) and (2) to make them say something they do not say?
>

Once you fully understand that H(P,P)==0 is definitely correct then the
fact that P(P) halts does not contradict this certainty.

I explain this on page three:

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


A cat is definitely not a dog. If the cat barks and the cat only has cat
DNA then we still know that it is definitely a cat even if it barks.

>>
>> If you want to continue to be a lying bastard that refuses to pay
>> attention I will continue to call you out on this.
>>
>

[Richard Damon]

WRONG. Need to at this is not the same as need to at some. 'this' is
nore specific then 'some'

Ypu have the meanings of the words wrong.

Simple example, 'This cat is black' means something different than 'Some
cat is black'.

The language needed for Mathematics is more precise that. I suppose this
goes against your false principle that all Truths can be encoded into
the Semantic Meaning of words, but it is true.

>
>>> ∴ The fact that P halted does not contradict the above because the above
>>> is impossibly false.
>>>
>>> The fact that P halted can be explained in a way that does not
>>> contradict the above only after enough attention is pay to fully
>>> comprehend that the above is impossibly false.
>>
>> How? I would like to see you try to come up with words that make the
>> fact that when we actually run this machine and not just halt decide it,
>> it comes to a halt on its own. Note, the DEFINITION of Halting is
>> exactly that, so you can't just pass it off as somehow being 'needed'
>>
>
> The definition of halting has been adapted to become the computationally
> equivalent definition of (2).

But by that definition, H did not NEED to abort P because P will halt on
its own. It is NOT true that THIS copy of H aborts the simulation of P
to remain halting, just that SOME copy of H needs to abort the
simulation, and since the next one will this one doesn't, even though it
will.

Get your meaning straight.

>
>> All that shows is that you have added some definition into the system
>> that made it inconsistent, like how about how you twisted the definition
>> is (1) and (2) to make them say something they do not say?
>>
>
> Once you fully understand that H(P,P)==0 is definitely correct then the
> fact that P(P) halts does not contradict this certainty.

But H(P,P) == 1 is also definitely correct, as it can be shown that P(P)
when run will halt, and that is the fundamental definition.

What this actually DOES prove is that your logic system is now
inconsistent, and thus logically worthless until fixed.

You have just run into your own version of the set of all sets that
don't contain themselves that made set theory rework what it could do.

Note, this inconsistency only happens when you include your strange
definition of halting, so the rest of the Theory that doesn't use it is
fine.

>
> I explain this on page three:
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
> A cat is definitely not a dog. If the cat barks and the cat only has cat
> DNA then we still know that it is definitely a cat even if it barks.

And the DNA of Halting is that a machine that Halts is Halts. THAT is
the fundamental.

[olcott]

So in other words you are saying that level 3 of the set of simulation
levels from 1...n is not the third element of this ordered set?

[Richard Damon]

No, I am saying that statement (2) says the abort must be at simulation
level 1 for the computation to be non-halting. An abort at any other
level does NOT imply that the computation is non-halting.

It must be at THIS level, level 1.

Statement (1) just says that at SOME level, it could be 1, it could be
20, some copy needs to decide to stop simulating, and then the chain can
collapse into finite execution. Thus the requirements are different.

Statement (1) is also about algorithmic design, being somewhat based on
Fatalism. Statement (2) is about the instance of execution, it is about
choice. Statement (2) allows us to ask what happens if we change THIS
INSTANCE of the machine to be different, does that results still happen.

Otherwise it can be shown that your halt decider is non-halting and thus
not a decider, by having a halt decider decide on your halt decider
deciding on an infinite loop of some sort.

If the outer Halt decider can say that because at SOME level of
simulation, the simulation must be aborted, thus the decider is
correctly decided as non-halting in its decision on the non-halting machine.

[olcott]

It does not say that and it does not mean that.

If the simulation of a computation must be aborted at any level
of simulation from 1...n to prevent the infinite execution of this
simulated input then the input is a non-halting computation.

This is just like an infinitely recursive chain of invocations, when any
invocation from from 1...n is aborted the whole infinitely recursive
chain stops. Every element in the whole chain must be considered an
aspect of this infinitely recursive chain.

[Richard Damon]

Yes it does mean that. That definition comes straight out of the
definition of Halting and the actions of UTMs.

> If the simulation of a computation must be aborted at any level
> of simulation from 1...n to prevent the infinite execution of this
> simulated input then the input is a non-halting computation.
>

Nope. Can you find any actually scholarly source that supports your
claim, using words like that, please cite it. (YOUR OWN 'PUBLICATIONS'
DON'T COUNT). I think you will find that there isn't any.

> This is just like an infinitely recursive chain of invocations, when any
> invocation from from 1...n is aborted the whole infinitely recursive
> chain stops. Every element in the whole chain must be considered an
> aspect of this infinitely recursive chain.
>

Right, IF the chain is ACTUALLY infinitely recursive, all the parts in
the recursion are infinitely recursive. If the chain is NOT actually
infinitely recursive because some piece can break the chain then the
chian ISN'T infinitely recursive.

So a decider that is outside the chain, if it can determine that nothing
in the chain can break the recursion, then it can call the chain
non-halting. BUT, if the decider is part of the chain, then the fact
that it can decider to break the chain, means something in the chain can
break the chain, so the chain isn't ACTUALLY infinitely recursive.

You keep on wanting to add words like, and is so even after the
simulation is aborted, which you won't find elsewhere. The aborting
doesn't change the halting status of the copy of the computation whose
simulation was aborted, but does to the computation that was doing the
simulation.

[olcott]

The question is: Will the simulation of H(P,P) ever end if H never
aborts its simulation of its input?

If the answer is no, then when H aborts its simulation of its input and
decides that its input does not halt H is necessarily correct.

[Richard Damon]

For Question (2) to give you an ansswer about Halting, it must be asking
if THIS INSTANCE of H didn't terminate the simulation.

And the answer to that is Yes, if you change THAT H to not abort, then
the P(P) that it is simulating will finish as you have shown.

Otherwise, you are saying that H(<InfintiteLoop>) is a non-Halting
computation, and thus H isn't proper decider as if we run
H(<H(InfiniteLoop)>) then the outer H is required to decide that this
computation only terminates if H doesn't abort its simulation, and is
thus non-Halting

You can't use this rule just some time, if it applies, it ALWAYS
applies, and because of that, it is possible to show that any simulating
halt decider is non-halting when deciding any non-halting machine.

[olcott]

No, not at all this is not the way it works.

[Richard Damon]

I say it does, so does the definitions in the Theory. Do YOU have any
reference that says otherwise, or is this just something you are making
up for yourself.

As I have asked a couple of times, if you are so sure is works the way
you say, find someone else who says that it works that way.

Definitions are what the general community define them to be, not what
one individual thinks they should be to match their ideas.

Halting is a long standing property of Turing Machines, and has
basically been defined the same way since they were invented, and match
the previous definition of something being computable which preceeded them.

Yes, maybe you can define this Olcott-Halting so that one proof of
undecidability doesn't work for it, but what good is Olcott-Halting? Are
there any real problems that want to know if something is
Olcott-Halting? Are you actually claiming that Olcott-Halting IS
decidable, or are you satisifed with just one of the types of proof
being defeated for it but it still being undecidable? (which actually
means you gained nothing out of it).

[Malcolm McLean]

It's easier to talk of Olcott non-halting. A machine / subroutine is Olcott
non-halting, if it would have run forever unless terminated by a simulating
decider.
We can see that one of the properties of Olcott non-halting is that the
paradox proof doesn't apply to it, as long was we define "simulating decider"
in such a way that the machine under test can itself be the simulating
decider.

Now that doesn't refute the "paradox" proof, because we've changed the
question. But the real issue is not whether we've refuted a proof or not,
but whether we've done something interesting.

Now one feature of Olcott halting is that the Olcott decider needs a conventional
decider built in. PO uses roughly the following argument -
The paradox proofs do not apply to an Olcott halt decider
The Olcott halt decider contains a conventional halt decider
Therefore the paradox proofs do not apply to a conventional decider.

I'll leave it to PO to go further, to avoid putting words into his mouth.

[Ben Bacarisse]

Malcolm McLean <malcolm.ar...@gmail.com> writes:

> It's easier to talk of Olcott non-halting. A machine / subroutine is Olcott
> non-halting, if it would have run forever unless terminated by a simulating
> decider.

My name, the "silly non-halting problem", didn't catch on.

> We can see that one of the properties of Olcott non-halting is that the
> paradox proof doesn't apply to it, as long was we define "simulating decider"
> in such a way that the machine under test can itself be the simulating
> decider.

What you call the paradox proof does not apply because the question is
no longer about halting. If you mean there is no possible "paradox
proof" that silly non-halting is undecidable then I disagree. In as
much as PO has even specified it, there is a simple proof that it is
undecidable.

But every time this comes up, PO retracts the general statement and
claims only to be address one case -- one single case in the wrong
"paradoxical proof". Discussing the pattern that applies to halting
when talking about anther decision problem is just silly, but that's
about the size of it.

> Now that doesn't refute the "paradox" proof, because we've changed the
> question. But the real issue is not whether we've refuted a proof or not,
> but whether we've done something interesting.

Partial deciders are ten-a-penny (especially simulating ones), and the
total decider that PO once claimed to have is impossible:

"The non-halting decider that I defined accepts any and all
non-halting inputs and rejects any and all halting inputs."

Do /you/ think there is anything interesting in the vast pile
of... stuff that's been posted by PO about halting?

> Now one feature of Olcott halting is that the Olcott decider needs a
> conventional decider built in.

He wisely retracts the general claim every time this is brought up.

--
Ben.

[olcott]

non-halting computation: (UTM(P,I) = ∞) ≡ (P,I) = ∞)

> We can see that one of the properties of Olcott non-halting is that the
> paradox proof doesn't apply to it, as long was we define "simulating decider"
> in such a way that the machine under test can itself be the simulating
> decider.
>

P invokes H(P,P) or contains Linz Ĥ(⟨Ĥ⟩) a simulating decider.

> Now that doesn't refute the "paradox" proof, because we've changed the
> question. But the real issue is not whether we've refuted a proof or not,
> but whether we've done something interesting.
>

Since this is known to be true: (UTM(P,I) = ∞) ≡ (P,I) = ∞)
we can know that we have not changed the question.

> Now one feature of Olcott halting is that the Olcott decider needs a conventional
> decider built in. PO uses roughly the following argument -

My solution only applies to simulating halt deciders.
Since the conventional deciders never propose examining the execution
trace of the simulation of their input it seems that there are no
conventional deciders involved.

> The paradox proofs do not apply to an Olcott halt decider
> The Olcott halt decider contains a conventional halt decider
> Therefore the paradox proofs do not apply to a conventional decider.
>
> I'll leave it to PO to go further, to avoid putting words into his mouth.
>

Your paraphrase is not quite correct yet still pretty good.

[olcott]

On 6/14/2021 9:19 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
>> It's easier to talk of Olcott non-halting. A machine / subroutine is Olcott
>> non-halting, if it would have run forever unless terminated by a simulating
>> decider.
>
> My name, the "silly non-halting problem", didn't catch on.
>

(2) Anyone that knows the theory of computation well enough knows that
any computation that never halts unless its simulation is aborted is a

conventional non-halting computation: (UTM(P,I) = ∞) ≡ (P,I) = ∞)

[olcott]

You are wrong.

[Richard Damon]

On 6/14/21 10:36 AM, olcott wrote:
> On 6/14/2021 9:19 AM, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> It's easier to talk of Olcott non-halting. A machine / subroutine is
>>> Olcott
>>> non-halting, if it would have run forever unless terminated by a
>>> simulating
>>> decider.
>>
>> My name, the "silly non-halting problem", didn't catch on.
>>
>
> (2) Anyone that knows the theory of computation well enough knows that
> any computation that never halts unless its simulation is aborted is a
> conventional non-halting computation: (UTM(P,I) = ∞) ≡ (P,I) = ∞)
>
>

Right, and UTM(H^,H^) is shown to halt, so H^(H^) is a Halting Computation.

[olcott]

We know with 100% perfect certainty that the input to H(P,P) never halts
without having its simulation aborted.

We know with 100% perfect certainty that when the simulation of an input
on its input never halts without having its simulation aborted this
means that this input is a computation that does not halt.

Because we know these two things with 100% perfect certainty then the
fact that main { P(P); } halts cannot possibly contradict this.

That means that the fact that main { P(P); } halts must have some
non-contradictory explanation.

[Richard Damon]

On 6/14/21 6:59 PM, olcott wrote:
> On 6/14/2021 5:46 PM, Richard Damon wrote:
>> On 6/14/21 10:36 AM, olcott wrote:
>>> On 6/14/2021 9:19 AM, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> It's easier to talk of Olcott non-halting. A machine / subroutine is
>>>>> Olcott
>>>>> non-halting, if it would have run forever unless terminated by a
>>>>> simulating
>>>>> decider.
>>>>
>>>> My name, the "silly non-halting problem", didn't catch on.
>>>>
>>>
>>> (2) Anyone that knows the theory of computation well enough knows that
>>> any computation that never halts unless its simulation is aborted is a
>>> conventional non-halting computation: (UTM(P,I) = ∞) ≡ (P,I) = ∞)
>>>
>>>
>>
>> Right, and UTM(H^,H^) is shown to halt, so H^(H^) is a Halting
>> Computation.
>>
>>
>
> We know with 100% perfect certainty that the input to H(P,P) never halts
> without having its simulation aborted.

YOU say that but are using the wrong definitions.

YOU YOURSELF have admittted and PROVED that H_Hat(H_Hat) will halt when
run, and thus UTM(H^, H^) will halt.

Are you calling yourself a liar?

>
> We know with 100% perfect certainty that when the simulation of an input
> on its input never halts without having its simulation aborted this
> means that this input is a computation that does not halt.

WRONG, at least with your definition.

That statement is ONLY true if you mean that THAT simulator had to abort
ITS simulation or it doesn't stop, not some copy of the simulation must
stop some copy of the input.

This is a MACHINE property, not an algorithm property. Remember, H^ has
its own copy of H when we express things as real Turing Machines, so
that rule applies to the need for the TOP LEVEL H ITSELF to need to
abort its exact input (since that is the only one it has). The fact that
some copy of its algorithm does it doesn't matter.

As I have said, find anyone else with any sort of reputation who makes
this claim of yours. Put up or shut up.

>
> Because we know these two things with 100% perfect certainty then the
> fact that main { P(P); } halts cannot possibly contradict this.

Then in your world 1 == 0, and everything is THAT messed up.

> That means that the fact that main { P(P); } halts must have some
> non-contradictory explanation.
>

Right, P(P) Halts, so the right answer that H(P,P) should return is
Halting, and if it says non-Halting it was wrong, because your claimed
rule is wrong.

[olcott]

On 6/14/2021 7:55 PM, Richard Damon wrote:
> On 6/14/21 6:59 PM, olcott wrote:
>> On 6/14/2021 5:46 PM, Richard Damon wrote:
>>> On 6/14/21 10:36 AM, olcott wrote:
>>>> On 6/14/2021 9:19 AM, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> It's easier to talk of Olcott non-halting. A machine / subroutine is
>>>>>> Olcott
>>>>>> non-halting, if it would have run forever unless terminated by a
>>>>>> simulating
>>>>>> decider.
>>>>>
>>>>> My name, the "silly non-halting problem", didn't catch on.
>>>>>
>>>>
>>>> (2) Anyone that knows the theory of computation well enough knows that
>>>> any computation that never halts unless its simulation is aborted is a
>>>> conventional non-halting computation: (UTM(P,I) = ∞) ≡ (P,I) = ∞)
>>>>
>>>>
>>>
>>> Right, and UTM(H^,H^) is shown to halt, so H^(H^) is a Halting
>>> Computation.
>>>
>>>
>>
>> We know with 100% perfect certainty that the input to H(P,P) never halts
>> without having its simulation aborted.
>
> YOU say that but are using the wrong definitions.
>

It seems that you believe that you can disagree with tautologies and not
look foolish.

The execution trace of P proves beyond all possible doubt that it will
never halt unless forced to halt.

[Richard Damon]

On 6/14/21 9:26 PM, olcott wrote:
> On 6/14/2021 7:55 PM, Richard Damon wrote:
>> On 6/14/21 6:59 PM, olcott wrote:
>>> On 6/14/2021 5:46 PM, Richard Damon wrote:
>>>> On 6/14/21 10:36 AM, olcott wrote:
>>>>> On 6/14/2021 9:19 AM, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>>>> It's easier to talk of Olcott non-halting. A machine / subroutine is
>>>>>>> Olcott
>>>>>>> non-halting, if it would have run forever unless terminated by a
>>>>>>> simulating
>>>>>>> decider.
>>>>>>
>>>>>> My name, the "silly non-halting problem", didn't catch on.
>>>>>>
>>>>>
>>>>> (2) Anyone that knows the theory of computation well enough knows that
>>>>> any computation that never halts unless its simulation is aborted is a
>>>>> conventional non-halting computation: (UTM(P,I) = ∞) ≡ (P,I) = ∞)
>>>>>
>>>>>
>>>>
>>>> Right, and UTM(H^,H^) is shown to halt, so H^(H^) is a Halting
>>>> Computation.
>>>>
>>>>
>>>
>>> We know with 100% perfect certainty that the input to H(P,P) never halts
>>> without having its simulation aborted.
>>
>> YOU say that but are using the wrong definitions.
>>
> It seems that you believe that you can disagree with tautologies and not
> look foolish.

And you beleive that you can make up things you call tautologies and
weem wise, while they actually make you look foolish.

It can't be a tautology if it isn't really true.

>
> The execution trace of P proves beyond all possible doubt that it will
> never halt unless forced to halt.
>

Then why does THIS trace you previously posted show that H_Hat (which
you are now calling P) actually comes to a halt without being forced to
halt?

Note, a COPY of the desciption of H_Hat had its simulation aborted, but
not this H_Hat.

I just deleted you name, does that mean your gone?

[olcott]

This execution trace of H(P,P) proves beyond all possible doubt that the
input to H never halt unless H aborts it.

Begin Local Halt Decider Simulation at Machine Address:af8
[00000af8][0021157e][00211582] 55 push ebp
[00000af9][0021157e][00211582] 8bec mov ebp,esp
[00000afb][0021157a][0020154e] 51 push ecx
[00000afc][0021157a][0020154e] 8b4508 mov eax,[ebp+08]
[00000aff][00211576][00000af8] 50 push eax // P
[00000b00][00211576][00000af8] 8b4d08 mov ecx,[ebp+08]
[00000b03][00211572][00000af8] 51 push ecx // P
[00000b04][0021156e][00000b09] e81ffeffff call 00000928 // H

The above eight instructions of P are repeated here

[00000af8][0025bfa6][0025bfaa] 55 push ebp
[00000af9][0025bfa6][0025bfaa] 8bec mov ebp,esp
[00000afb][0025bfa2][0024bf76] 51 push ecx
[00000afc][0025bfa2][0024bf76] 8b4508 mov eax,[ebp+08]
[00000aff][0025bf9e][00000af8] 50 push eax // P
[00000b00][0025bf9e][00000af8] 8b4d08 mov ecx,[ebp+08]
[00000b03][0025bf9a][00000af8] 51 push ecx // P
[00000b04][0025bf96][00000b09] e81ffeffff call 00000928 // H

Local Halt Decider: Infinite Recursion Detected Simulation Stopped

That you deny these facts makes you look quite foolish.

[Richard Damon]

On 6/14/21 9:50 PM, lying olcott wrote:
> On 6/14/2021 8:44 PM, Richard Damon wrote:

>> On 6/14/21 9:26 PM, lying olcott wrote:
>>> On 6/14/2021 7:55 PM, Richard Damon wrote:

WHY DO YOU KEEP OMITTING THE END???????
Where H returns to P and then P stops.

That show how you LIE when you say it doesn't stop!!!

> Local Halt Decider: Infinite Recursion Detected Simulation Stopped

[olcott]

The above proves that H had to force P to halt.
P ONLY ever stops because at least on P in the infinite
invocation chain was forced to stop.

[Richard Damon]

BUT P STOPS ON ITS OWN, AND THUS IT IS HALTING BY THE DEFINITION.
Remember, the H that did the stopping is part of P.

By your logic, this is an infinite loop:

for(int i=0; isLessThan(i, 5); i++) continue;

since the for loop doesn't stop it, only the decision of isLessThan().

Also, if a different Halt Decider is run on P, then its correct answer
is Halting, since it doesn't need to stop the simulation since the H in
P will do so.

This makes your definition of Halting worthless as it isn't a property
of the machine, but of the decider as well.

[olcott]

No knucklehead that has never been true.

[Malcolm McLean]

No real machine can run forever. If it is a process on a desktop, user will
give it about five minutes before saying "this will never stop" and killing it.
If it is embedded software, it might have a life of many years, but eventually
the device it is embedded in will come to the end of its active period
and will be powered down and scrapped.

So normally "halting / non-halting" applies to the abstract model. And if something
comes in from outside that abstract model, like the power being switched off,
we'd say "the machine was forced to halt".
However you're using the term differently. This is partly why you should have worked
on Turing machines rather than x86 code. If a machine is a simulator, and it
chooses to halt the machine it is simulating rather than let it reach a halt state,
you say "the machine was forced to halt".
There are many problems with this. But the main one is that is isn't very interesting.
Yes, you can say that Linz's proof applies only to halting, not to 'Olcott non-halting'.
But you can't extend that observation to produce any more properties. For instance,
you have to label H as "a simulating decider", you don't have an algorithmic or
even a non-algorithmic way of determining whether a machine is a "simulating
decider" or not. Then the simulating decider needs a conventional decider to determine
whether it needs to halt the test program. so an Olcott-non halting decider is harder
to build than a conventional halt decider. In order to have something interesting,
the Olcott non-halting decider needs to be at least easier to build than a
conventional halt decider.

[Richard Damon]

Then you are calling yourself a liar because you have said so and even
posted the trace that I have reposted that shows that it did.

I guess this just PROVES the truth about you, that there is no truth in
you. You logic is inconsistent and worthless.

[olcott]

When you say that it halts on its own this is never ever true.
I don't think that you are lying about this, you are just
horribly terrible at paying attention. You get a misconception
stuck in your mind that becomes unbreakable.

The execution trace where P was forced to halt is from this computation:
int main() { P(P); }

[olcott]

No one actually works with Turing machines, because of their lack of
direct memory access it ca take a 1000 page program to move a single
piece of data from one tape location to another.

> There are many problems with this. But the main one is that is isn't very interesting.
> Yes, you can say that Linz's proof applies only to halting, not to 'Olcott non-halting'.

This is ordinary non-halting knucklehead:
When UTM(⟨P⟩,I) never halts then we can know that P(I) never halts.

(1) Anyone that knows the x86 language well enough can know for sure
that simulating partial halt decider H must abort its simulation of P.

(see the x86 execution trace of H simulating its input in H(P,P) above).

(2) Anyone that knows the theory of computation well enough knows that
any computation that never halts unless its simulation is aborted is a
conventional non-halting computation:

When UTM(⟨P⟩,I) never halts then we can know that P(I) never halts.

Putting (1) and (2) together proves that H stops its simulation of P and
correctly reports that P does not halt.

I have shown that H(P,P)==0 is impossibly false therefore anything that
seems to show that it contradicts this cannot possibly be an actual
contradiction.

> But you can't extend that observation to produce any more properties. For instance,
> you have to label H as "a simulating decider", you don't have an algorithmic or
> even a non-algorithmic way of determining whether a machine is a "simulating
> decider" or not.

We can know that it is a perfect simulator when we stipulate that it is
a UTM. We can know that it does correctly decide the conventional
halting problem counter-examples by showing their infinitely repeating
pattern on page 6:

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

> Then the simulating decider needs a conventional decider to determine
> whether it needs to halt the test program.

I already explained how this is false. Have you chosen to be an idiot?
Any non-simulating halt decider is limited to static analysis and cannot
examine the execution trace of a simulated program.

> so an Olcott-non halting decider is harder
> to build than a conventional halt decider. In order to have something interesting,
> the Olcott non-halting decider needs to be at least easier to build than a
> conventional halt decider.
>

[Richard Damon]

But they do, but not to try to actually perform the calculation, but to
see if it is possible. The key is that Turing Machines are much easier
to reason about, so if you can write a program to solve a problem on a
Turing Machine, and then actually PROVE that the program is correct, and
maybe even that the program will halt, it tells you a lot about the
problem that you were trying to solve.

Of course, to do that means you need to know how to actually PROVE
something and not just make claims and try it.

>
>> There are many problems with this. But the main one is that is isn't
>> very interesting.
>> Yes, you can say that Linz's proof applies only to halting, not to
>> 'Olcott non-halting'.
>
> This is ordinary non-halting knucklehead:
> When UTM(⟨P⟩,I) never halts then we can know that P(I) never halts.

Then why did the trace of it show that it did? (See end of message)

>
> (1) Anyone that knows the x86 language well enough can know for sure
> that simulating partial halt decider H must abort its simulation of P.
> (see the x86 execution trace of H simulating its input in H(P,P) above).

Except that by that trace, H NEVER anxsered, thus H fails to be a decider.

>
> (2) Anyone that knows the theory of computation well enough knows that
> any computation that never halts unless its simulation is aborted is a
> conventional non-halting computation:
> When UTM(⟨P⟩,I) never halts then we can know that P(I) never halts.

B ut UTM(P,I) DOES Halt, you have even shown it, therefor you statement
is wrong. (Your trace attached at end of message)

>
> Putting (1) and (2) together proves that H stops its simulation of P and
> correctly reports that P does not halt.
>
> I have shown that H(P,P)==0 is impossibly false therefore anything that
> seems to show that it contradicts this cannot possibly be an actual
> contradiction.

But you have also shown that H(P,P) == 1 is the correct answer, so you
have shown your logic to be inconsistent.

>
>> But you can't extend that observation to produce any more properties.
>> For instance,
>> you have to label H as "a simulating decider", you don't have an
>> algorithmic or
>> even a non-algorithmic way of determining whether a machine is a
>> "simulating
>> decider" or not.
>
> We can know that it is a perfect simulator when we stipulate that it is
> a UTM. We can know that it does correctly decide the conventional
> halting problem counter-examples by showing their infinitely repeating
> pattern on page 6:
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
>> Then the simulating decider needs a conventional decider to determine
>> whether it needs to halt the test program.
>
> I already explained how this is false. Have you chosen to be an idiot?
> Any non-simulating halt decider is limited to static analysis and cannot
> examine the execution trace of a simulated program.
>
>> so an Olcott-non halting decider is harder
>> to build than a conventional halt decider. In order to have something
>> interesting,
>> the Olcott non-halting decider needs to be at least easier to build
>> than a
>> conventional halt decider.
>>
>
>

[Richard Damon]

And what CAN force that P to halt? There is no decider around it to
abort it. The actions of the decider in it are part of its computation
so if that decider aborts its execution and makes it stop, it HAS
halted, so is halting per the definition. That also means that the
decider never answered so failed to be a decider, so was wrong twice.

[Malcolm McLean]

The difference is that instead of asking "does this program halt?" we ask "would it have
run forever had it not been stopped by a simulating halt decider?". You've said this on
many occasions.
That's what Ben calls the silly non-halting problem, and I've called '"Olcott non-halting".

Until we're clear on this then it's all confusion.
>

[olcott]

Which apparently you are intentionally pretending to be too stupid to
see is only asking:

If the UTM simulation of the TM description of P on its input I never
halts does the execution of TM P on input I ever halt?

> That's what Ben calls the silly non-halting problem, and I've called '"Olcott non-halting".
>

Which makes you both look quite foolish for pretending to not know this
basic axiom of Turing machines.

> Until we're clear on this then it's all confusion.
>>
>

[Malcolm McLean]

A halt decider is not a UTM.

>
> > That's what Ben calls the silly non-halting problem, and I've called '"Olcott non-halting".
> >
> Which makes you both look quite foolish for pretending to not know this
> basic axiom of Turing machines.
> > Until we're clear on this then it's all confusion.
>

Ben and I are both perfectly aware what a universal Turing machine is. If you modify a
universal Turing machine, it is no longer a universal Turing machine, and it may lose
some of its properties.
But you have said on many occasions that you were changing the question the halt
decider answered, to make the Linz proof that there is an example a decider fails on
no longer apply. If this is no longer your position, then we're back to confusion.

[olcott]

When we ask does TM P halt on its input this question always has the
exact same answer as the question does the simulation of the TM
description of P on its input I halt?

When we ask the question: Does simulating halt decider H have to abort
its simulation of the TM description of P on its input that question
always has the exact same answer does the simulation of P(I) halt?

[olcott]

By attempting to imagine the result of a computation instead of
requiring that every single step of fully operational code be explicitly
specified huge gaps in understanding occur.

One might incorrectly imagine that a function called in infinite
recursion must return a value to its caller. By simply imagining these
things no one ever notices that a function is called in infinite recursion.

> The key is that Turing Machines are much easier >>
> to reason about, so if you can write a program to solve a problem on a
> Turing Machine, and then actually PROVE that the program is correct, and
> maybe even that the program will halt, it tells you a lot about the
> problem that you were trying to solve.
>
> Of course, to do that means you need to know how to actually PROVE
> something and not just make claims and try it.
>
>>
>>> There are many problems with this. But the main one is that is isn't
>>> very interesting.
>>> Yes, you can say that Linz's proof applies only to halting, not to
>>> 'Olcott non-halting'.
>>
>> This is ordinary non-halting knucklehead:
>> When UTM(⟨P⟩,I) never halts then we can know that P(I) never halts.
>
> Then why did the trace of it show that it did? (See end of message)
>

The trace shows that P must be aborted and then after it has been
correctly determined that P must be aborted P is aborted.

You are either too stupid or too dishonest to acknowledge this.

[olcott]

void P(u32 x)
{
u32 Input_Halts = H(x, x);

if (Input_Halts)
HERE: goto HERE;
}

int main() // The input to P is forced to halt.
{ // The invocation of H(P,P) from this P(P)
P((u32)P); // is the first element of an infinite
} // chain of invocations of H(P,P)

[Richard Damon]

So, WHAT forced the invocation of P called by main to be aborted?

If the invocation of H that P called did, then H can't be a Turing
Machine Equivalent that answers when H is called by main.

PERIOD.

By Definition a computation must ALWAYS do EXACTLY the same action for
every invocation of it for a given set of parameters, and Turing
Machines can only perform computation.


Your statement just proves that either you just flat out lie, or your H
is not the equivalent of a Turing Machine, and thus doesn't qualify as a
H in Linz.

I will point out, that I have posted a couple of times recently a copy
of YOUR trace which shows that your H does return to that P.

Your problem is that you can't keep your invocations straight.

The H that was called by P terminates it simulation of copy of P passed
to it, not the invocation of P that called it.

[Richard Damon]

No, but by using REAL logic they can tell that if H does abort its
simulation of P then it isn't caught in a real infinfite recursion and
thus IS able to return to the finitly executing routine that called it.

You don't seem to be able to actually read the traces you get, so they
don't seem to help you.

People who lie to themselves are the worse type of people, they have NO
ONE they can trust, not even themselves.

>
>> The key is that Turing Machines are much easier >>
>> to reason about, so if you can write a program to solve a problem on a
>> Turing Machine, and then actually PROVE that the program is correct, and
>> maybe even that the program will halt, it tells you a lot about the
>> problem that you were trying to solve.
>>
>> Of course, to do that means you need to know how to actually PROVE
>> something and not just make claims and try it.
>>
>>>
>>>> There are many problems with this. But the main one is that is isn't
>>>> very interesting.
>>>> Yes, you can say that Linz's proof applies only to halting, not to
>>>> 'Olcott non-halting'.
>>>
>>> This is ordinary non-halting knucklehead:
>>> When UTM(⟨P⟩,I) never halts then we can know that P(I) never halts.
>>
>> Then why did the trace of it show that it did? (See end of message)
>>
>
> The trace shows that P must be aborted and then after it has been
> correctly determined that P must be aborted P is aborted.
>
> You are either too stupid or too dishonest to acknowledge this.
>

First, the trace is built incorrectly, because it has had an improper
substitution performed. The trace SHOULD show the simulation of the code
of H with is within the P that is being simulated.

Second when you look at the FULL trace that you posted once, you see
that after H abort its simulation of a copy of P, it then is able to
return to its caller, which just so happens to be a DIFFERENT invocation
of P which then returns.

[olcott]

On 6/16/2021 7:27 PM, Richard Damon wrote:
> On 6/16/21 12:34 PM, olcott wrote:
>> On 6/15/2021 6:22 PM, Richard Damon wrote:
>>> On 6/15/21 10:27 AM, olcott wrote:
>>> When you say that it halts on its own this is never ever true.
>>>> I don't think that you are lying about this, you are just
>>>> horribly terrible at paying attention. You get a misconception
>>>> stuck in your mind that becomes unbreakable.
>>>>
>>>> The execution trace where P was forced to halt is from this computation:
>>>> int main() { P(P); }
>>>>
>>>
>>> And what CAN force that P to halt? There is no decider around it to
>>> abort it. The actions of the decider in it are part of its computation
>>> so if that decider aborts its execution and makes it stop, it HAS
>>> halted, so is halting per the definition. That also means that the
>>> decider never answered so failed to be a decider, so was wrong twice.
>>>
>>
>> void P(u32 x)
>> {
>>   u32 Input_Halts = H(x, x);
>>   if (Input_Halts)
>>     HERE: goto HERE;
>> }
>>
>> int main()    // The input to P is forced to halt.
>> {             // The invocation of H(P,P) from this P(P)
>>   P((u32)P); // is the first element of an infinite
>> }             // chain of invocations of H(P,P)
>>
>>
>
> So, WHAT forced the invocation of P called by main to be aborted?
>

When P called from main calls H(P,P) this is the first element of an
otherwise infinite invocation chain.

It is common knowledge that whenever any invocation of an infinite
invocation chain is terminated this terminates the whole chain.

I have proven that it was necessary for H to terminate this otherwise
infinite invocation chain.

I have proven that H did terminate the third invocation of this
otherwise infinite invocation chain.

[olcott]

No on ever noticed anything like this before. They simply used the
diagonal proof to show that neither true (halting) nor false (not halt)
could be returned to P from H.

It never occurred to anyone to consider infinite recursion at all. They
saw the result of the diagonal proof and stopped looking.

> You don't seem to be able to actually read the traces you get, so they
> don't seem to help you.
>
> People who lie to themselves are the worse type of people, they have NO
> ONE they can trust, not even themselves.
>
>>
>>> The key is that Turing Machines are much easier >>
>>> to reason about, so if you can write a program to solve a problem on a
>>> Turing Machine, and then actually PROVE that the program is correct, and
>>> maybe even that the program will halt, it tells you a lot about the
>>> problem that you were trying to solve.
>>>
>>> Of course, to do that means you need to know how to actually PROVE
>>> something and not just make claims and try it.
>>>
>>>>
>>>>> There are many problems with this. But the main one is that is isn't
>>>>> very interesting.
>>>>> Yes, you can say that Linz's proof applies only to halting, not to
>>>>> 'Olcott non-halting'.
>>>>
>>>> This is ordinary non-halting knucklehead:
>>>> When UTM(⟨P⟩,I) never halts then we can know that P(I) never halts.
>>>
>>> Then why did the trace of it show that it did? (See end of message)
>>>
>>
>> The trace shows that P must be aborted and then after it has been
>> correctly determined that P must be aborted P is aborted.
>>
>> You are either too stupid or too dishonest to acknowledge this.
>>
>
> First, the trace is built incorrectly, because it has had an improper
> substitution performed. The trace SHOULD show the simulation of the code
> of H with is within the P that is being simulated.
>

That is not the way that it works.
The question is: Does H have to abort its simulation of P to prevent the
infinite execution of P?

When a simulator is deciding whether or not its input species infinite
execution it must only examine the behavior of this input otherwise it
is answering a different question.

I wouldn't use such harsh terms such as "stupid" or "dishonest" if I had
not already corrected you on these things hundreds of times.

Sometimes being kind and empathetic to people sends a message to these
people that you will tolerate abuse from them.

> Second when you look at the FULL trace that you posted once, you see
> that after H abort its simulation of a copy of P, it then is able to
> return to its caller, which just so happens to be a DIFFERENT invocation
> of P which then returns.
>

[wij]

Sorry to interrupt. For the little things I can read.
It does not matter how the halt decider works as long as it behaves as specified
by as:

// [Ret] true: p(a) will return
// false: otherwise (p(a) will not return)
//
bool HaltDecider(Progam p, Arg a);

I am not sure whether or not your halt decider is so defined. If it is, then I
can build a function f like the following, making HaltDecider wrong:

void f(Arg a) {
while(HaltDecider(f,a)) {};
};

Conclusion: No such halt decider can fulfill the spec.

[Malcolm McLean]

As I understnad it, this function

void infiniteloop(U32 dummy)
{
while(1);
}

void testmachine(U32 Input)
{
Halts(infiniteloop, NULL);
}

testmachine is a halting computation (conventional definition) but an Olcott non-Halting
computation (new definition), because infiniteloop is simulated by Halts() and terminated.

Can you confirm this?

[Andy Walker]

On 17/06/2021 15:55, olcott wrote:
> On 6/16/2021 7:33 PM, Richard Damon wrote:

[...]

>> No, but by using REAL logic they can tell that if H does abort its
>> simulation of P then it isn't caught in a real infinfite recursion and
>> thus IS able to return to the finitly executing routine that called it.
> No on ever noticed anything like this before. They simply used the
> diagonal proof to show that neither true (halting) nor false (not
> halt) could be returned to P from H.

That's not what anyone shows. The point is not that no answer
can be returned, but that any answer that is returned is incorrect.
[I'm ignoring the other confusions here, which is not to say that I
haven't noticed (some of) them.]

> It never occurred to anyone to consider infinite recursion at all.
> They saw the result of the diagonal proof and stopped looking.

Of course that occurred. But if there is an instance -- /any/
instance -- for which that happens to "H", then "H" is not a decider,
let alone a decider that resolves the HP, so Linz and the others don't
need to analyse that case further. That is why some people prefer to
re-phrase the Linz-style proof [other proofs are available] into

For any TM "H", either
-- "H" sometimes doesn't halt, or
-- "H" halts without writing a proper answer on its tape, or
-- the "H^" construction provides an example which "H" gets wrong
so in all cases "H" is not a correct HP decider, and so
no correct HP decider exists, QED.

[...]

> The question is: Does H have to abort its simulation of P to prevent
> the infinite execution of P?

As you have been told previously, "simulation" is your addition;
there is no reason why a partial halt-decider should not come to its
decision in other ways [some of which are even useful, esp if "P" is
well written, eg inc assertions, pre-requisites, invariants]. But if
we restrict ourselves to simulating PHDs, then to answer that question
in general, we need first to know whether "P" has "infinite execution".
Halting Problem, meet Halting Problem. IOW, this new HP needs the same
HP powers as the original HP, and you have made no progress. Yes, you
could write [and perhaps have written] a partial Olcott-HP decider, which
resolves specific cases [such as the "here: goto here" examples which you
keep giving], but everyone already knows that such cases can be decided
by a half-way sensible conventional PHD. You've still made no progress,
and your arguments have no bearing whatsoever on Linz's proof [or the
version summarised above, or any of the other proofs].

> When a simulator is deciding whether or not its input species
> infinite execution it must only examine the behavior of this input
> otherwise it is answering a different question.

Yes, and ...?

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Spindler

[olcott]

You counter-example is decided to specify infinite recursion.
Its simulation by simulating halt decider H is aborted and H reports
false for (not halting). I show all the details here:

Halting problem undecidability and infinitely nested simulation

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