Truism(A) Every simulation of input P that never halts unless simulating
halt decider H aborts this simulation <is> a non-halting computation.
This remains true even after H stops simulating P.

When we are answering the question:
Would the input P to the simulating halt decider H halt if its
simulation was never aborted?

This question <is> correctly answered by the proxy: Would the input P to
a simulator S halt?

∃H ∈ Simulating_Halt_Deciders
∀P ∈ Turing_Machine_Descriptions
∀I ∈ Finite_Strings
(UTM(P,I) = ∞) ⊢ (H(P,I) = 0)

In English it says that whenever the input (P,I) to UTM would never halt
then a simulating halt decider correctly decides not halting on this input.

The behavior of the proxy computation forms the halt deciding basis for
the inputs that would otherwise specify the pathological self-reference
error.

http://www.liarparadox.org/Halting_problem_undecidability_and_infinitely_nested_simulation.pdf

--
Copyright 2021 Pete Olcott

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

On 5/21/21 3:25 PM, olcott wrote:
> Truism(A) Every simulation of input P that never halts unless simulating
> halt decider H aborts this simulation <is> a non-halting computation.
> This remains true even after H stops simulating P.

DANGER, DANGER WILL ROBINSON, WEASEL WORDS.

First, as explained before, this statement is NOT a Truisn. A Real
Truism is so plainly stated and so obviously true, that anyone will
accept it. This statement has too many weael words to be one.

There IS a Truism in part of the core of this statement, but you break
it with the added verbage.

It IS true that if a sumulation for the description of a machine with
its input will never stop, then the machine that is described is a
non-Halting Machine.

There is also Truth in the statement that if Halt Decider H can
CORRECTLY determine that its simulation of the description of a Machine
will never stop (and thus from above the machine is non-Halting) is can
terminate its simulation and not affact that.

Important note, This apply ONLY to the current instance of that decider.
If the machine that it is simulating the description on includes a copy
of this deciders algorithm, This decider MUST take into account the
actions of that copy of itself it is simulating, and if that simulated
version might terminate its simulation, the simulating copy needs to
take that into account for its decison and proofs. This is your problem
with H^.

You statement phrase "This remmains true even after H stops simulating
P" is only correct with regards to the simulating H stopping the
simulated P if it can show the non-halting taking into account any
stoppage of simulation of a simulated H inside of P.

It there is an embedded copy of H inside P, then its deciding to stop
simulating whatever it is give DOES affect the halting status of P, even
if the input that H is given is a description of that P.

>
> When we are answering the question:
> Would the input P to the simulating halt decider H halt if its
> simulation was never aborted?

Which as has been explained is the WRONG question. Inputs/Descriptions
do not halt. Machines Halt. The Halting problem is ALWAY about the
behavior of a Machine being actually run, and not some variation being
simulated by something.

>
> This question <is> correctly answered by the proxy: Would the input P to
> a simulator S halt?
>
> ∃H ∈ Simulating_Halt_Deciders
> ∀P ∈ Turing_Machine_Descriptions
> ∀I ∈ Finite_Strings
>   (UTM(P,I) = ∞) ⊢ (H(P,I) = 0)
>
> In English it says that whenever the input (P,I) to UTM would never halt
> then a simulating halt decider correctly decides not halting on this input.

And we have shown that UTM(H^, H^) when H^ is built on your defined H,
is a halting computation, thus H^(H^) is a halting computation.

>
> The behavior of the proxy computation forms the halt deciding basis for
> the inputs that would otherwise specify the pathological self-reference
> error.
>
> http://www.liarparadox.org/Halting_problem_undecidability_and_infinitely_nested_simulation.pdf
>
>

You are NOT allowed to change the machine being decided on. When given
H^, you must decide on IT, and not some alternate version. You can
create an alternate version if it help you to decide, but that answer
will ALWAYS be checked againtst that original, which has been shown to halt.

In basic words, H^ is a Halting Computation, BECAUSE your H will stop
(incorrectly) its simulation of the description of H^, H^.

You CAN'T try to argue that this stopping of the simulation in anyway
implies that a version of H trying to decide on this machine can somehow
justify it being non-halting.

On 5/21/2021 7:50 PM, Richard Damon wrote:
> On 5/21/21 3:25 PM, olcott wrote:
>> Truism(A) Every simulation of input P that never halts unless simulating
>> halt decider H aborts this simulation <is> a non-halting computation.
>> This remains true even after H stops simulating P.
>
> DANGER, DANGER WILL ROBINSON, WEASEL WORDS.
>
> First, as explained before, this statement is NOT a Truisn. A Real
> Truism is so plainly stated and so obviously true, that anyone will
> accept it. This statement has too many weael words to be one.
>
> There IS a Truism in part of the core of this statement, but you break
> it with the added verbage.
>
> It IS true that if a sumulation for the description of a machine with
> its input will never stop, then the machine that is described is a
> non-Halting Machine.
>

Yes that is the key basis for the truism.

> There is also Truth in the statement that if Halt Decider H can
> CORRECTLY determine that its simulation of the description of a Machine
> will never stop (and thus from above the machine is non-Halting) is can
> terminate its simulation and not affact that.
>

That is another part of it.

> Important note, This apply ONLY to the current instance of that decider.
> If the machine that it is simulating the description on includes a copy
> of this deciders algorithm, This decider MUST take into account the
> actions of that copy of itself it is simulating, and if that simulated
> version might terminate its simulation, the simulating copy needs to
> take that into account for its decison and proofs. This is your problem
> with H^.
>

No. In the case of an input with the pathological self-reference error
the correct halting decision can only be obtained from analyzing the
behavior of a proxy computation.

The whole point of this thread is to show that the halting behavior of
the proxy computation does decide the pathological self-reference input
correctly.

> You statement phrase "This remmains true even after H stops simulating
> P" is only correct with regards to the simulating H stopping the
> simulated P if it can show the non-halting taking into account any
> stoppage of simulation of a simulated H inside of P.
>

If the only reason that H stops P is that P would never otherwise halt
then P is correctly decided as a non-halting computation.

> It there is an embedded copy of H inside P, then its deciding to stop
> simulating whatever it is give DOES affect the halting status of P, even
> if the input that H is given is a description of that P.

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn

To make things simpler I am only examining the behavior of the embedded
halt decider at state Ĥ.qx on its input ([Ĥ],[Ĥ]) in the computation
Ĥ([Ĥ]).

>>
>> When we are answering the question:
>> Would the input P to the simulating halt decider H halt if its
>> simulation was never aborted?
>
> Which as has been explained is the WRONG question. Inputs/Descriptions
> do not halt.

The input to a simulating halt decider that is being simulated has a
halting property. Although your mistake here is rather large it does
seem that you are starting to understand these things.

> Machines Halt. The Halting problem is ALWAY about the
> behavior of a Machine being actually run, and not some variation being
> simulated by something.

>>
>> This question <is> correctly answered by the proxy: Would the input P to
>> a simulator S halt?
>>
>> ∃H ∈ Simulating_Halt_Deciders
>> ∀P ∈ Turing_Machine_Descriptions
>> ∀I ∈ Finite_Strings
>>   (UTM(P,I) = ∞) ⊢ (H(P,I) = 0)
>>
>> In English it says that whenever the input (P,I) to UTM would never halt
>> then a simulating halt decider correctly decides not halting on this input.
>
> And we have shown that UTM(H^, H^) when H^ is built on your defined H,
> is a halting computation, thus H^(H^) is a halting computation.
>

We haven't even gotten to that step yet. We are still talking about what
the internal halt decider at state Ĥ.qx does with its input ([Ĥ],[Ĥ])
and why it does it.

>>
>> The behavior of the proxy computation forms the halt deciding basis for
>> the inputs that would otherwise specify the pathological self-reference
>> error.
>>
>> http://www.liarparadox.org/Halting_problem_undecidability_and_infinitely_nested_simulation.pdf
>>
>>
>
> You are NOT allowed to change the machine being decided on. When given
> H^, you must decide on IT, and not some alternate version. You can
> create an alternate version if it help you to decide, but that answer
> will ALWAYS be checked againtst that original, which has been shown to halt.
>
> In basic words, H^ is a Halting Computation, BECAUSE your H will stop
> (incorrectly) its simulation of the description of H^, H^.
>
> You CAN'T try to argue that this stopping of the simulation in anyway
> implies that a version of H trying to decide on this machine can somehow
> justify it being non-halting.
>

All that I am discussing in this post is how we can verify that
Truism(A) really is true.

--
Copyright 2021 Pete Olcott

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

On 5/21/21 9:37 PM, olcott wrote:
> On 5/21/2021 7:50 PM, Richard Damon wrote:
>> On 5/21/21 3:25 PM, olcott wrote:
>>> Truism(A) Every simulation of input P that never halts unless simulating
>>> halt decider H aborts this simulation <is> a non-halting computation.
>>> This remains true even after H stops simulating P.
>>
>> DANGER, DANGER WILL ROBINSON, WEASEL WORDS.
>>
>> First, as explained before, this statement is NOT a Truisn. A Real
>> Truism is so plainly stated and so obviously true, that anyone will
>> accept it. This statement has too many weael words to be one.
>>
>> There IS a Truism in part of the core of this statement, but you break
>> it with the added verbage.
>>
>> It IS true that if a sumulation for the description of a machine with
>> its input will never stop, then the machine that is described is a
>> non-Halting Machine.
>>
>
> Yes that is the key basis for the truism.
>
>> There is also Truth in the statement that if Halt Decider H can
>> CORRECTLY determine that its simulation of the description of a Machine
>> will never stop (and thus from above the machine is non-Halting) is can
>> terminate its simulation and not affact that.
>>
>
> That is another part of it.
>
>> Important note, This apply ONLY to the current instance of that decider.
>> If the machine that it is simulating the description on includes a copy
>> of this deciders algorithm, This decider MUST take into account the
>> actions of that copy of itself it is simulating, and if that simulated
>> version might terminate its simulation, the simulating copy needs to
>> take that into account for its decison and proofs. This is your problem
>> with H^.
>>
>
> No. In the case of an input with the pathological self-reference error
> the correct halting decision can only be obtained from analyzing the
> behavior of a proxy computation.
>
> The whole point of this thread is to show that the halting behavior of
> the proxy computation does decide the pathological self-reference input
> correctly.
>

NO!! Halting is a well defined property. A Machine/Input combinition
WILL either Halt or it Won't. That FACT, is precisely defined by what
that machine does, not some proxy.

You are conflating What the actual Halting Property is with an algorithm
that can be used to detect it. The first is precisely defined by the
Theory (What the machine does), The second has actually been shown to be
impossible to create.

You confuse two questions, and that is the heart of your problem. The
REAL question, is does this machine Halt. Even in the case of this
'pathological self-reference', once H has been defined (as it must be)
this is normally easy to determine. Yes, it is possible that when we try
to evaluate this question for some machines it is hard (or impossible)
to determine, but for this machine it is easy. We also know that there
is ALWAYS exactly one right answer for a given computation. There is NO
need to work through this 'proxy' comutation.

The question you confuse it with is what answer should H return, and how
to determine that. THIS can be a very hard question, and as proven, at
times really impossible. Remember, H needs to be a computation, so it
needs an actual 'mechanical' algorithm to obtain its answer. It CAN'T
just be defined to deliver the 'right' answer, in part because as Linz
shows, that doesn't always exist.

>> You statement phrase "This remmains true even after H stops simulating
>> P" is only correct with regards to the simulating H stopping the
>> simulated P if it can show the non-halting taking into account any
>> stoppage of simulation of a simulated H inside of P.
>>
>
> If the only reason that H stops P is that P would never otherwise halt
> then P is correctly decided as a non-halting computation.

As long as we don't conflate the H that is deciding THIS CASE with a
copy of H that is embedded in P.

As I have pointed out, H^(H^) when run by itself does Halt, so H(H^,H^)
does NOT need to stop its simulation for it to finish. (The H inside H^
will stop its simulation, which is a big part of how H^ runs, but that
is a DIFFERENT decision, n

>
>> It there is an embedded copy of H inside P, then its deciding to stop
>> simulating whatever it is give DOES affect the halting status of P, even
>> if the input that H is given is a description of that P.
>
> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>
> To make things simpler I am only examining the behavior of the embedded
> halt decider at state Ĥ.qx on its input ([Ĥ],[Ĥ]) in the computation
> Ĥ([Ĥ]).

Note, you err in your logic by trying to adjust the embedded decider to
figure out what the machine that it is embedded does. The machine being
decided on needs to be the machine to be decided. H is NOT allowed to be
a 'variable', it is a fixed quantity.

You could use this sort of analysis to try to find an H to propose, but
you need to accept that when you get the 'contradiction' state, that
this is telling you that you can't find a machine to do the job, not
that the question is wrong.

As I have mentioned many times before, not all questions have answers,
and that isn't a flaw in the question. Some things are just impossible
to do. One example I have given is creating an algorithm to always win
at Tic-Tac-Toe. It can't be done. That doesn't make Tic-Tac-Toe not a
game (in fact it makes it a more interesting game). In the same way, you
can't make a machine to always correctly decide halting on another machine.

>
>>>
>>> When we are answering the question:
>>> Would the input P to the simulating halt decider H halt if its
>>> simulation was never aborted?
>>
>> Which as has been explained is the WRONG question. Inputs/Descriptions
>> do not halt.
>
> The input to a simulating halt decider that is being simulated has a
> halting property. Although your mistake here is rather large it does
> seem that you are starting to understand these things.

Inputs do not Halt or not. They represent machines that Do. Confusing
these get

>
>> Machines Halt. The Halting problem is ALWAY about the
>> behavior of a Machine being actually run, and not some variation being
>> simulated by something.
>
>>>
>>> This question <is> correctly answered by the proxy: Would the input P to
>>> a simulator S halt?
>>>
>>> ∃H ∈ Simulating_Halt_Deciders
>>> ∀P ∈ Turing_Machine_Descriptions
>>> ∀I ∈ Finite_Strings
>>>    (UTM(P,I) = ∞) ⊢ (H(P,I) = 0)
>>>
>>> In English it says that whenever the input (P,I) to UTM would never halt
>>> then a simulating halt decider correctly decides not halting on this
>>> input.
>>
>> And we have shown that UTM(H^, H^) when H^ is built on your defined H,
>> is a halting computation, thus H^(H^) is a halting computation.
>>
>
> We haven't even gotten to that step yet. We are still talking about what
> the internal halt decider at state Ĥ.qx does with its input ([Ĥ],[Ĥ])
> and why it does it.

And the Internal H, when given <[H^], [H^]> will incorrectly decide that
it is non-halting. If that H didn't stop it simulation too soon, it
would find that H^([H^]) does Halt, as we have shown.

This can be seen by just running H^([H^]) or running UTM(<[H^], [H^]>

Both show that H^ here is a Halting Computation.

What is invalid is changing the definition of H^ and looking at
UTM^([UTM^]), THAT is a different machine, with different halting behavior.

Remember, H^ is ALWAYS defined for a particular Halt decider algorithm,
and should not be changed when testing if that algorithm was correct.

THAT is your fatal flaw in logic. You want to examine Black Cats by
looking at Rainbow Cats.

>
>>>
>>> The behavior of the proxy computation forms the halt deciding basis for
>>> the inputs that would otherwise specify the pathological self-reference
>>> error.
>>>
>>> http://www.liarparadox.org/Halting_problem_undecidability_and_infinitely_nested_simulation.pdf
>>>
>>>
>>>
>>
>> You are NOT allowed to change the machine being decided on. When given
>> H^, you must decide on IT, and not some alternate version. You can
>> create an alternate version if it help you to decide, but that answer
>> will ALWAYS be checked againtst that original, which has been shown to
>> halt.
>>
>> In basic words, H^ is a Halting Computation, BECAUSE your H will stop
>> (incorrectly) its simulation of the description of H^, H^.
>>
>> You CAN'T try to argue that this stopping of the simulation in anyway
>> implies that a version of H trying to decide on this machine can somehow
>> justify it being non-halting.
>>
>
> All that I am discussing in this post is how we can verify that
> Truism(A) really is true.
>
>

On 5/22/2021 8:00 AM, Richard Damon wrote:
> On 5/21/21 9:37 PM, olcott wrote:
>> On 5/21/2021 7:50 PM, Richard Damon wrote:
>>> On 5/21/21 3:25 PM, olcott wrote:
>>>> Truism(A) Every simulation of input P that never halts unless simulating
>>>> halt decider H aborts this simulation <is> a non-halting computation.
>>>> This remains true even after H stops simulating P.
>>>
>>> DANGER, DANGER WILL ROBINSON, WEASEL WORDS.
>>>
>>> First, as explained before, this statement is NOT a Truisn. A Real
>>> Truism is so plainly stated and so obviously true, that anyone will
>>> accept it. This statement has too many weael words to be one.
>>>
>>> There IS a Truism in part of the core of this statement, but you break
>>> it with the added verbage.
>>>
>>> It IS true that if a sumulation for the description of a machine with
>>> its input will never stop, then the machine that is described is a
>>> non-Halting Machine.
>>>
>>
>> Yes that is the key basis for the truism.
>>
>>> There is also Truth in the statement that if Halt Decider H can
>>> CORRECTLY determine that its simulation of the description of a Machine
>>> will never stop (and thus from above the machine is non-Halting) is can
>>> terminate its simulation and not affact that.
>>>
>>
>> That is another part of it.
>>
>>> Important note, This apply ONLY to the current instance of that decider.
>>> If the machine that it is simulating the description on includes a copy
>>> of this deciders algorithm, This decider MUST take into account the
>>> actions of that copy of itself it is simulating, and if that simulated
>>> version might terminate its simulation, the simulating copy needs to
>>> take that into account for its decison and proofs. This is your problem
>>> with H^.
>>>
>>
>> No. In the case of an input with the pathological self-reference error
>> the correct halting decision can only be obtained from analyzing the
>> behavior of a proxy computation.
>>
>> The whole point of this thread is to show that the halting behavior of
>> the proxy computation does decide the pathological self-reference input
>> correctly.
>>
>
> NO!! Halting is a well defined property. A Machine/Input combinition
> WILL either Halt or it Won't. That FACT, is precisely defined by what
> that machine does, not some proxy.

===========================================================
https://groups.google.com/g/sci.logic/c/4kIXI1kxmsI/m/hRroMoQZx2IJ
The Psychology of Self-Reference
Daryl McCullough sci.logic Jun 25, 2004, 6:30:39 PM

Both Godel's proof and Turing's proof have the flavor of using
self-reference to force someone to make a mistake. Both cases
seem a little like the following paradox (call it the "Gotcha"
paradox).

You ask someone (we'll call him "Jack") to give a truthful
yes/no answer to the following question:

Will Jack's answer to this question be no?

Jack can't possibly give a correct yes/no answer to the question.
===========================================================
void H_Hat(u32 P)
{ u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
}

Which value of 1 or 0 could Halts correctly return to H_Hat?
============================================================
The logical law of polar questions
Peter Olcott sci.lang Feb 20, 2015, 11:38:48 AM

When posed to a man whom has never been married,
the question: Have you stopped beating your wife?
Is an incorrect polar question because neither yes nor
no is a correct answer.
============================================================
When confronted with an incorrect question the only possible correct
answer requires correcting the mistake in the question.
============================================================

The pathological self-reference error of the halting theorem is
circumvented by using a proxy computation as its halt deciding basis.

When it is understood that the x86utm halt decider is using the exact
same way to decide the pathological self-reference error cases of the
halting theorem by using the behavior of a simulator as a proxy for the
behavior of a simulating halt decider then it can be understood that
they both decide halting on the same basis.

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

Halts decides the above case by using the behavior of the above code
when a simulator is substituted for the simulating halt decider to
correctly answer this question:

Would the input P to the simulating halt decider Halts halt if its
simulation was never aborted?

This question <is> correctly answered by the proxy: Would the input P to
a simulator S halt?

The reason that the proxy can be used to answer the original question is
that the only difference between a simulating halt decider and a
simulator is that the simulating halt decider stops simulating some of
its inputs.

If it only stops simulating those inputs that would never halt if they
were simulated in a simulator then it correctly decides halting on all
these inputs.

I will stop here. As soon as we have mutual understanding on the above
we can move to the next step.

> You are conflating What the actual Halting Property is with an algorithm
> that can be used to detect it. The first is precisely defined by the
> Theory (What the machine does), The second has actually been shown to be
> impossible to create.
>
> You confuse two questions, and that is the heart of your problem. The
> REAL question, is does this machine Halt. Even in the case of this
> 'pathological self-reference', once H has been defined (as it must be)
> this is normally easy to determine. Yes, it is possible that when we try
> to evaluate this question for some machines it is hard (or impossible)
> to determine, but for this machine it is easy. We also know that there
> is ALWAYS exactly one right answer for a given computation. There is NO
> need to work through this 'proxy' comutation.
>
> The question you confuse it with is what answer should H return, and how
> to determine that. THIS can be a very hard question, and as proven, at
> times really impossible. Remember, H needs to be a computation, so it
> needs an actual 'mechanical' algorithm to obtain its answer. It CAN'T
> just be defined to deliver the 'right' answer, in part because as Linz
> shows, that doesn't always exist.
>
>>> You statement phrase "This remmains true even after H stops simulating
>>> P" is only correct with regards to the simulating H stopping the
>>> simulated P if it can show the non-halting taking into account any
>>> stoppage of simulation of a simulated H inside of P.
>>>
>>
>> If the only reason that H stops P is that P would never otherwise halt
>> then P is correctly decided as a non-halting computation.
>
>
> As long as we don't conflate the H that is deciding THIS CASE with a
> copy of H that is embedded in P.
>
> As I have pointed out, H^(H^) when run by itself does Halt, so H(H^,H^)
> does NOT need to stop its simulation for it to finish. (The H inside H^
> will stop its simulation, which is a big part of how H^ runs, but that
> is a DIFFERENT decision, n
>
>>
>>> It there is an embedded copy of H inside P, then its deciding to stop
>>> simulating whatever it is give DOES affect the halting status of P, even
>>> if the input that H is given is a description of that P.
>>
>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>>
>> To make things simpler I am only examining the behavior of the embedded
>> halt decider at state Ĥ.qx on its input ([Ĥ],[Ĥ]) in the computation
>> Ĥ([Ĥ]).
>
> Note, you err in your logic by trying to adjust the embedded decider to
> figure out what the machine that it is embedded does. The machine being
> decided on needs to be the machine to be decided. H is NOT allowed to be
> a 'variable', it is a fixed quantity.
>

Sometimes you just flat out don't pay enough attention.
I am examining this computation Ĥ([Ĥ])
I am <not> examining this computation H([Ĥ], [Ĥ])

> You could use this sort of analysis to try to find an H to propose, but
> you need to accept that when you get the 'contradiction' state, that
> this is telling you that you can't find a machine to do the job, not
> that the question is wrong.
>
> As I have mentioned many times before, not all questions have answers,
> and that isn't a flaw in the question. Some things are just impossible
> to do. One example I have given is creating an algorithm to always win
> at Tic-Tac-Toe. It can't be done. That doesn't make Tic-Tac-Toe not a
> game (in fact it makes it a more interesting game). In the same way, you
> can't make a machine to always correctly decide halting on another machine.
>
>>
>>>>
>>>> When we are answering the question:
>>>> Would the input P to the simulating halt decider H halt if its
>>>> simulation was never aborted?
>>>
>>> Which as has been explained is the WRONG question. Inputs/Descriptions
>>> do not halt.
>>
>> The input to a simulating halt decider that is being simulated has a
>> halting property. Although your mistake here is rather large it does
>> seem that you are starting to understand these things.
>
> Inputs do not Halt or not. They represent machines that Do. Confusing
> these get
>

On 5/22/2021 8:00 AM, Richard Damon wrote:
> On 5/21/21 9:37 PM, olcott wrote:
>> On 5/21/2021 7:50 PM, Richard Damon wrote:
>>> On 5/21/21 3:25 PM, olcott wrote:
>>>> Truism(A) Every simulation of input P that never halts unless simulating
>>>> halt decider H aborts this simulation <is> a non-halting computation.
>>>> This remains true even after H stops simulating P.
>>>
>>> DANGER, DANGER WILL ROBINSON, WEASEL WORDS.
>>>
>>> First, as explained before, this statement is NOT a Truisn. A Real
>>> Truism is so plainly stated and so obviously true, that anyone will
>>> accept it. This statement has too many weael words to be one.
>>>
>>> There IS a Truism in part of the core of this statement, but you break
>>> it with the added verbage.
>>>
>>> It IS true that if a sumulation for the description of a machine with
>>> its input will never stop, then the machine that is described is a
>>> non-Halting Machine.
>>>
>>
>> Yes that is the key basis for the truism.
>>
>>> There is also Truth in the statement that if Halt Decider H can
>>> CORRECTLY determine that its simulation of the description of a Machine
>>> will never stop (and thus from above the machine is non-Halting) is can
>>> terminate its simulation and not affact that.
>>>
>>
>> That is another part of it.
>>
>>> Important note, This apply ONLY to the current instance of that decider.
>>> If the machine that it is simulating the description on includes a copy
>>> of this deciders algorithm, This decider MUST take into account the
>>> actions of that copy of itself it is simulating, and if that simulated
>>> version might terminate its simulation, the simulating copy needs to
>>> take that into account for its decison and proofs. This is your problem
>>> with H^.
>>>
>>
>> No. In the case of an input with the pathological self-reference error
>> the correct halting decision can only be obtained from analyzing the
>> behavior of a proxy computation.
>>
>> The whole point of this thread is to show that the halting behavior of
>> the proxy computation does decide the pathological self-reference input
>> correctly.
>>
>
> NO!! Halting is a well defined property. A Machine/Input combinition
> WILL either Halt or it Won't. That FACT, is precisely defined by what
> that machine does, not some proxy.
>
> You are conflating What the actual Halting Property is with an algorithm
> that can be used to detect it. The first is precisely defined by the
> Theory (What the machine does), The second has actually been shown to be
> impossible to create.
>
> You confuse two questions, and that is the heart of your problem. The
> REAL question, is does this machine Halt. Even in the case of this
> 'pathological self-reference', once H has been defined (as it must be)
> this is normally easy to determine. Yes, it is possible that when we try
> to evaluate this question for some machines it is hard (or impossible)
> to determine, but for this machine it is easy. We also know that there
> is ALWAYS exactly one right answer for a given computation. There is NO
> need to work through this 'proxy' comutation.
>
> The question you confuse it with is what answer should H return, and how
> to determine that. THIS can be a very hard question, and as proven, at
> times really impossible. Remember, H needs to be a computation, so it
> needs an actual 'mechanical' algorithm to obtain its answer. It CAN'T
> just be defined to deliver the 'right' answer, in part because as Linz
> shows, that doesn't always exist.
>
>>> You statement phrase "This remmains true even after H stops simulating
>>> P" is only correct with regards to the simulating H stopping the
>>> simulated P if it can show the non-halting taking into account any
>>> stoppage of simulation of a simulated H inside of P.
>>>
>>
>> If the only reason that H stops P is that P would never otherwise halt
>> then P is correctly decided as a non-halting computation.
>
>
> As long as we don't conflate the H that is deciding THIS CASE with a
> copy of H that is embedded in P.
>
> As I have pointed out, H^(H^) when run by itself does Halt, so H(H^,H^)
> does NOT need to stop its simulation for it to finish. (The H inside H^
> will stop its simulation, which is a big part of how H^ runs, but that
> is a DIFFERENT decision, n
>
>>
>>> It there is an embedded copy of H inside P, then its deciding to stop
>>> simulating whatever it is give DOES affect the halting status of P, even
>>> if the input that H is given is a description of that P.
>>
>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>>
>> To make things simpler I am only examining the behavior of the embedded
>> halt decider at state Ĥ.qx on its input ([Ĥ],[Ĥ]) in the computation
>> Ĥ([Ĥ]).
>
> Note, you err in your logic by trying to adjust the embedded decider to
> figure out what the machine that it is embedded does. The machine being
> decided on needs to be the machine to be decided. H is NOT allowed to be
> a 'variable', it is a fixed quantity.
>
> You could use this sort of analysis to try to find an H to propose, but
> you need to accept that when you get the 'contradiction' state, that
> this is telling you that you can't find a machine to do the job, not
> that the question is wrong.
>
> As I have mentioned many times before, not all questions have answers,
> and that isn't a flaw in the question. Some things are just impossible
> to do. One example I have given is creating an algorithm to always win
> at Tic-Tac-Toe. It can't be done. That doesn't make Tic-Tac-Toe not a
> game (in fact it makes it a more interesting game). In the same way, you
> can't make a machine to always correctly decide halting on another machine.
>
>>
>>>>
>>>> When we are answering the question:
>>>> Would the input P to the simulating halt decider H halt if its
>>>> simulation was never aborted?
>>>
>>> Which as has been explained is the WRONG question. Inputs/Descriptions
>>> do not halt.
>>
>> The input to a simulating halt decider that is being simulated has a
>> halting property. Although your mistake here is rather large it does
>> seem that you are starting to understand these things.
>
> Inputs do not Halt or not. They represent machines that Do. Confusing
> these get

We can correctly construe that a finite string representing a
computation does have a halting property on the basis of the computation
that this finite string represents.

We could also construe it as if it was only the source code for an
executable and does not have a halting property until it is compiled and
executed. It seems to me that both of these views are correct.

>>
>>> Machines Halt. The Halting problem is ALWAY about the
>>> behavior of a Machine being actually run, and not some variation being
>>> simulated by something.
>>
>>>>
>>>> This question <is> correctly answered by the proxy: Would the input P to
>>>> a simulator S halt?
>>>>
>>>> ∃H ∈ Simulating_Halt_Deciders
>>>> ∀P ∈ Turing_Machine_Descriptions
>>>> ∀I ∈ Finite_Strings
>>>>    (UTM(P,I) = ∞) ⊢ (H(P,I) = 0)
>>>>
>>>> In English it says that whenever the input (P,I) to UTM would never halt
>>>> then a simulating halt decider correctly decides not halting on this
>>>> input.
>>>
>>> And we have shown that UTM(H^, H^) when H^ is built on your defined H,
>>> is a halting computation, thus H^(H^) is a halting computation.
>>>
>>
>> We haven't even gotten to that step yet. We are still talking about what
>> the internal halt decider at state Ĥ.qx does with its input ([Ĥ],[Ĥ])
>> and why it does it.
>
> And the Internal H, when given <[H^], [H^]> will incorrectly decide that
> it is non-halting. If that H didn't stop it simulation too soon, it
> would find that H^([H^]) does Halt, as we have shown.
>
> This can be seen by just running H^([H^]) or running UTM(<[H^], [H^]>
>
> Both show that H^ here is a Halting Computation.
>
> What is invalid is changing the definition of H^ and looking at
> UTM^([UTM^]), THAT is a different machine, with different halting behavior.
>
> Remember, H^ is ALWAYS defined for a particular Halt decider algorithm,
> and should not be changed when testing if that algorithm was correct.
>
> THAT is your fatal flaw in logic. You want to examine Black Cats by
> looking at Rainbow Cats.
>
>
>>
>>>>
>>>> The behavior of the proxy computation forms the halt deciding basis for
>>>> the inputs that would otherwise specify the pathological self-reference
>>>> error.
>>>>
>>>> http://www.liarparadox.org/Halting_problem_undecidability_and_infinitely_nested_simulation.pdf
>>>>
>>>>
>>>>
>>>
>>> You are NOT allowed to change the machine being decided on. When given
>>> H^, you must decide on IT, and not some alternate version. You can
>>> create an alternate version if it help you to decide, but that answer
>>> will ALWAYS be checked againtst that original, which has been shown to
>>> halt.
>>>
>>> In basic words, H^ is a Halting Computation, BECAUSE your H will stop
>>> (incorrectly) its simulation of the description of H^, H^.
>>>
>>> You CAN'T try to argue that this stopping of the simulation in anyway
>>> implies that a version of H trying to decide on this machine can somehow
>>> justify it being non-halting.
>>>
>>
>> All that I am discussing in this post is how we can verify that
>> Truism(A) really is true.
>>
>>
>
> And, as I explained, the first part is true, when using the right
> definitions. The last sentance is FALSE, and thus not a Truism, or even
> a Truth (at least the way you want to make it).
>

On 5/22/21 10:05 AM, olcott wrote:
> On 5/22/2021 8:00 AM, Richard Damon wrote:
>> On 5/21/21 9:37 PM, olcott wrote:
>>> On 5/21/2021 7:50 PM, Richard Damon wrote:
>>>> On 5/21/21 3:25 PM, olcott wrote:
>>>>> Truism(A) Every simulation of input P that never halts unless
>>>>> simulating
>>>>> halt decider H aborts this simulation <is> a non-halting computation.
>>>>> This remains true even after H stops simulating P.
>>>>
>>>> DANGER, DANGER WILL ROBINSON, WEASEL WORDS.
>>>>
>>>> First, as explained before, this statement is NOT a Truisn. A Real
>>>> Truism is so plainly stated and so obviously true, that anyone will
>>>> accept it. This statement has too many weael words to be one.
>>>>
>>>> There IS a Truism in part of the core of this statement, but you break
>>>> it with the added verbage.
>>>>
>>>> It IS true that if a sumulation for the description of a machine with
>>>> its input will never stop, then the machine that is described is a
>>>> non-Halting Machine.
>>>>
>>>
>>> Yes that is the key basis for the truism.
>>>
>>>> There is also Truth in the statement that if Halt Decider H can
>>>> CORRECTLY determine that its simulation of the description of a Machine
>>>> will never stop (and thus from above the machine is non-Halting) is can
>>>> terminate its simulation and not affact that.
>>>>
>>>
>>> That is another part of it.
>>>
>>>> Important note, This apply ONLY to the current instance of that
>>>> decider.
>>>> If the machine that it is simulating the description on includes a copy
>>>> of this deciders algorithm, This decider MUST take into account the
>>>> actions of that copy of itself it is simulating, and if that simulated
>>>> version might terminate its simulation, the simulating copy needs to
>>>> take that into account for its decison and proofs. This is your problem
>>>> with H^.
>>>>
>>>
>>> No. In the case of an input with the pathological self-reference error
>>> the correct halting decision can only be obtained from analyzing the
>>> behavior of a proxy computation.
>>>
>>> The whole point of this thread is to show that the halting behavior of
>>> the proxy computation does decide the pathological self-reference input
>>> correctly.
>>>
>>
>> NO!! Halting is a well defined property. A Machine/Input combinition
>> WILL either Halt or it Won't. That FACT, is precisely defined by what
>> that machine does, not some proxy.
>
> ===========================================================
> https://groups.google.com/g/sci.logic/c/4kIXI1kxmsI/m/hRroMoQZx2IJ
> The Psychology of Self-Reference
> Daryl McCullough  sci.logic  Jun 25, 2004, 6:30:39 PM
>
> Both Godel's proof and Turing's proof have the flavor of using
> self-reference to force someone to make a mistake. Both cases
> seem a little like the following paradox (call it the "Gotcha"
> paradox).
>
> You ask someone (we'll call him "Jack") to give a truthful
> yes/no answer to the following question:
>
> Will Jack's answer to this question be no?
>
> Jack can't possibly give a correct yes/no answer to the question.
> ===========================================================
> void H_Hat(u32 P)
> {
>   u32 Input_Halts = Halts(P, P);
>   if (Input_Halts)
>     HERE: goto HERE;
> }
>
> Which value of 1 or 0 could Halts correctly return to H_Hat?
> ============================================================
> The logical law of polar questions
> Peter Olcott  sci.lang  Feb 20, 2015, 11:38:48 AM
>
> When posed to a man whom has never been married,
> the question: Have you stopped beating your wife?
> Is an incorrect polar question because neither yes nor
> no is a correct answer.
> ============================================================
> When confronted with an incorrect question the only possible correct
> answer requires correcting the mistake in the question.
> ============================================================
>
> The pathological self-reference error of the halting theorem is
> circumvented by using a proxy computation as its halt deciding basis.
>
> When it is understood that the x86utm halt decider is using the exact
> same way to decide the pathological self-reference error cases of the
> halting theorem by using the behavior of a simulator as a proxy for the
> behavior of a simulating halt decider then it can be understood that
> they both decide halting on the same basis.
>
> void H_Hat(u32 P)
> {
>   u32 Input_Halts = Halts(P, P);
>   if (Input_Halts)
>     HERE: goto HERE;
> }
>
> Halts decides the above case by using the behavior of the above code
> when a simulator is substituted for the simulating halt decider to
> correctly answer this question:
>
> Would the input P to the simulating halt decider Halts halt if its
> simulation was never aborted?
>
> This question <is> correctly answered by the proxy: Would the input P to
> a simulator S halt?
>
> The reason that the proxy can be used to answer the original question is
> that the only difference between a simulating halt decider and a
> simulator is that the simulating halt decider stops simulating some of
> its inputs.

And, if that simulator is embedded in a computation, that IS a
difference. You can NOT ask how fast will car A go by changing car A to
car B. It is the WRONG answer.

You can do the proxy substitution IN THE TOP LEVEL to see if the answer
was right, but you can not change the machine that is being decided on,
and while that has a 'copy' of H, when you change your H for this test,
the copy in H^ does NOT change.

>
> If it only stops simulating those inputs that would never halt if they
> were simulated in a simulator then it correctly decides halting on all
> these inputs.
>
> I will stop here. As soon as we have mutual understanding on the above
> we can move to the next step.

Too bad you didn't

>
>> You are conflating What the actual Halting Property is with an algorithm
>> that can be used to detect it. The first is precisely defined by the
>> Theory (What the machine does), The second has actually been shown to be
>> impossible to create.
>>
>> You confuse two questions, and that is the heart of your problem. The
>> REAL question, is does this machine Halt. Even in the case of this
>> 'pathological self-reference', once H has been defined (as it must be)
>> this is normally easy to determine. Yes, it is possible that when we try
>> to evaluate this question for some machines it is hard (or impossible)
>> to determine, but for this machine it is easy. We also know that there
>> is ALWAYS exactly one right answer for a given computation. There is NO
>> need to work through this 'proxy' comutation.
>>
>> The question you confuse it with is what answer should H return, and how
>> to determine that. THIS can be a very hard question, and as proven, at
>> times really impossible. Remember, H needs to be a computation, so it
>> needs an actual 'mechanical' algorithm to obtain its answer. It CAN'T
>> just be defined to deliver the 'right' answer, in part because as Linz
>> shows, that doesn't always exist.
>>
>>>> You statement phrase "This remmains true even after H stops simulating
>>>> P" is only correct with regards to the simulating H stopping the
>>>> simulated P if it can show the non-halting taking into account any
>>>> stoppage of simulation of a simulated H inside of P.
>>>>
>>>
>>> If the only reason that H stops P is that P would never otherwise halt
>>> then P is correctly decided as a non-halting computation.
>>
>>
>> As long as we don't conflate the H that is deciding THIS CASE with a
>> copy of H that is embedded in P.
>>
>> As I have pointed out, H^(H^) when run by itself does Halt, so H(H^,H^)
>> does NOT need to stop its simulation for it to finish. (The H inside H^
>> will stop its simulation, which is a big part of how H^ runs, but that
>> is a DIFFERENT decision, n
>>
>>>
>>>> It there is an embedded copy of H inside P, then its deciding to stop
>>>> simulating whatever it is give DOES affect the halting status of P,
>>>> even
>>>> if the input that H is given is a description of that P.
>>>
>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
>>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>>>
>>> To make things simpler I am only examining the behavior of the embedded
>>> halt decider at state Ĥ.qx on its input ([Ĥ],[Ĥ]) in the computation
>>> Ĥ([Ĥ]).
>>
>> Note, you err in your logic by trying to adjust the embedded decider to
>> figure out what the machine that it is embedded does. The machine being
>> decided on needs to be the machine to be decided. H is NOT allowed to be
>> a 'variable', it is a fixed quantity.
>>
>
> Sometimes you just flat out don't pay enough attention.
> I am examining this computation Ĥ([Ĥ])
> I am <not> examining this computation H([Ĥ], [Ĥ])