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

On 6/11/2021 7:12 PM, Richard Damon wrote:
> On 6/11/21 7:36 PM, olcott wrote:
>> On 6/11/2021 6:30 PM, Richard Damon wrote:
>>> On 6/11/21 7:09 PM, olcott wrote:
>>>> On 6/11/2021 5:59 PM, Richard Damon wrote:
>>>>> 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.
>>>>>
>>>>
>>>> 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.
>>>>
>>>
>>> But that doesn't matter.
>>
>> It is all that matters.
>
> 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.
>

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

--
Copyright 2021 Pete 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.

--
Copyright 2021 Pete Olcott

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

On 6/12/2021 8:32 PM, Ben Bacarisse wrote:
> "dklei...@gmail.com" <dkleinecke@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.
>

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.

--
Copyright 2021 Pete Olcott

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

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.

--
Copyright 2021 Pete Olcott

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

On 6/18/2021 4:32 AM, Malcolm McLean wrote:
> On Friday, 18 June 2021 at 02:02:14 UTC+1, Richard Damon wrote:
>> On 6/17/21 10:55 AM, olcott wrote:
>>> On 6/16/2021 7:33 PM, Richard Damon wrote:
>>>>
>>>>
>>>> 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?
>> WRONG. The question is does P(I) Halt or not. THAT is the question.
>>
> I've tried to get clarification on this.
> In Linz's proof of the course the question is "does the program halt". PO has on

We must remove the erroneous pathological self-reference(Olcott 2004)
from the original incorrect question. Most people aren't smart enough to
understand that it is erroneous so they believe that the original
question is valid.

When we are asking: Does the input program halt? and conflate the
behavior of the halt decider with the behavior of the input program we
would provide the wrong answer.

When we ask the question: Does the simulation of the input have to be
aborted to prevent its infinite execution? We have properly divided the
behavior of the program from the behavior of the halt decider.

> occasion stated that, in so far as it goes, he considers Linz's proof to be
> valid. However he has slightly changed the question, so that Linz's proof no

The important thing about proofs is whether or not their conclusion is
correct. The Linz proof has an incorrect conclusion. The analytical
framework that Linz provides for analyzing the problem is optimal. It
has the perfect precision of state transitions and is nearly as simple
as possible.

> longer applies.
> However I'm unsure what his exact position is. Sometimes he says that the
> new question is exactly equivalent to Linz's original question, in which case
> it's hard to see how it gets him anywhere.
>

If we ask the question Does program P halt on its input such that both
true(halting) and false (not halting) are contradicted by the behavior
of the input then the pathological self-reference(Olcott 2004) must be
removed from this incorrect question.

> As I've said, the real issue is not with defining a new question which is similar
> to the halting question but slightly different. That's a reasonable thing to do.
> The real issue is whether you can do that in an interesting way, if the new question
> has properties that lead on to further work. To do that, you need to be able to
> give some basic examples of where it differs from the conventional halting problem,
> as a bare minimum. In fact defining a new problem in computer science which is
> interesting enough for other people to want to work on it is a very hard thing to
> do.
>

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.

The above new question is known to be computationally equivalent to the
original question.

The only difference is that the original question has been transformed
to eliminate its pathological self-reference(Olcott 2004) error.

This new question does correctly decide that the conventional halting
problem counter-examples are computations that do not halt.

∴ The elimination of the pathological self-reference(Olcott 2004) error
from the conventional halting problem proofs shows that the conclusion
of these proofs (that a universal halt decider cannot be defined) is
flat-out incorrect, these proofs show no such thing.

Halting problem undecidability and infinitely nested simulation

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

--
Copyright 2021 Pete Olcott

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

On 6/18/2021 9:19 AM, Malcolm McLean wrote:
> On Friday, 18 June 2021 at 12:27:48 UTC+1, Richard Damon wrote:
>> On 6/18/21 5:32 AM, Malcolm McLean wrote:
>>> On Friday, 18 June 2021 at 02:02:14 UTC+1, Richard Damon wrote:
>>>> On 6/17/21 10:55 AM, olcott wrote:
>>>>> On 6/16/2021 7:33 PM, Richard Damon wrote:
>>>>>>
>>>>>>
>>>>>> 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?
>>>> WRONG. The question is does P(I) Halt or not. THAT is the question.
>>>>
>>> I've tried to get clarification on this.
>>> In Linz's proof of the course the question is "does the program halt". PO has on
>>> occasion stated that, in so far as it goes, he considers Linz's proof to be
>>> valid. However he has slightly changed the question, so that Linz's proof no
>>> longer applies.
>>> However I'm unsure what his exact position is. Sometimes he says that the
>>> new question is exactly equivalent to Linz's original question, in which case
>>> it's hard to see how it gets him anywhere.
>>>
>>> As I've said, the real issue is not with defining a new question which is similar
>>> to the halting question but slightly different. That's a reasonable thing to do.
>>> The real issue is whether you can do that in an interesting way, if the new question
>>> has properties that lead on to further work. To do that, you need to be able to
>>> give some basic examples of where it differs from the conventional halting problem,
>>> as a bare minimum. In fact defining a new problem in computer science which is
>>> interesting enough for other people to want to work on it is a very hard thing to
>>> do.
>>>
>> The issue is that if you want your 'counter' to be applicable to the
>> proof, you HAVE to keep the question the same, not something 'close'.
>>
>> That is how logic works.
>>
>> Peter needs to decide, does he want to invent a new 'problem', some
>> sort-of-halting that can't be disproved by this form of proof, or is he
>> trying to actually contradict the proofs.
>>
>> He claims he is contradicting the proofs, so he isn't allowed to change
>> the definition, but he tries anyway.
>>
> The idea is to exclude the "pathological self reference" cases from consideration.
> The argument is that all proofs that halting is undecideable rely on these
> cases.

I did not eliminate these cases. I used a computationally equivalent
criteria to correctly decide these cases. The original criteria had the
pathological self-reference(Olcott 2004) error.

> Now you could regard that as "defining a different problem" or you could regard
> it as "showing that the halting problem proofs are irrelevant".
>

The conclusion of these proofs is simply wrong.

> I'd want to ask these questions. Can you define "pathological self reference"?
> Can you recognise it, either with a human or by an algorithmic method?

We simply define a computationally equivalent criteria that is imperious
to the pathological self-reference(Olcott 2004) error:

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.

> Having removed the "pathological self reference" instances from the set

I did not do this. I made these instances decidable.

> of target machines, can you then decide halting, or as a lesser but still
> impressive achievement can you show that no proof that halting is undecidable
> is possible? Or can we make simple modifications to the conventional halting
> proofs which show that the new set is also undecidable? Or maybe are
> those simple modifications not so simple after all?
>
> Even if you don't actually make any progress on halting, are there any other
> properties which arise from your "pathological self reference" set? Would
> the distinction be of interest to anyone working in another area of computer
> science?

Halting problem undecidability and infinitely nested simulation

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

--
Copyright 2021 Pete Olcott

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

On 6/18/2021 10:42 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Friday, 18 June 2021 at 02:02:14 UTC+1, Richard Damon wrote:
>>> On 6/17/21 10:55 AM, olcott wrote:
>>>> On 6/16/2021 7:33 PM, Richard Damon wrote:
>>>>>
>>>>>
>>>>> 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?
>>> WRONG. The question is does P(I) Halt or not. THAT is the question.
>>>
>> I've tried to get clarification on this.
>> In Linz's proof of the course the question is "does the program
>> halt". PO has on occasion stated that, in so far as it goes, he
>> considers Linz's proof to be valid. However he has slightly changed
>> the question, so that Linz's proof no longer applies. However I'm
>> unsure what his exact position is. Sometimes he says that the new
>> question is exactly equivalent to Linz's original question, in which
>> case it's hard to see how it gets him anywhere.
>
> You won't get any clarification on this unless something causes him to
> loose his delusions of greatness. He's spent years on this. His whole
> sense of self-worth is based on seeing things that have escaped the
> greatest minds. There is simply no way his mind can accommodate the
> fact that he's either wrong or wasting his time with a useless new
> definition.
>
> He's tried to persuade people that the definitions are the same. He's
> tried to convince people that the new one is the only reasonable one.
> He's even tried to find a way to make the wrong answer (for the halting
> problem) sound like it might just be the right answer. Simply coming
> clean is just not an option for a mind like his.
>

The fact that all you have is rhetoric entirely bereft of any supporting
reasoning is very telling.

The only material "error" that anyone ever pointed out was merely a
confused misconception on their part. I have much clearer words to
correct this misconception now.

Halting problem undecidability and infinitely nested simulation

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

--
Copyright 2021 Pete Olcott

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

On 6/18/2021 11:22 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> The idea is to exclude the "pathological self reference" cases from
>> consideration.
>
> This is a bad name because there is no self-reference, even in the

That is very clearly a knuckle-head thing to say:

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

So when Ĥ is applied to *it own* Turing machine description then
this means that Ĥ is applied to some other Turing machine description
that *is not its own* ?

Is it your primary purpose to seem like a knuckle-head ?
(You did a great job of that!)

> trivial case, and to exclude all such cases requires a TM that can
> recognise an embedded set of states (that could be anywhere among its
> states) the /behaves/ like that "hat" construction. This it not
> possible.
>

I am not excluding these cases. I am merely transforming the criterion
measure for deciding these cases into a computationally equivalent
criterion measure.

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.

--
Copyright 2021 Pete Olcott

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

On 6/18/2021 12:08 PM, Malcolm McLean wrote:
> On Friday, 18 June 2021 at 17:22:20 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> or as a lesser but still impressive achievement can you show that no proof that
>>> halting is undecidable is possible?
>> What is impressive about that? What exactly is it you think would be
>> would be impressive to prove?
>>
> We define the "confounding property" such that we can clearly say whether any
> machine has "the confounding property". We then remove these machines from
> our set of all Turing machines. However we maybe still can't write a halt decider
> which decides this set, which is what we really want. What we can maybe do, however,
> is show that every proof that a universal decider is not possible relies on example
> machines with the confounding property, and no proof that doesn't rely on this
> can be offered. I'd settle for that if I was working on this problem.
>
> (Needless to say, I don't claim to define the "confounding property" myself.)
>

All we need is a computationally equivalent criterion measure of "not
halting" that is impervious to the confounding property:

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.

Halting problem undecidability and infinitely nested simulation

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

--
Copyright 2021 Pete Olcott

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

On 6/19/2021 5:00 AM, Malcolm McLean wrote:
> On Saturday, 19 June 2021 at 04:06:26 UTC+1, olcott wrote:
>> On 6/18/2021 9:33 PM, Richard Damon wrote:
>>> On 6/18/21 9:32 PM, olcott wrote:
>>>> On 6/18/2021 7:46 PM, Richard Damon wrote:
>>>>> On 6/18/21 8:40 PM, olcott wrote:
>>>>>> On 6/18/2021 7:31 PM, Daniel Pehoushek wrote:
>>>>>>> On Friday, June 18, 2021 at 7:47:05 PM UTC-4, olcott wrote:
>>>>>>>> On 6/18/2021 5:49 PM, Daniel Pehoushek wrote:
>>>>>>>>> no no no none of that bullshit i am a theoretician
>>>>>>>> I am not a theoretician.
>>>>>>>>> i just want information about your thoughts on general cycle
>>>>>>>>> detection in a graph with N vertices and M edges
>>>>>>>>>
>>>>>>>>> gods favorite symbol is +
>>>>>>>>> gods favorite number is three
>>>>>>>>> my favorite number is ten
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Copyright 2021 Pete Olcott
>>>>>>>>
>>>>>>>> "Great spirits have always encountered violent opposition from
>>>>>>>> mediocre
>>>>>>>> minds." Einstein
>>>>>>>
>>>>>>> you claim you are nay a theoretician.
>>>>>>> why then are you spamming the living fuck out of the theoreticians
>>>>>>> group?
>>>>>>> my mind is superb, not mediocre.
>>>>>>>
>>>>>>> i just want information about your thoughts on general cycle detection
>>>>>>> in a graph with N vertices and M edges
>>>>>>> so that i may judge you competently surely quickly and so forth so i
>>>>>>> can move on with my good life.
>>>>>>>
>>>>>>
>>>>>> If you cannot evaluate what I am saying on the basis of software
>>>>>> engineering you may not be able to evaluate what I am saying at all.
>>>>>>
>>>>>> Actual working C code supersedes any assumptions about purely mental
>>>>>> models of computation where the precise details of the behavior are
>>>>>> never explicitly stated.
>>>>>
>>>>> But the C code shows that H_Hat does Halt, the Halts is wrong.
>>>>>
>>>>
>>>> The C code also shows that an actual infinite loop halts for the same
>>>> reason. Every non-halting input to a simulating halt decider has its
>>>> simulation terminated thus forcing it to halt.
>>>>
>>>
>>> Nope, you keep looking at the wrong place. The program where main calls
>>> H_Hat/P which calls H is the one I am refering to, where it SHOWS that
>>> the actual program H_Hat/P does Halt.
>> If none of the invocations of H(P,P) from P are ever terminated then P
>> never terminates.
>>
>> Do you agree or are you going to lie?
>>
>> The call to H(P,P) from int main () { P(P); } is the first element of an
>> infinite invocation sequence that is terminated at its third invocation.
>>
>> int main()
>> {
>> P(P);
>> }
>>
>> The global halt decider aborts it invocation of P from main() emitting
>> an x86utm operating system error comparable to a divide by zero error.
>>
> We seem to have gone back to the idea that you abort the machine
> instead of returning false (non-halting) when running the halt detector.
> Maybe you only abort the machine for the confounding cases, which
> brings us back to the question of how to detect the confounding cases.
>
The x86utm operating system considers a computation that never halts the
same as a divide-by-zero error.

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

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

(a) We can know that the input to H(P,P) is input that never halts with
100% perfect certainty on the basis of its x86 execution trace.

(b) This means that we can know with 100% perfect certainty that a
simulating halt decider must abort its simulation of its input.

(c) This means that we can know with 100% perfect certainty that a
simulating halt decider correctly reports that this input never halts.

Clueless wonders can deny any one of these three steps on the basis of
ignorance or simply not paying attention.

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

--
Copyright 2021 Pete Olcott

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

On 6/21/2021 6:48 PM, Richard Damon wrote:
> On 6/21/21 9:46 AM, olcott wrote:
>> On 6/21/2021 4:47 AM, Andy Walker wrote:
>>> On 21/06/2021 00:10, Ben Bacarisse wrote:
>>>> [...] I don't
>>>> think it's obvious that the cases any one TM gets wrong are going to be
>>>> interesting.  This may be a case where I'd change my mind when someone
>>>> comes up with a definition and it just turns out to be interesting in
>>>> some as yet unforeseen sense, but I can't see that happening right now
>>>> (as is to be expected of unforeseen occurrences).
>>>
>>>      If we take the "one TM" to be a TM that always halts with the
>>> answer "HALTS", then the cases it gets wrong are precisely the cases
>>> that don't halt.  That's interesting, as there is a simple proof that
>>> there is no TM that can determine just those cases [tho' there are
>>> TMs that determine supersets of them].  Perhaps that's not quite what
>>> you meant?
>>>
>>
>> // Simplified Linz Ĥ (Linz:1990:319)
>> void P(u32 x)
>> {
>>   u32 Input_Halts = H(x, x);
>>   if (Input_Halts)
>>     HERE: goto HERE;
>> }
>>
>> int main()
>> {
>>   u32 Input_Halts = H((u32)P, (u32)P);
>>   Output("Input_Halts = ", Input_Halts);
>> }
>>
>> In the above case no instance of P ever sees any return value from H.
>>
>> Halting problem undecidability and infinitely nested simulation
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>>
>
> Only because H make a mistake and does try to find out what really happens.
>
> Change main to:
>
> int main()
> {
> P(u32)P);
> }
>
> and the P that main calls DOES get the return value from H (or you syste
> is proved to be fradulent) and then halt and H is proved wrong.
>

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

Whenever P calls H(P,P) H must abort its simulation of P. The above
computation P(P) calls H(P,P) which is the first invocation of an
infinite sequence of invocations.

Everyone that is not dumber than a box of rocks knows that when any
invocation of an infinite sequence of invocations is terminated then the
entire sequence halts.

In the computation P(P) the third element of the infinite sequence of
invocations is terminated.

> Since this is the machine that the Halting Problem is asking about, that
> is the important one.
>

--
Copyright 2021 Pete Olcott

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