On 2021-07-28 12:35, olcott wrote:
On 7/28/2021 11:38 AM, olcott wrote:
On 7/28/2021 10:31 AM, André G. Isaak wrote:
On 2021-07-28 08:09, olcott wrote:
On 7/27/2021 10:39 PM, André G. Isaak wrote:
So does P(P) halt or not?
Even though the first P in the invocation sequence reaches its
final state the fact that it only reaches its final state because
the second P in the invocation sequence was aborted proves that
H(P,P)==0 is correct.
If a car only crashes because its brakes failed, that does not imply
that it didn't crash.
If a program returns the wrong result only because it has a bug,
that does not imply that it didn't return the right answer.
If a program only halts because the second P was aborted, that does
not imply that it didn't halt.
If an infinitely recursive sequence of function calls is aborted on
the second call instead of the first call that does not mean that it
was not an infinitely recursive sequence.
Because this is too difficult to understand and accept I have
temporarily changed the subject to refuting Rice's theorem. The
fact that the first P reaches its final state and the second P is
aborted can be used as the criterion measure to consistently
reject all and only self-contradictory inputs. This does refute
Rices theorem.
You have on the one hand acknowledged that it does, while at the
same time claimed that it doesn't halt in a 'pure simulator'. So
if your 'global simulator' is not a pure simulator, what kind of
simulator is it?
You didn't answer the above. In the past you've claimed (falsely)
that in a pure simulator, P(P) doesn't halt.
While H remains a pure simulator of its input H(P,P) its input never
halts thus proving that its input never halts.
Now you appear to be using your 'global simulator' to recognise that
P(P) does halt so that you can compare this with the results of H(P,
P).
It is still true that H(P,P) did correctly decide that its input
never halts. Because this is difficult to understand I am temporarily
changing the subject to Rice's theorem.
But if P(P) doesn't halt in a 'pure simulator' then what kind of
I did not say that P(P) does not halt in a pure simulator, you must
pay careful attention to every single word that I say. When you skip
a single word that reverses the meaning of what I say.
The input to H(P,P) never halts while H remains in pure simulator mode.
simulator is your 'global simulator' which, apparently, correctly
detects that P(P) halts?
It correctly detects that the P of int main() { P(P); } reaches its
final state.
There will not actually be any function call Simulate(P,P) perThe problem is that H isn't doing the detecting. To the extent
say and this code has not been designed yet.
The very easy part that you should have understood many messages >>>>>>> ago is that when the code somehow determines that the halt
decider return value is not consistent with the behavior of P
this is freaking used to freaking refute Rice.
that what you say makes sense it is some other software which
tests the result of H(P,P) against the result of your 'global
simulator'. But *that* piece of software will have its *own* H_Hat >>>>>> which will be just as susceptible to the Linz proof as your H.
Every putative halt decider has its *own* H_Hat which it will not
be able to decide, which is perfectly in line with Rice.
André
That each of these putative halt deciders recognize and reject all
and only self-contradictory inputs refutes Rice.
And you've demonstrated this where, exactly?
As far as I can tell your H doesn't reject anything. It simply gets
some cases wrong.
The code to reject inputs has not even been fully designed yet.
It is easy to see that the criteria for this already exists.
Your H(P, P) claims that P(P) doesn't halt, which is wrong.
The input to H(P,P) never halts while H remains in pure simulator mode.
You claim that you can reject this based on the fact that it doesn't
match which your 'global simulator' concludes.
But that means that neither the global simulator nor H on their own
are capable of rejecting anything.
So what?
Whatever code is comparing these two values is what is doing the
rejecting. And we can construct from *that* piece of code another
H_Hat which *that* piece of code cannot answer correctly.
André
int Simulate(u32 P, u32 I)
{
((int(*)(int))P)(I);
return 1;
}
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}
u32 PSR_Decider(u32 P, u32 I)
{
if (Simulate(P, I) != H(P, I))
return 1;
return 0;
}
int main()
{
Output("PSR_Decider = ", PSR_Decider((u32)P, (u32)P));
}
So what exactly happens for a *genuine* non-halting computation? Your H returns 0 for non-halting and your Simulate runs forever to confirm that
this is correct? Remember that a decider, by definition, must *halt*.
André
On 2021-07-28 10:38, olcott wrote:
On 7/28/2021 10:31 AM, André G. Isaak wrote:
On 2021-07-28 08:09, olcott wrote:
On 7/27/2021 10:39 PM, André G. Isaak wrote:
So does P(P) halt or not?
Even though the first P in the invocation sequence reaches its final
state the fact that it only reaches its final state because the
second P in the invocation sequence was aborted proves that
H(P,P)==0 is correct.
If a car only crashes because its brakes failed, that does not imply
that it didn't crash.
If a program returns the wrong result only because it has a bug, that
does not imply that it didn't return the right answer.
If a program only halts because the second P was aborted, that does
not imply that it didn't halt.
If an infinitely recursive sequence of function calls is aborted on
the second call instead of the first call that does not mean that it
was not an infinitely recursive sequence.
But the definition of halting makes no mention of infinitely recursive sequences or aborted function calls. It only requires that P(P) reach a
final state in a finite amount of time. P(P) meets this definition.
Because this is too difficult to understand and accept I have
temporarily changed the subject to refuting Rice's theorem. The fact
that the first P reaches its final state and the second P is aborted
can be used as the criterion measure to consistently reject all
and only self-contradictory inputs. This does refute Rices theorem.
You have on the one hand acknowledged that it does, while at the
same time claimed that it doesn't halt in a 'pure simulator'. So if
your 'global simulator' is not a pure simulator, what kind of
simulator is it?
You didn't answer the above. In the past you've claimed (falsely)
that in a pure simulator, P(P) doesn't halt.
While H remains a pure simulator of its input H(P,P) its input never
halts thus proving that its input never halts.
But the definition of halting makes no mention of what happens inside H, regardless of whether it remains a 'pure simulator'. It only requires
that the actual computation P(P) reach a final state in a finite amount
of time. P(P) meets this definition.
Now you appear to be using your 'global simulator' to recognise that
P(P) does halt so that you can compare this with the results of H(P, P).
It is still true that H(P,P) did correctly decide that its input never
halts. Because this is difficult to understand I am temporarily
changing the subject to Rice's theorem.
No, it is not. The definition of halting is clearly defined, and P(P)
clearly meets the definition of halting. Rice's theorem has no bearing
on the fact that P(P) is halting computation.
But if P(P) doesn't halt in a 'pure simulator' then what kind of
I did not say that P(P) does not halt in a pure simulator, you must
pay careful attention to every single word that I say. When you skip a
single word that reverses the meaning of what I say.
The input to H(P,P) never halts while H remains in pure simulator mode.
So what's the difference between a 'pure simulator' and H running in
'pure simulator mode'? One would have assumed that the latter meant that
H was acting as a pure simulator.
simulator is your 'global simulator' which, apparently, correctly
detects that P(P) halts?
It correctly detects that the P of int main() { P(P); } reaches its
final state.
Which means that P(P) meets the definition of halting and is therefore a halting computation.
There will not actually be any function call Simulate(P,P) per say >>>>>> and this code has not been designed yet.The problem is that H isn't doing the detecting. To the extent that
The very easy part that you should have understood many messages
ago is that when the code somehow determines that the halt decider >>>>>> return value is not consistent with the behavior of P this is
freaking used to freaking refute Rice.
what you say makes sense it is some other software which tests the
result of H(P,P) against the result of your 'global simulator'. But
*that* piece of software will have its *own* H_Hat which will be
just as susceptible to the Linz proof as your H.
Every putative halt decider has its *own* H_Hat which it will not
be able to decide, which is perfectly in line with Rice.
André
That each of these putative halt deciders recognize and reject all
and only self-contradictory inputs refutes Rice.
And you've demonstrated this where, exactly?
As far as I can tell your H doesn't reject anything. It simply gets
some cases wrong.
The code to reject inputs has not even been fully designed yet.
So why talk about it, then? Until you actually have it you're just
blowing smoke.
It is easy to see that the criteria for this already exists.
No. It isn't.
Your H(P, P) claims that P(P) doesn't halt, which is wrong.
The input to H(P,P) never halts while H remains in pure simulator mode.
But the definition of halting makes no mention of what happens inside H, regardless of whether it remains in 'pure simulator mode'. It makes no mention of H at all. It only requires that the *actual* computation P(P) reach a final state in a finite amount of time. P(P) meets this definition.
André
You claim that you can reject this based on the fact that it doesn't
match which your 'global simulator' concludes.
But that means that neither the global simulator nor H on their own
are capable of rejecting anything.
So what?
Whatever code is comparing these two values is what is doing the
rejecting. And we can construct from *that* piece of code another
H_Hat which *that* piece of code cannot answer correctly.
André
I am not going to go down the path of infinitely nested operating
systems.
On 2021-07-28 14:06, olcott wrote:
On 7/28/2021 1:40 PM, André G. Isaak wrote:
On 2021-07-28 10:38, olcott wrote:
On 7/28/2021 10:31 AM, André G. Isaak wrote:
On 2021-07-28 08:09, olcott wrote:
On 7/27/2021 10:39 PM, André G. Isaak wrote:
So does P(P) halt or not?
Even though the first P in the invocation sequence reaches its
final state the fact that it only reaches its final state because
the second P in the invocation sequence was aborted proves that
H(P,P)==0 is correct.
If a car only crashes because its brakes failed, that does not
imply that it didn't crash.
If a program returns the wrong result only because it has a bug,
that does not imply that it didn't return the right answer.
If a program only halts because the second P was aborted, that does
not imply that it didn't halt.
If an infinitely recursive sequence of function calls is aborted on
the second call instead of the first call that does not mean that it
was not an infinitely recursive sequence.
But the definition of halting makes no mention of infinitely
recursive sequences or aborted function calls. It only requires that
P(P) reach a final state in a finite amount of time. P(P) meets this
definition.
If we base the decision on whether or not P halts entirely on the fact
that it reaches its final state
That's the DEFINITION of halting, so of course that's the only thing we should base the decision of whether P halts on.
then we have the same situation as "This sentence is not true." It is
indeed not true and the definition of a true sentence is whether or
not its assertion is satisfied.
I fail to see any parallels between P and the liar.
When we explicitly take into account the self-contradictory nature of
these two cases things are not as cut-and-dried.
There's nothing self-contradictory about it.
"This sentence is not true." is indeed not true yet when we apply this
to the satisfaction of the whole sentence and not just its assertion
That is gibberish.
then we get a contradiction. If it is true that it is not true then
that makes is not true.
It is an easily verifiable fact that the input to H(P,P) cannot
possibly reach its final state while H remains a pure simulator.
Because H
But the definition of halting makes no reference to what H does at all,
nor to pure simulators. whether P(P) halts is based solely on the
behaviour of P(P).
remains a pure simulator until after it makes its halt status decision
then its decision that its input never halts is necessarily correct.
That the first P in the infinitely recursive sequence reaches its
final state after H has made its correct halt status decision is just
like saying the liar paradox is true on the basis that its assertion
is satisfied.
No. That the first P reaches its final state means that P(P) halts. The definition of halting doesn't care how or why it reaches this state.
Only that it does.
Because this is too difficult to understand and accept I have
temporarily changed the subject to refuting Rice's theorem. The
fact that the first P reaches its final state and the second P is
aborted can be used as the criterion measure to consistently
reject all and only self-contradictory inputs. This does refute
Rices theorem.
You have on the one hand acknowledged that it does, while at the >>>>>>> same time claimed that it doesn't halt in a 'pure simulator'. So >>>>>>> if your 'global simulator' is not a pure simulator, what kind of >>>>>>> simulator is it?
You didn't answer the above. In the past you've claimed (falsely)
that in a pure simulator, P(P) doesn't halt.
While H remains a pure simulator of its input H(P,P) its input never
halts thus proving that its input never halts.
But the definition of halting makes no mention of what happens inside
H, regardless of whether it remains a 'pure simulator'. It only
requires that the actual computation P(P) reach a final state in a
finite amount of time. P(P) meets this definition.
Now you appear to be using your 'global simulator' to recognise
that P(P) does halt so that you can compare this with the results
of H(P, P).
It is still true that H(P,P) did correctly decide that its input
never halts. Because this is difficult to understand I am
temporarily changing the subject to Rice's theorem.
No, it is not. The definition of halting is clearly defined, and P(P)
clearly meets the definition of halting. Rice's theorem has no
bearing on the fact that P(P) is halting computation.
In this exact same way we would have to say that the liar paradox is
true because its assertion that it is not true is fully satisfied.
The LP's "assertion that it is not true" is *not* satisfied, fully or otherwise.
P(P), on the other hand, fully meets the definition of halting.
Whenever the assertion of a declarative sentence is satisfied we know
that this declarative sentence is true unless this declarative
sentence is self-contradictory.
Whenever H decides that its input never halts its input never reaches
a final state. When its input is self-contradictory then another
different
The input to H is simply *data*. Halting applies to *computations*.
instance of the program that is not an input to H may halt.
So what's the difference between a 'pure simulator' and H running inBut if P(P) doesn't halt in a 'pure simulator' then what kind of
I did not say that P(P) does not halt in a pure simulator, you must
pay careful attention to every single word that I say. When you skip
a single word that reverses the meaning of what I say.
The input to H(P,P) never halts while H remains in pure simulator mode. >>>
'pure simulator mode'? One would have assumed that the latter meant
that H was acting as a pure simulator.
H is evaluating the halt status of its input on the basis of what the
behavior of this input would be if H never aborts the simulation of
this input.
Which is the wrong criterion for evaluating this. The correct criterion
is simply whether P(P) reaches a final state.
<snippage>
The bottom line is that self-contradiction must be treated
differently, the conventional rules do not apply to self-contradiction.
Where does the definition of halting entail some class which must be
treated differently? All computations either reach a final state in a
finite amount of time or they do not. There is no third option.
When the assertion of a declarative sentence is satisfied this makes
the sentence true unless the sentence is self-contradictory.
The fact that "This sentence is not true." is not true does not make
the sentence true because the sentence is self-contradictory.
When a simulating halt decider reports that its input does not halt
then no instance of the same program ever reaches a final state unless
the input program specifies self-contradiction.
There are no 'instances of the same program' when talking in terms of
Turing Machines.
André
On 2021-07-28 13:07, olcott wrote:
So what exactly happens for a *genuine* non-halting computation? Your
H returns 0 for non-halting and your Simulate runs forever to confirm
that this is correct? Remember that a decider, by definition, must
*halt*.
André
When H is fully elaborated to become a full decider its divides all
inputs into halting / (not-halting or PSR Error), this still refutes
Rice.
First off, that wasn't an answer to my question.
Secondly, (not halting or PSR error) isn't a legitimate semantic
property so it has nothing to do with Rice.
Halting vs. Non-Halting would be a legitimate semantic property.
Halting vs. Non-Halting + all the cases H get wrong isn't.
André
On 2021-07-28 21:51, olcott wrote:
On 7/28/2021 6:36 PM, André G. Isaak wrote:
On 2021-07-28 14:06, olcott wrote:
On 7/28/2021 1:40 PM, André G. Isaak wrote:
On 2021-07-28 10:38, olcott wrote:
On 7/28/2021 10:31 AM, André G. Isaak wrote:
On 2021-07-28 08:09, olcott wrote:
On 7/27/2021 10:39 PM, André G. Isaak wrote:
So does P(P) halt or not?
Even though the first P in the invocation sequence reaches its >>>>>>>> final state the fact that it only reaches its final state
because the second P in the invocation sequence was aborted
proves that H(P,P)==0 is correct.
If a car only crashes because its brakes failed, that does not
imply that it didn't crash.
If a program returns the wrong result only because it has a bug, >>>>>>> that does not imply that it didn't return the right answer.
If a program only halts because the second P was aborted, that
does not imply that it didn't halt.
If an infinitely recursive sequence of function calls is aborted
on the second call instead of the first call that does not mean
that it was not an infinitely recursive sequence.
But the definition of halting makes no mention of infinitely
recursive sequences or aborted function calls. It only requires
that P(P) reach a final state in a finite amount of time. P(P)
meets this definition.
If we base the decision on whether or not P halts entirely on the
fact that it reaches its final state
That's the DEFINITION of halting, so of course that's the only thing
we should base the decision of whether P halts on.
This is equally the definition of not halting:
Every input to a simulating halt decider that only stops running when
its simulation is aborted unequivocally specifies a computation that
never halts.
No, it isn't a definition of halting. At best, it is something which you
have proposed as a *test* for halting, but it is a broken test since, at least according to you, it sometimes gives an answer that does *not* correspond to the *actual* definition of halting.
then we have the same situation as "This sentence is not true." It
is indeed not true and the definition of a true sentence is whether
or not its assertion is satisfied.
I fail to see any parallels between P and the liar.
When we explicitly take into account the self-contradictory nature
of these two cases things are not as cut-and-dried.
There's nothing self-contradictory about it.
"This sentence is not true." is indeed not true yet when we apply
this to the satisfaction of the whole sentence and not just its
assertion
That is gibberish.
then we get a contradiction. If it is true that it is not true then
that makes is not true.
It is an easily verifiable fact that the input to H(P,P) cannot
possibly reach its final state while H remains a pure simulator.
Because H
But the definition of halting makes no reference to what H does at
all, nor to pure simulators. whether P(P) halts is based solely on
the behaviour of P(P).
The definition of UTM does make reference to computational equivalence
forcing this statement to be necessarily true:
Please show me a definition of UTM which makes reference to
computational equivalence.
Every input to a simulating halt decider that only stops running when
its simulation is aborted unequivocally specifies a computation that
never halts.
A 'simulating halt decider' and UTM are different things.
remains a pure simulator until after it makes its halt status
decision then its decision that its input never halts is necessarily
correct.
That the first P in the infinitely recursive sequence reaches its
final state after H has made its correct halt status decision is
just like saying the liar paradox is true on the basis that its
assertion is satisfied.
No. That the first P reaches its final state means that P(P) halts.
The definition of halting doesn't care how or why it reaches this
state. Only that it does.
So then we must conclude the the self contradictory input causes the
logic of the system to be inconsistent because it proves that P halts
and it proves that P never halts.
It shows the logic of the *decider* to be inconsistent. It doesn't show anything inconsistent about the definition of halting, nor does it
provide to treat a computation which halts as anything other than a computation which halts.
Whether P(P) halts is a question which is independent of any 'halt
decider'.
H cannot decide P(P) correctly. Other partial deciders are able to
decide it correctly. But the definition of halting makes no reference to whether any other TM can decide it correctly. It refers only to whether
P(P) reaches a final state in a finite number of steps. It does.
Therefore it halts.
Because this is too difficult to understand and accept I have
temporarily changed the subject to refuting Rice's theorem. The >>>>>>>> fact that the first P reaches its final state and the second P >>>>>>>> is aborted can be used as the criterion measure to
consistently reject all and only self-contradictory inputs. This >>>>>>>> does refute Rices theorem.
You have on the one hand acknowledged that it does, while at >>>>>>>>> the same time claimed that it doesn't halt in a 'pure
simulator'. So if your 'global simulator' is not a pure
simulator, what kind of simulator is it?
You didn't answer the above. In the past you've claimed (falsely) >>>>>>> that in a pure simulator, P(P) doesn't halt.
While H remains a pure simulator of its input H(P,P) its input
never halts thus proving that its input never halts.
But the definition of halting makes no mention of what happens
inside H, regardless of whether it remains a 'pure simulator'. It
only requires that the actual computation P(P) reach a final state
in a finite amount of time. P(P) meets this definition.
Now you appear to be using your 'global simulator' to recognise
that P(P) does halt so that you can compare this with the results >>>>>>> of H(P, P).
It is still true that H(P,P) did correctly decide that its input
never halts. Because this is difficult to understand I am
temporarily changing the subject to Rice's theorem.
No, it is not. The definition of halting is clearly defined, and
P(P) clearly meets the definition of halting. Rice's theorem has no
bearing on the fact that P(P) is halting computation.
In this exact same way we would have to say that the liar paradox is
true because its assertion that it is not true is fully satisfied.
The LP's "assertion that it is not true" is *not* satisfied, fully or
otherwise.
The Liar Paradox: "This sentence is not true."
is indeed provably not true on the basis that it leads to a
contradiction and on the basis that it specifies and infinite cycle.
Only my own unique work finally resolves this:
Apparently in all of the years prior to my original (2016) paper no
one ever separated the analysis of propositions into their atomic
units of semantic compositionality:
(a) Assertion (Boolean) // What the expression of language claims to
be True
(b) Satisfied (Boolean) // Whether or not the expression of
language is True
You've raised this before. It's as meaningless now as it was when you
first suggested it.
https://www.researchgate.net/publication/323866366_The_Notion_of_Truth_in_Natural_and_Formal_Languages
P(P), on the other hand, fully meets the definition of halting.
Whenever the assertion of a declarative sentence is satisfied we
know that this declarative sentence is true unless this declarative
sentence is self-contradictory.
Whenever H decides that its input never halts its input never
reaches a final state. When its input is self-contradictory then
another different
The input to H is simply *data*. Halting applies to *computations*.
Not exactly: UTM(P,I) ≡ P(I)
The inputs to a UTM are equally not a computation. They are data.
instance of the program that is not an input to H may halt.
But if P(P) doesn't halt in a 'pure simulator' then what kind of
I did not say that P(P) does not halt in a pure simulator, you
must pay careful attention to every single word that I say. When
you skip a single word that reverses the meaning of what I say.
The input to H(P,P) never halts while H remains in pure simulator
mode.
So what's the difference between a 'pure simulator' and H running
in 'pure simulator mode'? One would have assumed that the latter
meant that H was acting as a pure simulator.
H is evaluating the halt status of its input on the basis of what
the behavior of this input would be if H never aborts the simulation
of this input.
Which is the wrong criterion for evaluating this. The correct
criterion is simply whether P(P) reaches a final state.
<snippage>
The bottom line is that self-contradiction must be treatedWhere does the definition of halting entail some class which must be
differently, the conventional rules do not apply to self-contradiction. >>>
treated differently? All computations either reach a final state in a
finite amount of time or they do not. There is no third option.
It is generally always the case that self-contradictory expressions of
language must always be treated differently than non
self-contradictory expressions of language.
But there is no 'self-contradictory expression of language' in the Linz proof.
The definition of halting exhaustively partitions the set of all Turing Machines into two categories: those that halt and those that don't.
There is *no* turing machine which fails to belong to one of these two classes because there is no logically possible third option.
That some sub-fields never noticed this is their fault and limitation.
When the assertion of a declarative sentence is satisfied this makes
the sentence true unless the sentence is self-contradictory.
The fact that "This sentence is not true." is not true does not make
the sentence true because the sentence is self-contradictory.
When a simulating halt decider reports that its input does not halt
then no instance of the same program ever reaches a final state
unless the input program specifies self-contradiction.
There are no 'instances of the same program' when talking in terms of
Turing Machines.
André
Ĥ.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
Ĥ( ⟨Ĥ⟩ ) specifies an infinite cycle from Ĥ.qx to Ĥ.q0 all the time >> that Ĥ.qx remains a pure simulator of its input.
Every simulation that would never stop unless its simulating halt
decider stops it at some point specifies infinite execution. This
remains true for: Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩)
Ĥ( ⟨Ĥ⟩ ) only stops because its simulating halt decider stops it at
some point.
And the definition of halting gives not one damn about *why* something
halts. It only cares that it halts.
André
On 2021-07-28 22:31, olcott wrote:
On 7/28/2021 11:15 PM, André G. Isaak wrote:
On 2021-07-28 21:51, olcott wrote:
On 7/28/2021 6:36 PM, André G. Isaak wrote:
On 2021-07-28 14:06, olcott wrote:
On 7/28/2021 1:40 PM, André G. Isaak wrote:
On 2021-07-28 10:38, olcott wrote:
On 7/28/2021 10:31 AM, André G. Isaak wrote:
On 2021-07-28 08:09, olcott wrote:
On 7/27/2021 10:39 PM, André G. Isaak wrote:
So does P(P) halt or not?
Even though the first P in the invocation sequence reaches its >>>>>>>>>> final state the fact that it only reaches its final state
because the second P in the invocation sequence was aborted >>>>>>>>>> proves that H(P,P)==0 is correct.
If a car only crashes because its brakes failed, that does not >>>>>>>>> imply that it didn't crash.
If a program returns the wrong result only because it has a
bug, that does not imply that it didn't return the right answer. >>>>>>>>>
If a program only halts because the second P was aborted, that >>>>>>>>> does not imply that it didn't halt.
If an infinitely recursive sequence of function calls is aborted >>>>>>>> on the second call instead of the first call that does not mean >>>>>>>> that it was not an infinitely recursive sequence.
But the definition of halting makes no mention of infinitely
recursive sequences or aborted function calls. It only requires
that P(P) reach a final state in a finite amount of time. P(P)
meets this definition.
If we base the decision on whether or not P halts entirely on the
fact that it reaches its final state
That's the DEFINITION of halting, so of course that's the only
thing we should base the decision of whether P halts on.
This is equally the definition of not halting:
Every input to a simulating halt decider that only stops running
when its simulation is aborted unequivocally specifies a computation
that never halts.
No, it isn't a definition of halting. At best, it is something which
you have proposed as a *test* for halting, but it is a broken test
since, at least according to you, it sometimes gives an answer that
does *not* correspond to the *actual* definition of halting.
It is computationally equivalent to not halting.
By the definition of halting, P(P) halts.
According to you, your definition leads to the conclusion that P(P)
doesn't halt.
They cannot be equivalent if they lead to different results (and I have
no idea why you use the expression 'computationally equivalent').
then we have the same situation as "This sentence is not true." It >>>>>> is indeed not true and the definition of a true sentence is
whether or not its assertion is satisfied.
I fail to see any parallels between P and the liar.
When we explicitly take into account the self-contradictory nature >>>>>> of these two cases things are not as cut-and-dried.
There's nothing self-contradictory about it.
"This sentence is not true." is indeed not true yet when we apply
this to the satisfaction of the whole sentence and not just its
assertion
That is gibberish.
then we get a contradiction. If it is true that it is not true
then that makes is not true.
It is an easily verifiable fact that the input to H(P,P) cannot
possibly reach its final state while H remains a pure simulator.
Because H
But the definition of halting makes no reference to what H does at
all, nor to pure simulators. whether P(P) halts is based solely on
the behaviour of P(P).
The definition of UTM does make reference to computational
equivalence forcing this statement to be necessarily true:
Please show me a definition of UTM which makes reference to
computational equivalence.
The simulation of the TM description of TM P on input I is stipulated
to be computationally equivalent to P(I). In an honest dialogue I
would not have to repeat this fifty times.
I asked you to show me a *definition* of UTM which refers to
computational equivalence. The above is not a definition.
Every input to a simulating halt decider that only stops running
when its simulation is aborted unequivocally specifies a computation
that never halts.
A 'simulating halt decider' and UTM are different things.
Not while the simulating halt decider is in pure simulator mode.
UTM(P, P) halts.
You claim that your 'simulating halt decider in pure simulator mode'
doesn't halt on input P, P.
Therefore they are not the same thing.
And why does it matter what happens in a 'simulating halt decider in
pure simulator mode'?
The definition of halting is only concerned with what the computation
P(P) does, not with what happens inside a 'simulating halt decider in
pure simulator mode'.
remains a pure simulator until after it makes its halt status
decision then its decision that its input never halts is
necessarily correct.
That the first P in the infinitely recursive sequence reaches its
final state after H has made its correct halt status decision is
just like saying the liar paradox is true on the basis that its
assertion is satisfied.
No. That the first P reaches its final state means that P(P) halts.
The definition of halting doesn't care how or why it reaches this
state. Only that it does.
So then we must conclude the the self contradictory input causes the
logic of the system to be inconsistent because it proves that P
halts and it proves that P never halts.
It shows the logic of the *decider* to be inconsistent. It doesn't
show anything inconsistent about the definition of halting, nor does
it provide to treat a computation which halts as anything other than
a computation which halts.
Within the hypothesis that this is correct:
Within the hypothesis that this is correct:
Within the hypothesis that this is correct:
Within the hypothesis that this is correct:
Every input to a simulating halt decider that only stops running when
its simulation is aborted unequivocally specifies a computation that
never halts.
Then the fact that the first P of int main(){ P(P); } reaches its
final state wold seem to prove that we are getting the same
contradiction as the liar paradox.
Bad logic on your part leads to bad results on your part. Your
'hypothesis' as you interpret it is *not* correct.
This make perfect sense:
garbage in (self contradictory input)
garbage out (contradictory result).
No. It does not make perfect sense since P(P) very clearly meets the
actual definition of halting.
The input is defined to contradict whatever the halt decider decides >> Now we construct a new Turing machine D with H as a subroutine.
This new TM calls H to determine what M does when the input to
M is its own description ⟨M⟩. Once D has determined this information,
it does the opposite. (Sipser:1997:165)
Where does a 'self-contradictory expression of language' appear in the
above? Nowhere that I can see.
André
<snip remainder, including, asinine, juvenile repetition>
On 2021-07-28 21:51, olcott wrote:Try and provide a counter-example of an input to H that is a halting computation even though it never halts unless its simulation is aborted.
This is equally the definition of not halting:
Every input to a simulating halt decider that only stops running when
its simulation is aborted unequivocally specifies a computation that
never halts.
No, it isn't a definition of halting. At best, it is something which you
have proposed as a *test* for halting, but it is a broken test since, at least according to you, it sometimes gives an answer that does *not* correspond to the *actual* definition of halting.
On 2021-07-29 12:15, olcott wrote:
On 7/28/2021 11:15 PM, André G. Isaak wrote:
On 2021-07-28 21:51, olcott wrote:
This is equally the definition of not halting:
Every input to a simulating halt decider that only stops running
when its simulation is aborted unequivocally specifies a computation
that never halts.
No, it isn't a definition of halting. At best, it is something which
you have proposed as a *test* for halting, but it is a broken test
since, at least according to you, it sometimes gives an answer that
does *not* correspond to the *actual* definition of halting.
Try and provide a counter-example of an input to H that is a halting
computation even though it never halts unless its simulation is aborted.
P(P) is a counterexample to your H because your H claims that P(P) won't
halt without its simulation being aborted when clearly this is not the
case. P(P) halts when run independently. And when run independently P(P) isn't being simulated, so it can't have its simulation aborted.
André
On 2021-07-29 17:27, olcott wrote:
On 7/29/2021 5:58 PM, André G. Isaak wrote:
On 2021-07-29 16:50, olcott wrote:
On 7/29/2021 2:55 PM, André G. Isaak wrote:
On 2021-07-29 12:15, olcott wrote:
On 7/28/2021 11:15 PM, André G. Isaak wrote:
On 2021-07-28 21:51, olcott wrote:
This is equally the definition of not halting:
Every input to a simulating halt decider that only stops running >>>>>>>> when its simulation is aborted unequivocally specifies a
computation that never halts.
No, it isn't a definition of halting. At best, it is something
which you have proposed as a *test* for halting, but it is a
broken test since, at least according to you, it sometimes gives >>>>>>> an answer that does *not* correspond to the *actual* definition
of halting.
Try and provide a counter-example of an input to H that is a
halting computation even though it never halts unless its
simulation is aborted.
P(P) is a counterexample to your H because your H claims that P(P)
won't
Try and provide a
counter-example of an input to H
counter-example of an input to H
counter-example of an input to H
counter-example of an input to H
counter-example of an input to H
that is a halting
computation even though it never halts unless its simulation is
aborted.
No computation that *truly* wouldn't halt unless its simulation is
aborted would be a halting computatation. I don't think anyone
disputes that. But your H doesn't actually test for this condition
since it claims that computations such as P(P) which *are* halting
computations need to have their simulations aborted in order for them
to halt.
But this isn't a viable *definition* of halting since halting is a
property of computations which exists *independently* of any halt
decider or simulator, so a definition of halting shouldn't refer to
such things.
Try and show how the
input to H
input to H
input to H
input to H
could ever reach its final state.
If by the "input to H" you mean (P, P), then yes, the simulation of P(P) would have reached a final state had H not prematurely aborted it.
This is shown by the simple fact that the actual computation P(P) halts.
André
André
On 2021-07-29 18:54, olcott wrote:
On 7/29/2021 7:25 PM, André G. Isaak wrote:
On 2021-07-29 17:27, olcott wrote:
On 7/29/2021 5:58 PM, André G. Isaak wrote:
On 2021-07-29 16:50, olcott wrote:
On 7/29/2021 2:55 PM, André G. Isaak wrote:
On 2021-07-29 12:15, olcott wrote:
On 7/28/2021 11:15 PM, André G. Isaak wrote:
On 2021-07-28 21:51, olcott wrote:
This is equally the definition of not halting:
Every input to a simulating halt decider that only stops
running when its simulation is aborted unequivocally specifies >>>>>>>>>> a computation that never halts.
No, it isn't a definition of halting. At best, it is something >>>>>>>>> which you have proposed as a *test* for halting, but it is a >>>>>>>>> broken test since, at least according to you, it sometimes
gives an answer that does *not* correspond to the *actual*
definition of halting.
Try and provide a counter-example of an input to H that is a
halting computation even though it never halts unless its
simulation is aborted.
P(P) is a counterexample to your H because your H claims that
P(P) won't
Try and provide a
counter-example of an input to H
counter-example of an input to H
counter-example of an input to H
counter-example of an input to H
counter-example of an input to H
that is a halting
computation even though it never halts unless its simulation is
aborted.
No computation that *truly* wouldn't halt unless its simulation is
aborted would be a halting computatation. I don't think anyone
disputes that. But your H doesn't actually test for this condition
since it claims that computations such as P(P) which *are* halting
computations need to have their simulations aborted in order for
them to halt.
But this isn't a viable *definition* of halting since halting is a
property of computations which exists *independently* of any halt
decider or simulator, so a definition of halting shouldn't refer to
such things.
Try and show how the
input to H
input to H
input to H
input to H
could ever reach its final state.
If by the "input to H" you mean (P, P), then yes, the simulation of
P(P) would have reached a final state had H not prematurely aborted it.
This is incorrect as the code below proves:
The code below proves nothing. Code and traces aren't proofs. Moreover,
the code below is incomplete because it doesn't include what occurs at address 955.
P either remains infinitely stuck in its first seven instructions or H
seeing that P is permanently stuck in its first seven instructions
stops simulating P. There is no possible way that P ever reaches its
final state, thus meeting the NEVER HALTS criteria.
If you stopped ignoring what occurs at address 955 you would find that
you are mistaken.
André
On 2021-07-29 22:34, olcott wrote:
On 7/29/2021 8:25 PM, André G. Isaak wrote:
On 2021-07-29 18:54, olcott wrote:
_P()
[00000c25](01) 55 push ebp
[00000c26](02) 8bec mov ebp,esp
[00000c28](03) 8b4508 mov eax,[ebp+08]
[00000c2b](01) 50 push eax // 2nd Param
[00000c2c](03) 8b4d08 mov ecx,[ebp+08]
[00000c2f](01) 51 push ecx // 1st Param
[00000c30](05) e820fdffff call 00000955 // call H
[00000c35](03) 83c408 add esp,+08
[00000c38](02) 85c0 test eax,eax
[00000c3a](02) 7402 jz 00000c3e
[00000c3c](02) ebfe jmp 00000c3c
[00000c3e](01) 5d pop ebp
[00000c3f](01) c3 ret
Size in bytes:(0027) [00000c3f]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
Begin Local Halt Decider Simulation at Machine Address:c25
[00000c25][00211776][0021177a] 55 push ebp // P begins
[00000c26][00211776][0021177a] 8bec mov ebp,esp
[00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
[00000c2b][00211772][00000c25] 50 push eax // push P
[00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0021176e][00000c25] 51 push ecx // push P
[00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H(P,P)
[00000c25][0025c19e][0025c1a2] 55 push ebp // P begins
[00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
[00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
[00000c2b][0025c19a][00000c25] 50 push eax // push P
[00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0025c196][00000c25] 51 push ecx // push P
[00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
P either remains infinitely stuck in its first seven instructions or
H seeing that P is permanently stuck in its first seven instructions
stops simulating P. There is no possible way that P ever reaches its
final state, thus meeting the NEVER HALTS criteria.
If you stopped ignoring what occurs at address 955 you would find
that you are mistaken.
André
The claim is that the input to H(P,P) cannot possibly reach its final
state @ 0x3cf. Since we know that H is a simulating halt decider we
know that it can either continue to simulate P(P) or stop simulating
P(P). In either case the input to H(P,P) cannot possibly reach its
final state @ 0x3cf.
Without knowing what happens at address 955, none of the above tells us anything at all about what happens in this code.
André
On Saturday, 31 July 2021 at 22:15:01 UTC+8, olcott wrote:
On 7/30/2021 10:54 PM, Richard Damon wrote:
On 7/30/21 7:08 PM, olcott wrote:_P()
On 7/30/2021 8:57 PM, Richard Damon wrote:
On 7/30/21 6:42 PM, olcott wrote:
On 7/30/2021 12:44 AM, Richard Damon wrote:
On 7/29/21 9:34 PM, olcott wrote:
The claim is that the input to H(P,P) cannot possibly reach its final >>>>>>>> state @ 0x3cf. Since we know that H is a simulating halt decider we >>>>>>>> know
that it can either continue to simulate P(P) or stop simulating >>>>>>>> P(P). In
either case the input to H(P,P) cannot possibly reach its final >>>>>>>> state @
0x3cf.
But that doesn't actually matter.
Sure it does it proves that the input to H(P,P) never halts thus proving >>>>>> that H(P,P)==0 is correct no matter what another different P that is not >>>>>> an input to H does.
WHY?
As I said, the fact that an ABORTED simulation didn't reach a final
halting state does NOT prove that the machine it represents is
non-halting.
The fact that the input to H(P,P) and the input to embedded halt decider >>>> Ĥ.qx(⟨Ĥ⟩, ⟨Ĥ⟩) of the actual full blown Linz proof can't possibly reach
their final state whether or not this input is ever aborted conclusively >>>> proves that both H and Ĥ.qx correctly decide that their inputs never halt.
No, it does NOT prove that. Only a UNCONDITIONAL Simulation would show that.
[00000c25](01) 55 push ebp
[00000c26](02) 8bec mov ebp,esp
[00000c28](03) 8b4508 mov eax,[ebp+08]
[00000c2b](01) 50 push eax // 2nd Param
[00000c2c](03) 8b4d08 mov ecx,[ebp+08]
[00000c2f](01) 51 push ecx // 1st Param
[00000c30](05) e820fdffff call 00000955 // call H
[00000c35](03) 83c408 add esp,+08
[00000c38](02) 85c0 test eax,eax
[00000c3a](02) 7402 jz 00000c3e
[00000c3c](02) ebfe jmp 00000c3c
[00000c3e](01) 5d pop ebp
[00000c3f](01) c3 ret
Size in bytes:(0027) [00000c3f]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
Begin Local Halt Decider Simulation at Machine Address:c25
[00000c25][00211776][0021177a] 55 push ebp // P1 begins
[00000c26][00211776][0021177a] 8bec mov ebp,esp
[00000c28][00211776][0021177a] 8b4508 mov eax,[ebp+08]
[00000c2b][00211772][00000c25] 50 push eax // push P
[00000c2c][00211772][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0021176e][00000c25] 51 push ecx // push P
[00000c30][0021176a][00000c35] e820fdffff call 00000955 // call H1(P2,P2)
[00000c25][0025c19e][0025c1a2] 55 push ebp // P2 begins
[00000c26][0025c19e][0025c1a2] 8bec mov ebp,esp
[00000c28][0025c19e][0025c1a2] 8b4508 mov eax,[ebp+08]
[00000c2b][0025c19a][00000c25] 50 push eax // push P
[00000c2c][0025c19a][00000c25] 8b4d08 mov ecx,[ebp+08]
[00000c2f][0025c196][00000c25] 51 push ecx // push P
[00000c30][0025c192][00000c35] e820fdffff call 00000955 // call H2(P3,P3)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
Anyone that knows the x86 language can see that the input to P cannot
possibly ever reach its halt state of 0xc3f whether or not H remains in
pure simulator mode AKA unconditional simulation.
Exactly, That is why "undecidable" is called.
There always exists "pathological" inputs that the halt decider H will fail.
The "pathological" self-reference input need not necessarily to look anything like self-reference or "pathological".
As I have said, all that your statement proves is that no H can prove--
that its H^ halts.
Failure to prove is not a proof of the opposite.
You logic is totally UNSOUND.
You logic is totally inconsistent.
I would even say your mind seems to be UNSOUND if it can't see the
UNSOUNDNESS of the argument.
I would say you also totally don't understand how logic works if you
think that this is a real proof.
Copyright 2021 Pete Olcott
"Great spirits have always encountered violent opposition from mediocre
minds." Einstein
On 7/31/21 11:57 AM, olcott wrote:
On 7/31/2021 1:31 PM, Richard Damon wrote:
On 7/31/21 9:35 AM, olcott wrote:
One would think that this is true, yet because H knows that it only acts >>>> as a pure simulator of its input until after its halt status decision
has been made it knows that it has no behavior that can possibly effect >>>> the behavior of P. Because of this H knows that it can totally ignore
all of its own behavior in any execution trace that it examines as the >>>> basis of its halt status decision.
Something that acted like a 'pure simulator until ...' is NOT a pure
simulator.
You are dishonestly dodging the point by dishonestly changing the
subject to a different subject.
What different subject? We are talking about the soundness of your
argument. You claim that you can treat H as a Pure Simulator, when it
isn't since it is only a pure simulator until ... which is NOT a pure simulator.
By Your Logic, you must think Trump still has Presidental powers,
because he was President until he got voted out.
The point is that because H acts as a pure simulator until after its
halt status decision has been made H can ignore its own behavior in any
execution traces.
FALSE. DISPROVEN. UNSOUND. DELUSIONAL even.
Try to actually prove it.
H is wrong because it doesn't look at all of the behaior of the machine
it is deciding on.
H can ignore its own behavior in any execution traces while it remains a
pure simulator of its input because a pure simulator of its input cannot
possibly have any effect on the behavior of its input thus not have any
effect on the halt status decision regarding the behavior of the input.
WRONG. DISPROVEN. UNSOUND. DELUSIONAL.
FAIL.
H doesn't affact the behavior of the machine it is simulating, but DOES affect the machine that it is part of. Ignoring that just makes you UNSOUND.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 379 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 67:00:19 |
| Calls: | 8,084 |
| Calls today: | 2 |
| Files: | 13,068 |
| Messages: | 5,849,427 |