What if a cat barks?

[olcott]

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

[Chris M. Thomasson]

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.

[olcott]

On 6/20/2021 11: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?
>
> 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

So when we check the DNA of the cat [ review the sound deductive
inference chain of the embedded halt decider's decision to abort the
simulation of Ĥ(⟨Ĥ⟩) ] We find that even when the cat barks [ Ĥ(⟨Ĥ⟩)
halts ] that this does not contradict that the cat is indeed a cat [
that Ĥ(⟨Ĥ⟩) really does specify a computation that never halts ].


Here is how the cat barks [ non-halting computation Ĥ(⟨Ĥ⟩) halts ]:
Ĥ(⟨Ĥ⟩) specifies an infinite chain of invocation that is terminated
at its third invocation. The first call from Ĥ(⟨Ĥ⟩) to H(⟨Ĥ⟩, ⟨Ĥ⟩) is
the first element of the infinite chain of invocations.

Everyone knows 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.

[olcott]

On 6/21/2021 1:24 PM, André G. Isaak wrote:

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

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.

[olcott]

On 6/21/2021 4:11 PM, 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 (premise[1])

Every computation that never halts unless its simulation is aborted is a
computation that never halts.

Self-Evident-Truth (premise[2])

The ⟨Ĥ⟩ ⟨Ĥ⟩ input to the embedded halt decider at Ĥ.qx is a computation
that never halts unless its simulation is aborted.

∴ Sound Deductive Conclusion

[olcott]

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.

[olcott]

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.


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

100% of every single detail of the execution trace of the input without
the most minute details not totally and completely specified. We just
flat out can't do that with TM's of the sophistication of H and P.
With the Linz proof we are left to simply imagine hundreds of thousands
of steps. With my C/x86 code we see every single relevant detail.

Crucially we the absolute necessity for H to abort its simulation of P
on the basis of the actual x86 execution trace of P.

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

[olcott]

On 6/22/2021 11:47 AM, André G. Isaak wrote:

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

> Which is subsumed under option C. The above enumerates all logical
> possibilities.
>

Then you needs a (D)

(C) H MUST stop its simulation of P or P never halts

(D) H stops its simulation of P for some other reason.

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

> Option C never said anything about why it aborts the simulation.

That is its horribly terrible error. To simply ignore the key most
important halt deciding criteria is a terribly awful mistake.


> Whether
> it aborts it because it MUST do so (or, in your case, because you think
> it MUST stop its simulation) or for some other reason, or for no reason
> at all, H can still halt.
>

When-so-ever H must abort its input to prevent the infinite execution of
this input H always correctly decides that this input never halts 100%
of all the time.

We can know this in the same way that we know that a dead person is not
alive.

>> 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.
>>
>>
>>> 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?
>>
>> 100% of every single detail of the execution trace of the input
>> without the most minute details not totally and completely specified.
>> We just flat out can't do that with TM's of the sophistication of H
>> and P.
>

> Of course we can. People work with actual Turing Machines all the time
> and they don't have to 'imagine' anything.

Only for very trivial things.
No one has even attempted to write a C to TM compiler.

> You just don't want to work
> with actual Turing Machines because you don't understand what they are
> or how they work.
>
> André
>

The lack of direct memory access cripples the expressiveness of the TM
model.

[olcott]

On 6/22/2021 7:31 PM, wij wrote:
> On Wednesday, 23 June 2021 at 01:22:47 UTC+8, olcott wrote:
>> On 6/22/2021 12:16 PM, wij wrote:
>>> On Wednesday, 23 June 2021 at 01:14:01 UTC+8, wij wrote:
>>>> On Wednesday, 23 June 2021 at 01:08:26 UTC+8, olcott wrote:
>>>>> 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:

>>>>>>>>>>>> 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.
>>>> Your H does not do what P exactly does. That you claim that it 'simulate'
>>>>> 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
>>>

>>> Your H does not do what P exactly does. That you claim that it 'simulate'
>>> proves that it is wrong.
>>>
>> H is a simulator and P is not a simulator therefore if H did exactly
>> what P does H would be wrong. H does show exactly what P does.

>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein
>

> H2 would do functionally exactly the same H does (H2 can show exactly what H
> does), whatever you call H is (pure?). Manipulating descriptive words is not a
> good sign you honestly want to understand the issues of your proof.
>
> Since you made your refutation a real program (this is very good), but it
> can't stand real tests in my estimate.
> In any cases, reviewer need to duplicate your running program to reproduce
> your result and claim. Everything else is just talk.
>

Anyone that simply understands what I am saying in this paper regarding
my C/x86 proof can easily verify that I am correct.

Halting problem undecidability and infinitely nested simulation

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

> There are tons of undecidable problems:
> https://en.wikipedia.org/wiki/List_of_undecidable_problems
> But I don't think you understand the meaning of your proof.

[olcott]

On 6/22/2021 8:47 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>
>> On 6/21/2021 4:16 AM, Ben Bacarisse wrote:

>>> 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
>
> Well he flip-flops on this. He keeps saying that he has a halt decider
> (sometimes without realising that he's said it) but when this is pointed
> out he claims he only cares about the one case -- the "hat" construction
> given in so many proofs.
>
> That, alone, would be noteworthy because it's impossible. Way back in
> Dec 2018, he was waffling about a decider for one case (which is
> trivial), when someone (I think it was Mike Terry) spotted that he was
> actually claiming to have a TM H that gave the correct result for the
> computation <[H^], [H^]> (my notation -- I'll explain it if you really
> care about the details). Once it was pointed out that everyone knows
> this is impossible PO was delighted and wrote things like:
>
> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
> specs does not exist. I now have a fully encoded pair of Turing
> Machines H / Ĥ proving them wrong."
>
> "I now have an actual H that decides actual halting for an actual (Ĥ,
> Ĥ) input pair. I have to write the UTM to execute this code, that
> should not take very long. The key thing is the H and Ĥ are 100%
> fully encoded as actual Turing machines."
>
> "I am waiting to encode the UTM in C++ so that I can actually execute
> H on the input pair: (Ĥ, Ĥ). This should take a week or two. It is not
> a universal halt decider, yet it is exactly and precisely the Peter
> Linz H and Ĥ, with H actually deciding input pair: (Ĥ, Ĥ) on the basis
> of Ĥ actually deciding itself."
>
> I refer to this as the Big Lie because, of course, he never had any such
> pair of TMs, but as you can see, it was getting one (impossible) case
> right that was the jumping-off point for the last two an half years of
> nonsense.
>

Yes and of course when I make a C program that is computationally
equivalent to the standard relation between the HP halt decider and its
impossible input and show all of the steps of how this halt decider
correctly decides this "known" to be impossible input that does not
count at all because it is not 100% perfectly an actual TM.

The C program is implemented in the x86utm operating system using an
actual x86 emulator. This work began in earnest at the end of 2019 after
the huge false start of trying to implement an interpreter for a tiny
subset of C from scratch.

Halting problem undecidability and infinitely nested simulation

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

Ben: You (and others) have affirmed premise (1).

You might be able to see that the conclusion logically follows from
premise (1) and premise (2).

There was one very highly qualified person that has affirmed that
premise (2) is a verified fact.

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

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

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

[olcott]

On 6/22/2021 10:00 PM, Richard Damon wrote:

> Except that it isn't because H^ doesn't make copies as it is supposed to
> so you don't end up with a true equivalent.

Others know that it is sufficiently equivalent.

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

Its pretty obvious that the C code and the pseudo-code are saying
exactly the same thing.

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

> This lets you 'cheat' to
> detect the recursion that doesn't really exist in the original problem.

Because others know that it is sufficiently equivalent they can also see
the infinite recursion in the Linz proof as soon as they sufficiently
understand my x86/C proof.

[olcott]

On 6/23/2021 11:00 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
>> On Wednesday, 23 June 2021 at 11:57:06 UTC+1, Richard Damon wrote:

>>> On 6/22/21 11:21 PM, olcott wrote:
>>>> On 6/22/2021 10:00 PM, Richard Damon wrote:
>>>>>
>>>>>> Yes and of course when I make a C program that is computationally
>>>>>> equivalent to the standard relation between the HP halt decider and its
>>>>>> impossible input and show all of the steps of how this halt decider
>>>>>> correctly decides this "known" to be impossible input that does not
>>>>>> count at all because it is not 100% perfectly an actual TM.
>>>>>
>>>>> Except that it isn't because H^ doesn't make copies as it is supposed to
>>>>> so you don't end up with a true equivalent.
>>>>
>>>> Others know that it is sufficiently equivalent.

>>> There is no 'sufficiently' it only is or it isn't.
>>>
>>> Is 2.0001 sufficiently equivalent to 2? Its pretty close, but is it
>>> equivalent.
>>>
>> PO's system uses x86 code instead of Turing machines. That enables him
>> to detect when the halt decider is being called on a program including itself.
>> That's not the root of the error (the halting problem also applies to x86
>> programs) but it is the root of the confusion.
>> PO obviously thinks that he has found a counter example to Linz's
>> impossible H.
>
> I find this hard to believe but I accept that there are minds out there
> that I have little understanding of. Even so, how can anyone think they
> have a decider M that is correct about <[M^],[M^]> if
>
> a. M rejects <[M^],[M^]>, but
> b. M^([M^]) halts?

>

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

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

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

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

Conclusion (3) From the above true premises it necessarily follows that

simulating halt decider H correctly reports that its input: (P,P) never
halts.

When (1) is true and (2) is true and (1) & (2) logically entails that
(3) is true, nothing can possibly contradict that (3) is true.

Make sure you carefully ignore all those words because that is the only
way that any fake ruse of a rebuttal can continue.

Halting problem undecidability and infinitely nested simulation

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

> It seems impossible to me that anyone can accept these facts and claim
> to have "a counter example" to the proof's hat construction. Surely
> even PO can see that such a TM is not correct? It think he know.
> That's why he was, briefly, honest about redefining what "halting"
> means. It was only after he realised that everyone would ignore him if
> he was talking about some other notion of "halting" that he stopped
> being clear about this redefinition.
>
> Further, PO recently posted this:
>
> | Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
> | if M applied to wM halts, and
> |
> | Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
> | if M applied to wM does not halt
>
> which is (roughly) Linz's notation for what H^, built from a correct H,
> should do. I showed the last tiny step which is to set wM = <Ĥ> (so M
> is Ĥ) to get
>
> Ĥ.q0 <Ĥ> ⊢* Ĥ.qx <Ĥ> <Ĥ> ⊢* Ĥ.qy ⊢* ∞
> if Ĥ applied to <Ĥ> halts, and
>
> Ĥ.q0 <Ĥ> ⊢* Ĥ.qx <Ĥ> <Ĥ> ⊢* Ĥ.qn
> if Ĥ applied to <Ĥ> does not halt
>
> which, in words is, "Ĥ run (from state q0) on input <Ĥ> does not halt if
> Ĥ applied to <Ĥ> halts", and "Ĥ run (from state q0) on input <Ĥ> halts
> (in state qn) if Ĥ applied to <Ĥ> does not halt".
>
> In reply, PO said he understood that, but then went on to say more
> things as if anything, true or false, can alter the fact that the
> assumption about H leads to a contradiction. Do you think he genuinely
> believes that saying more things, even true things, can "undo" a
> contradiction? That is a strange mind indeed.

[olcott]

On 6/23/2021 12:29 PM, André G. Isaak wrote:
> On 2021-06-22 13:17, olcott wrote:
>> On 6/22/2021 1:38 PM, André G. Isaak wrote:

>>> On 2021-06-22 11:05, olcott wrote:
>>>> On 6/22/2021 11:47 AM, André G. Isaak wrote:
>

> <snip>
>
>> In the case of the simulation of P it is verified on the basis of the
>> x86 execution trace of B, thus an established verified fact.
>
> Except that an execution trace doesn't 'verify' anything. No one doubts
> that your program decides that P(P) == 0. But unless the logic
> underlying your program is actually correct, this result tells us
> nothing. And you haven't provided any sort of proof that the logic
> underlying your program is actually correct.

>

Halting problem undecidability and infinitely nested simulation

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

Sure I have. When we look as page 3 and 4 of the above paper it is very
easy to see that H does faithfully simulate the execution of P and that
P has no escape from infinite execution in its own code.

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

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

Conclusion(3) From the above true premises it necessarily follows that

simulating halt decider H correctly reports that its input: (P,P) never
halts.

Only by very diligently making sure to not pay attention is it possible
to maintain the ruse of a fake rebuttal.

> And it isn't correct. Most significantly, your trace skips over certain
> portions of the P being simulated which completely invalidates its results.
>

The question is:

Does the simulation of P have to be aborted to prevent its infinite
execution?

As long as the answer to this question is [YES] then Premise(2) is
perfectly satisfied and your objection is utterly pointless.

As long as the answer to this question is [YES] then Premise(2) is
perfectly satisfied and your objection is utterly pointless.

As long as the answer to this question is [YES] then Premise(2) is
perfectly satisfied and your objection is utterly pointless.

As long as the answer to this question is [YES] then Premise(2) is
perfectly satisfied and your objection is utterly pointless.


> <snip>

>
>>>>> Option C never said anything about why it aborts the simulation.
>>>>
>>>> That is its horribly terrible error. To simply ignore the key most
>>>> important halt deciding criteria is a terribly awful mistake.
>>>

>>> Clearly you have reading comprehension problems. The halting status
>>> of the *simulator* has nothing to do with the halting status of its
>>> input computation if the simulator is capable of aborting the
>>> simulation of that input. That applies equally to your (C) and your
>>> (D). In either case, the simulator can halt.
>>>
>>
>> An intentional fallacy of equivocation error that very persistently
>> tries to hide the correct halt deciding criteria.
>>
>> Key to refuting all the conventional HP undecidability proofs
>>
>> -- H MUST stop its simulation of P or P never halts
>
> I'm not hiding anything. Whether the halt deciding criterion is correct
> or not has no bearing on my claim, which is that once a simulation is
> aborted the simulator can still halt. That's true of a simulator using a
> 'correct' criterion just as much as its true of one which simply aborts
> its simulation at random.
>
> André

[olcott]

On 6/23/2021 6:13 PM, André G. Isaak wrote:

> On 2021-06-23 14:07, olcott wrote:
>> On 6/23/2021 12:29 PM, André G. Isaak wrote:
>>> On 2021-06-22 13:17, olcott wrote:
>>>> On 6/22/2021 1:38 PM, André G. Isaak wrote:
>>>>> On 2021-06-22 11:05, olcott wrote:
>>>>>> On 6/22/2021 11:47 AM, André G. Isaak wrote:
>>>
>>> <snip>
>>>
>>>> In the case of the simulation of P it is verified on the basis of
>>>> the x86 execution trace of B, thus an established verified fact.
>>>
>>> Except that an execution trace doesn't 'verify' anything. No one
>>> doubts that your program decides that P(P) == 0. But unless the logic
>>> underlying your program is actually correct, this result tells us
>>> nothing. And you haven't provided any sort of proof that the logic
>>> underlying your program is actually correct.
>>>
>>
>> Halting problem undecidability and infinitely nested simulation
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>> Sure I have. When we look as page 3 and 4 of the above paper it is
>> very easy to see that H does faithfully simulate the execution of P
>> and that P has no escape from infinite execution in its own code.
>

> No. First, it *doesn't* faithfully simulate the code. If H(P, P) is
> simulating P(P), then P(P) can't call the main H -- it can only invoke a
> copy of H *within the simulation*.
>

It is actually and quite factually not a copy.
I have had to say this hundreds of times now.

It is the same freaking machine language at the
same freaking machine language address.

> Second, even if we ignore the above, the decision criterion you use is
> flawed because it completely ignores all conditional branches contained
> within P's copy of H, and it's these conditional branches which prevent
> P(P) from being an 'infinitely recursive' computation.
>

Unless we keep the independent variable separate from the dependent
variable our analysis is incorrect.

The independent variable is the cause. Its value is independent of other
variables in your study.

The dependent variable is the effect. Its value depends on changes in
the independent variable.

https://www.scribbr.com/methodology/independent-and-dependent-variables/

When we are asking whether or not H must abort its simulation of P we
examine the simulation of P. We must not examine the behavior of H.

> Once again, traces do not constitute proofs. If you want to be taken
> seriously, you need to provide some actual *proof* that your algorithm
> works.

That my proof does not conform to academic conventions does not show
that it is not a proof. As long as I start with a set of premises that
can be verified as true and my conclusion logically follows from these
true premises then I definitely have a proof even if everyone in the
universe disagrees.

>> Premise(1) Every computation that never halts unless its simulation is
>> aborted is a computation that never halts. This verified as true on
>> the basis of the meaning of its words.
>>
>> Premise(2) The simulation of the input to H(P,P) never halts without
>> being aborted is a verified fact on the basis of its x86 execution
>> trace. (shown below).
>>
>> Conclusion(3) From the above true premises it necessarily follows that
>> simulating halt decider H correctly reports that its input: (P,P)
>> never halts.
>>
>> Only by very diligently making sure to not pay attention is it
>> possible to maintain the ruse of a fake rebuttal.
>>
>>> And it isn't correct. Most significantly, your trace skips over
>>> certain portions of the P being simulated which completely
>>> invalidates its results.
>>>
>>
>> The question is:
>>
>> Does the simulation of P have to be aborted to prevent its infinite
>> execution?
>>
>> As long as the answer to this question is [YES] then Premise(2) is
>> perfectly satisfied and your objection is utterly pointless.
>

> You should cut it out with the asinine repetition.It just makes you look
> like a three-year old.
>

If I don't get ridiculous with the repetition in a single reply then I
need twenty replies to make the same point because this point is
perpetually ignored. I usually don't repeat the same sentence five times
until after a key point has been ignored in several replies.

> And no, the objection is *not* pointless. You can't claim that there is
> "no escape from infinite execution" when you ignore the conditional
> statements which would allow P(P) to abort the simulation it is
> conducting. Those are the conditional branches which provide that escape.
>
> André
>

The question is whether or not H must abort its simulation of P.
The behavior of H is totally irrelevant to this question.

Of the two hypothetical possibilities: (independent variable)
(1) H aborts the simulation of P
(2) H never aborts the simulation of P

We ask what is the effect on the behavior of P? (dependent variable)

(1) P halts
(2) P never halts

The above answer applies to every possible encoding of any simulating
halt decoder H when applied to P or any computational equivalent to P
such as the Linz ⟨Ĥ⟩.

[olcott]

On 6/23/2021 7:49 PM, André G. Isaak wrote:

> But if it isn't a copy, then your P isn't derived from your H in the
> manner prescribed by the Linz proof. If you want to claim to have
> provided a 'counterexample' to the 'standard proofs' then you need to
> actually construct your P in the same manner that H_Hat is constructed
> in those proofs.

>
>> It is the same freaking machine language at the
>> same freaking machine language address.
>

> If P is calling H directly, then in what sense is P being 'simulated'?

>
>>> Second, even if we ignore the above, the decision criterion you use
>>> is flawed because it completely ignores all conditional branches
>>> contained within P's copy of H, and it's these conditional branches
>>> which prevent P(P) from being an 'infinitely recursive' computation.
>>>
>>
>> Unless we keep the independent variable separate from the dependent
>> variable our analysis is incorrect.
>>
>> The independent variable is the cause. Its value is independent of
>> other variables in your study.
>>
>> The dependent variable is the effect. Its value depends on changes in
>> the independent variable.
>>
>> https://www.scribbr.com/methodology/independent-and-dependent-variables/
>>
>> When we are asking whether or not H must abort its simulation of P we
>> examine the simulation of P. We must not examine the behavior of H.
>

> This is simply wrong. You can ignore the code in the *decider*, but not
> code inside the computation which the decider is simulating. The call to
> H inside P is an integral part of the computation performed by P. You
> can't ignore this anymore than you can ignore any other instructions
> inside P.
>
> André

>

The independent variable is the cause. Its value is independent of other
variables in your study.

The dependent variable is the effect. Its value depends on changes in
the independent variable.

https://www.scribbr.com/methodology/independent-and-dependent-variables/

The question is whether or not H must abort its simulation of P.
The behavior of H is totally irrelevant to this question.

As I have proven below.
As I have proven below.
As I have proven below.
As I have proven below.

Of the two hypothetical possibilities: (independent variable)
(1) H aborts the simulation of P
(2) H never aborts the simulation of P

We ask what is the effect on the behavior of P? (dependent variable)

(1) P halts
(2) P never halts

It does not freaking matter at all what-ever-the-Hell H does except what
the behavior of P is under the above two hypothetical scenarios.

If the result of purely hypothetical H that never aborts its
simulation/execution of P would result in the infinite execution of P
then we know axiomatically that H decides that P never halts correctly.

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

[olcott]

On 6/24/2021 4:40 AM, Malcolm McLean wrote:

> On Wednesday, 23 June 2021 at 17:00:57 UTC+1, Ben Bacarisse wrote:
>>
>> In reply, PO said he understood that, but then went on to say more
>> things as if anything, true or false, can alter the fact that the
>> assumption about H leads to a contradiction. Do you think he genuinely
>> believes that saying more things, even true things, can "undo" a
>> contradiction? That is a strange mind indeed.
>>

> We've had quite a bit of flip-flopping. We had a period when it was
> acknowledged that Linz's proof was sound but he had a slightly
> different property.

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

That H(P,P) cannot return a correct halt status to P in the above
computation is well proven.

That H(P,P) ever needs to return to P at all in the above code is the
key false assumption that unravels the whole proof.

> Defining a slightly different property to halting
> is not an inherently bad thing to do, it could be the starting point
> of some significant work. But that's very hard to do, and you and I
> pointed out that PO's different problem wasn't one of the "interesting"
> ones. You needed to solve the original halting problem first to decide
> it, for example.
>
> So there might have been a row back from that when he realised that
> the response would be "well that might be true but it doesn't get us
> anywhere".
>
> However I do think that he genuinely thinks that he's got something
> significant. I'm not a mind reader, but a troll would have got bored by
> now, whilst the posts go off at too many tangents to be a fraudster.
> When you dry run his simulating halt decider on itself, it is confusing.
> Take out the halt detector and it runs forever. Put the halt detector in,
> and it detects non-halting behaviour (according to PO, no real reason
> to disbelieve him). So surely it's got that right?


> But in fact simulate
> one more step, and the halt detection in the simulated machine will
> kick in and halt it.
>

I had the false assumption myself for a couple of days a year or two
ago. H can wait any fixed number of recursions before aborting its
input. If H simply waits for a later recursion to abort its input then
its input is never aborted because the code to abort this input does not
exist.

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

[olcott]

On 6/24/2021 5:49 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>

>> On Wednesday, 23 June 2021 at 17:00:57 UTC+1, Ben Bacarisse wrote:
>>>
>>> In reply, PO said he understood that, but then went on to say more
>>> things as if anything, true or false, can alter the fact that the
>>> assumption about H leads to a contradiction. Do you think he genuinely
>>> believes that saying more things, even true things, can "undo" a
>>> contradiction? That is a strange mind indeed.
>>>
>> We've had quite a bit of flip-flopping. We had a period when it was
>> acknowledged that Linz's proof was sound but he had a slightly

>> different property. Defining a slightly different property to halting

>> is not an inherently bad thing to do, it could be the starting point
>> of some significant work. But that's very hard to do, and you and I
>> pointed out that PO's different problem wasn't one of the "interesting"
>> ones. You needed to solve the original halting problem first to decide
>> it, for example.
>>
>> So there might have been a row back from that when he realised that
>> the response would be "well that might be true but it doesn't get us
>> anywhere".
>>
>> However I do think that he genuinely thinks that he's got something
>> significant. I'm not a mind reader, but a troll would have got bored by
>> now, whilst the posts go off at too many tangents to be a fraudster.
>

> I don't think he's a troll, and I don't think he's a fraudster, but the
> changes in his claims suggest to me that he is aware of being wrong and
> having to row-back the wildest ones.

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

That H(P,P) cannot return a correct halt status to P in the above
computation is well proven.

That H(P,P) ever needs to return to P at all in the above code is the
key false assumption that unravels the whole proof.

> He certainly knows, but has not
> admitted, that he never had "two actual Turing machines" "fully encoded"
> back in Dec 2018, waiting only for a TM simulator to be able to run them

Virtual machines that are "computationally equivalent" to a Turing
machines are sufficiently Turing machines.

> (he claimed that would take about a week). I don't think these
> deceptions are fraudulent. I think his self-image can't cope with the
> concept of being wrong.

>
>> When you dry run his simulating halt decider on itself, it is confusing.
>> Take out the halt detector and it runs forever. Put the halt detector in,
>> and it detects non-halting behaviour (according to PO, no real reason
>> to disbelieve him). So surely it's got that right?
>

> I don't know what you mean. How do you run anything of his? We've
> never even seen the key function.

>
>> But in fact simulate
>> one more step, and the halt detection in the simulated machine will
>> kick in and halt it.
>

> I don't see the value in discussing all these details, though others
> clearly do. He's stated in various round-about ways that his "decider"
> (the hidden code we will never see) is wrong as far as "conventional"
> halting is concerned. There is zero dispute on the facts that the code
> indicates false for a halting computation.
>

When a simulating halt decider decides that an actual infinite loop
would never halt and it stops this simulation of this infinite loop it
correctly reports that the input never halts, even though the input does
indeed halt.

The same reasoning applies to infinite recursion and infinitely nested
simulation.

You always dodge this challenge because you know that you will fail
You always dodge this challenge because you know that you will fail
You always dodge this challenge because you know that you will fail
You always dodge this challenge because you know that you will fail

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

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

trace. (pages 3-4 of the paper).

Conclusion(3) From the above true premises it necessarily follows that

simulating halt decider H correctly reports that its input: (P,P) never
halts.

Halting problem undecidability and infinitely nested simulation

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

[olcott]

On 6/24/2021 10:47 AM, Malcolm McLean wrote:

> On Thursday, 24 June 2021 at 16:25:00 UTC+1, olcott wrote:
>> On 6/24/2021 4:40 AM, Malcolm McLean wrote:
>>
>> That H(P,P) cannot return a correct halt status to P in the above
>> computation is well proven.
>>
>> That H(P,P) ever needs to return to P at all in the above code is the
>> key false assumption that unravels the whole proof.
>>

> H has to be a Turing machine.

In the pseudo-code proofs H is always pseudo-code and never a Turing
machine. It is not true that H must be a Turing machine as long as the
H/P relationship is sufficiently equivalent to the H/⟨Ĥ⟩ the C/x86
version applied.

>>
>>> But in fact simulate
>>> one more step, and the halt detection in the simulated machine will
>>> kick in and halt it.
>>>
>> I had the false assumption myself for a couple of days a year or two
>> ago. H can wait any fixed number of recursions before aborting its
>> input. If H simply waits for a later recursion to abort its input then
>> its input is never aborted because the code to abort this input does not
>> exist.
>> Halting problem undecidability and infinitely nested simulation
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>

> It's not really recursion. It's nested simulation, which is similar to recursion,
> but different from it in that control never passes to the child function.

It is sufficiently computationally equivalent.

> Instead the child function is simulated, then simulated by a simulated function,
> then simulated by a simulated simulated function and so on, with control
> always remaining in the root function.
>
> If H doesn't abort, then this goes on forever. However if it does abort, it always
> aborts one step before the child would have performed the identical abort.

This is not true. If we simply wait for the child to do it then it never
happens.

> So you've kind of created your own paradox problem here. The abort / don't
> abort decision is always wrong.

>

Of the two hypothetical possibilities: (independent variable)
(1) H aborts the simulation of P
(2) H never aborts the simulation of P

We ask what is the effect on the behavior of P? (dependent variable)

(1) P halts
(2) P never halts

If the result of purely hypothetical H that never aborts its
simulation/execution of P would result in the infinite execution of P
then we know axiomatically that H decides that P never halts correctly.

This is the axiom:

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

[olcott]

On 6/24/2021 4:13 PM, André G. Isaak wrote:

> Is there some reason you always insist on posting a webpage link to
> explain really basic concepts? In the unlikely event that someone here
> doesn't understand what this is they can always look it up themselves.

>
>>
>>
>> The question is whether or not H must abort its simulation of P.
>> The behavior of H is totally irrelevant to this question.
>>
>> As I have proven below.
>> As I have proven below.
>> As I have proven below.
>> As I have proven below.
>>
>> Of the two hypothetical possibilities: (independent variable)
>> (1) H aborts the simulation of P
>> (2) H never aborts the simulation of P
>
>> We ask what is the effect on the behavior of P? (dependent variable)
>>
>> (1) P halts
>

> You are abusing terms here. A Turing Machine halts only when it reaches
> one of its final states. If H aborts its simulation of P, then P does
> *not* halt (regardless of whether it is a halting or non-halting
> computation). Its simulation simply ends prematurely at which point H
> halts.

>
>> (2) P never halts
>>
>> It does not freaking matter at all what-ever-the-Hell H does except
>> what the behavior of P is under the above two hypothetical scenarios.
>

> P *is derived* from H, so the behaviour of P depends on the behaviour of
> H. Therefore it *does* matter what H does.
>
> Because of the above H and P are *interdependent* variables. If you want
> to treat H as an independent variable, then you must insure that P
> remains invariant, i.e. that the copy of H within P remains the same
> regardless of any changes you make to the outermost H.
>
> If the outermost H doesn't halt the simulation of P (i.e. if you disable
> the ability of the outermost H to abort simulations, and *only* the
> outermost H), then the copy of H inside P will abort the simulation of
> its input, at which point P *will* halt.

>

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

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

The question can be rephrased this way in the hypothetical case where
the H/P is replaced with an x86 emulator and the hypothetical case where
the halt decider embedded at Ĥ.qx is replaced with a UTM

we can know that the original P(P) and Ĥ(⟨Ĥ⟩) are correctly decided as
computations that never halt by a simulating halt decider if the above
computations never halt because a simulating halt acts only as a x86
emulator / UTM until after its input demonstrates an infinitely
repeating behavior pattern.

That people have difficulty comprehending the necessary truth of this
does not count as any rebuttal what-so-ever.

>> If the result of purely hypothetical H that never aborts its
>> simulation/execution of P would result in the infinite execution of P
>> then we know axiomatically that H decides that P never halts correctly.
>>
>> Premise(1) Every computation that never halts unless its simulation is
>> aborted is a computation that never halts. This verified as true on
>> the basis of the meaning of its words.
>

> No, it isn't, because it is entirely unclear what 'its simulation'
> refers to. No claim with such sloppy wording can be 'verified as true on
> the basis of the meaning of its words.'
>
> And in actual proofs, we show things to be true based on the fact that
> they can be derived from axioms using accepted rules of inference, not
> 'on the basis of the meaning of [their] words'. What you're engaging in
> is simply word-games.
>
> André

[olcott]

On 6/24/2021 7:51 PM, André G. Isaak wrote:
> On 2021-06-24 15:40, olcott wrote:
>
> <snip>

>
>> The question can be rephrased this way in the hypothetical case where
>> the H/P is replaced with an x86 emulator and the hypothetical case
>> where the halt decider embedded at Ĥ.qx is replaced with a UTM
>

> If you want to test your claim that the halt decider *MUST* terminate
> its input, you change the behaviour of the halt decider so it can't
> terminate its input. (Or, better yet, you just run P(P) directly without
> making any changes at all -- your aversion to this option is truly
> mystifying).
>

It is silly that I have to repeat my words like this so that you pay
attention, you should just pay attention.

hypothetical case
hypothetical case
hypothetical case
hypothetical case

> What you *CAN'T* do is change the behaviour of the input to the decider
> which is what you are doing if you also change the H which is contained
> inside P. By doing this, you change P(P) into an entirely different
> computation.
>
> You claim that H is an independent variable and P is a dependent
> variable. If you change both P and H, then P is not an independent
> variable. P and H are interdependent variables, which means any test you
> perform is worthless.

>
>> we can know that the original P(P) and Ĥ(⟨Ĥ⟩) are correctly decided as
>> computations that never halt by a simulating halt decider if the above
>> computations never halt because a simulating halt acts only as a x86
>> emulator / UTM until after its input demonstrates an infinitely
>> repeating behavior pattern.
>>
>> That people have difficulty comprehending the necessary truth of this
>> does not count as any rebuttal what-so-ever.
>

> People comprehend things just fine. They comprehend that to test you
> claim we must change *only* the topmost H, not the copy of H embedded in P.
>
> André
>
>

In the computation P(P) if any invocation of the infinite chain of
invocations must be terminated to prevent the infinite execution of this
chain then we know that P(P) does specify an infinite chain of invocations.

I have finally gotten my words clear enough that any disagreement would
look quite foolish. On the above key point this took six months and
thousands of reviews.

[olcott]

On 6/24/2021 9:39 PM, Richard Damon wrote:
> On 6/24/21 11:42 AM, olcott wrote:
>> On 6/24/2021 6:29 AM, Richard Damon wrote:

>>> On 6/23/21 11:03 PM, olcott wrote:
>>>> If the result of purely hypothetical H that never aborts its
>>>> simulation/execution of P would result in the infinite execution of P
>>>> then we know axiomatically that H decides that P never halts correctly.
>>>

>>> Right, The P based on the never aborting H has infinite execution, but
>>> that isn't the P we are looking at,
>>
>> That hypothetical H/P proves beyond all possible doubt that the in the
>> actual H(P,P) the input to H never halts on the basis of this axiom:

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

> Except that that the two P's are different. You are saying that the
> Black cat is white because you are looking at the white dog instead.
>
> Remember, EVERY time you change the properties of H, you get a DIFFERENT P.

Not when the H and the P are both hypothetical.

Of the two hypothetical possibilities: (independent variable)
(1) H aborts the simulation of P
(2) H never aborts the simulation of P

We ask what is the effect on the behavior of P? (dependent variable)

(1) P halts
(2) P never halts

If the result of purely hypothetical H that never aborts its
simulation/execution of P would result in the infinite execution of P
then we know axiomatically that H decides that P never halts correctly.

Axiom(1) Every computation that never halts unless its simulation is

[olcott]

On 6/25/2021 12:14 PM, Richard Damon wrote:

> On 6/25/21 12:33 PM, olcott wrote:
>> On 6/24/2021 9:39 PM, Richard Damon wrote:
>>> On 6/24/21 11:42 AM, olcott wrote:
>>>> On 6/24/2021 6:29 AM, Richard Damon wrote:
>>>>> On 6/23/21 11:03 PM, olcott wrote:
>>>>>> If the result of purely hypothetical H that never aborts its
>>>>>> simulation/execution of P would result in the infinite execution of P
>>>>>> then we know axiomatically that H decides that P never halts
>>>>>> correctly.
>>>>>
>>>>> Right, The P based on the never aborting H has infinite execution, but
>>>>> that isn't the P we are looking at,
>>>>
>>>> That hypothetical H/P proves beyond all possible doubt that the in the
>>>> actual H(P,P) the input to H never halts on the basis of this axiom:
>>>>
>>>> Premise(1) Every computation that never halts unless its simulation is
>>>> aborted is a computation that never halts. This verified as true on the
>>>> basis of the meaning of its words.
>>>>
>>>
>>> Except that that the two P's are different. You are saying that the
>>> Black cat is white because you are looking at the white dog instead.
>>>
>>> Remember, EVERY time you change the properties of H, you get a
>>> DIFFERENT P.
>>
>> Not when the H and the P are both hypothetical.
>

> WRONG. P is DEFINED based on H. If you Hypothetically create a P that
> doesn't follow that form, then you are hypothetically creating nonsense
> and can't use it to for anything logical.
>

Of every possible encoding of simulating partial halt decider H that can
possibly exist H*, if H* never aborts the simulation of its input
results in the infinite execution of the invocation of of P(P) then a
simulating halt decider H that does abort its simulation of this input
does correctly decide that this input does specify the never halting
behavior of an infinite chain of invocations.

>>
>> Of the two hypothetical possibilities: (independent variable)
>> (1) H aborts the simulation of P
>> (2) H never aborts the simulation of P
>>
>> We ask what is the effect on the behavior of P? (dependent variable)
>>
>> (1) P halts
>> (2) P never halts
>

[olcott]

On 6/25/2021 4:59 PM, Richard Damon wrote:
> On 6/25/21 4:40 PM, olcott wrote:
>> On 6/25/2021 3:11 PM, Richard Damon wrote:

>>> On 6/25/21 2:50 PM, olcott wrote:
>>>> On 6/25/2021 12:14 PM, Richard Damon wrote:
>>>>
>>>>> WRONG. P is DEFINED based on H. If you Hypothetically create a P that
>>>>> doesn't follow that form, then you are hypothetically creating nonsense
>>>>> and can't use it to for anything logical.
>>>>>
>>>>
>>>> Of every possible encoding of simulating partial halt decider H that can
>>>> possibly exist  H*, if H* never aborts the simulation of its input
>>>> results in the infinite execution of the invocation of of P(P) then a
>>>> simulating halt decider H that does abort its simulation of this input
>>>> does correctly decide that this input does specify the never halting
>>>> behavior of an infinite chain of invocations.
>>>

>>> Yes, if H* is an element of the set of non-aborting deciders (Hn), P
>>> will result in infinite recursion,
>>
>> Which logically entails beyond all possible doubt that the set of
>> encodings of simulating partial halt deciders H2* that do abort the
>> simulation of the (P,P) input would correctly report that this input
>> never halts.
>
> WHY?
>

Axiom(1) Every computation that never halts unless its simulation is

aborted is a computation that never halts. This verified as true on the
basis of the meaning of its words.

> In what universe does the properties of a Dog define the properties of a
> Cat.
>
> The logic shows that Ha can correctly decide that Pn(Pn) is non-Halting.
> Since your logic NEVER looked at Pa and determined anything about its
> behavior, it makes no determination about them. You are ignoring that P
> is a function of H, and thus if you change H then you have changed P so
> this whole argument isn't valid. You CAN'T decide the properties of one
> P based on another, which means you can't argue about one H based on
> another H.

[olcott]

On 6/25/2021 7:40 PM, Richard Damon wrote:

> WRONG.
>
> Your test does not match the plain meaning of the words, as has been
> explained many times.
>

Those words may be over your head, yet several others understand that
they are necessarily correct.

> Note, it is easy to show that your interpretation is wrong since even
> you admit that Linz H^, now called P by you will come to its end and
> halt when given it own representation as its input, and thus is BY
> DEFINITION a Halting Computation, Thus the H deciding it didn't need to
> abort its execution to get the wrong answer of Non-Halting.
>

Because at least one invocation of the infinite invocation chain
specified by P(P) had to be terminated to prevent the infinite execution
of this infinite invocation chain it is confirmed beyond all possible
doubt that P(P) specifies an invocation chain.

That terminating a single invocation of this infinite invocation chain
terminates the whole chain is to be expected when any infinitely
recursive chain is broken.

To a guy that truly believes that functions called in infinite recursion
must return a value to their caller this all may be way over your head.

> You FAULTY language is thus shown to be incorrect and leads to
> inconsistent logic, as you whole argument has shown.
>
> I will again repeat, that statement does NOT need to be made an Axiom,
> it can actually be formally proven with the right interpretation of the
> words, you only need to try to make is an (incorrect) axiom because you
> can't show your false version to be true any other way.
>
> Face it, your logic generates so many contradictions that it gets hard
> to find anything that actually has a real factual basis.

[olcott]

On 6/25/2021 8:37 PM, Richard Damon wrote:

> I have seen NO ONE agree to your interpretation of it. The plain meaning
> is that if it can be shown that if the given instance of the simulator
> simulating a given input doesn't stop its simulation that this
> simulation will run forevr, then the machine that is being simulated can
> be corrected decided as non-Halting.
>
> An more formal way to say that is if UTM(P,I) is non-halting then it is
> correct for H(P,I) to return the non-halting result.
>
> This actually follows since UTM(P,I) will be non-halting if and only if
> P(I) is non-halting by the definition of a UTM, so that statement is
> trivially proven.
>
> Your interpretation, where even if a copy of the algorithm of H is
> included in P and that included copy needs to abort the simulation of
> the copy of the machine that it was given, can be PROVEN wrong, as even
> you have shown that P(P) in this case does Halt, thus your claimed
> correct answer is wrong by the definition of the problem.
>
> Only if you define that your answer isn't actually supposed to be the
> answer to the halting problem can you justify your answer to be correct,
> but then you proof doesn't achieve the goal you claim.

>
>>
>>> Note, it is easy to show that your interpretation is wrong since even
>>> you admit that Linz H^, now called P by you will come to its end and
>>> halt when given it own representation as its input, and thus is BY
>>> DEFINITION a Halting Computation, Thus the H deciding it didn't need to
>>> abort its execution to get the wrong answer of Non-Halting.
>>>
>>
>> Because at least one invocation of the infinite invocation chain
>> specified by P(P) had to be terminated to prevent the infinite execution
>> of this infinite invocation chain it is confirmed beyond all possible
>> doubt that P(P) specifies an invocation chain.
>

> WRONG. Given that we have an H that can answer H(P,P) because it knows
> at least enough to terminate the pattern you describe, then when we run
> P(P) then because the H within it also knows to abort this sequence
> (since it is built on the same algorithm) this P is NOT part of an
> infinite chain of execution, and thus its H can return its (wrong)
> answer to it and that P can then Halt.

P(P) specifies in infinite invocation sequence that is terminated on its
third invocation of H(P,P).

P(P) specifies in infinite invocation sequence that is terminated on its
third invocation of H(P,P).

P(P) specifies in infinite invocation sequence that is terminated on its
third invocation of H(P,P).

P(P) specifies in infinite invocation sequence that is terminated on its
third invocation of H(P,P).

P(P) specifies in infinite invocation sequence that is terminated on its
third invocation of H(P,P).

Now I have told this this several hundred times.

[olcott]

On 6/25/2021 9:07 PM, Richard Damon wrote:

> WRONG.
>
> P(P) starts.
>
> Calls H(P,P)
>
> H starts the simulation.
>
> H simulates P starting
>
> H simulates P calling H
>
> H simulates H starting its simulation
>
> H simulates H simulating P starting
>
> H simulates H simulating P calling H
>
> The first H about here detects what it THINKS is an infinite execution
>
> THe first H aborts its simulation
>
> The first H returns its answer (Non-Halting) to its caller
>
> P then Halts
>
> Showing P is a Halting Computation.

As you already admitted P ONLY halts because some H aborts some P
otherwise P never ever halts.

As you already admitted P ONLY halts because some H aborts some P
otherwise P never ever halts.

As you already admitted P ONLY halts because some H aborts some P
otherwise P never ever halts.

As you already admitted P ONLY halts because some H aborts some P
otherwise P never ever halts.

As you already admitted P ONLY halts because some H aborts some P
otherwise P never ever halts.

[Chris M. Thomasson]

Are you nuts, or are recovering from a recent head injury?

[Jeff Barnett]

It's not recent. It seems he's been at it for a few decades.
--
Jeff Barnett

[olcott]

On 6/26/2021 9:51 AM, Ben Bacarisse wrote:
> I've trimmed the newsgroups. I suggest everyone else does so as well.
> There is no need to damage more than one group with this junk.

> I first cam across PO when he was about to get rich selling some
> software based on two junk patents he'd filed. The software was vapour
> ware (at the time) but the expectation of riches was real enough. The
> situation may be reversed now.
>
> I appear to have first talked about halting with PO in 2012. I had a
> look at one of the replies I made back then. See how predictable it all
> is:
>
> "You see? No connection to what I said. No discussion. Just a
> re-statement of the same false claim. Should I state, yet again, why
> it's false? Is there any reason to think you'd address the argument
> if I did so?"
>
> That's a shade off 20 years ago. It really is futile.
>

On 10/17/2006 7:03 PM, Ben Bacarisse wrote:
> "Peter Olcott" <NoS...@SeeScreen.com> writes:

It is the case that P(P) has infinite execution unless one its infinite
chain of invocations is aborted.

You know there is no rebuttal to this because it is an easily verifiable
fact, even Richard acknowledged that P(P) never halts

On 6/25/2021 3:11 PM, Richard Damon wrote:
>
> Yes, if H* is an element of the set of non-aborting deciders (Hn), P
> will result in infinite recursion,

So you will misdirect with ad hominem and rhetoric because you know that
there is no plausible rebuttal using logic.

[olcott]

On 6/26/2021 10:06 AM, Richard Damon wrote:
> On 6/26/21 10:55 AM, olcott wrote:
>> On 6/26/2021 5:32 AM, Richard Damon wrote:

>>> Yes, P halts because the H it contains terminated the simulation of
>>> another copy of its description.
>>>
>>> YOUR problem is that you think that actually means something, it doesn't
>>>
>>
>> Whenever one invocation of the infinite invocation chain of infinite
>> recursion is aborted the whole chain terminates.
>
> WRONG, if the aborting is occurring inside the chain, which it is in
> this case.
>

In the computation int main() { P(P); } If no P ever halts unless some H
aborts some P this proves beyond all possible doubt that P(P) specifies
an infinitely recursive chain of invocations.

That it took me so long to find these words proves that I am a
relatively terrible communicator. On the other hand these words do
unequivocally validate that my logic was correct all along.

[olcott]

On 6/26/2021 11:15 AM, Richard Damon wrote:

> But if your H does answer the question H(P,P) then the P DOES Halt,

Every competent software engineer knows that an infinitely recursive
chain of invocations stops as soon as one link in this chain is broken.

Every competent software engineer knows that when the whole chains stops
because one link is broken that this provides no evidence that it was
not an infinitely recursive chain of invocations.

When people that are not competent software engineers argue against this
they look very foolish.

[olcott]

On 6/26/2021 12:57 PM, Ben Bacarisse wrote:

> olcott <No...@NoWhere.com> writes:
>
>
>> On 10/17/2006 7:03 PM, Ben Bacarisse wrote:
>>> "Peter Olcott" <NoS...@SeeScreen.com> writes:
>>

>> It is the case that P(P) has infinite execution...
>
> I did not quote you saying that 2006. That attribution line is a lie.
>

I am just pointing out the date and time that you first spoke to me
knucklehead. It was not 2012. Then I go on to point out the irrefutable
reasoning that proves that I am correct.

It is the case that P(P) has infinite execution unless one of its

[olcott]

On 6/26/2021 7:42 PM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> On 6/26/2021 12:57 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 10/17/2006 7:03 PM, Ben Bacarisse wrote:
>>>>> "Peter Olcott" <NoS...@SeeScreen.com> writes:
>>>>
>>>> It is the case that P(P) has infinite execution...
>>> I did not quote you saying that 2006. That attribution line is a lie.
>>>
>>
>> I am just pointing out the date and time that you first spoke to me
>> knucklehead. It was not 2012.
>

> I know. I was point out that your attribution line was a lie. You
> probably have no idea what that means having only used Usenet for a few
> decades.
>

Ben Bacarisse the king of dishonest dodges.
Ben Bacarisse the king of dishonest dodges.
Ben Bacarisse the king of dishonest dodges.

I am daring you (or anyone else) to point out any error in the following.
I am daring you (or anyone else) to point out any error in the following.
I am daring you (or anyone else) to point out any error in the following.

[olcott]

On 6/26/2021 7:32 PM, Richard Damon wrote:

> On 6/26/21 8:01 PM, olcott wrote:
>> On 6/26/2021 12:57 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>
>>>> On 10/17/2006 7:03 PM, Ben Bacarisse wrote:
>>>>> "Peter Olcott" <NoS...@SeeScreen.com> writes:
>>>>
>>>> It is the case that P(P) has infinite execution...
>>>
>>> I did not quote you saying that 2006.  That attribution line is a lie.
>>>
>>
>> I am just pointing out the date and time that you first spoke to me
>> knucklehead. It was not 2012. Then I go on to point out the irrefutable
>> reasoning that proves that I am correct.
>>
>> It is the case that P(P) has infinite execution unless one of its
>> infinite chain of invocations is aborted.
>

> Yes, If H will never abort its P, then THAT P will be non-halting.
>
> Problem is
That you do not understand that when one invocation of the connected
chain of invocations of infinite recursion int main(){ P(P); }

is aborted thus forcing the whole chain to halt, this does not mean that
int main(){ P(P); } does not specify a chain of infinite invocations.

Everyone here that is proficient at software engineering knows that I am
correct about this.

[olcott]

On 6/26/2021 7:48 PM, Daniel Pehoushek wrote:
> -I am just pointing out the date and time that you first spoke to me
> -knucklehead. It was not 2012. Then I go on to point out the irrefutable
> how can someone care so much about others opinions?

I must first make my point understood by continual improvement of the
words of this point. I can only do this through trial-and-error with
feedback.

Six months ago I had no way to clearly explain exactly why H(P,P)==0 is
correct even though P(P) halts. I now have an irrefutable way to clearly
explain this.

It is the case that P(P) has infinite execution unless one of its
infinite chain of invocations is aborted.

Try reading the whole paper, if you are the author that you claim to be
you should have the capacity to understand that it is correct, even
though the form of this paper is not nearly in the ballpark of academic
journal quality. Far too many people rank style over substance.

Halting problem undecidability and infinitely nested simulation

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

[olcott]

On 6/26/2021 7:48 PM, Richard Damon wrote:
> On 6/26/21 8:12 PM, olcott wrote:
>> On 6/26/2021 6:20 PM, Richard Damon wrote:
>>> On 6/26/21 12:23 PM, Jeff Barnett wrote:
>>>>
>>>> That's why I question that you and others spend so much time trying to
>>>> educate him by endlessly repeating the same facts and conclusions. I
>>>> think the Piper would quit marching if the rats would not follow.
>>>
>>> I don't spend 'that much' time at it, his comments are easy to rebut,
>>> and I just check when I have spare time.
>>>
>>> It also is a bit of mental exercise to keep things fit.
>>>
>>> Although, I will admit sometimes feel a bit bad about fighting against
>>> an unarmed man in the battle of wits.
>>>
>>> He does have doggedly determined down pat though.
>>>
>>
>> A not quite genius can out perform profoundly brilliant geniuses on a
>> specific task such as the halting problem when 10,000-fold more time and
>> effort is applied. By going over all the details enormously more times
>> than anyone else has patience for, details that were never noticed
>> before are uncovered.
>
> Firing blanks again.
>
> You have proved NOTHING.
Pearls before swine.

It is the case that P(P) has infinite execution unless one of its
infinite chain of invocations is aborted.

This proves beyond all doubt that P(P) specifies a computation that does
not halt.

Halting problem undecidability and infinitely nested simulation

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

[olcott]

On 6/26/2021 8:08 PM, Richard Damon wrote:

> You say this, but refuse to answer the question of when this happens,
> what happens to the execution path of the halt decider that made this
> decision?
>

As long as we can know that P(P) specifies infinite recursion then we
know that H(P,P) did correctly abort its input an report that its input
never halts.

> Remember, in this case, you have dectect the loop that includes BOTH P
> and H in the loop. Thus this H is PART of the infinite chain that you
> claim as ALL gone.
>
> Did you machine just blow up?
>
> Did it just abort the whole program?
>
> Answer this for me, what actually happens.
>

As long as we can know that P(P) specifies infinite recursion then we
know that H(P,P) did correctly abort its input an report that its input
never halts.

This is correct and true no matter what else.

> And then, what does this mean as the behavior of the actual Turing
> Machine this is supposed to be the equivalent of?
> > I don't think you have an answer for this, as once you define what
> happens here, we can show how that answer shows you machine was wrong.
>

As long as we can know that P(P) specifies infinite recursion then we
know that H(P,P) did correctly abort its input an report that its input
never halts.

This is correct and true no matter what else.

If X > Y && Y > Z then X > Z

We don't even need to know what X, Y, and Z are
and we don't need to know the criterion measure of >.

[olcott]

On 6/26/2021 8:17 PM, Richard Damon wrote:

> On 6/26/21 8:49 PM, olcott wrote:
>> On 6/26/2021 7:42 PM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 6/26/2021 12:57 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 10/17/2006 7:03 PM, Ben Bacarisse wrote:
>>>>>>> "Peter Olcott" <NoS...@SeeScreen.com> writes:
>>>>>>
>>>>>> It is the case that P(P) has infinite execution...
>>>>> I did not quote you saying that 2006.  That attribution line is a lie.
>>>>>
>>>>
>>>> I am just pointing out the date and time that you first spoke to me
>>>> knucklehead. It was not 2012.
>>>
>>> I know.  I was point out that your attribution line was a lie.  You
>>> probably have no idea what that means having only used Usenet for a few
>>> decades.
>>>
>>
>> Ben Bacarisse the king of dishonest dodges.
>> Ben Bacarisse the king of dishonest dodges.
>> Ben Bacarisse the king of dishonest dodges.
>
>

> Olcott is the emperor of the dishonest dodge, never answering the tough
> questions put to him to acutally explain what he is saying,

>
>>
>> I am daring you (or anyone else) to point out any error in the following.
>> I am daring you (or anyone else) to point out any error in the following.
>> I am daring you (or anyone else) to point out any error in the following.
>>
>> It is the case that P(P) has infinite execution unless one of its
>> infinite chain of invocations is aborted.
>>
>> You know there is no rebuttal to this because it is an easily verifiable
>> fact, even Richard acknowledged that P(P) never halts:
>>
>> On 6/25/2021 3:11 PM, Richard Damon wrote:
>>>
>>> Yes, if H* is an element of the set of non-aborting deciders (Hn), P
>>> will result in infinite recursion,
>>
>> So you will misdirect with ad hominem and rhetoric because you know that
>> there is no plausible rebuttal using logic.
>>
>

> The error is a confusion of same named machines.
>

int Factorial(int n)
{
if (n > 1)
return n * Factorial(n - 1);
else
return 1;
}

That is not the way that recursion works.

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

When P called with the machine address of P invokes simulating halt
decider H(P,P) P is invoking its own machine address in the same way
that Factorial is invoking its own machine address.

[Chris M. Thomasson]

On 6/26/2021 5:49 PM, olcott wrote:
> On 6/26/2021 7:42 PM, Ben Bacarisse wrote:
>> olcott <No...@NoWhere.com> writes:
>>
>>> On 6/26/2021 12:57 PM, Ben Bacarisse wrote:
>>>> olcott <No...@NoWhere.com> writes:
>>>>
>>>>> On 10/17/2006 7:03 PM, Ben Bacarisse wrote:
>>>>>> "Peter Olcott" <NoS...@SeeScreen.com> writes:
>>>>>
>>>>> It is the case that P(P) has infinite execution...
>>>> I did not quote you saying that 2006.  That attribution line is a lie.
>>>>
>>>
>>> I am just pointing out the date and time that you first spoke to me
>>> knucklehead. It was not 2012.
>>
>> I know.  I was point out that your attribution line was a lie.  You
>> probably have no idea what that means having only used Usenet for a few
>> decades.
>>
>
> Ben Bacarisse the king of dishonest dodges.
> Ben Bacarisse the king of dishonest dodges.
> Ben Bacarisse the king of dishonest dodges.
>
> I am daring you (or anyone else) to point out any error in the following.
> I am daring you (or anyone else) to point out any error in the following.
> I am daring you (or anyone else) to point out any error in the following.

[...]

Oh my! Wow, you really are nuts!? I am not a frequent commentator on
your numerous nonsense threads, but wow. There are a lot of people that
are trying their best to help you, big time! Why do you mock and insult
them...? Wow!

;^/

[olcott]

On 6/26/2021 9:06 PM, Richard Damon wrote:

> Problem is that you keep refering to the wrong P.
The problem is that people that are dumber than a box of rocks do not
understand that with infinite recursion "any P will do".

An invocation chain remains infinitely recursive until one of its
invocations from the 1 ... n is terminated.

[olcott]

On 6/27/2021 12:10 PM, Richard Damon wrote:

> Then explain in simple words how you can examine program A to determine
> the Halting behavior of program B.
>
> Note, although you call then all 'P', they are TOTALLY different
> programs, with just the smallest part of common code.
>

That the different levels of infinite recursion are different programs
is such a foolishly stupid thing to say.

int Factorial(int n)
{
if (n > 1)
return n * Factorial(n - 1);
else
return 1;
}

> This is what you forget.
>
> Remember, you are using the Halting Problem defined for Turing Machines,
> so you need to work under the rules of Turing Machines, and that means
> that machine P includes ALL the code that is part of its algorithm,
> which includes the H that it is built on.

I am only talking about the C/x86 version of H/P nitwit.

[olcott]

On 6/27/2021 2:24 PM, Mike Terry wrote:
> On 27/06/2021 18:54, Malcolm McLean wrote:
>> On Sunday, 27 June 2021 at 00:04:35 UTC+1, Jeff Barnett wrote:
>>> On 6/26/2021 11:55 AM, Ben Bacarisse wrote:

>>>> Jeff Barnett <j...@notatt.com> writes:
>>>>
>>>>> That's why I question that you and others spend so much time trying to
>>>>> educate him by endlessly repeating the same facts and conclusions. I
>>>>> think the Piper would quit marching if the rats would not follow.
>>>>

>>>> I don't appreciate the analogy.
>>> Sorry but do you have another gentler but more pithy/cheesy substitute?
>>>
>>> Also, I'm in there with you all so don't take it as a shot at you.
>>>
>> Seagulls following the sprats of easy points that the trolling trawler
>> leaves
>> in its wake.
>>
>
> You're suggesting that the trawlers would quit trawling if the seagulls
> didn't follow in their wake?  :)
>
> So the whole seagull/trawler analogy doesn't quite work, although I'll
> grant seagulls can be nicer than rats, provided we exclude the naughty
> ones that swipe your bag of chips or jump up and down on your caravan
> roof at the break of dawn...
>
> Mike.
>

It may superficially seem that my claim to have correctly refuted the
conventional halting problem proofs is implausible.

As a simple matter of verifiable fact I have created the specific
algorithm that does correctly decide the computational equivalent of the
conventional halting problem counter-examples.

The one and only sticking point on this has been that some people
believed that the fact that int main() { P(P); } halts seemed to
contradict that int main() { H(P,P); } does correctly report 0 for does
not halt.

(1) int main() { P(P); } specifies the computational equivalent of
infinite recursion.

(2) Every simulating halt decider must abort the simulation of every
input that never halts.

Now that I have proven my point all those that were only interested in
providing rebuttals have given up because they know that all these
rebuttals were incorrect.

Halting problem undecidability and infinitely nested simulation

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

[olcott]

On 6/27/2021 2:40 PM, Richard Damon wrote:

> On 6/27/21 2:00 PM, olcott wrote:
>> On 6/27/2021 12:10 PM, Richard Damon wrote:
>>> On 6/27/21 10:43 AM, olcott wrote:
>>>> On 6/26/2021 9:06 PM, Richard Damon wrote:
>>>
>>>>>
>>>>> Problem is that you keep refering to the wrong P.
>>>> The problem is that people that are dumber than a box of rocks do not
>>>> understand that with infinite recursion "any P will do".
>>>>
>>>> An invocation chain remains infinitely recursive until one of its
>>>> invocations from the 1 ... n is terminated.
>>>>
>>>
>>> Then explain in simple words how you can examine program A to determine
>>> the Halting behavior of program B.
>>>
>>> Note, although you call then all 'P', they are TOTALLY different
>>> programs, with just the smallest part of common code.
>>>
>>
>> That the different levels of infinite recursion are different programs
>> is such a foolishly stupid thing to say.
>

> Nonsense.
>
> There are MANY programs that you call 'P', just as you talk about many
> different H's


That I have provided the source-code and machine-code for P along with
the execution trace of the machine-code of P proves that you are a damn
liar. Infinitely nested simulation has computationally equivalent
behavior to infinite recursion.

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

_P()
[00000b25](01) 55 push ebp
[00000b26](02) 8bec mov ebp,esp
[00000b28](01) 51 push ecx
[00000b29](03) 8b4508 mov eax,[ebp+08]
[00000b2c](01) 50 push eax
[00000b2d](03) 8b4d08 mov ecx,[ebp+08]
[00000b30](01) 51 push ecx
[00000b31](05) e81ffeffff call 00000955
[00000b36](03) 83c408 add esp,+08
[00000b39](03) 8945fc mov [ebp-04],eax
[00000b3c](04) 837dfc00 cmp dword [ebp-04],+00
[00000b40](02) 7402 jz 00000b44
[00000b42](02) ebfe jmp 00000b42
[00000b44](02) 8be5 mov esp,ebp
[00000b46](01) 5d pop ebp
[00000b47](01) c3 ret
Size in bytes:(0035) [00000b47]

Columns
(1) Machine address of instruction
(2) Machine address of top of stack
(3) Value of top of stack after instruction executed
(4) Machine language bytes
(5) Assembly language text
===============================
Begin Local Halt Decider Simulation at Machine Address:b25
...[00000b25][002116fe][00211702](01) 55 push ebp
...[00000b26][002116fe][00211702](02) 8bec mov ebp,esp
...[00000b28][002116fa][002016ce](01) 51 push ecx
...[00000b29][002116fa][002016ce](03) 8b4508 mov eax,[ebp+08]
...[00000b2c][002116f6][00000b25](01) 50 push eax
...[00000b2d][002116f6][00000b25](03) 8b4d08 mov ecx,[ebp+08]
...[00000b30][002116f2][00000b25](01) 51 push ecx
...[00000b31][002116ee][00000b36](05) e81ffeffff call 00000955
...[00000b25][0025c126][0025c12a](01) 55 push ebp
...[00000b26][0025c126][0025c12a](02) 8bec mov ebp,esp
...[00000b28][0025c122][0024c0f6](01) 51 push ecx
...[00000b29][0025c122][0024c0f6](03) 8b4508 mov eax,[ebp+08]
...[00000b2c][0025c11e][00000b25](01) 50 push eax
...[00000b2d][0025c11e][00000b25](03) 8b4d08 mov ecx,[ebp+08]
...[00000b30][0025c11a][00000b25](01) 51 push ecx
...[00000b31][0025c116][00000b36](05) e81ffeffff call 00000955
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

[olcott]

On 6/27/2021 4:01 PM, Mike Terry wrote:

> Rubbish.
>
> There is a key factor here, which you constantly fail to take in to
> account:  You are a Deluded Dumbo!
>
> I know you /think/ you've done all the things you claim, and that you're
> an unacknowledged genius, but when you view this from the correct
> perspective of "PO is a Deluded Dumbo", you will see that that is just
> part of your delusion.
>
> Just about everybody here has pointed out your various mistakes numerous
> time, but you lack the intellect to understand what people tell you.
> (And your delusions stop you from seeing the whole situation rationally,
> so instead you conclude everybody else is stupid instead of you.)

>
>>
>> The one and only sticking point on this has been that some people
>> believed that the fact that int main() { P(P); } halts seemed to
>> contradict that int main() { H(P,P); } does correctly report 0 for
>> does not halt.
>>
>> (1) int main() { P(P); } specifies the computational equivalent of
>> infinite recursion.
>>
>> (2) Every simulating halt decider must abort the simulation of every
>> input that never halts.
>>
>> Now that I have proven my point all those that were only interested in
>> providing rebuttals have given up because they know that all these
>> rebuttals were incorrect.
>

> No.  That's delusional thinking.  People have stopped posting [I would
> guess] largely because they've realised they're wasting their time, and
> in the end they have better things to do than repeat the same arguments
> to you over and over.  Believing that a lack of response means that
> people agree with you is a classic crank delusion, or maybe you don't
> really believe that, and it's just a deliberate attempt at goading
> people into further responses?  (Or maybe you're thinking future people
> will read your words and think "PO must have been right, because people
> stopped responding, and the person who posts last is automatically
> right"?  That's a complete misunderstanding of how other people think...)
>
> If you really think your argument is correct, I guess it's time for you
> to move on and get published now.  Nobody here is going to write your
> paper for you, and you're not getting any younger so no time to waste -
> best just get on with it!!
>
>
> Mike.

>

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

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

I have now proven:

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

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

The details are provided ion this paper:

Halting problem undecidability and infinitely nested simulation

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

If you honestly believe that there have been any correct rebuttals to
this then you can either post the time and date stamp of such a rebuttal
or if this is too much trouble post another equivalent rebuttal.

Everything that you posted above is mere guff, posturing, ad hominem and
rhetoric.

I expect that you will come up with some excuse for not posting or
simply ignore this challenge. The one thing that I do not expect from
you is some half-baked nonsense.

You and Kaz are the only ones that never replied with any half-baked
nonsense, all of the actual reasoning has been sound.

[olcott]

On 6/27/2021 3:17 PM, Richard Damon wrote:

> On 6/27/21 4:04 PM, olcott wrote:
>> On 6/27/2021 2:40 PM, Richard Damon wrote:
>>> On 6/27/21 2:00 PM, olcott wrote:
>>>> On 6/27/2021 12:10 PM, Richard Damon wrote:
>>>>> On 6/27/21 10:43 AM, olcott wrote:
>>>>>> On 6/26/2021 9:06 PM, Richard Damon wrote:
>>>>>
>>>>>>>
>>>>>>> Problem is that you keep refering to the wrong P.
>>>>>> The problem is that people that are dumber than a box of rocks do not
>>>>>> understand that with infinite recursion "any P will do".
>>>>>>
>>>>>> An invocation chain remains infinitely recursive until one of its
>>>>>> invocations from the 1 ... n is terminated.
>>>>>>
>>>>>
>>>>> Then explain in simple words how you can examine program A to determine
>>>>> the Halting behavior of program B.
>>>>>
>>>>> Note, although you call then all 'P', they are TOTALLY different
>>>>> programs, with just the smallest part of common code.
>>>>>
>>>>
>>>> That the different levels of infinite recursion are different programs
>>>> is such a foolishly stupid thing to say.
>>>
>>> Nonsense.
>>>
>>> There are MANY programs that you call 'P', just as you talk about many
>>> different H's
>>
>>
>> That I have provided the source-code and machine-code for P along with
>> the execution trace of the machine-code of P proves that you are a damn
>> liar. Infinitely nested simulation has computationally equivalent
>> behavior to infinite recursion.
>

> No, you haven't provided the source code for the machine P, as that

OK I will up the ante, you are a damned liar.

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

_P()
[00000b25](01) 55 push ebp
[00000b26](02) 8bec mov ebp,esp
[00000b28](01) 51 push ecx
[00000b29](03) 8b4508 mov eax,[ebp+08]
[00000b2c](01) 50 push eax
[00000b2d](03) 8b4d08 mov ecx,[ebp+08]
[00000b30](01) 51 push ecx
[00000b31](05) e81ffeffff call 00000955
[00000b36](03) 83c408 add esp,+08
[00000b39](03) 8945fc mov [ebp-04],eax
[00000b3c](04) 837dfc00 cmp dword [ebp-04],+00
[00000b40](02) 7402 jz 00000b44
[00000b42](02) ebfe jmp 00000b42
[00000b44](02) 8be5 mov esp,ebp
[00000b46](01) 5d pop ebp
[00000b47](01) c3 ret
Size in bytes:(0035) [00000b47]

[olcott]

On 6/27/2021 6:03 PM, Richard Damon wrote:

> That is the code for the FUNCTION P, not the complete code for the
> MACHINE P.
>
> If you don't understand the difference, you shouldn't be trying to prove
> theorems about Turing Machines.
>
> Call and Raise.
>

Finally a response that is not pure nonsense.

Because the behavior of VM P is entirely controlled by the machine
language of function P your correct assessment is utterly moot.

Infinitely nested simulation is essentially exactly the same thing as
infinite recursion with a few extra purely extraneous details mixed in.

[olcott]

On 6/27/2021 6:07 PM, Richard Damon wrote:

> No, you haven't.
>
> You have shown that a P built on an H that doesn't recognizes this
> behavior and thsu doesn't answer is non-Halting.
>
> You have actually proved by providing a trace that the P that is built
> on the H in (2) is Halting.
>
> FAIL.
>

When a simulating halt decider stops simulating its input to prevent the
infinite execution of this input this does not mean this forced to halt
input does not specify infinite execution.

The infinite invocation chain specified by main() is aborted at its
third invocation. As you already agreed if the infinite invocation chain
specified by main() was never aborted it would never halt.

[olcott]

On 6/27/2021 8:08 PM, Jeff Barnett wrote:
> On 6/27/2021 2:37 PM, Ben Bacarisse wrote:

>> Mike Terry <news.dead.p...@darjeeling.plus.com> writes:
>>
>>> On 27/06/2021 18:54, Malcolm McLean wrote:
>>>> On Sunday, 27 June 2021 at 00:04:35 UTC+1, Jeff Barnett wrote:
>>>>> On 6/26/2021 11:55 AM, Ben Bacarisse wrote:
>>>>>> Jeff Barnett <j...@notatt.com> writes:
>>>>>>
>>>>>>> That's why I question that you and others spend so much time
>>>>>>> trying to
>>>>>>> educate him by endlessly repeating the same facts and conclusions. I
>>>>>>> think the Piper would quit marching if the rats would not follow.
>>>>>>
>>>>>> I don't appreciate the analogy.
>>>>> Sorry but do you have another gentler but more pithy/cheesy
>>>>> substitute?
>>>>>
>>>>> Also, I'm in there with you all so don't take it as a shot at you.
>>>>>
>>>> Seagulls following the sprats of easy points that the trolling
>>>> trawler leaves
>>>> in its wake.
>>>
>>> You're suggesting that the trawlers would quit trawling if the
>>> seagulls didn't follow in their wake?  :)
>>>
>>> So the whole seagull/trawler analogy doesn't quite work, although I'll
>>> grant seagulls can be nicer than rats, provided we exclude the naughty
>>> ones that swipe your bag of chips or jump up and down on your caravan
>>> roof at the break of dawn...
>>

>> For the record, my objection was not so much being a rat per se, but
>> that the Pied Piper analogy makes the commentators the problem and PO
>> the hero.  A hero, in fact, who was cheated of his rightful reward!
>
> His rightful (I assume that you have a good idea what rightful means)
> reward does not include technical responses to gibberish.

On 1/6/2015 1:05 PM, Jeff Barnett wrote:
> Peter Olcott wrote on 1/6/2015 6:25 AM:

I removed my words here are your words:

> Of course they cannot exist. UNDECIDABLE is not a property of a problem
> instance, it's a property of a problem given a particular model of
> problem instances and algorithms. So stop here. Your done because your
> terminology is hopelessly broken. If you want to continue these
> repetitive and off the wall threads, give a clear concise definition of
> the representations of computation and how to emulate them. C and its
> derivatives don't count for many many reasons: 1) the ANSI speck allows
> the same lexical program to return different values in different (or the
> same!!!) implementation 2) read point one again, 3) it's not a very
> interesting computation model, in any event, compared to the members of
> an expanded Chomsky hierarchy.

In other words you simply don't have the software engineering background
to evaluate what I am saying on the basis of software engineering.

[olcott]

On 6/27/2021 8:29 PM, Mike Terry wrote:

> <snip reposting of claims not related to my post>

>>
>> If you honestly believe that there have been any correct rebuttals to
>> this then you can either post the time and date stamp of such a
>> rebuttal or if this is too much trouble post another equivalent rebuttal.
>

> I have made many serious posts on the content of your claims in the
> past, and without exception you have not understood them, and often even
> not read them.  It's clear to me you are not capable of understanding
> such arguments, which is not your fault, but it means that all such
> attempts to seriously discuss your claims with you are a waste of time.
>

I take this as a cop-out.
I am willing to re-read all of your posts to make sure.
At what point in time do you think that you made a sufficient rebuttal?

[olcott]

On 6/27/2021 8:29 PM, Mike Terry wrote:

> <snip reposting of claims not related to my post>
>>

>> If you honestly believe that there have been any correct rebuttals to
>> this then you can either post the time and date stamp of such a
>> rebuttal or if this is too much trouble post another equivalent rebuttal.
>

> I have made many serious posts on the content of your claims in the
> past, and without exception you have not understood them, and often even
> not read them.  It's clear to me you are not capable of understanding
> such arguments, which is not your fault, but it means that all such
> attempts to seriously discuss your claims with you are a waste of time.
>

> YOU want everybody here to continue posting for you, using up their own
> time for your benefit while you go round and round in circles forever,
> reposting the same beliefs and simply ignoring the responses.  I'm not
> interested in doing that.

>
>>
>> Everything that you posted above is mere guff, posturing, ad hominem
>> and rhetoric.
>

> It was not a comment on your specific technical arguments - that's been
> done elsewhere.

I just responded to your "rebuttal".
All that you did was dismiss what I said out-of-hand.

This time I provided all of the actual code that proves that the
conclusion of my sound deductive inference is correct.

That you reject sound deductive inference as proof seems to show that
you are a style-over-substance kind of guy.

[Don Stockbauer]

On Wednesday, June 30, 2021 at 2:33:07 PM UTC-5, jobsearc...@gmail.com wrote:
> On Monday, June 28, 2021 at 8:03:32 PM UTC+1, esa 4me wrote:
> > On Monday, June 21, 2021 at 5:15:27 AM 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.
> > >
> > > ∴ 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

> > Cats & dogs can growl of course. Theres generally a behaviourist in computer AI, likely not only because that most animals couldn't speak for themselves in a common language. There are senders & recievers, an animal sends messages to a recipent who will decide on what contingency level for decoding the message is meant .
> https://en.wikipedia.org/wiki/Suspension_of_disbelief

Thank you, job search I always wanted to know what suspension of disbelief is.

[esa 4me]

Happy Independence Day Don & to others

[esa 4me]

Did you manage to get your wire fencing around your land, (Area 53 wasn't in it !)

[Don Stockbauer]

I didn't give it a name like area 53 , all it is is 1 acre of land in back of the house . I did get it finished finally , now the dogs are prisoners but that's better than them running up to the highway and getting run over. I like building Electric fences.
One of the dogs named Max the dog pound told me is a Australian cattle dog , but Google tells me it's a dingo, The wild dog of Australia.

[assumed. identiy.3396]

Your dogs are dogs not cats, you are quite clear on that subject.

[assumed. identiy.3396]

Cannes Film Festival is showing a film called simply 'cow', it seems to be growing in steady popularity, were any of your cows famous Don ?

[Don Stockbauer]

On Friday, July 9, 2021 at 3:13:17 PM UTC-5, assumed. identiy.3396 wrote:
> Cannes Film Festival is showing a film called simply 'cow', it seems to be growing in steady popularity, were any of your cows famous Don ?

Is area 53 pretty close to area 51? it only has area 52 between area 51 snd area 53?

[assumed. identiy.3396]

is their name sinisterly connected to the temperature in their zones? If Eve did not offer an apple to Adam would she still be male?

[Don Stockbauer]

Your comments are too logical to comment on.

[assumed. identiy.3396]

and everyone can understand that the Turing debate is no better solved when computers become sophisticated
https://www.bbc.co.uk/news/business-57761873

[Don Stockbauer]

well this voice imitation thing is just one more way to screw people the way I see it.

Boy that voice cloning just another way the Internet has become chaos.
temperatures of area 51 and 53 are connected to the numbers 51 and 53 but I'm not sure if it's Fahrenheit or centigrade.
you ask would Eve still be male which assumes that she was male , does it have something to do with these males they try to become females and they have male genitalia still but they take bunches of female hormone so that their upper parts look like a female and I don't mean an ugly female , these women are drop dead gorgeous .
Happy Independence Day to you too .
do I have any famous cows yes I do one of them was president before Biden
you are correct , dogs are not cats , the same as squirrels are not porcupines and the Andromeda galaxy is not a gopher . funny how that works.

[assumed. identiy.3396]

lol

[Don Stockbauer]

Let's not have just an LOL , I really need some decisive commentary on my post.

[Don Stockbauer]

Or maybe not.

[assumed. identiy.3396]

On Wednesday, July 14, 2021 at 2:40:38 AM UTC+1, Don Stockbauer wrote:
> On Tuesday, July 13, 2021 at 11:22:31 AM UTC-5, Don Stockbauer wrote:
> > On Monday, July 12, 2021 at 2:59:29 PM UTC-5, assumed.i...@gmail.com wrote:
> > > On Monday, July 12, 2021 at 4:51:57 PM UTC+1, Don Stockbauer wrote:
> > > > On Monday, July 12, 2021 at 8:02:46 AM UTC-5, assumed.i...@gmail.com wrote:
> > > > > On Sunday, July 11, 2021 at 1:12:10 PM UTC+1, Don Stockbauer wrote:
> > > > > > On Saturday, July 10, 2021 at 3:21:07 PM UTC-5, assumed. identiy.3396 wrote:
> > > > > > > On Saturday, July 10, 2021 at 10:54:51 AM UTC+1, Don Stockbauer wrote:
> > > > > > > > On Friday, July 9, 2021 at 3:13:17 PM UTC-5, assumed. identiy.3396 wrote:
> > > > > > > > > Cannes Film Festival is showing a film called simply 'cow', it seems to be growing in steady popularity, were any of your cows famous Don ?
> > > > > > > > Is area 53 pretty close to area 51? it only has area 52 between area 51 snd area 53?
> > > > > > > is their name sinisterly connected to the temperature in their zones? If Eve did not offer an apple to Adam would she still be male?
> > > > > > Your comments are too logical to comment on.
> > > > > and everyone can understand that the Turing debate is no better solved when computers become sophisticated
> > > > > https://www.bbc.co.uk/news/business-57761873
> > > > well this voice imitation thing is just one more way to screw people the way I see it.

character imitated, some people remember those chat bots set off replying online to one another. "I dislike the tone of your voice while attempting to provoke me to take that apple, whoever you are" had never seemed likely arguement !

> > > >
> > > > Boy that voice cloning just another way the Internet has become chaos.

seems so.

[assumed. identiy.3396]

and these are so realistic, its would be uncomplimentary to pick out the errors you percieve to exist. e.g. I would not like to say "I think you are too narrow, short, weightless to be a mortal human"
https://www.bbc.co.uk/news/av/technology-57569224

[Don Stockbauer]

I didn't see a message in your last post; is it in invisible ink?

[Don Stockbauer]

Shouldn't there be more to life than chat bots, that is, endlessly worrying about them?

[Don Stockbauer]

No , I don't have any famous cows because they're not mine , the neighbor leases the place and runs them.

[Don Stockbauer]

so this voice imitation software , we can see where it's good for crime , does it have any positive uses at all?

[esa 4me]

thats called redundent or phatic communication (make your choice) either means your negative response in a logically parsed calculation.

[esa 4me]

I don't worry about them one way or another, I try to avoid scams trying to use tecnology to ruin ordinary person to person (information) correspondence

[esa 4me]

so your neighbour runs cows ? like bull runs but with udders, keep away from me if thats what you want from your ladies.

[esa 4me]

could be soothing to ajust to a pleasant pitch, tone & speed for reading poetry at bed time

[Don Stockbauer]

Running cattle means that you are raising cattle , you're running them on the pasture , they eat the grass , they raise themselves . then you sell them , so now that you see that running has a perfectly innocent definition what I want from my ladies is for her to not get greedy with our money, to be approximately my age which is 68, have at least average looks, she should be from the United Kingdom because I hear the ladies from there are the best , most well mannered , intelligent ladies of the entire world.

[Don Stockbauer]

So you want me to stay away from you? Then I won't be able to write and send your letter!

[Don Stockbauer]

Oh wait a minute you're using an alias .so maybe you aren't the person I think you are ,so maybe you never said that . God , you know the Internet and all these alias are just pure chaos , how does any thing ever get done?

[esa 4me]

Expect several replies Don. How lovely !

[assumed. identiy.3396]

did the cat bark !

[Don Stockbauer]

I don't advocate that everybody use their real name whatever they're comfortable with is fine I use my real name there's Don and Stockbauer in all my emails because I want credit for what I do . I know the downside is identity theft, at least so far (knock on wood ) it's never happened. I almost never read poetry ; short stories are science fiction . there's so much correspondence and such online it's hard to read any novels . I told a librarian once I dont read many books anymore and she just about started crying. My cat surely doesn't bark ; when I go outside she's right by the door wanting food I've often wondered how long she waits , hours? she was a cat that took up residence out here she had been dumped and she is so skittish that you barely move your hand around her and she's 100 feet away.

[Don Stockbauer]

On Monday, July 19, 2021 at 2:29:54 PM UTC-5, assumed.i...@gmail.com wrote:

> There have been lots of reports of id theft. My ID was used & ID stolen. Not much fun. It must have been because of click credit marketing. The longer you have been online the broader wider audience has been data stashed. Purely ranking, I haven't done very much constructive with my computers .I took few apart & tried to create 'art' with a couple of them.

> >I know the downside is identity theft, at least so far (knock on wood ) it's never happened. I almost never read >poetry ; short stories are science fiction . there's so much correspondence and such online it's hard to read any >novels . I told a librarian once I dont read many books anymore and she just about started crying.

> Our local library is vast, then computers were brought in, now due to covid they have been turned off & the chairs bound over or removed. I hated the affect of apps on social in the library, suddenly it seemed to become the place to be if you wanted or were wanted for a pick-up. I liked the quiet avenues of old tomes the polite staff & courtious manners, squeeking shoes & the smell of polished wood & brass. I went in recently and asked the young lady behind her new sheet of perspex, "Excuse me do you have a copy of 'The Justinion Deception', ?", She typed in the title on their records UI then said in an irritated tone, " No, not here. If its not on Amazon we haven't a copy"

> >My cat surely doesn't bark ; when I go outside she's right by the door wanting food I've often wondered how >long she waits , hours? she was a cat that took up residence out here she had been dumped and she is so >skittish that you barely move your hand around her and she's 100 feet away.

> possibly.

I don't care if they steal my identity, my nanny is worthless.
so what she does is if you ask for a book title she just orders it from Amazon for you?
No , not possibly, it happened exactly as I stated in here.

[assumed. identiy.3396]

how many languages do you speak ?

[Don Stockbauer]

Just one, Olde English . Hofstadter speaks a lot more than I do.

[Don Stockbauer]

I knew a Chris Thompson in 1978 at NASA who was the head operator for the CDC 74 mainframe. Is that you?

[Don Stockbauer]

On Thursday, July 22, 2021 at 11:00:13 AM UTC-5, assumed.i...@gmail.com wrote:

> nope, I wrote to you recently realtime, was the envelope and stamp damp ?

No ma'am , it was dry and an excellent letter it was,
I replied to it , mailed mine a couple of days ago , you should be receiving it.

[assumed. identiy.3396]

while because :)

[Don Stockbauer]

I don't know what you mean by that, but I'm not going to ask.

[Don Stockbauer]

Oooook Eeeeeek?
Oooook Eeeeeek???

the worst thing humans ever did was to invent language.

[Don Stockbauer]

Can we send emails ? I like emails. We can still do the hand written letters.

[esa 4me]

Should I write instead of typing then.........?

[Don Stockbauer]

What I was getting at is we're sending handwritten letters but maybe just every now and then do an email , however I know you have never wanted to do emails so we don't have to.

[Don Stockbauer]

If I were you (but then who would I be?) Just forget all these recent requests.

[Don Stockbauer]

I'm kind of getting tired of this forum myself but there's always handwritten letters , looking forward to them.