On 6/21/2021 6:07 PM, olcott wrote:
> On 6/21/2021 7:15 PM, Chris M. Thomasson wrote:
>> On 6/21/2021 4:16 AM, Ben Bacarisse wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>
>>>> On 6/20/2021 9:15 PM, olcott wrote:
>>>>> If you see an animal and test its DNA and confirm that it is
>>>>> definitely a cat, what happens when the cat barks?
>>>> [...]
>>>>
>>>> Have you been hearing cats bark lately? Wow.
>>>
>>> He's making a bad analogy.  The correct analogy is that /assuming/ that
>>> a cat barks leads to a contradiction so we must reject the assumption.
>>>
>>> He can see the contradiction that assuming a halt decider leads to (at
>>> least he claimed to be able to see it) so what to do?  He has to state
>>> that he has a barking cat -- a halt decider that works at least for the
>>> confounding case.  Of course he doesn't, but he has to find some way to
>>> keep the discussion going (he only cares about keeping people talking).
>>>
>>
>> Ahhh. Good. Okay, well I am still wondering why, when I tell him to
>> run his "halt decider" against an unknown, black box program created
>> by somebody else... Well, he seems to get pissed off. Afaict, his
>> decider only works on programs that he already knows are, decided.
>> Cheating 101? Or what? ;^o
>
> It is not actually a contradiction at all if one is paying very close
> attention. Since people want me to be wrong they don't want to pay
> enough attention to see that I am right.
>

If I give you a black box program, can you decide if it halts or not?

On 6/21/2021 7:57 PM, André G. Isaak wrote:
> On 2021-06-21 15:11, olcott wrote:
>> On 6/21/2021 1:24 PM, André G. Isaak wrote:
>>> On 2021-06-20 23:04, Chris M. Thomasson wrote:
>>>> On 6/20/2021 9:15 PM, olcott wrote:
>>>>> If you see an animal and test its DNA and confirm that it is
>>>>> definitely a cat, what happens when the cat barks?
>>>> [...]
>>>>
>>>> Have you been hearing cats bark lately? Wow.
>>>
>>> As long as he's just hearing them bark, we're probably fine.
>>>
>>> It's when the barking cats start telling him to do things (like kill
>>> neighbours, steal catnip, or conquer Liechtenstein) that we really
>>> need to worry.
>>>
>>> André
>>>
>>
>> The point is that the mere intuition about the halting behavior of Ĥ
>> applied to ⟨Ĥ⟩ is superseded by meticulous sound deductive inference.
>>
>> SELF-EVIDENT-TRUTH
>> Every computation that never halts unless its simulation is aborted is
>> a computation that never halts.
>
> How can that possibly be "self-evident" when it doesn't even explain
> what "its simulation" means. Its simulation of/by what?
>

We could simplify this and say that any computation that never halts
unless this computation is aborted is a computation that never halts.

>> SELF-EVIDENT-TRUTH
>> The ⟨Ĥ⟩ ⟨Ĥ⟩ input to the embedded halt decider at Ĥ.qx is a
>> computation that never halts unless its simulation is aborted.
>
> If that were self-evident, you wouldn't have so many people pointing out
> to you that it is simply wrong. Things can't be both wrong and
> self-evident.
>

That people simply don't want to bother to pay enough attention to see
that I am right is not actually any rebuttal at all.

>> ∴ IMPOSSIBLY FALSE CONCLUSION
>
> "Impossibly false" is a meaningless expression. No journal is going to
> take you seriously if this phrase appears anywhere in your work.
>

I improved this. I now call it the conclusion of sound deduction, which
means exactly the same thing as impossibly false.

>> The embedded simulating halt decider at Ĥ.qx correctly decides its
>> input: ⟨Ĥ⟩ ⟨Ĥ⟩ is a computation that never halts.
>>
>> Ĥ.q0 ⟨Ĥ⟩ specifies an infinite chain of invocations that is terminated
>> at its third invocation. The first invocation of Ĥ.qx ⟨Ĥ⟩, ⟨Ĥ⟩ is the
>> first element of an infinite chain of invocations.
>>
>> It is common knowledge that when any invocation of an infinite chain
>> of invocations is terminated that the whole chain terminates. That the
>> first element of this infinite chain terminates after its third
>> element has been terminated does not entail that this first element is
>> an actual terminating computation.
>
> No. It isn't "common knowledge". It is simply false.
>

I will make a common knowledge concrete example:
Infinite recursion is an infinite sequence of invocations right?

If any element of the infinite sequence of invocations of infinite
recursion is aborted then the whole sequence stops right?

If the third invocation of the infinite sequence of invocations of
infinite recursion is aborted then the whole sequence stops right?

Was it really that hard to see the above three steps on the basis of my
claim of common knowledge?

> And if the simulation is terminated after the third call to Ĥ, the you
> don't have an infinite chain of calls. You have a chain of three calls.
>

When the halt decider is analyzing the behavior stipulated by a finite
string it is incorrect for the halt decider to conflate its own behavior
in this analysis.

The question that the halt decider is answering is whether or not a pure
simulation/execution of the input must be aborted to prevent the
infinite execution of this input.

>> For the first element to be an actual terminating computation it must
>> terminate without any of the elements of the infinite chain of
>> invocations being terminated.
>
> This is just plain silly.

See my infinite recursion example above.

> If some program H simulates another program Y
> along with an input string but has the ability to terminate a
> simulation, then there are three possibilities:
>
> A) The simulation is allowed to continue until Y reaches one of its
> final states. In such a case we can say that Y halts. Since Y halts, H
> can also halt.
>
> B) The simulation is allowed to continue forever, but it never reaches a
> final state. The simulation continues forever. In this case, Y doesn't
> halt. H therefore also doesn't halt. Of course, this option would be
> difficult to empirically verify since we can't actually observe
> something running for an infinite amount of time.
>
> C) H decides to discontinue the simulation. In this case the simulation
> neither halts nor runs forever. It may be that that Y is non-halting, or
> it may be that H simply discontinued the simulation prematurely. But in
> either of these two cases, H can halt.
>
> André
>

As I have said so very many hundreds of times now that you really should
not have made such a terrible mistake with part C

When H must terminate the simulation of its input to prevent the
infinite execution of P then H does necessarily infallibly correctly
decide that its input never halts.

Unlike Turing machines where we must simply imagine crucially important
details and have no way to infallibly ascertain that our imagination
accurately represent the truth we can examine the x86 execution trace of
P and know with 100% perfectly correct certainty that P would never ever
halt unless H aborts P.

--
Copyright 2021 Pete Olcott

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

On 6/21/2021 8:35 PM, Chris M. Thomasson wrote:
> On 6/21/2021 6:07 PM, olcott wrote:
>> On 6/21/2021 7:15 PM, Chris M. Thomasson wrote:
>>> On 6/21/2021 4:16 AM, Ben Bacarisse wrote:
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>
>>>>> On 6/20/2021 9:15 PM, olcott wrote:
>>>>>> If you see an animal and test its DNA and confirm that it is
>>>>>> definitely a cat, what happens when the cat barks?
>>>>> [...]
>>>>>
>>>>> Have you been hearing cats bark lately? Wow.
>>>>
>>>> He's making a bad analogy.  The correct analogy is that /assuming/ that
>>>> a cat barks leads to a contradiction so we must reject the assumption.
>>>>
>>>> He can see the contradiction that assuming a halt decider leads to (at
>>>> least he claimed to be able to see it) so what to do?  He has to state
>>>> that he has a barking cat -- a halt decider that works at least for the
>>>> confounding case.  Of course he doesn't, but he has to find some way to
>>>> keep the discussion going (he only cares about keeping people talking).
>>>>
>>>
>>> Ahhh. Good. Okay, well I am still wondering why, when I tell him to
>>> run his "halt decider" against an unknown, black box program created
>>> by somebody else... Well, he seems to get pissed off. Afaict, his
>>> decider only works on programs that he already knows are, decided.
>>> Cheating 101? Or what? ;^o
>>
>> It is not actually a contradiction at all if one is paying very close
>> attention. Since people want me to be wrong they don't want to pay
>> enough attention to see that I am right.
>>
>
> If I give you a black box program, can you decide if it halts or not?

Within the context of the halting problem that is a very stupid question.

--
Copyright 2021 Pete Olcott

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

On 6/21/2021 6:40 PM, olcott wrote:
> On 6/21/2021 8:35 PM, Chris M. Thomasson wrote:
>> On 6/21/2021 6:07 PM, olcott wrote:
>>> On 6/21/2021 7:15 PM, Chris M. Thomasson wrote:
>>>> On 6/21/2021 4:16 AM, Ben Bacarisse wrote:
>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>
>>>>>> On 6/20/2021 9:15 PM, olcott wrote:
>>>>>>> If you see an animal and test its DNA and confirm that it is
>>>>>>> definitely a cat, what happens when the cat barks?
>>>>>> [...]
>>>>>>
>>>>>> Have you been hearing cats bark lately? Wow.
>>>>>
>>>>> He's making a bad analogy.  The correct analogy is that /assuming/
>>>>> that
>>>>> a cat barks leads to a contradiction so we must reject the assumption.
>>>>>
>>>>> He can see the contradiction that assuming a halt decider leads to (at
>>>>> least he claimed to be able to see it) so what to do?  He has to state
>>>>> that he has a barking cat -- a halt decider that works at least for
>>>>> the
>>>>> confounding case.  Of course he doesn't, but he has to find some
>>>>> way to
>>>>> keep the discussion going (he only cares about keeping people
>>>>> talking).
>>>>>
>>>>
>>>> Ahhh. Good. Okay, well I am still wondering why, when I tell him to
>>>> run his "halt decider" against an unknown, black box program created
>>>> by somebody else... Well, he seems to get pissed off. Afaict, his
>>>> decider only works on programs that he already knows are, decided.
>>>> Cheating 101? Or what? ;^o
>>>
>>> It is not actually a contradiction at all if one is paying very close
>>> attention. Since people want me to be wrong they don't want to pay
>>> enough attention to see that I am right.
>>>
>>
>> If I give you a black box program, can you decide if it halts or not?
>
> Within the context of the halting problem that is a very stupid question.
>

Why? Does the program halt or not? You cannot tell. Get over it.

On 6/21/2021 8:05 PM, André G. Isaak wrote:
> On 2021-06-21 18:37, olcott wrote:
>> On 6/21/2021 7:03 PM, Richard Damon wrote:
>>> On 6/21/21 5:11 PM, olcott wrote:
>>>
>>>> The point is that the mere intuition about the halting behavior of Ĥ
>>>> applied to ⟨Ĥ⟩ is superseded by meticulous sound deductive inference.
>>>>
>>>> SELF-EVIDENT-TRUTH
>>>> Every computation that never halts unless its simulation is aborted
>>>> is a
>>>> computation that never halts.
>>>>
>>>> SELF-EVIDENT-TRUTH
>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ input to the embedded halt decider at Ĥ.qx is a computation
>>>> that never halts unless its simulation is aborted.
>>>>
>>>> ∴ IMPOSSIBLY FALSE CONCLUSION
>>>> The embedded simulating halt decider at Ĥ.qx correctly decides its
>>>> input: ⟨Ĥ⟩ ⟨Ĥ⟩ is a computation that never halts.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ specifies an infinite chain of invocations that is terminated
>>>> at its third invocation. The first invocation of Ĥ.qx ⟨Ĥ⟩, ⟨Ĥ⟩ is the
>>>> first element of an infinite chain of invocations.
>>>>
>>>> It is common knowledge that when any invocation of an infinite chain of
>>>> invocations is terminated that the whole chain terminates. That the
>>>> first element of this infinite chain terminates after its third element
>>>> has been terminated does not entail that this first element is an
>>>> actual
>>>> terminating computation.
>>>>
>>>> For the first element to be an actual terminating computation it must
>>>> terminate without any of the elements of the infinite chain of
>>>> invocations being terminated.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Halting problem undecidability and infinitely nested simulation
>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> Self evident FALSEHOODS as previously shown.
>>>
>>
>> Saying that you think that an assertion is incorrect is not actually
>> any rebuttal at all.
>
> There's nothing to rebut since you've provided no actual argument.
> Declaring things to be 'self-evident' doesn't constitute an argument.
>
> André
>

Self-evident means that an expression of language can be verified as
necessarily true entirely basis on the meaning of its words.

Because sound deduction requires premises to be true we must have some
way to confirm that the premises are true.

5 > 3 self-evident
7 > 5 self-evident
∴ 7 > 3

Your challenge that you can not see that it is true provides the means
for me to work towards a mutual understanding by improving the quality
of my explanation.

Most people say that they know that I must be wrong entirely on the
basis that they really really believe that I must be wrong. That
provides no basis for any mutual understanding.

--
Copyright 2021 Pete Olcott

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

On 6/21/21 9:42 PM, Chris M. Thomasson wrote:
> On 6/21/2021 6:40 PM, olcott wrote:
>> On 6/21/2021 8:35 PM, Chris M. Thomasson wrote:
>>> On 6/21/2021 6:07 PM, olcott wrote:
>>>> On 6/21/2021 7:15 PM, Chris M. Thomasson wrote:
>>>>> On 6/21/2021 4:16 AM, Ben Bacarisse wrote:
>>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>>>>
>>>>>>> On 6/20/2021 9:15 PM, olcott wrote:
>>>>>>>> If you see an animal and test its DNA and confirm that it is
>>>>>>>> definitely a cat, what happens when the cat barks?
>>>>>>> [...]
>>>>>>>
>>>>>>> Have you been hearing cats bark lately? Wow.
>>>>>>
>>>>>> He's making a bad analogy.  The correct analogy is that /assuming/
>>>>>> that
>>>>>> a cat barks leads to a contradiction so we must reject the
>>>>>> assumption.
>>>>>>
>>>>>> He can see the contradiction that assuming a halt decider leads to
>>>>>> (at
>>>>>> least he claimed to be able to see it) so what to do?  He has to
>>>>>> state
>>>>>> that he has a barking cat -- a halt decider that works at least
>>>>>> for the
>>>>>> confounding case.  Of course he doesn't, but he has to find some
>>>>>> way to
>>>>>> keep the discussion going (he only cares about keeping people
>>>>>> talking).
>>>>>>
>>>>>
>>>>> Ahhh. Good. Okay, well I am still wondering why, when I tell him to
>>>>> run his "halt decider" against an unknown, black box program
>>>>> created by somebody else... Well, he seems to get pissed off.
>>>>> Afaict, his decider only works on programs that he already knows
>>>>> are, decided. Cheating 101? Or what? ;^o
>>>>
>>>> It is not actually a contradiction at all if one is paying very
>>>> close attention. Since people want me to be wrong they don't want to
>>>> pay enough attention to see that I am right.
>>>>
>>>
>>> If I give you a black box program, can you decide if it halts or not?
>>
>> Within the context of the halting problem that is a very stupid question.
>>
>
> Why? Does the program halt or not? You cannot tell. Get over it.

Well, the problem is that Turing Machines CAN'T be black boxes. And the
definition of the Halting Problem is that the decider is given a full
description of the Turing Machine, which is basically like a full
listing of the program.

Now, this works two ways, a PO needs to realize that his Halt Decider
also can't avoid being examined, and thus H, if it answers, can't avoid
giving that answer to H^, so that it can make the answer wrong.

On 6/21/21 9:48 PM, olcott wrote:
> On 6/21/2021 8:05 PM, André G. Isaak wrote:
>> On 2021-06-21 18:37, olcott wrote:
>>> On 6/21/2021 7:03 PM, Richard Damon wrote:
>>>> On 6/21/21 5:11 PM, olcott wrote:
>>>>
>>>>> The point is that the mere intuition about the halting behavior of Ĥ
>>>>> applied to ⟨Ĥ⟩ is superseded by meticulous sound deductive inference.
>>>>>
>>>>> SELF-EVIDENT-TRUTH
>>>>> Every computation that never halts unless its simulation is aborted
>>>>> is a
>>>>> computation that never halts.
>>>>>
>>>>> SELF-EVIDENT-TRUTH
>>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ input to the embedded halt decider at Ĥ.qx is a
>>>>> computation
>>>>> that never halts unless its simulation is aborted.
>>>>>
>>>>> ∴ IMPOSSIBLY FALSE CONCLUSION
>>>>> The embedded simulating halt decider at Ĥ.qx correctly decides its
>>>>> input: ⟨Ĥ⟩ ⟨Ĥ⟩ is a computation that never halts.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ specifies an infinite chain of invocations that is terminated
>>>>> at its third invocation. The first invocation of Ĥ.qx ⟨Ĥ⟩, ⟨Ĥ⟩ is the
>>>>> first element of an infinite chain of invocations.
>>>>>
>>>>> It is common knowledge that when any invocation of an infinite
>>>>> chain of
>>>>> invocations is terminated that the whole chain terminates. That the
>>>>> first element of this infinite chain terminates after its third
>>>>> element
>>>>> has been terminated does not entail that this first element is an
>>>>> actual
>>>>> terminating computation.
>>>>>
>>>>> For the first element to be an actual terminating computation it must
>>>>> terminate without any of the elements of the infinite chain of
>>>>> invocations being terminated.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Halting problem undecidability and infinitely nested simulation
>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Self evident FALSEHOODS as previously shown.
>>>>
>>>
>>> Saying that you think that an assertion is incorrect is not actually
>>> any rebuttal at all.
>>
>> There's nothing to rebut since you've provided no actual argument.
>> Declaring things to be 'self-evident' doesn't constitute an argument.
>>
>> André
>>
>
> Self-evident means that an expression of language can be verified as
> necessarily true entirely basis on the meaning of its words.

Except they aren't, and in fact it is clear that they ARE wrong when we
use the language of computation theory to look at them.

I have explained in detail before the errors in your words, and you just
ignore it, my guess is because you can't actually think.

>
> Because sound deduction requires premises to be true we must have some
> way to confirm that the premises are true.
>
> 5 > 3 self-evident
> 7 > 5 self-evident
> ∴ 7 > 3
>
> Your challenge that you can not see that it is true provides the means
> for me to work towards a mutual understanding by improving the quality
> of my explanation.
>
> Most people say that they know that I must be wrong entirely on the
> basis that they really really believe that I must be wrong. That
> provides no basis for any mutual understanding.
>

I don't need to start with an assumption you are wrong, I have shown so
many ways you are actually wrong that I have lost count.

You seem to have no concept of what Truth actually means, so it isn't
that surprising that those proofs are unintelligible to you.

I figure they must be, because you NEVER show an actual error in my
statements just make the wild claim again and say I must be wrong.

The ultimate problem is it seems you whole logic system is fundamentally
inconsistent, in part because you want to insist on the basic principle
that All Truth is Provable, but don't want to live within the well know
limitations of the logic basis. Maybe you have even convinced yourself
that this must be a universal truth (which it isn't).

You have refused to learn from history and all your flaws are well knows
from decades to centuries past, because you have condemned yourself to
repeat them.

On 6/21/21 9:39 PM, olcott wrote:
> On 6/21/2021 7:57 PM, André G. Isaak wrote:

>> How can that possibly be "self-evident" when it doesn't even explain
>> what "its simulation" means. Its simulation of/by what?
>>
>
> We could simplify this and say that any computation that never halts
> unless this computation is aborted is a computation that never halts.
>

Which with the RIGHT definitions of the words is true. The problem is
you don't use the right defintions of the words.

Stated more clearly, if a simulation of a computation would never end
unless the simulator of THAT simulation needs to halt it, then the
computation would never halt.

The problem when applying this to H^ (aka P) is that since the copy of
the simulator will halt its simulation of the copy of the program it has
been given, then THIS simulator doesn't NEED to end its simulation. This
can be seen by changing the top level to be a UTM instead of H (but P
still calls H) and we see that it will simulate P calling H, which will
see what it THINKS (incorrectly) is an infinite recursion, stop its
simulation, and return the Non-Halting answer to P which will Halt, and
thus the UTM finishes is simulation. Therefore, we see that that H
didn't NEED to abort is simulation, because the copy of H it was
simulating is going to make the error in terminating its simulation.

>>> SELF-EVIDENT-TRUTH
>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ input to the embedded halt decider at Ĥ.qx is a
>>> computation that never halts unless its simulation is aborted.
>>
>> If that were self-evident, you wouldn't have so many people pointing
>> out to you that it is simply wrong. Things can't be both wrong and
>> self-evident.
>>
>
> That people simply don't want to bother to pay enough attention to see
> that I am right is not actually any rebuttal at all.

Care to say what is actually wrong with may analysis above? Would you be
willing to stake you LIFE on P(P) being non-Halting.

>
>>> ∴ IMPOSSIBLY FALSE CONCLUSION
>>
>> "Impossibly false" is a meaningless expression. No journal is going to
>> take you seriously if this phrase appears anywhere in your work.
>>
>
> I improved this. I now call it the conclusion of sound deduction, which
> means exactly the same thing as impossibly false.

Except it has been shown to be unsound as it is built on false premises.

>
>>> The embedded simulating halt decider at Ĥ.qx correctly decides its
>>> input: ⟨Ĥ⟩ ⟨Ĥ⟩ is a computation that never halts.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ specifies an infinite chain of invocations that is
>>> terminated at its third invocation. The first invocation of Ĥ.qx ⟨Ĥ⟩,
>>> ⟨Ĥ⟩ is the first element of an infinite chain of invocations.
>>>
>>> It is common knowledge that when any invocation of an infinite chain
>>> of invocations is terminated that the whole chain terminates. That
>>> the first element of this infinite chain terminates after its third
>>> element has been terminated does not entail that this first element
>>> is an actual terminating computation.
>>
>> No. It isn't "common knowledge". It is simply false.
>>
>
> I will make a common knowledge concrete example:
> Infinite recursion is an infinite sequence of invocations right?

STRAWMAN. The fact that a rule works in one case is NOT proof that it
works in all.
>
> If any element of the infinite sequence of invocations of infinite
> recursion is aborted then the whole sequence stops right?

WRONG. only the element past the point of abortion. Since the simulation
is PART of the infinite recursion, if it abort everything, it doesn't
answer and fails.
>
> If the third invocation of the infinite sequence of invocations of
> infinite recursion is aborted then the whole sequence stops right?

Nope, only third and later, 1st and 2nd are still there.

Or are you saying H doesn't answer when it is the 1st element of the
infinite recursion either?

>
> Was it really that hard to see the above three steps on the basis of my
> claim of common knowledge?

No probably at all at showing your errors, there are so many.

>
>> And if the simulation is terminated after the third call to Ĥ, the you
>> don't have an infinite chain of calls. You have a chain of three calls.
>>
>
> When the halt decider is analyzing the behavior stipulated by a finite
> string it is incorrect for the halt decider to conflate its own behavior
> in this analysis.

It must not conflate, but if the behavior is based on a copy of itself,
it does need to take into account the behavior of that copy,

>
> The question that the halt decider is answering is whether or not a pure
> simulation/execution of the input must be aborted to prevent the
> infinite execution of this input.

And THAT'S your problem. you have the wrong question. Where did you get
that from?

The question it is SUPPOSED to be answering is does the machine and
input it has been given a description of Halt in a finite number of
steps or not.

This IS the question, and the ONLY question, of the Halting Problem that
the Halting Decider is supposed to answer.

>
>>> For the first element to be an actual terminating computation it must
>>> terminate without any of the elements of the infinite chain of
>>> invocations being terminated.
>>
>> This is just plain silly.
>
> See my infinite recursion example above.

See my rebuttal above.
>
>> If some program H simulates another program Y along with an input
>> string but has the ability to terminate a simulation, then there are
>> three possibilities:
>>
>> A) The simulation is allowed to continue until Y reaches one of its
>> final states. In such a case we can say that Y halts. Since Y halts, H
>> can also halt.
>>
>> B) The simulation is allowed to continue forever, but it never reaches
>> a final state. The simulation continues forever. In this case, Y
>> doesn't halt. H therefore also doesn't halt. Of course, this option
>> would be difficult to empirically verify since we can't actually
>> observe something running for an infinite amount of time.
>>
>> C) H decides to discontinue the simulation. In this case the
>> simulation neither halts nor runs forever. It may be that that Y is
>> non-halting, or it may be that H simply discontinued the simulation
>> prematurely. But in either of these two cases, H can halt.
>>
>> André
>>
>
> As I have said so very many hundreds of times now that you really should
> not have made such a terrible mistake with part C
>
> When H must terminate the simulation of its input to prevent the
> infinite execution of P then H does necessarily infallibly correctly
> decide that its input never halts.

And who cares what the halt decider did. P(P) Halts and THAT is what is
important so H got the wrong answer and can't blame that on anyone else.
>
> Unlike Turing machines where we must simply imagine crucially important
> details and have no way to infallibly ascertain that our imagination
> accurately represent the truth we can examine the x86 execution trace of
> P and know with 100% perfectly correct certainty that P would never ever
> halt unless H aborts P.
>

Yes, And you have shown that P(P) halts. So the right answer needs to be
Halts.

It actually doesn't take 'imagination' to see this. It can be done with
mathematical PROOF. Something you don't seem to understand.

On 6/21/2021 9:22 PM, Richard Damon wrote:
> On 6/21/21 9:39 PM, olcott wrote:
>> On 6/21/2021 7:57 PM, André G. Isaak wrote:
>
>>> How can that possibly be "self-evident" when it doesn't even explain
>>> what "its simulation" means. Its simulation of/by what?
>>>
>>
>> We could simplify this and say that any computation that never halts
>> unless this computation is aborted is a computation that never halts.
>>
>
> Which with the RIGHT definitions of the words is true. The problem is
> you don't use the right defintions of the words.
>
> Stated more clearly, if a simulation of a computation would never end
> unless the simulator of THAT simulation needs to halt it, then the
> computation would never halt.

That stupidly ignores:

When any element of infinitely nested simulations or invocation of the
infinite chain of invocations of infinite recursion is terminated then
the whole chain terminates,

When no element of infinitely nested simulations or invocation of the
infinite chain of invocations of infinite recursion is terminated then
the whole chain never terminates.

--
Copyright 2021 Pete Olcott

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

On 2021-06-21 19:39, olcott wrote:
> On 6/21/2021 7:57 PM, André G. Isaak wrote:
>> On 2021-06-21 15:11, olcott wrote:
>>> On 6/21/2021 1:24 PM, André G. Isaak wrote:
>>>> On 2021-06-20 23:04, Chris M. Thomasson wrote:
>>>>> On 6/20/2021 9:15 PM, olcott wrote:
>>>>>> If you see an animal and test its DNA and confirm that it is
>>>>>> definitely a cat, what happens when the cat barks?
>>>>> [...]
>>>>>
>>>>> Have you been hearing cats bark lately? Wow.
>>>>
>>>> As long as he's just hearing them bark, we're probably fine.
>>>>
>>>> It's when the barking cats start telling him to do things (like kill
>>>> neighbours, steal catnip, or conquer Liechtenstein) that we really
>>>> need to worry.
>>>>
>>>> André
>>>>
>>>
>>> The point is that the mere intuition about the halting behavior of Ĥ
>>> applied to ⟨Ĥ⟩ is superseded by meticulous sound deductive inference.
>>>
>>> SELF-EVIDENT-TRUTH
>>> Every computation that never halts unless its simulation is aborted
>>> is a computation that never halts.
>>
>> How can that possibly be "self-evident" when it doesn't even explain
>> what "its simulation" means. Its simulation of/by what?
>>
>
> We could simplify this and say that any computation that never halts
> unless this computation is aborted is a computation that never halts.

That's no better. A computation which is aborted doesn't halt. 'Halt'
means to reach one of the final states. If you abort something it
doesn't reach a final state. But the simulator itself can.

>>> SELF-EVIDENT-TRUTH
>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ input to the embedded halt decider at Ĥ.qx is a
>>> computation that never halts unless its simulation is aborted.
>>
>> If that were self-evident, you wouldn't have so many people pointing
>> out to you that it is simply wrong. Things can't be both wrong and
>> self-evident.
>>
>
> That people simply don't want to bother to pay enough attention to see
> that I am right is not actually any rebuttal at all.
>
>>> ∴ IMPOSSIBLY FALSE CONCLUSION
>>
>> "Impossibly false" is a meaningless expression. No journal is going to
>> take you seriously if this phrase appears anywhere in your work.
>>
>
> I improved this. I now call it the conclusion of sound deduction, which
> means exactly the same thing as impossibly false.

So where is the sound deduction from which you reach the above
conclusion? You start with two premises, one of which is too vague to be
interpreted and the other of which is simply false. That's not how
deductively sound arguments work.

>>> The embedded simulating halt decider at Ĥ.qx correctly decides its
>>> input: ⟨Ĥ⟩ ⟨Ĥ⟩ is a computation that never halts.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ specifies an infinite chain of invocations that is
>>> terminated at its third invocation. The first invocation of Ĥ.qx ⟨Ĥ⟩,
>>> ⟨Ĥ⟩ is the first element of an infinite chain of invocations.
>>>
>>> It is common knowledge that when any invocation of an infinite chain
>>> of invocations is terminated that the whole chain terminates. That
>>> the first element of this infinite chain terminates after its third
>>> element has been terminated does not entail that this first element
>>> is an actual terminating computation.
>>
>> No. It isn't "common knowledge". It is simply false.
>>
>
> I will make a common knowledge concrete example:
> Infinite recursion is an infinite sequence of invocations right?

Sure, but there is no infinite recursion (or recursion period) in the
Linz example.

> If any element of the infinite sequence of invocations of infinite
> recursion is aborted then the whole sequence stops right?

Not necessarily. That depends entirely on what is meant by 'abort'.

> If the third invocation of the infinite sequence of invocations of
> infinite recursion is aborted then the whole sequence stops right?

No. The third invocation is aborted. The simulator itself continues to
run and is able to halt.

> Was it really that hard to see the above three steps on the basis of my
> claim of common knowledge?

Things that you believe and 'common knowledge' are not the same thing.

>> And if the simulation is terminated after the third call to Ĥ, the you
>> don't have an infinite chain of calls. You have a chain of three calls.
>>
>
> When the halt decider is analyzing the behavior stipulated by a finite
> string it is incorrect for the halt decider to conflate its own behavior
> in this analysis.

And I am not conflating them. When you abort the simulation that doesn't
entail aborting the simulator. You conflate them by concluding that the
topmost program doesn't halt based on what happens to the program it is
simulating.

> The question that the halt decider is answering is whether or not a pure
> simulation/execution of the input must be aborted to prevent the
> infinite execution of this input.
>
>>> For the first element to be an actual terminating computation it must
>>> terminate without any of the elements of the infinite chain of
>>> invocations being terminated.
>>
>> This is just plain silly.
>
> See my infinite recursion example above.

As I said, the above is just plain silly.

>> If some program H simulates another program Y along with an input
>> string but has the ability to terminate a simulation, then there are
>> three possibilities:
>>
>> A) The simulation is allowed to continue until Y reaches one of its
>> final states. In such a case we can say that Y halts. Since Y halts, H
>> can also halt.
>>
>> B) The simulation is allowed to continue forever, but it never reaches
>> a final state. The simulation continues forever. In this case, Y
>> doesn't halt. H therefore also doesn't halt. Of course, this option
>> would be difficult to empirically verify since we can't actually
>> observe something running for an infinite amount of time.
>>
>> C) H decides to discontinue the simulation. In this case the
>> simulation neither halts nor runs forever. It may be that that Y is
>> non-halting, or it may be that H simply discontinued the simulation
>> prematurely. But in either of these two cases, H can halt.
>>
>> André
>>
>
> As I have said so very many hundreds of times now that you really should
> not have made such a terrible mistake with part C

There is no mistake in C. Your 'self-evident' truths are wrong, as
virtually everyone posting here has pointed out.

> When H must terminate the simulation of its input to prevent the
> infinite execution of P then H does necessarily infallibly correctly
> decide that its input never halts.
>
> Unlike Turing machines where we must simply imagine crucially important
> details and have no way to infallibly ascertain that our imagination

Exactly which 'crucially important details' do you think we need to
imagine? Turing machines are precisely defined entities with precisely
defined behaviours. And there are literally thousands of programs
available which will allow you to execute Turing Machines if you'd
rather not trace through them manually.

> accurately represent the truth we can examine the x86 execution trace of
> P and know with 100% perfectly correct certainty that P would never ever
> halt unless H aborts P.

An execution trace does nothing other than to show what a particular
program did on a particular input. It provides no evidence whatsoever
for the correctness of the program. For that you need to provide actual
proof. An execution trace is not a proof.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 6/21/2021 9:29 PM, André G. Isaak wrote:
> On 2021-06-21 19:39, olcott wrote:
>> On 6/21/2021 7:57 PM, André G. Isaak wrote:
>>> On 2021-06-21 15:11, olcott wrote:
>>>> On 6/21/2021 1:24 PM, André G. Isaak wrote:
>>>>> On 2021-06-20 23:04, Chris M. Thomasson wrote:
>>>>>> On 6/20/2021 9:15 PM, olcott wrote:
>>>>>>> If you see an animal and test its DNA and confirm that it is
>>>>>>> definitely a cat, what happens when the cat barks?
>>>>>> [...]
>>>>>>
>>>>>> Have you been hearing cats bark lately? Wow.
>>>>>
>>>>> As long as he's just hearing them bark, we're probably fine.
>>>>>
>>>>> It's when the barking cats start telling him to do things (like
>>>>> kill neighbours, steal catnip, or conquer Liechtenstein) that we
>>>>> really need to worry.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> The point is that the mere intuition about the halting behavior of Ĥ
>>>> applied to ⟨Ĥ⟩ is superseded by meticulous sound deductive inference.
>>>>
>>>> SELF-EVIDENT-TRUTH
>>>> Every computation that never halts unless its simulation is aborted
>>>> is a computation that never halts.
>>>
>>> How can that possibly be "self-evident" when it doesn't even explain
>>> what "its simulation" means. Its simulation of/by what?
>>>
>>
>> We could simplify this and say that any computation that never halts
>> unless this computation is aborted is a computation that never halts.
>
> That's no better. A computation which is aborted doesn't halt. 'Halt'
> means to reach one of the final states. If you abort something it
> doesn't reach a final state. But the simulator itself can.
>

When we are trying to determine whether or not an infinite loop is an
infinite loop we can debug step through this code and see that it
endlessly repeats and there is no escape from this endless repetition in
this code. It is not really that hard.

>>>> SELF-EVIDENT-TRUTH
>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ input to the embedded halt decider at Ĥ.qx is a
>>>> computation that never halts unless its simulation is aborted.
>>>
>>> If that were self-evident, you wouldn't have so many people pointing
>>> out to you that it is simply wrong. Things can't be both wrong and
>>> self-evident.
>>>
>>
>> That people simply don't want to bother to pay enough attention to see
>> that I am right is not actually any rebuttal at all.
>>
>>>> ∴ IMPOSSIBLY FALSE CONCLUSION
>>>
>>> "Impossibly false" is a meaningless expression. No journal is going
>>> to take you seriously if this phrase appears anywhere in your work.
>>>
>>
>> I improved this. I now call it the conclusion of sound deduction,
>> which means exactly the same thing as impossibly false.
>
> So where is the sound deduction from which you reach the above
> conclusion? You start with two premises, one of which is too vague to be
> interpreted and the other of which is simply false. That's not how
> deductively sound arguments work.

We really have to look at this in terms of H and P because there is no
other possible way to make sure that we examine all the details when we
try to imagine what a Turing machine might do.

>>>> The embedded simulating halt decider at Ĥ.qx correctly decides its
>>>> input: ⟨Ĥ⟩ ⟨Ĥ⟩ is a computation that never halts.
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ specifies an infinite chain of invocations that is
>>>> terminated at its third invocation. The first invocation of Ĥ.qx
>>>> ⟨Ĥ⟩, ⟨Ĥ⟩ is the first element of an infinite chain of invocations.
>>>>
>>>> It is common knowledge that when any invocation of an infinite chain
>>>> of invocations is terminated that the whole chain terminates. That
>>>> the first element of this infinite chain terminates after its third
>>>> element has been terminated does not entail that this first element
>>>> is an actual terminating computation.
>>>
>>> No. It isn't "common knowledge". It is simply false.
>>>
>>
>> I will make a common knowledge concrete example:
>> Infinite recursion is an infinite sequence of invocations right?
>
> Sure, but there is no infinite recursion (or recursion period) in the
> Linz example.
>
>> If any element of the infinite sequence of invocations of infinite
>> recursion is aborted then the whole sequence stops right?
>
> Not necessarily. That depends entirely on what is meant by 'abort'.
>
>> If the third invocation of the infinite sequence of invocations of
>> infinite recursion is aborted then the whole sequence stops right?
>
> No. The third invocation is aborted. The simulator itself continues to
> run and is able to halt.
>
>> Was it really that hard to see the above three steps on the basis of
>> my claim of common knowledge?
>
> Things that you believe and 'common knowledge' are not the same thing.
>
>>> And if the simulation is terminated after the third call to Ĥ, the
>>> you don't have an infinite chain of calls. You have a chain of three
>>> calls.
>>>
>>
>> When the halt decider is analyzing the behavior stipulated by a finite
>> string it is incorrect for the halt decider to conflate its own
>> behavior in this analysis.
>
> And I am not conflating them. When you abort the simulation that doesn't
> entail aborting the simulator. You conflate them by concluding that the
> topmost program doesn't halt based on what happens to the program it is
> simulating.
>
>> The question that the halt decider is answering is whether or not a
>> pure simulation/execution of the input must be aborted to prevent the
>> infinite execution of this input.
>>
>>>> For the first element to be an actual terminating computation it
>>>> must terminate without any of the elements of the infinite chain of
>>>> invocations being terminated.
>>>
>>> This is just plain silly.
>>
>> See my infinite recursion example above.
>
> As I said, the above is just plain silly.
>
>>> If some program H simulates another program Y along with an input
>>> string but has the ability to terminate a simulation, then there are
>>> three possibilities:
>>>
>>> A) The simulation is allowed to continue until Y reaches one of its
>>> final states. In such a case we can say that Y halts. Since Y halts,
>>> H can also halt.
>>>
>>> B) The simulation is allowed to continue forever, but it never
>>> reaches a final state. The simulation continues forever. In this
>>> case, Y doesn't halt. H therefore also doesn't halt. Of course, this
>>> option would be difficult to empirically verify since we can't
>>> actually observe something running for an infinite amount of time.
>>>
>>> C) H decides to discontinue the simulation. In this case the
>>> simulation neither halts nor runs forever. It may be that that Y is
>>> non-halting, or it may be that H simply discontinued the simulation
>>> prematurely. But in either of these two cases, H can halt.
>>>
>>> André
>>>
>>
>> As I have said so very many hundreds of times now that you really
>> should not have made such a terrible mistake with part C
>
> There is no mistake in C.

C) H decides to discontinue the simulation.
This is very terribly incorrect

H MUST stop its simulation of P or P never halts
H MUST stop its simulation of P or P never halts
H MUST stop its simulation of P or P never halts
H MUST stop its simulation of P or P never halts
H MUST stop its simulation of P or P never halts

This is not at all the same thing as H arbitrarily stops simulating P
for possibly no good reason at all.

This is not at all the same thing as H arbitrarily stops simulating P
for possibly no good reason at all.

This is not at all the same thing as H arbitrarily stops simulating P
for possibly no good reason at all.

This is not at all the same thing as H arbitrarily stops simulating P
for possibly no good reason at all.

On Monday, 21 June 2021 at 14:44:05 UTC+1, olcott wrote:
> On 6/21/2021 4:17 AM, Malcolm McLean wrote:
> > On Monday, 21 June 2021 at 05:15:27 UTC+1, olcott wrote:
> >> If you see an animal and test its DNA and confirm that it is definitely
> >> a cat, what happens when the cat barks?
> >>
> >> When we examine the behavior of the Peter Linz Ĥ applied to its own
> >> Turing machine description: ⟨Ĥ⟩ and simply assume that the embedded halt
> >> decider at its internal state of Ĥ.qx is a UTM then we find that this
> >> machine has infinitely nested simulation.
> >>
> >> SELF-EVIDENT-TRUTH
> >> Every computation that never halts unless its simulation is aborted is a
> >> computation that never halts.
> >>
> >> SELF-EVIDENT-TRUTH
> >> The <Ĥ> <Ĥ> input to the embedded halt decider at Ĥ.qx is a computation
> >> that never halts unless its simulation is aborted.
> >>
> > Not at all obvious. A comptuation that would never halt unless its simulation
> > were aborted may be a non-halting computation.
> Good.
> > But the simulation itself
> > is a computation, and it may halt even if it is simulating a non-halting
> When the simulator is examining whether or not it must abort its
> simulation of its input it must ignore its own behavior and merely act
> as a pure simulator for this input until it recognizes a non-halting
> behavior pattern by this input.
> > computation (if it is not a perfect simulator, of course). That's the situation
> > with your H and H_Hat.
>
> >>
> >> ∴ IMPOSSIBLY FALSE CONCLUSION
> >> The embedded simulating halt decider at Ĥ.qx correctly decides its
> >> input: <Ĥ> <Ĥ> is a computation that never halts.
> >>
> > Yes, the conclusion is false. I've explained why. It's now time to wind down
> > these threads.
> >
> That you made a freaking false assumption does not actually point out
> any error in my work. Please try again, this time without the false
> assumption.
>
I think I see your difficulty.

If we have this

recurse() { recurse();}

then in the abstract model, it goes on forever. If we have

simuate(recurse)

then simulate will likely take action against it at some point or another. So simulate(recurse)
is a halting calculation.

So far, fairly simple.

Now if we write srecruse

srecurse(){simulate(srecurse);}

then it also goes on forever, but not on the regular call stack. There's only one subroutine call,
to "simulate". Everything else is simulated code, not native run code. If simulate is well written,
it will detect that the simulation is getting too big at some point and terminate it before the
computer runs out of resources. But it won't be a simple "count the call stack depth" test such
as you would likely use for recurse(). (Simulate is a simulator, it doesn't try to be a halt decider).

srecurse() is therefore a halting calculation.

Now what happens when we do

simulate(srecruse)

Probably what will happen is that simulate will stop the simulation just before the simulated
simulator detects that it is tight on resources. So you get the impression that srecurse
is non-halting, when in fact this isn't the case. If we used a different, more capable simulator

simulate2(srecruse)

the simulated simulator would run out resources and terminate.

Now you can say "surely it would have run forever if the simulator didn't stop itself so it
must be non-halting". That's true if instead of a function in a high-level language called
"simulate" we make simulate a UTM with and infinite tape. Then srecurse() will run forever,
as will recurse. But as soon as you adapt the UTM to abort its input, it is no longer
a strict UTM.

On 6/21/21 10:29 PM, olcott wrote:
> On 6/21/2021 9:22 PM, Richard Damon wrote:
>> On 6/21/21 9:39 PM, olcott wrote:
>>> On 6/21/2021 7:57 PM, André G. Isaak wrote:
>>
>>>> How can that possibly be "self-evident" when it doesn't even explain
>>>> what "its simulation" means. Its simulation of/by what?
>>>>
>>>
>>> We could simplify this and say that any computation that never halts
>>> unless this computation is aborted is a computation that never halts.
>>>
>>
>> Which with the RIGHT definitions of the words is true. The problem is
>> you don't use the right defintions of the words.
>>
>> Stated more clearly, if a simulation of a computation would never end
>> unless the simulator of THAT simulation needs to halt it, then the
>> computation would never halt.
>
> That stupidly ignores:
>
> When any element of infinitely nested simulations or invocation of the
> infinite chain of invocations of infinite recursion is terminated then
> the whole chain terminates,

Which is a FALSE statement. Where do you get this from? Do you have any
PROOF of this statement? A potentially infinite sequence when the cause
of the possible infinite behavior is ended becomes a finite sequence to
the point where the change occurred.

Or, are you saying that H terminated the simulation by blowing up the
computer that is was running on? Did it terminate by just halting the
whole program? In either of these cases, H has now failed to answer per
its requirements.

>
> When no element of infinitely nested simulations or invocation of the
> infinite chain of invocations of infinite recursion is terminated then
> the whole chain never terminates.
>

Right, IF no element terminates, then the whole chain never terminates,
but that isn't the case we have here. That is like your if cats were
dogs analogy. Cats AREN'T dogs, and you H does abort the simulation, or
it wouldn't answer and thus not even be in the contention.

Since H DOES abort the simulation (incorrectly deciding non-halting),
the chain after the point of being aborted stops, and thus the H that
DID the abort can return to its caller.

On Monday, 21 June 2021 at 23:37:49 UTC+8, olcott wrote:
> On 6/21/2021 10:33 AM, wij wrote:
> > On Monday, 21 June 2021 at 21:47:51 UTC+8, olcott wrote:
> >> On 6/21/2021 2:46 AM, wij wrote:
> >>> On Monday, 21 June 2021 at 12:15:27 UTC+8, olcott wrote:
> >>>> If you see an animal and test its DNA and confirm that it is definitely
> >>>> a cat, what happens when the cat barks?
> >>>>
> >>>> When we examine the behavior of the Peter Linz Ĥ applied to its own
> >>>> Turing machine description: ⟨Ĥ⟩ and simply assume that the embedded halt
> >>>> decider at its internal state of Ĥ.qx is a UTM then we find that this
> >>>> machine has infinitely nested simulation.
> >>>>
> >>>> SELF-EVIDENT-TRUTH
> >>>> Every computation that never halts unless its simulation is aborted is a
> >>>> computation that never halts.
> >>>>
> >>>> SELF-EVIDENT-TRUTH
> >>>> The <Ĥ> <Ĥ> input to the embedded halt decider at Ĥ.qx is a computation
> >>>> that never halts unless its simulation is aborted.
> >>>>
> >>>> ∴ IMPOSSIBLY FALSE CONCLUSION
> >>>> The embedded simulating halt decider at Ĥ.qx correctly decides its
> >>>> input: <Ĥ> <Ĥ> is a computation that never halts.
> >>>>
> >>>> The above three elements essentially provide the DNA of the cat.
> >>>>
> >>>>
> >>>> 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
> >>>
> >>> As I said the question is very simple:
> >>> You have to show a correct implement (pseudo-code is OK) of the function
> >>> "bool HaltDecider(Func f, Arg a)". This is a MUST.
> >>> Other things (paper/talk) are auxiliary.
> >> I have done that six months ago using different naming conventions.
> >
> > This is a very great achievement, deserves 3 Nobel Prizes.
> >
> >> Halting problem undecidability and infinitely nested simulation
> >>
> >> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
> >>
> >
> > Quoting the paper makes me baffled completely. It to me just is like searching for a set of
> > codes using 'simulator', not a good strategy while static code analyzer is sufficient.
> This is my paper that I wrote that has the code that you asked for.
>
> // 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);
> }
>
> H is a simulating halt decider based on an x86 emulator. I spent nearly
> two years creating the x86utm operating system so that I could implement H.
> >
> >>
> >>
> >>>
> >>> Evading this 'simple' question is taken as "No, my proof can't stand such a test".
> >>> Therefore... everything you have said is.... you imagine it.
> >>>
> >> --
> >> Copyright 2021 Pete Olcott
> >>
> >> "Great spirits have always encountered violent opposition from mediocre
> >> minds." Einstein
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein

Your proof may be 100% correct. But it only valid for your instance P.
I think you mis-interpreted the conventional HP proof.

I have shown an instance P that simulates H in different way(H2) will make H
behave incorrectly. The conventional HP proof can be demonstrated in C-like
pseudo-code which is more useful, applicable, most people can comprehend
immediately. A refutation should be capable of being demonstrated in the same way.

From software engineering point of view, your proof is 'optimized' too soon
to the lowest level (assembly, TM). Creating a x86utm operating system makes
no sense to refute HP. Beside, to refute, the 'x86utm operating system' (all) has to
be present in the paper for peer to reproduce the result.

On Tuesday, 22 June 2021 at 19:52:15 UTC+8, wij wrote:
> On Monday, 21 June 2021 at 23:37:49 UTC+8, olcott wrote:
> > On 6/21/2021 10:33 AM, wij wrote:
> > > On Monday, 21 June 2021 at 21:47:51 UTC+8, olcott wrote:
> > >> On 6/21/2021 2:46 AM, wij wrote:
> > >>> On Monday, 21 June 2021 at 12:15:27 UTC+8, olcott wrote:
> > >>>> If you see an animal and test its DNA and confirm that it is definitely
> > >>>> a cat, what happens when the cat barks?
> > >>>>
> > >>>> When we examine the behavior of the Peter Linz Ĥ applied to its own
> > >>>> Turing machine description: ⟨Ĥ⟩ and simply assume that the embedded halt
> > >>>> decider at its internal state of Ĥ.qx is a UTM then we find that this
> > >>>> machine has infinitely nested simulation.
> > >>>>
> > >>>> SELF-EVIDENT-TRUTH
> > >>>> Every computation that never halts unless its simulation is aborted is a
> > >>>> computation that never halts.
> > >>>>
> > >>>> SELF-EVIDENT-TRUTH
> > >>>> The <Ĥ> <Ĥ> input to the embedded halt decider at Ĥ..qx is a computation
> > >>>> that never halts unless its simulation is aborted.
> > >>>>
> > >>>> ∴ IMPOSSIBLY FALSE CONCLUSION
> > >>>> The embedded simulating halt decider at Ĥ.qx correctly decides its
> > >>>> input: <Ĥ> <Ĥ> is a computation that never halts.
> > >>>>
> > >>>> The above three elements essentially provide the DNA of the cat.
> > >>>>
> > >>>>
> > >>>> 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
> > >>>
> > >>> As I said the question is very simple:
> > >>> You have to show a correct implement (pseudo-code is OK) of the function
> > >>> "bool HaltDecider(Func f, Arg a)". This is a MUST.
> > >>> Other things (paper/talk) are auxiliary.
> > >> I have done that six months ago using different naming conventions.
> > >
> > > This is a very great achievement, deserves 3 Nobel Prizes.
> > >
> > >> Halting problem undecidability and infinitely nested simulation
> > >>
> > >> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
> > >>
> > >
> > > Quoting the paper makes me baffled completely. It to me just is like searching for a set of
> > > codes using 'simulator', not a good strategy while static code analyzer is sufficient.
> > This is my paper that I wrote that has the code that you asked for.
> >
> > // 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);
> > }
> >
> > H is a simulating halt decider based on an x86 emulator. I spent nearly
> > two years creating the x86utm operating system so that I could implement H.
> > >
> > >>
> > >>
> > >>>
> > >>> Evading this 'simple' question is taken as "No, my proof can't stand such a test".
> > >>> Therefore... everything you have said is.... you imagine it.
> > >>>
> > >> --
> > >> Copyright 2021 Pete Olcott
> > >>
> > >> "Great spirits have always encountered violent opposition from mediocre
> > >> minds." Einstein
> > --
> > Copyright 2021 Pete Olcott
> >
> > "Great spirits have always encountered violent opposition from mediocre
> > minds." Einstein
> Your proof may be 100% correct. But it only valid for your instance P.
> I think you mis-interpreted the conventional HP proof.
>
> I have shown an instance P that simulates H in different way(H2) will make H
> behave incorrectly. The conventional HP proof can be demonstrated in C-like
> pseudo-code which is more useful, applicable, most people can comprehend
> immediately. A refutation should be capable of being demonstrated in the same way.
>
> From software engineering point of view, your proof is 'optimized' too soon
> to the lowest level (assembly, TM). Creating a x86utm operating system makes
> no sense to refute HP. Beside, to refute, the 'x86utm operating system' (all) has to
> be present in the paper for peer to reproduce the result.

I just checked the book, [Linz,p320] (Linz's book is the most readable of my 6 similar books)
....
It does not preclude solving the halting problem for specific cases; often we
can tell by an analysis of M and 𝐰 whether or not the Turing machine will halt.
What the theorem says is that this cannot always be done; there is no algorithm
that can make a correct decision for all Wm and 𝐰.

On 6/22/2021 4:38 AM, Malcolm McLean wrote:
> On Monday, 21 June 2021 at 14:44:05 UTC+1, olcott wrote:
>> On 6/21/2021 4:17 AM, Malcolm McLean wrote:
>>> On Monday, 21 June 2021 at 05:15:27 UTC+1, olcott wrote:
>>>> If you see an animal and test its DNA and confirm that it is definitely
>>>> a cat, what happens when the cat barks?
>>>>
>>>> When we examine the behavior of the Peter Linz Ĥ applied to its own
>>>> Turing machine description: ⟨Ĥ⟩ and simply assume that the embedded halt
>>>> decider at its internal state of Ĥ.qx is a UTM then we find that this
>>>> machine has infinitely nested simulation.
>>>>
>>>> SELF-EVIDENT-TRUTH
>>>> Every computation that never halts unless its simulation is aborted is a
>>>> computation that never halts.
>>>>
>>>> SELF-EVIDENT-TRUTH
>>>> The <Ĥ> <Ĥ> input to the embedded halt decider at Ĥ.qx is a computation
>>>> that never halts unless its simulation is aborted.
>>>>
>>> Not at all obvious. A comptuation that would never halt unless its simulation
>>> were aborted may be a non-halting computation.
>> Good.
>>> But the simulation itself
>>> is a computation, and it may halt even if it is simulating a non-halting
>> When the simulator is examining whether or not it must abort its
>> simulation of its input it must ignore its own behavior and merely act
>> as a pure simulator for this input until it recognizes a non-halting
>> behavior pattern by this input.
>>> computation (if it is not a perfect simulator, of course). That's the situation
>>> with your H and H_Hat.
>>
>>>>
>>>> ∴ IMPOSSIBLY FALSE CONCLUSION
>>>> The embedded simulating halt decider at Ĥ.qx correctly decides its
>>>> input: <Ĥ> <Ĥ> is a computation that never halts.
>>>>
>>> Yes, the conclusion is false. I've explained why. It's now time to wind down
>>> these threads.
>>>
>> That you made a freaking false assumption does not actually point out
>> any error in my work. Please try again, this time without the false
>> assumption.
>>
> I think I see your difficulty.
>
> If we have this
>
> recurse() { recurse();}
>
> then in the abstract model, it goes on forever. If we have
>
> simuate(recurse)
>
> then simulate will likely take action against it at some point or another. So simulate(recurse)
> is a halting calculation.
>
> So far, fairly simple.
>
> Now if we write srecruse
>
> srecurse(){simulate(srecurse);}
>
> then it also goes on forever, but not on the regular call stack. There's only one subroutine call,
> to "simulate". Everything else is simulated code, not native run code. If simulate is well written,
> it will detect that the simulation is getting too big at some point and terminate it before the
> computer runs out of resources. But it won't be a simple "count the call stack depth" test such
> as you would likely use for recurse(). (Simulate is a simulator, it doesn't try to be a halt decider).
>
> srecurse() is therefore a halting calculation.
>
> Now what happens when we do
>
> simulate(srecruse)
>
> Probably what will happen is that simulate will stop the simulation just before the simulated
> simulator detects that it is tight on resources. So you get the impression that srecurse
> is non-halting, when in fact this isn't the case. If we used a different, more capable simulator
>
> simulate2(srecruse)
>
> the simulated simulator would run out resources and terminate.
>
> Now you can say "surely it would have run forever if the simulator didn't stop itself so it
> must be non-halting". That's true if instead of a function in a high-level language called
> "simulate" we make simulate a UTM with and infinite tape. Then srecurse() will run forever,
> as will recurse. But as soon as you adapt the UTM to abort its input, it is no longer
> a strict UTM.
>

The idea is to sufficiently approximate a UTM in the high level of C/x86
where we can see all of the details of the relationship between the
simulating halt decider H and its input P.

With the Linz proof we have to simply imagine 100,000 steps of an actual
UTM and have no way to verify that our imagination is accurate.

With the H/P computation it is easy to verify that H must abort its
input because we can see by the x86 execution trace of P that P has no
escape from its infinitely recursive simulation.

When we know that every simulation that must be aborted to prevent the
infinite execution of its input is a computation that never halts we
know that H correctly decides that P never halts axiomatically.

When we know this then we might have enough insight to the Linz proof.
If we don't know this then we do not have enough insight to apply to the
Linz proof, we simply assume that there is some error with the Linz
proof on the basis of the ambiguity of the unspecified steps.

--
Copyright 2021 Pete Olcott

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

olcott wrote:
> If you see an animal and test its DNA and confirm that it is definitely
> a cat, what happens when the cat barks?

If your definition of "cat" just refers to its DNA, then a barking cat
is just a cat making an unusual (for a cat) noise.

But note that the word "cat" has been in use for many years before DNA
was even known to exist and during that time the definition of "cat"
might well have made reference to what vocalizations it could produce.

--
The world will little note, nor long remember what we say here
Abraham Lincoln at Gettysburg

On 6/22/2021 6:52 AM, wij wrote:
> On Monday, 21 June 2021 at 23:37:49 UTC+8, olcott wrote:
>> On 6/21/2021 10:33 AM, wij wrote:
>>> On Monday, 21 June 2021 at 21:47:51 UTC+8, olcott wrote:
>>>> On 6/21/2021 2:46 AM, wij wrote:
>>>>> On Monday, 21 June 2021 at 12:15:27 UTC+8, olcott wrote:
>>>>>> If you see an animal and test its DNA and confirm that it is definitely
>>>>>> a cat, what happens when the cat barks?
>>>>>>
>>>>>> When we examine the behavior of the Peter Linz Ĥ applied to its own
>>>>>> Turing machine description: ⟨Ĥ⟩ and simply assume that the embedded halt
>>>>>> decider at its internal state of Ĥ.qx is a UTM then we find that this
>>>>>> machine has infinitely nested simulation.
>>>>>>
>>>>>> SELF-EVIDENT-TRUTH
>>>>>> Every computation that never halts unless its simulation is aborted is a
>>>>>> computation that never halts.
>>>>>>
>>>>>> SELF-EVIDENT-TRUTH
>>>>>> The <Ĥ> <Ĥ> input to the embedded halt decider at Ĥ.qx is a computation
>>>>>> that never halts unless its simulation is aborted.
>>>>>>
>>>>>> ∴ IMPOSSIBLY FALSE CONCLUSION
>>>>>> The embedded simulating halt decider at Ĥ.qx correctly decides its
>>>>>> input: <Ĥ> <Ĥ> is a computation that never halts.
>>>>>>
>>>>>> The above three elements essentially provide the DNA of the cat.
>>>>>>
>>>>>>
>>>>>> 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
>>>>>
>>>>> As I said the question is very simple:
>>>>> You have to show a correct implement (pseudo-code is OK) of the function
>>>>> "bool HaltDecider(Func f, Arg a)". This is a MUST.
>>>>> Other things (paper/talk) are auxiliary.
>>>> I have done that six months ago using different naming conventions.
>>>
>>> This is a very great achievement, deserves 3 Nobel Prizes.
>>>
>>>> Halting problem undecidability and infinitely nested simulation
>>>>
>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>
>>>
>>> Quoting the paper makes me baffled completely. It to me just is like searching for a set of
>>> codes using 'simulator', not a good strategy while static code analyzer is sufficient.
>> This is my paper that I wrote that has the code that you asked for.
>>
>> // 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);
>> }
>>
>> H is a simulating halt decider based on an x86 emulator. I spent nearly
>> two years creating the x86utm operating system so that I could implement H.
>>>
>>>>
>>>>
>>>>>
>>>>> Evading this 'simple' question is taken as "No, my proof can't stand such a test".
>>>>> Therefore... everything you have said is.... you imagine it.
>>>>>
>>>> --
>>>> Copyright 2021 Pete Olcott
>>>>
>>>> "Great spirits have always encountered violent opposition from mediocre
>>>> minds." Einstein
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein
>
> Your proof may be 100% correct. But it only valid for your instance P.
> I think you mis-interpreted the conventional HP proof.
>

When we compare the conventional pseudo-code to my C code that statement
seem ridiculously stupid.

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

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

> I have shown an instance P that simulates H in different way(H2) will make H
> behave incorrectly. The conventional HP proof can be demonstrated in C-like

If it is not a pure simulation then it is wrong and all pure simulations
must be identical.

> pseudo-code which is more useful, applicable, most people can comprehend
> immediately. A refutation should be capable of being demonstrated in the same way.
>
> From software engineering point of view, your proof is 'optimized' too soon
> to the lowest level (assembly, TM). Creating a x86utm operating system makes
> no sense to refute HP. Beside, to refute, the 'x86utm operating system' (all) has to
> be present in the paper for peer to reproduce the result.
>

It is enormously easier to analyze the ready made directed graphs of
control flow that assembly language provides rather than have to build
these directed graphs from scratch manually. Any unbroken cycle in a
directed graph is infinite execution that must be aborted.

--
Copyright 2021 Pete Olcott

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

On 6/22/2021 7:56 AM, wij wrote:
> On Tuesday, 22 June 2021 at 19:52:15 UTC+8, wij wrote:
>> On Monday, 21 June 2021 at 23:37:49 UTC+8, olcott wrote:
>>> On 6/21/2021 10:33 AM, wij wrote:
>>>> On Monday, 21 June 2021 at 21:47:51 UTC+8, olcott wrote:
>>>>> On 6/21/2021 2:46 AM, wij wrote:
>>>>>> On Monday, 21 June 2021 at 12:15:27 UTC+8, olcott wrote:
>>>>>>> If you see an animal and test its DNA and confirm that it is definitely
>>>>>>> a cat, what happens when the cat barks?
>>>>>>>
>>>>>>> When we examine the behavior of the Peter Linz Ĥ applied to its own
>>>>>>> Turing machine description: ⟨Ĥ⟩ and simply assume that the embedded halt
>>>>>>> decider at its internal state of Ĥ.qx is a UTM then we find that this
>>>>>>> machine has infinitely nested simulation.
>>>>>>>
>>>>>>> SELF-EVIDENT-TRUTH
>>>>>>> Every computation that never halts unless its simulation is aborted is a
>>>>>>> computation that never halts.
>>>>>>>
>>>>>>> SELF-EVIDENT-TRUTH
>>>>>>> The <Ĥ> <Ĥ> input to the embedded halt decider at Ĥ.qx is a computation
>>>>>>> that never halts unless its simulation is aborted.
>>>>>>>
>>>>>>> ∴ IMPOSSIBLY FALSE CONCLUSION
>>>>>>> The embedded simulating halt decider at Ĥ.qx correctly decides its
>>>>>>> input: <Ĥ> <Ĥ> is a computation that never halts.
>>>>>>>
>>>>>>> The above three elements essentially provide the DNA of the cat.
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>
>>>>>> As I said the question is very simple:
>>>>>> You have to show a correct implement (pseudo-code is OK) of the function
>>>>>> "bool HaltDecider(Func f, Arg a)". This is a MUST.
>>>>>> Other things (paper/talk) are auxiliary.
>>>>> I have done that six months ago using different naming conventions.
>>>>
>>>> This is a very great achievement, deserves 3 Nobel Prizes.
>>>>
>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>
>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>
>>>>
>>>> Quoting the paper makes me baffled completely. It to me just is like searching for a set of
>>>> codes using 'simulator', not a good strategy while static code analyzer is sufficient.
>>> This is my paper that I wrote that has the code that you asked for.
>>>
>>> // 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);
>>> }
>>>
>>> H is a simulating halt decider based on an x86 emulator. I spent nearly
>>> two years creating the x86utm operating system so that I could implement H.
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Evading this 'simple' question is taken as "No, my proof can't stand such a test".
>>>>>> Therefore... everything you have said is.... you imagine it.
>>>>>>
>>>>> --
>>>>> Copyright 2021 Pete Olcott
>>>>>
>>>>> "Great spirits have always encountered violent opposition from mediocre
>>>>> minds." Einstein
>>> --
>>> Copyright 2021 Pete Olcott
>>>
>>> "Great spirits have always encountered violent opposition from mediocre
>>> minds." Einstein
>> Your proof may be 100% correct. But it only valid for your instance P.
>> I think you mis-interpreted the conventional HP proof.
>>
>> I have shown an instance P that simulates H in different way(H2) will make H
>> behave incorrectly. The conventional HP proof can be demonstrated in C-like
>> pseudo-code which is more useful, applicable, most people can comprehend
>> immediately. A refutation should be capable of being demonstrated in the same way.
>>
>> From software engineering point of view, your proof is 'optimized' too soon
>> to the lowest level (assembly, TM). Creating a x86utm operating system makes
>> no sense to refute HP. Beside, to refute, the 'x86utm operating system' (all) has to
>> be present in the paper for peer to reproduce the result.
>
> I just checked the book, [Linz,p320] (Linz's book is the most readable of my 6 similar books)
> ...
> It does not preclude solving the halting problem for specific cases; often we

It does preclude deciding Ĥ applied to ⟨Ĥ⟩ input correctly.
My H/P are a sufficient model of Ĥ / ⟨Ĥ⟩.

> can tell by an analysis of M and 𝐰 whether or not the Turing machine will halt.
> What the theorem says is that this cannot always be done; there is no algorithm
> that can make a correct decision for all Wm and 𝐰.
>

--
Copyright 2021 Pete Olcott

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

On 6/22/2021 6:00 AM, Richard Damon wrote:
> On 6/21/21 10:29 PM, olcott wrote:
>> On 6/21/2021 9:22 PM, Richard Damon wrote:
>>> On 6/21/21 9:39 PM, olcott wrote:
>>>> On 6/21/2021 7:57 PM, André G. Isaak wrote:
>>>
>>>>> How can that possibly be "self-evident" when it doesn't even explain
>>>>> what "its simulation" means. Its simulation of/by what?
>>>>>
>>>>
>>>> We could simplify this and say that any computation that never halts
>>>> unless this computation is aborted is a computation that never halts.
>>>>
>>>
>>> Which with the RIGHT definitions of the words is true. The problem is
>>> you don't use the right defintions of the words.
>>>
>>> Stated more clearly, if a simulation of a computation would never end
>>> unless the simulator of THAT simulation needs to halt it, then the
>>> computation would never halt.
>>
>> That stupidly ignores:
>>
>> When any element of infinitely nested simulations or invocation of the
>> infinite chain of invocations of infinite recursion is terminated then
>> the whole chain terminates,
>
> Which is a FALSE statement. Where do you get this from?

void Infinite_Recursion(u32 N)
{ Infinite_Recursion(N);
}

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

_Infinite_Recursion()
[00000acc](01) 55 push ebp
[00000acd](02) 8bec mov ebp,esp
[00000acf](03) 8b4508 mov eax,[ebp+08]
[00000ad2](01) 50 push eax
[00000ad3](05) e8f4ffffff call 00000acc
[00000ad8](03) 83c404 add esp,+04
[00000adb](01) 5d pop ebp
[00000adc](01) c3 ret
Size in bytes:(0017) [00000adc]

_main()
[00000c1c](01) 55 push ebp
[00000c1d](02) 8bec mov ebp,esp
[00000c1f](01) 51 push ecx
[00000c20](02) 6a01 push +01
[00000c22](05) 68cc0a0000 push 00000acc
[00000c27](05) e840fdffff call 0000096c
[00000c2c](03) 83c408 add esp,+08
[00000c2f](03) 8945fc mov [ebp-04],eax
[00000c32](03) 8b45fc mov eax,[ebp-04]
[00000c35](01) 50 push eax
[00000c36](05) 6857030000 push 00000357
[00000c3b](05) e84cf7ffff call 0000038c
[00000c40](03) 83c408 add esp,+08
[00000c43](02) 33c0 xor eax,eax
[00000c45](02) 8be5 mov esp,ebp
[00000c47](01) 5d pop ebp
[00000c48](01) c3 ret
Size in bytes:(0045) [00000c48]

===============================
....[00000c1c][001016b4][00000000](01) 55 push ebp
....[00000c1d][001016b4][00000000](02) 8bec mov ebp,esp
....[00000c1f][001016b0][00000000](01) 51 push ecx
....[00000c20][001016ac][00000001](02) 6a01 push +01
....[00000c22][001016a8][00000acc](05) 68cc0a0000 push 00000acc
....[00000c27][001016a4][00000c2c](05) e840fdffff call 0000096c
Begin Local Halt Decider Simulation at Machine Address:acc
....[00000acc][00211754][00211758](01) 55 push ebp
....[00000acd][00211754][00211758](02) 8bec mov ebp,esp
....[00000acf][00211754][00211758](03) 8b4508 mov eax,[ebp+08]
....[00000ad2][00211750][00000001](01) 50 push eax
....[00000ad3][0021174c][00000ad8](05) e8f4ffffff call 00000acc
....[00000acc][00211748][00211754](01) 55 push ebp
....[00000acd][00211748][00211754](02) 8bec mov ebp,esp
....[00000acf][00211748][00211754](03) 8b4508 mov eax,[ebp+08]
....[00000ad2][00211744][00000001](01) 50 push eax
....[00000ad3][00211740][00000ad8](05) e8f4ffffff call 00000acc
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
....[00000c2c][001016b0][00000000](03) 83c408 add esp,+08
....[00000c2f][001016b0][00000000](03) 8945fc mov [ebp-04],eax
....[00000c32][001016b0][00000000](03) 8b45fc mov eax,[ebp-04]
....[00000c35][001016ac][00000000](01) 50 push eax
....[00000c36][001016a8][00000357](05) 6857030000 push 00000357
---[00000c3b][001016a8][00000357](05) e84cf7ffff call 0000038c
Input_Would_Halt2 = 0
....[00000c40][001016b0][00000000](03) 83c408 add esp,+08
....[00000c43][001016b0][00000000](02) 33c0 xor eax,eax
....[00000c45][001016b4][00000000](02) 8be5 mov esp,ebp
....[00000c47][001016b8][00100000](01) 5d pop ebp
....[00000c48][001016bc][00000068](01) c3 ret
Number_of_User_Instructions(27)
Number of Instructions Executed(1240)

--
Copyright 2021 Pete Olcott

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

On 6/22/2021 9:05 AM, Peter wrote:
> olcott wrote:
>> If you see an animal and test its DNA and confirm that it is
>> definitely a cat, what happens when the cat barks?
>
> If your definition of "cat" just refers to its DNA, then a barking cat
> is just a cat making an unusual (for a cat) noise.
>
> But note that the word "cat" has been in use for many years before DNA
> was even known to exist and during that time the definition of "cat"
> might well have made reference to what vocalizations it could produce.
>
>

When we can easily see by the x86 execution trace of P that P is a
computation that never halts unless its simulation is aborted by H we
can know with 100% perfect certainty that H correctly decides that its
input P never halts. This remains true that P never halts even when P
does halt because H terminated its simulation of P.

Every computation that only halts because it was aborted by its halt
decider is a computation that never halts.

So the fact that P halts is like a cat that barks, we already know for
sure that it is a cat, so when it barks this does not contradict that it
is a cat.

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 2021-06-21 21:09, olcott wrote:
> On 6/21/2021 9:29 PM, André G. Isaak wrote:
>> On 2021-06-21 19:39, olcott wrote:
>>> On 6/21/2021 7:57 PM, André G. Isaak wrote:
>>>> On 2021-06-21 15:11, olcott wrote:
>>>>> On 6/21/2021 1:24 PM, André G. Isaak wrote:
>>>>>> On 2021-06-20 23:04, Chris M. Thomasson wrote:
>>>>>>> On 6/20/2021 9:15 PM, olcott wrote:
>>>>>>>> If you see an animal and test its DNA and confirm that it is
>>>>>>>> definitely a cat, what happens when the cat barks?
>>>>>>> [...]
>>>>>>>
>>>>>>> Have you been hearing cats bark lately? Wow.
>>>>>>
>>>>>> As long as he's just hearing them bark, we're probably fine.
>>>>>>
>>>>>> It's when the barking cats start telling him to do things (like
>>>>>> kill neighbours, steal catnip, or conquer Liechtenstein) that we
>>>>>> really need to worry.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> The point is that the mere intuition about the halting behavior of
>>>>> Ĥ applied to ⟨Ĥ⟩ is superseded by meticulous sound deductive
>>>>> inference.
>>>>>
>>>>> SELF-EVIDENT-TRUTH
>>>>> Every computation that never halts unless its simulation is aborted
>>>>> is a computation that never halts.
>>>>
>>>> How can that possibly be "self-evident" when it doesn't even explain
>>>> what "its simulation" means. Its simulation of/by what?
>>>>
>>>
>>> We could simplify this and say that any computation that never halts
>>> unless this computation is aborted is a computation that never halts.
>>
>> That's no better. A computation which is aborted doesn't halt. 'Halt'
>> means to reach one of the final states. If you abort something it
>> doesn't reach a final state. But the simulator itself can.
>>
>
> When we are trying to determine whether or not an infinite loop is an
> infinite loop we can debug step through this code and see that it
> endlessly repeats and there is no escape from this endless repetition in
> this code. It is not really that hard.

Which has nothing to do with what I wrote.

>>>>> SELF-EVIDENT-TRUTH
>>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ input to the embedded halt decider at Ĥ.qx is a
>>>>> computation that never halts unless its simulation is aborted.
>>>>
>>>> If that were self-evident, you wouldn't have so many people pointing
>>>> out to you that it is simply wrong. Things can't be both wrong and
>>>> self-evident.
>>>>
>>>
>>> That people simply don't want to bother to pay enough attention to
>>> see that I am right is not actually any rebuttal at all.
>>>
>>>>> ∴ IMPOSSIBLY FALSE CONCLUSION
>>>>
>>>> "Impossibly false" is a meaningless expression. No journal is going
>>>> to take you seriously if this phrase appears anywhere in your work.
>>>>
>>>
>>> I improved this. I now call it the conclusion of sound deduction,
>>> which means exactly the same thing as impossibly false.
>>
>> So where is the sound deduction from which you reach the above
>> conclusion? You start with two premises, one of which is too vague to
>> be interpreted and the other of which is simply false. That's not how
>> deductively sound arguments work.
>
> We really have to look at this in terms of H and P because there is no
> other possible way to make sure that we examine all the details when we
> try to imagine what a Turing machine might do.

Which doesn't answer my question. Where is your 'sound deductive argument'?

>>>>> The embedded simulating halt decider at Ĥ.qx correctly decides its
>>>>> input: ⟨Ĥ⟩ ⟨Ĥ⟩ is a computation that never halts.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ specifies an infinite chain of invocations that is
>>>>> terminated at its third invocation. The first invocation of Ĥ.qx
>>>>> ⟨Ĥ⟩, ⟨Ĥ⟩ is the first element of an infinite chain of invocations.
>>>>>
>>>>> It is common knowledge that when any invocation of an infinite
>>>>> chain of invocations is terminated that the whole chain terminates.
>>>>> That the first element of this infinite chain terminates after its
>>>>> third element has been terminated does not entail that this first
>>>>> element is an actual terminating computation.
>>>>
>>>> No. It isn't "common knowledge". It is simply false.
>>>>
>>>
>>> I will make a common knowledge concrete example:
>>> Infinite recursion is an infinite sequence of invocations right?
>>
>> Sure, but there is no infinite recursion (or recursion period) in the
>> Linz example.
>>
>>> If any element of the infinite sequence of invocations of infinite
>>> recursion is aborted then the whole sequence stops right?
>>
>> Not necessarily. That depends entirely on what is meant by 'abort'.
>>
>>> If the third invocation of the infinite sequence of invocations of
>>> infinite recursion is aborted then the whole sequence stops right?
>>
>> No. The third invocation is aborted. The simulator itself continues to
>> run and is able to halt.
>>
>>> Was it really that hard to see the above three steps on the basis of
>>> my claim of common knowledge?
>>
>> Things that you believe and 'common knowledge' are not the same thing.
>>
>>>> And if the simulation is terminated after the third call to Ĥ, the
>>>> you don't have an infinite chain of calls. You have a chain of three
>>>> calls.
>>>>
>>>
>>> When the halt decider is analyzing the behavior stipulated by a
>>> finite string it is incorrect for the halt decider to conflate its
>>> own behavior in this analysis.
>>
>> And I am not conflating them. When you abort the simulation that
>> doesn't entail aborting the simulator. You conflate them by concluding
>> that the topmost program doesn't halt based on what happens to the
>> program it is simulating.
>>
>>> The question that the halt decider is answering is whether or not a
>>> pure simulation/execution of the input must be aborted to prevent the
>>> infinite execution of this input.
>>>
>>>>> For the first element to be an actual terminating computation it
>>>>> must terminate without any of the elements of the infinite chain of
>>>>> invocations being terminated.
>>>>
>>>> This is just plain silly.
>>>
>>> See my infinite recursion example above.
>>
>> As I said, the above is just plain silly.
>>
>>>> If some program H simulates another program Y along with an input
>>>> string but has the ability to terminate a simulation, then there are
>>>> three possibilities:
>>>>
>>>> A) The simulation is allowed to continue until Y reaches one of its
>>>> final states. In such a case we can say that Y halts. Since Y halts,
>>>> H can also halt.
>>>>
>>>> B) The simulation is allowed to continue forever, but it never
>>>> reaches a final state. The simulation continues forever. In this
>>>> case, Y doesn't halt. H therefore also doesn't halt. Of course, this
>>>> option would be difficult to empirically verify since we can't
>>>> actually observe something running for an infinite amount of time.
>>>>
>>>> C) H decides to discontinue the simulation. In this case the
>>>> simulation neither halts nor runs forever. It may be that that Y is
>>>> non-halting, or it may be that H simply discontinued the simulation
>>>> prematurely. But in either of these two cases, H can halt.
>>>>
>>>> André
>>>>
>>>
>>> As I have said so very many hundreds of times now that you really
>>> should not have made such a terrible mistake with part C
>>
>> There is no mistake in C.
>
>
> C) H decides to discontinue the simulation.
> This is very terribly incorrect
>
> H MUST stop its simulation of P or P never halts

On Tuesday, 22 June 2021 at 22:06:42 UTC+8, olcott wrote:
> On 6/22/2021 6:52 AM, wij wrote:
> > On Monday, 21 June 2021 at 23:37:49 UTC+8, olcott wrote:
> >> On 6/21/2021 10:33 AM, wij wrote:
> >>> On Monday, 21 June 2021 at 21:47:51 UTC+8, olcott wrote:
> >>>> On 6/21/2021 2:46 AM, wij wrote:
> >>>>> On Monday, 21 June 2021 at 12:15:27 UTC+8, olcott wrote:
> >>>>>> If you see an animal and test its DNA and confirm that it is definitely
> >>>>>> a cat, what happens when the cat barks?
> >>>>>>
> >>>>>> When we examine the behavior of the Peter Linz Ĥ applied to its own
> >>>>>> Turing machine description: ⟨Ĥ⟩ and simply assume that the embedded halt
> >>>>>> decider at its internal state of Ĥ.qx is a UTM then we find that this
> >>>>>> machine has infinitely nested simulation.
> >>>>>>
> >>>>>> SELF-EVIDENT-TRUTH
> >>>>>> Every computation that never halts unless its simulation is aborted is a
> >>>>>> computation that never halts.
> >>>>>>
> >>>>>> SELF-EVIDENT-TRUTH
> >>>>>> The <Ĥ> <Ĥ> input to the embedded halt decider at Ĥ..qx is a computation
> >>>>>> that never halts unless its simulation is aborted.
> >>>>>>
> >>>>>> ∴ IMPOSSIBLY FALSE CONCLUSION
> >>>>>> The embedded simulating halt decider at Ĥ.qx correctly decides its
> >>>>>> input: <Ĥ> <Ĥ> is a computation that never halts.
> >>>>>>
> >>>>>> The above three elements essentially provide the DNA of the cat.
> >>>>>>
> >>>>>>
> >>>>>> 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
> >>>>>
> >>>>> As I said the question is very simple:
> >>>>> You have to show a correct implement (pseudo-code is OK) of the function
> >>>>> "bool HaltDecider(Func f, Arg a)". This is a MUST.
> >>>>> Other things (paper/talk) are auxiliary.
> >>>> I have done that six months ago using different naming conventions.
> >>>
> >>> This is a very great achievement, deserves 3 Nobel Prizes.
> >>>
> >>>> Halting problem undecidability and infinitely nested simulation
> >>>>
> >>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
> >>>>
> >>>
> >>> Quoting the paper makes me baffled completely. It to me just is like searching for a set of
> >>> codes using 'simulator', not a good strategy while static code analyzer is sufficient.
> >> This is my paper that I wrote that has the code that you asked for.
> >>
> >> // 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);
> >> }
> >>
> >> H is a simulating halt decider based on an x86 emulator. I spent nearly
> >> two years creating the x86utm operating system so that I could implement H.
> >>>
> >>>>
> >>>>
> >>>>>
> >>>>> Evading this 'simple' question is taken as "No, my proof can't stand such a test".
> >>>>> Therefore... everything you have said is.... you imagine it.
> >>>>>
> >>>> --
> >>>> Copyright 2021 Pete Olcott
> >>>>
> >>>> "Great spirits have always encountered violent opposition from mediocre
> >>>> minds." Einstein
> >> --
> >> Copyright 2021 Pete Olcott
> >>
> >> "Great spirits have always encountered violent opposition from mediocre
> >> minds." Einstein
> >
> > Your proof may be 100% correct. But it only valid for your instance P.
> > I think you mis-interpreted the conventional HP proof.
> >
> When we compare the conventional pseudo-code to my C code that statement
> seem ridiculously stupid.
>
> procedure compute_g(i):
> if f(i, i) == 0 then
> return 0
> else
> loop forever // (Wikipedia:Halting Problem)
> // 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);
> }
> > I have shown an instance P that simulates H in different way(H2) will make H
> > behave incorrectly. The conventional HP proof can be demonstrated in C-like
> If it is not a pure simulation then it is wrong and all pure simulations
> must be identical.

H2 is designed to simulate H in different way.
Why anyone's simulation of H2 is not a pure simulation while your H is?

> > pseudo-code which is more useful, applicable, most people can comprehend
> > immediately. A refutation should be capable of being demonstrated in the same way.
> >
> > From software engineering point of view, your proof is 'optimized' too soon
> > to the lowest level (assembly, TM). Creating a x86utm operating system makes
> > no sense to refute HP. Beside, to refute, the 'x86utm operating system' (all) has to
> > be present in the paper for peer to reproduce the result.
> >
> It is enormously easier to analyze the ready made directed graphs of
> control flow that assembly language provides rather than have to build
> these directed graphs from scratch manually. Any unbroken cycle in a
> directed graph is infinite execution that must be aborted.
> --
> Copyright 2021 Pete Olcott
>
> "Great spirits have always encountered violent opposition from mediocre
> minds." Einstein

You fabricated a halt-decider which only works in your head.

On 6/22/2021 11:47 AM, André G. Isaak wrote:
> On 2021-06-21 21:09, olcott wrote:
>> On 6/21/2021 9:29 PM, André G. Isaak wrote:
>>> On 2021-06-21 19:39, olcott wrote:
>>>> On 6/21/2021 7:57 PM, André G. Isaak wrote:
>>>>> On 2021-06-21 15:11, olcott wrote:
>>>>>> On 6/21/2021 1:24 PM, André G. Isaak wrote:
>>>>>>> On 2021-06-20 23:04, Chris M. Thomasson wrote:
>>>>>>>> On 6/20/2021 9:15 PM, olcott wrote:
>>>>>>>>> If you see an animal and test its DNA and confirm that it is
>>>>>>>>> definitely a cat, what happens when the cat barks?
>>>>>>>> [...]
>>>>>>>>
>>>>>>>> Have you been hearing cats bark lately? Wow.
>>>>>>>
>>>>>>> As long as he's just hearing them bark, we're probably fine.
>>>>>>>
>>>>>>> It's when the barking cats start telling him to do things (like
>>>>>>> kill neighbours, steal catnip, or conquer Liechtenstein) that we
>>>>>>> really need to worry.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> The point is that the mere intuition about the halting behavior of
>>>>>> Ĥ applied to ⟨Ĥ⟩ is superseded by meticulous sound deductive
>>>>>> inference.
>>>>>>
>>>>>> SELF-EVIDENT-TRUTH
>>>>>> Every computation that never halts unless its simulation is
>>>>>> aborted is a computation that never halts.
>>>>>
>>>>> How can that possibly be "self-evident" when it doesn't even
>>>>> explain what "its simulation" means. Its simulation of/by what?
>>>>>
>>>>
>>>> We could simplify this and say that any computation that never halts
>>>> unless this computation is aborted is a computation that never halts.
>>>
>>> That's no better. A computation which is aborted doesn't halt. 'Halt'
>>> means to reach one of the final states. If you abort something it
>>> doesn't reach a final state. But the simulator itself can.
>>>
>>
>> When we are trying to determine whether or not an infinite loop is an
>> infinite loop we can debug step through this code and see that it
>> endlessly repeats and there is no escape from this endless repetition
>> in this code. It is not really that hard.
>
> Which has nothing to do with what I wrote.
>

It explains the details of how a computation that must be aborted by the
halt decider to prevent the infinite execution of this computation <is>
a computation that never halts.

>>>>>> SELF-EVIDENT-TRUTH
>>>>>> The ⟨Ĥ⟩ ⟨Ĥ⟩ input to the embedded halt decider at Ĥ.qx is a
>>>>>> computation that never halts unless its simulation is aborted.
>>>>>
>>>>> If that were self-evident, you wouldn't have so many people
>>>>> pointing out to you that it is simply wrong. Things can't be both
>>>>> wrong and self-evident.
>>>>>
>>>>
>>>> That people simply don't want to bother to pay enough attention to
>>>> see that I am right is not actually any rebuttal at all.
>>>>
>>>>>> ∴ IMPOSSIBLY FALSE CONCLUSION
>>>>>
>>>>> "Impossibly false" is a meaningless expression. No journal is going
>>>>> to take you seriously if this phrase appears anywhere in your work.
>>>>>
>>>>
>>>> I improved this. I now call it the conclusion of sound deduction,
>>>> which means exactly the same thing as impossibly false.
>>>
>>> So where is the sound deduction from which you reach the above
>>> conclusion? You start with two premises, one of which is too vague to
>>> be interpreted and the other of which is simply false. That's not how
>>> deductively sound arguments work.
>>
>> We really have to look at this in terms of H and P because there is no
>> other possible way to make sure that we examine all the details when
>> we try to imagine what a Turing machine might do.
>
> Which doesn't answer my question. Where is your 'sound deductive argument'?
>

(a) Every computation P that never halts unless the halt decider H
aborts this computation is a computation that never halts.

(b) X is a computation that never halts unless it is aborted by its halt
decider.

∴ (c) X is a computation that is correctly decided to be a computation
that never halts.

>>>>>> The embedded simulating halt decider at Ĥ.qx correctly decides its
>>>>>> input: ⟨Ĥ⟩ ⟨Ĥ⟩ is a computation that never halts.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ⟩ specifies an infinite chain of invocations that is
>>>>>> terminated at its third invocation. The first invocation of Ĥ.qx
>>>>>> ⟨Ĥ⟩, ⟨Ĥ⟩ is the first element of an infinite chain of invocations.
>>>>>>
>>>>>> It is common knowledge that when any invocation of an infinite
>>>>>> chain of invocations is terminated that the whole chain
>>>>>> terminates. That the first element of this infinite chain
>>>>>> terminates after its third element has been terminated does not
>>>>>> entail that this first element is an actual terminating computation.
>>>>>
>>>>> No. It isn't "common knowledge". It is simply false.
>>>>>
>>>>
>>>> I will make a common knowledge concrete example:
>>>> Infinite recursion is an infinite sequence of invocations right?
>>>
>>> Sure, but there is no infinite recursion (or recursion period) in the
>>> Linz example.
>>>
>>>> If any element of the infinite sequence of invocations of infinite
>>>> recursion is aborted then the whole sequence stops right?
>>>
>>> Not necessarily. That depends entirely on what is meant by 'abort'.
>>>
>>>> If the third invocation of the infinite sequence of invocations of
>>>> infinite recursion is aborted then the whole sequence stops right?
>>>
>>> No. The third invocation is aborted. The simulator itself continues
>>> to run and is able to halt.
>>>
>>>> Was it really that hard to see the above three steps on the basis of
>>>> my claim of common knowledge?
>>>
>>> Things that you believe and 'common knowledge' are not the same thing.
>>>
>>>>> And if the simulation is terminated after the third call to Ĥ, the
>>>>> you don't have an infinite chain of calls. You have a chain of
>>>>> three calls.
>>>>>
>>>>
>>>> When the halt decider is analyzing the behavior stipulated by a
>>>> finite string it is incorrect for the halt decider to conflate its
>>>> own behavior in this analysis.
>>>
>>> And I am not conflating them. When you abort the simulation that
>>> doesn't entail aborting the simulator. You conflate them by
>>> concluding that the topmost program doesn't halt based on what
>>> happens to the program it is simulating.
>>>
>>>> The question that the halt decider is answering is whether or not a
>>>> pure simulation/execution of the input must be aborted to prevent
>>>> the infinite execution of this input.
>>>>
>>>>>> For the first element to be an actual terminating computation it
>>>>>> must terminate without any of the elements of the infinite chain
>>>>>> of invocations being terminated.
>>>>>
>>>>> This is just plain silly.
>>>>
>>>> See my infinite recursion example above.
>>>
>>> As I said, the above is just plain silly.
>>>
>>>>> If some program H simulates another program Y along with an input
>>>>> string but has the ability to terminate a simulation, then there
>>>>> are three possibilities:
>>>>>
>>>>> A) The simulation is allowed to continue until Y reaches one of its
>>>>> final states. In such a case we can say that Y halts. Since Y
>>>>> halts, H can also halt.
>>>>>
>>>>> B) The simulation is allowed to continue forever, but it never
>>>>> reaches a final state. The simulation continues forever. In this
>>>>> case, Y doesn't halt. H therefore also doesn't halt. Of course,
>>>>> this option would be difficult to empirically verify since we can't
>>>>> actually observe something running for an infinite amount of time.
>>>>>
>>>>> C) H decides to discontinue the simulation. In this case the
>>>>> simulation neither halts nor runs forever. It may be that that Y is
>>>>> non-halting, or it may be that H simply discontinued the simulation
>>>>> prematurely. But in either of these two cases, H can halt.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> As I have said so very many hundreds of times now that you really
>>>> should not have made such a terrible mistake with part C
>>>
>>> There is no mistake in C.
>>
>>
>> C) H decides to discontinue the simulation.
>> This is very terribly incorrect
>>
>> H MUST stop its simulation of P or P never halts
>
> Which is subsumed under option C. The above enumerates all logical
> possibilities.
>

On 6/22/2021 12:02 PM, wij wrote:
> On Tuesday, 22 June 2021 at 22:06:42 UTC+8, olcott wrote:
>> On 6/22/2021 6:52 AM, wij wrote:
>>> On Monday, 21 June 2021 at 23:37:49 UTC+8, olcott wrote:
>>>> On 6/21/2021 10:33 AM, wij wrote:
>>>>> On Monday, 21 June 2021 at 21:47:51 UTC+8, olcott wrote:
>>>>>> On 6/21/2021 2:46 AM, wij wrote:
>>>>>>> On Monday, 21 June 2021 at 12:15:27 UTC+8, olcott wrote:
>>>>>>>> If you see an animal and test its DNA and confirm that it is definitely
>>>>>>>> a cat, what happens when the cat barks?
>>>>>>>>
>>>>>>>> When we examine the behavior of the Peter Linz Ĥ applied to its own
>>>>>>>> Turing machine description: ⟨Ĥ⟩ and simply assume that the embedded halt
>>>>>>>> decider at its internal state of Ĥ.qx is a UTM then we find that this
>>>>>>>> machine has infinitely nested simulation.
>>>>>>>>
>>>>>>>> SELF-EVIDENT-TRUTH
>>>>>>>> Every computation that never halts unless its simulation is aborted is a
>>>>>>>> computation that never halts.
>>>>>>>>
>>>>>>>> SELF-EVIDENT-TRUTH
>>>>>>>> The <Ĥ> <Ĥ> input to the embedded halt decider at Ĥ.qx is a computation
>>>>>>>> that never halts unless its simulation is aborted.
>>>>>>>>
>>>>>>>> ∴ IMPOSSIBLY FALSE CONCLUSION
>>>>>>>> The embedded simulating halt decider at Ĥ.qx correctly decides its
>>>>>>>> input: <Ĥ> <Ĥ> is a computation that never halts.
>>>>>>>>
>>>>>>>> The above three elements essentially provide the DNA of the cat.
>>>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>>>
>>>>>>> As I said the question is very simple:
>>>>>>> You have to show a correct implement (pseudo-code is OK) of the function
>>>>>>> "bool HaltDecider(Func f, Arg a)". This is a MUST.
>>>>>>> Other things (paper/talk) are auxiliary.
>>>>>> I have done that six months ago using different naming conventions.
>>>>>
>>>>> This is a very great achievement, deserves 3 Nobel Prizes.
>>>>>
>>>>>> Halting problem undecidability and infinitely nested simulation
>>>>>>
>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>
>>>>>
>>>>> Quoting the paper makes me baffled completely. It to me just is like searching for a set of
>>>>> codes using 'simulator', not a good strategy while static code analyzer is sufficient.
>>>> This is my paper that I wrote that has the code that you asked for.
>>>>
>>>> // 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);
>>>> }
>>>>
>>>> H is a simulating halt decider based on an x86 emulator. I spent nearly
>>>> two years creating the x86utm operating system so that I could implement H.
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Evading this 'simple' question is taken as "No, my proof can't stand such a test".
>>>>>>> Therefore... everything you have said is.... you imagine it.
>>>>>>>
>>>>>> --
>>>>>> Copyright 2021 Pete Olcott
>>>>>>
>>>>>> "Great spirits have always encountered violent opposition from mediocre
>>>>>> minds." Einstein
>>>> --
>>>> Copyright 2021 Pete Olcott
>>>>
>>>> "Great spirits have always encountered violent opposition from mediocre
>>>> minds." Einstein
>>>
>>> Your proof may be 100% correct. But it only valid for your instance P.
>>> I think you mis-interpreted the conventional HP proof.
>>>
>> When we compare the conventional pseudo-code to my C code that statement
>> seem ridiculously stupid.
>>
>> procedure compute_g(i):
>> if f(i, i) == 0 then
>> return 0
>> else
>> loop forever // (Wikipedia:Halting Problem)
>> // 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);
>> }
>>> I have shown an instance P that simulates H in different way(H2) will make H
>>> behave incorrectly. The conventional HP proof can be demonstrated in C-like
>> If it is not a pure simulation then it is wrong and all pure simulations
>> must be identical.
>
> H2 is designed to simulate H in different way.
> Why anyone's simulation of H2 is not a pure simulation while your H is?
>

Every simulation that is not a pure simulation is a wrong simulation.
If your simulation is not a pure simulation then it is wrong.

If your simulation is a pure simulation then it cannot possibly differ
from any other pure simulation. That you claim that it is different
proves that it is wrong.

>>> pseudo-code which is more useful, applicable, most people can comprehend
>>> immediately. A refutation should be capable of being demonstrated in the same way.
>>>
>>> From software engineering point of view, your proof is 'optimized' too soon
>>> to the lowest level (assembly, TM). Creating a x86utm operating system makes
>>> no sense to refute HP. Beside, to refute, the 'x86utm operating system' (all) has to
>>> be present in the paper for peer to reproduce the result.
>>>
>> It is enormously easier to analyze the ready made directed graphs of
>> control flow that assembly language provides rather than have to build
>> these directed graphs from scratch manually. Any unbroken cycle in a
>> directed graph is infinite execution that must be aborted.
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein
>
> You fabricated a halt-decider which only works in your head.
>

--
Copyright 2021 Pete Olcott

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