Re: Black box halt decider is NOT a partial decider [ paradox rather than contradiction ]

1 view
Skip to first unread message

olcott

unread,
Jul 25, 2021, 11:54:04 PMJul 25
to
On 7/25/2021 3:54 PM, Malcolm McLean wrote:
> On Sunday, 25 July 2021 at 20:52:04 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>>> On Sunday, 25 July 2021 at 17:14:20 UTC+1, Mike Terry wrote:
>>>>
>>>> I think this is all a bit like Malcolm suggesting that PO is raising
>>>> "interesting ideas" that might be useful with more study, or that some
>>>> basic idea of PO's is "really quite clever...". It is NOT. PO has no
>>>> incling of those possibilities and really no interest in them. He is
>>>> simply saying things he naively thinks are true, without any logical
>>>> reasoning going on. No cleverness at all. He is not "performing a
>>>> magic trick", where he will pull a rabit out of a hat - he genuinely
>>>> believes he is refuting the Linz proof, no tricks. Pretending otherwise
>>>> may be being nice to PO, making him feel better, but is ultimately
>>>> unhelpful IMO. I'd say it seems like "dishonest niceness" to me. (But
>>>> maybe Malcolm really thinks PO is producing worthwhile results, or is on
>>>> the path to that, in which case it's just being "actually nice"!)
>>>>
>>> I've always been very clear that I haven't yet seen from PO anything that
>>> constitutes a refutation of Linz.
>> Unless I've misunderstood what you mean, that's an extraordinary thing
>> to say. What do you mean by a "a refutation of Linz"? PO won't say, so
>> you can't be using the term as he does. Do you mean a demonstration
>> that a TM halt decider does exist (as PO sometimes claims)? Do you mean
>> the production of a TM X such that X(<[X^][X^]> is correct about
>> X^([X^]) (as PO originally clamed)? Or do you mean the finding of
>> irreparable errors in the two proofs of the theorem in Linz?
>>
> What would you accept as proof that the Earth is flat? I had a very good
> teacher who used to pretend to be a flat earther. His case was that light
> didn't travel in straight lines. When you relax the requirement that light travels
> in straight lines, all of the simple proofs you read in geography textbooks
> become invalid, and as schoolboys we didn't have the intellectual equipment
> to refute him. But of course we knew that he was kidding. No one for a
> moment supposed seriously that the Earth wasn't round.
>
> All the things you have mentioned would be extraordinary, and all have been
> attempted by PO (he won't show the halt decider but he does show the
> execution traces, he claims that Linz's roof is based on a "pathological
> liar paradox"). I and plenty of others have pointed out why we don't accept
> that he truly has an extraordinary result, much less a refutation.
>
> Whilst on the face of it your question seems reasonable, I think really
> it's a poor basis on which to proceed. If there's an argument from PO
> that seems to make sense, and doesn't have an obvious hole in it, that's
> the time to start worrying about what criteria we'll apply to accept that
> Linz has been refuted.

I have established that H(P,P)==0 is the correct return value for the
input to H even though the P of int main(){ P(P); } does halt.

No one is willing to carefully examine the detailed steps that I have
provided that prove this, they all skip to the end and simply assume
that it must be incorrect because the P of int main(){ P(P); } does halt.

If they bothered to go through the steps of this proof they would see
the actual paradox rather than what superficially seems to be a
contradiction. I take this as direct dishonestly.

You ask: "What criteria we'll apply to accept that Linz has been refuted?"

The answer is that almost no one will accept any criteria because they
have no interest in me being right the only care about me being wrong.
Flibble, wij and you may be exceptions to this rule.

I have proved that there is a paradox rather than a contradiction. The
reason that there is a paradox is that self-contradictory input is
inherently erroneous in the same way that the liar paradox is simply
erroneous.

>>
>> In all cases your "yet" is a very odd word to use. What concept of such
>> a simple and well-established theorem do you have that using the word
>> "yet" is reasonable in this context?
>>
> "Yet" is disingenuous.
>


--
Copyright 2021 Pete Olcott

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

olcott

unread,
Jul 26, 2021, 10:20:50 AMJul 26
to
On 7/26/2021 12:09 AM, André G. Isaak wrote:
> On 2021-07-25 21:53, olcott wrote:
>
>> I have established that H(P,P)==0 is the correct return value for the
>> input to H even though the P of int main(){ P(P); } does halt.
>
> The behaviour of int main(){ P(P); } is, *by definition*, the only
> correct answer to H(P,P)
>

The behavior of H(P,P) and P(P) varies only because of the erroneous
self-contradictory input.

That the input has the pathological-self-reference(Olcott 2004) error
can be discerned on the basis that H(P,P) != P(P). This refutes Rice.

>> No one is willing to carefully examine the detailed steps that I have
>> provided that prove this, they all skip to the end and simply assume
>> that it must be incorrect because the P of int main(){ P(P); } does halt.
>>
>> If they bothered to go through the steps of this proof they would see
>> the actual paradox rather than what superficially seems to be a
>> contradiction. I take this as direct dishonestly.
>
> How exactly do you distinguish between a paradox and a contradiction?

If H(P,P) is verified as correct and P(P) is verified as correct then
H(P,P) != P(P) is not a contradiction.

Because of the fact that No P ever halts unless H(P,P) aborts the
simulation of its input H(P,P) is more correct than P(P).

The error is not with H(P,P)==0 if all of the steps are analyzed no
error can be found because there is no error. That the input to H(P,P)
never halts is a verified fact. By not examining all of these steps when
repeatedly asked to do so really seems to prove that you must be dishonest.

>
> André

olcott

unread,
Jul 26, 2021, 12:41:40 PMJul 26
to
On 7/26/2021 11:09 AM, André G. Isaak wrote:
> On 2021-07-26 08:20, olcott wrote:
>> On 7/26/2021 12:09 AM, André G. Isaak wrote:
>>> On 2021-07-25 21:53, olcott wrote:
>>>
>>>> I have established that H(P,P)==0 is the correct return value for
>>>> the input to H even though the P of int main(){ P(P); } does halt.
>>>
>>> The behaviour of int main(){ P(P); } is, *by definition*, the only
>>> correct answer to H(P,P)
>>>
>>
>> The behavior of H(P,P) and P(P) varies only because of the erroneous
>> self-contradictory input.
>>
>> That the input has the pathological-self-reference(Olcott 2004) error
>> can be discerned on the basis that H(P,P) != P(P). This refutes Rice.
>>
>>>> No one is willing to carefully examine the detailed steps that I
>>>> have provided that prove this, they all skip to the end and simply
>>>> assume that it must be incorrect because the P of int main(){ P(P);
>>>> } does halt.
>>>>
>>>> If they bothered to go through the steps of this proof they would
>>>> see the actual paradox rather than what superficially seems to be a
>>>> contradiction. I take this as direct dishonestly.
>>>
>>> How exactly do you distinguish between a paradox and a contradiction?
>>
>> If H(P,P) is verified as correct and P(P) is verified as correct then
>> H(P,P) != P(P) is not a contradiction.
>
> But H(P, P) *isn't* verified as correct.

While the input to H(P,P) is simulated in pure simulation mode it cannot
possibly ever reach a final state thus conclusively proving that this
input never halts.

Anyone bothering to carefully examine these things must necessarily
conclude that the pure simulation of the input to H(P,P) cannot possibly
reach its final state. Anyone not bothering to carefully examine these
things is a liar and a cheat.

_P()
[00000c36](01) 55 push ebp
[00000c37](02) 8bec mov ebp,esp
[00000c39](03) 8b4508 mov eax,[ebp+08] // 2nd Param
[00000c3c](01) 50 push eax
[00000c3d](03) 8b4d08 mov ecx,[ebp+08] // 1st Param
[00000c40](01) 51 push ecx
[00000c41](05) e820fdffff call 00000966 // call H(P,P)
[00000c46](03) 83c408 add esp,+08
[00000c49](02) 85c0 test eax,eax
[00000c4b](02) 7402 jz 00000c4f
[00000c4d](02) ebfe jmp 00000c4d
[00000c4f](01) 5d pop ebp
[00000c50](01) c3 ret
Size in bytes:(0027) [00000c50]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
Begin Local Halt Decider Simulation at Machine Address:c36
[00000c36][002117ca][002117ce] 55 push ebp
[00000c37][002117ca][002117ce] 8bec mov ebp,esp
[00000c39][002117ca][002117ce] 8b4508 mov eax,[ebp+08]
[00000c3c][002117c6][00000c36] 50 push eax // push P
[00000c3d][002117c6][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][002117c2][00000c36] 51 push ecx // push P
[00000c41][002117be][00000c46] e820fdffff call 00000966 // call H(P,P)

[00000c36][0025c1f2][0025c1f6] 55 push ebp
[00000c37][0025c1f2][0025c1f6] 8bec mov ebp,esp
[00000c39][0025c1f2][0025c1f6] 8b4508 mov eax,[ebp+08]
[00000c3c][0025c1ee][00000c36] 50 push eax // push P
[00000c3d][0025c1ee][00000c36] 8b4d08 mov ecx,[ebp+08]
[00000c40][0025c1ea][00000c36] 51 push ecx // push P
[00000c41][0025c1e6][00000c46] e820fdffff call 00000966 // call H(P,P)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

> H(P, P) is required by the
> definition of the halting problem accept P(P) if and only if P(P), when
> run as an independent computation halts. The *only* correct answer to
> the question 'does P(P) halt' is the one that corresponds to the
> *actual* behaviour of P(P).
>
>> Because of the fact that No P ever halts unless H(P,P) aborts the
>> simulation of its input H(P,P) is more correct than P(P).
>
> You really need to reread what you've written above and think carefully
> about it.
>
> You're claiming that an answer which does *not* correspond to the actual
> answer to the question is somehow 'more correct' than the one which does
> correspond to the actual answer to the question.
>
> That's what I would call a 'pathological claim'.
>
> André
>

P(P) != H(P,P) recognizes the pathological self-reference(Olcott 2004)
error thus refuting Rice's theorem.

Jeff Barnett

unread,
Jul 26, 2021, 1:16:54 PMJul 26
to
On 7/26/2021 10:41 AM, olcott wrote:
> On 7/26/2021 11:09 AM, André G. Isaak wrote:

<SNIP>

>> You're claiming that an answer which does *not* correspond to the
>> actual answer to the question is somehow 'more correct' than the one
>> which does correspond to the actual answer to the question.
>>
>> That's what I would call a 'pathological claim'.
>>
>> André
>>
>
> P(P) != H(P,P) recognizes the pathological self-reference(Olcott 2004)
> error thus refuting Rice's theorem.

Reread the above and note how polite and nurturing Andre has been. And
yet you reject his simple, near trivial point. Of course he is correct.
You should apologize to him, not make silly arguments.

oh yes, how was Andres so polite to you? Well he called it a
"pathological claim"; a "pathological and irrational claimer" is much
nearer the mark others would say.

And what do you know about Rice? Since you likely can't boil water
without supervision to keep you from harm, you couldn't prepare rice. I
know it's a silly play on words but it's hard to believe that you can
function in the real world with such a disoriented mind.
--
Jeff Barnett

olcott

unread,
Jul 26, 2021, 2:57:27 PMJul 26
to
The HP has the same self-contradictory pattern as the Liar Paradox.
"This sentence is not true." is indeed not true just
like the P of int main() { P(P); } definitely reaches its halting state.

It is a mistake to take the fact that "This sentence is not true" is not
true as an indication that it is true.

In the exact same way it is a mistake to take the fact that the P of int
main() { P(P); } definitely reaches its halting state as an indication
that it is a halting computation.
It is very easy to see that the pure simulation of the input to H(P,P)
cannot possibly ever reach its final state by the fact that there are no
conditional instructions that can possibly break out of the above
infinite recursion.

It looks like people greatly prefer to be God damned liars on this issue.

I would hope for their sake that the following verse is not literally
true. If it was up to me they would simply be forgiven rather than
condemned to Hell (the literal meaning of: "God damned").

Revelation 21:8 (KJV)
...all liars, shall have their part in the lake which burneth with fire
and brimstone: which is the second death.

olcott

unread,
Jul 26, 2021, 3:40:13 PMJul 26
to
On 7/26/2021 12:00 PM, André G. Isaak wrote:
> On 2021-07-26 10:41, olcott wrote:
>> On 7/26/2021 11:09 AM, André G. Isaak wrote:
>
>>> But H(P, P) *isn't* verified as correct.
>>
>> While the input to H(P,P) is simulated in pure simulation mode it
>> cannot possibly ever reach a final state thus conclusively proving
>> that this input never halts.
>
> But P(P) is defined as including a copy of H which *isn't* run in 'pure
> simulation mode'.
>

Because it is common knowledge that in any scientific investigation when
we examine the effect of an independent variable[1] on a dependent
variable[2] that any back-channel communication from the dependent
variable[2] to the independent variable[1] corrupts the analysis.

[1] The behavior of P
[2] The halt status evaluation by H

The way to correct for this when an input to the halt decider was
intentionally defined to corrupt this process is to examine the behavior
of the input in pure simulation mode expressly disallowing any
corrupting back-channel communication from H to P.

> You can set the *outermost* H to run in 'pure simulator mode' if you
> want. But you can't change what occurs in P's copy of H (or put it in
> some other 'mode') or you are no longer evaluating P but something else.
>
>>>> Because of the fact that No P ever halts unless H(P,P) aborts the
>>>> simulation of its input H(P,P) is more correct than P(P).
>>>
>>> You really need to reread what you've written above and think
>>> carefully about it.
>>>
>>> You're claiming that an answer which does *not* correspond to the
>>> actual answer to the question is somehow 'more correct' than the one
>>> which does correspond to the actual answer to the question.
>>>
>>> That's what I would call a 'pathological claim'.
>>>
>>> André
>>>
>>
>> P(P) != H(P,P) recognizes the pathological self-reference(Olcott 2004)
>> error thus refuting Rice's theorem.
>
> There is no 'pathological self-reference error'. Nothing in Linz's proof
> involves something which refers at all, let alone something which refers
> to itself.
>

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

In the last page of the Linz proof provided in my paper above Linz does
apply Ĥ to its own machine decription. Why lie?

> The only pathological error here is your claim that an incorrect answer
> is 'more correct' than a correct answer.

olcott

unread,
Jul 26, 2021, 4:34:55 PMJul 26
to
On 7/26/2021 2:55 PM, André G. Isaak wrote:
> On 2021-07-26 12:57, olcott wrote:
>
>> In the exact same way it is a mistake to take the fact that the P of
>> int main() { P(P); } definitely reaches its halting state as an
>> indication that it is a halting computation.
>
> You seem to have a serious difficulty processing definitions.
>
> The *definition* of a halting computation is a computation which reaches
> one of its final states in a finite number of steps. This refers only to
> the *actual* computation.
>
> This definition exhaustively partitions the set of computations into two
> mutually-exclusive groups. If we observe that a computation such as P(P)
> reaches a final state in a finite number of steps, it goes in the
> halting group. Otherwise, it goes into the non-halting group.
>
> The definition is clear and unambiguous.
>
> It does not mention anything about simulators or aborted simulations.
>
> It makes no exceptions for 'pathological' inputs.
>
> It doesn't care *how* they end up in their final state. That is, it
> doesn't say "except if the only reason it halted was become some
> otherwise infinite chain of simulations was aborted".
>
> The *only* thing it cares about is whether the computation ends up in a
> final state after a finite number of steps.
>
> Once we have observed that P(P) *does* reach a final state in a finite
> number of steps, we put it in the 'halting' group and we are done.
>
> At this point, there are absolutely no additional considerations which
> can have any relevance whatsoever. No arguments, or traces, or claims
> about 'pathological' anything will make a difference to the fact that it
> has been placed in the halting group and thus *cannot* be a non-halting
> computation.
>
> The *only* possible way you can claim that H(P, P)==0 is if you are
> using an entirely different definition of 'halting' from the rest of the
> world,

A self-contradictory inputs such as the last page of the Linz proof
where the Linz Ĥ is applied to its own TM description must be handled
differently than inputs that are not self-contradictory.

You can say that when Ĥ is applied to its own TM description that it is
not a case of a TM being applied to its own TM description (an obvious
lie) or you can admit that this is a case of self-reference.

Being able to simply recognize that this input is self-contradictory
refutes Rice's Theorem. If the halt decider returned 2 for invalid input
this refutes Rices Theorem.

// Simplified Linz Ĥ (Linz:1990:319)
// Strachey(1965) CPL translated to C
void P(u32 x)
{
if (H(x, x))
HERE: goto HERE;
}

You can also say that when the input to H does the opposite of whatever
that halt decider decides that it is not doing the opposite of whatever
that halt decider decides. This would be an obvious lie.

Or you can admit that when the input does the opposite of whatever the
halt decider decides that it is contradicting the halt decider.



> in which case your argument has no bearing on the halting problem
> since that problem uses the standard definition of halting. An
> Olcott-Halting Decider is *not* a Halting Decider.
>
> André

olcott

unread,
Jul 26, 2021, 8:15:02 PMJul 26
to
On 7/26/2021 2:55 PM, André G. Isaak wrote:
> On 2021-07-26 12:57, olcott wrote:
>
>> In the exact same way it is a mistake to take the fact that the P of
>> int main() { P(P); } definitely reaches its halting state as an
>> indication that it is a halting computation.
>
> You seem to have a serious difficulty processing definitions.
>
> The *definition* of a halting computation is a computation which reaches
> one of its final states in a finite number of steps. This refers only to
> the *actual* computation.
>
> This definition exhaustively partitions the set of computations into two
> mutually-exclusive groups. If we observe that a computation such as P(P)
> reaches a final state in a finite number of steps, it goes in the
> halting group. Otherwise, it goes into the non-halting group.
>
> The definition is clear and unambiguous.
>
> It does not mention anything about simulators or aborted simulations.
>
> It makes no exceptions for 'pathological' inputs.
>

None-the-less if pathological inputs can be recognized this refutes Rice.
None-the-less if pathological inputs can be recognized this refutes Rice.
None-the-less if pathological inputs can be recognized this refutes Rice.
None-the-less if pathological inputs can be recognized this refutes Rice.

olcott

unread,
Jul 26, 2021, 9:03:39 PMJul 26
to
On 7/26/2021 7:21 PM, André G. Isaak wrote:
> There *are no* patholological inputs. There are simply inputs that H
> gets wrong. There's nothing absolutely 'pathological' about that.

If my system recognizes whatever you want to call it the cases where the
halt decider gets wrong, this refutes Rice.

At this point I suspect that you may think that I am talking about the
breakfast cereal and have no idea about Rice's Theorem.

In computability theory, Rice's theorem states that all non-trivial,
semantic properties of programs are undecidable.
https://en.wikipedia.org/wiki/Rice%27s_theorem

olcott

unread,
Jul 26, 2021, 9:30:39 PMJul 26
to
On 7/26/2021 8:24 PM, André G. Isaak wrote:
> What does that unsubstantiated claim have to do with the question I'd
> asked, which was:
>
> How can the claim that H(P, P)==0 be justified *in terms of the
> definition of halting* and in terms of the *actual behaviour* of P(P).
>

That does not currently matter, as long as we can consistently use
H(P,P) != P(P) to detect and reject the halting problem counter-examples
we have refuted Rice's theorem.

Is it possible for you to detect when the subject has been changed or do
you have a hard-coded robot brain?

> P(P) meets this definition. Therefore P(P) halts.
>
> If your your system is really capable of recogonizing the inputs that it
> gets wrong, why does it still get them wrong?
>
> André
>

Self-contradictory input is incorrect in the same way that the liar
paradox is neither true nor false.

olcott

unread,
Jul 26, 2021, 11:18:54 PMJul 26
to
On 7/26/2021 9:34 PM, André G. Isaak wrote:
> Of course it currently matters.
>
>> as long as we can consistently use H(P,P) != P(P) to detect and reject
>> the halting problem counter-examples we have refuted Rice's theorem.
>
> How on earth would that refute Rice's theorem?
>
> I *think* that by H(P,P) != P(P) you're *trying* (badly) to say 'the
> answer given by H(P, P) does not match the halting behaviour of P(P).
>
> But *we* would be the ones recognizing these counterexamples. That your
> machine gets these cases wrong means the machine certainly isn't
> recognizing them.
>

When the machine is able to reject these inputs it defeats Rice's
theorem. You must be clueless on this aspect.

When the machine is able to reject these inputs it defeats Rice's
theorem. You must be clueless on this aspect.

When the machine is able to reject these inputs it defeats Rice's
theorem. You must be clueless on this aspect.

>> Is it possible for you to detect when the subject has been changed or
>> do you have a hard-coded robot brain?
>
> You seem to 'change the subject' whenever you get stuck. Why not try
> actually sticking with a subject for a change rather than simply
> sweeping all objections under the rug and then claiming that no one has
> given you good arguments (a common tact with you).
>
> >> If your your system is really capable of recogonizing the inputs that
> >> it gets wrong, why does it still get them wrong?
>
>> Self-contradictory input is incorrect in the same way that the liar
>> paradox is neither true nor false.
>
> There *is no input* when I ask you to justify the claim that P(P)
> doesn't halt when it clearly does not. I'm asking about the behaviour of
> the computation P(P).
>
> André

olcott

unread,
Jul 27, 2021, 11:25:00 AMJul 27
to
On 7/27/2021 4:42 AM, Malcolm McLean wrote:
> On Tuesday, 27 July 2021 at 04:55:26 UTC+1, André G. Isaak wrote:
>> On 2021-07-26 21:31, olcott wrote:
>>>
>>>
>>> I have explained this totally several times now.
>>> if H(P,P) != P(P)
>>> incorrect input
>>> else
>>> correct input.
>> Will you please explain what is meant by H(P,P) != P(P)?
>>
>> As written, it mean 'if the result returned by H(P, P) does not equal
>> the result returned by P(P)', but as I said I *think* by P(P) you
>> actually mean 'the halting status of P'.
>>
>> If that is what you mean then how is H(P,P) != P(P) supposed to be
>> evaluated *by a Turing Machine*? Rice's Theorem is about what can be
>> computed, not just about things that can be stated.
>>
>> H(P, P) gets P(P) wrong, but it doesn't *know* that it gets this wrong
>> (otherwise you'd be able to easily fix H to get it right).
>>
> We've had a development. The claim that H(P,P) = false is correct when
> P(P) halts has been modified.
> Now we run H on P(P), and run P(P). If they match, then obviously H has
> done its job. If they don't, then that means that the input is "pathological".
> The special case suggested by Linz has been detected.
>
> There are snags with this approach, of course. For example, if P(P) is
> non-halting, how would you know when to terminate it? Ben said that
> this suggestion always comes up (UCL is a pretty high status university
> with the UK that attracts intelligent students).

No one has ever gotten as far as I have. No one has ever previously
shown that the input to a simulating halt decider specifies infinitely
nested simulation to this halt decider in the HP counter-example cases.

Any rebuttals to this assertion require complete citations.

Since no one has ever previously accomplished this key insight this
makes it impossible that anyone created any software system that
correctly recognizes and reports this infinitely nested simulation.

When the global simulator reports that the P of int main(){ P(P); }
halts this is encoded here as P(P)==1

When the local partial halt decider H reports that P(P) never halts
this is encoded here as H(P,P)==0

When they are out-of-sync for inputs with the pathological
self-reference(Olcott 2004) error we say P(P) != H(P,P)

We will show that this error is exactly the same as the Liar Paradox in
that both Boolean values are contradicted.

When P(P) != H(P,P) if we change H(P,P)==0 to correspond with P(P)==1
then the P of int main(){ P(P); } never halts.

Because P was intentionally defined to do the opposite of whatever
halt status value that H reports neither Boolean value is correct.

This is exactly the same result as the Liar Paradox.

Because it is true that no P ever halts unless some P is aborted it
still seems to me that H(P,P)==0 is correct and the fact that the P of
int main(){ P(P); } halts is the error.

Because no P ever halts unless some P is aborted seems to prove that int
main(){ P(P); } specifies a non-halting computation.

> The suggestion is to detect
> the Linz input and special case it.
>

I don't even have to write any more code. Whenever a human sees that
H(P,P) reports 0 and the P of int main(){ P(P); } reaches its final
state we know this is a case of the self-contradictory input
pathological self-reference(Olcott 2004) error.

Applying this same idea to a fully elaborated complete halt decider
would derive a halt decider where the only time that the input reaches a
final state and the halt decider reports that this input never halts are
the self-contradictory input pathological self-reference(Olcott 2004)
error cases.

Jeff Barnett

unread,
Jul 27, 2021, 1:21:48 PMJul 27
to
On 7/27/2021 9:24 AM, olcott wrote:

<SNIP>

> No one has ever gotten as far as I have. No one has ever previously
> shown that the input to a simulating halt decider specifies infinitely
> nested simulation to this halt decider in the HP counter-example cases.

I'm glad to see you have something to take pride in. However, lets make
sure we all know what that accomplishment really is: You have set a
world record in number of wrong conclusions reached by a record long
chain of improper inferences. You have also set a world record for
turning a deaf ear to all of those trying-to-help people who have
pointed out the mistakes at each and every step.

I have not cut the set of newsgroups this message will reach: I think
all will rejoice at your success and hope you will retire into silence.
Should we contact Guinness? Or will you take care of that?

Alright everyone, lets hear a loud cheer for PO!
--
Jeff Barnett

olcott

unread,
Jul 28, 2021, 9:56:27 AMJul 28
to
On 7/28/2021 4:41 AM, Malcolm McLean wrote:
> On Wednesday, 28 July 2021 at 04:12:00 UTC+1, olcott wrote:
>>
>> Simulate(P,P)==1 indicates that the global simulator embedded in the
>> x86utm operating system has determined that the function called by main
>> has reached its final state.
>>
>> There will not actually be any function call Simulate(P,P) per 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.
>>
>> Yo argued against even considering Rice because you Are stuck in
>> rebuttal mode. This bias is a form of dishonesty.
>>
> "Confounds H" is maybe a non-trivial semantic property of a machine. Not
> quite sure about this. But to compute it, you need H, and a correct halt decider.
> So I doubt it's a fruitful path for invesigation.
>

The reason that no one has solved these things before is that they never
bothered to think through ALL the possibilities. They try a few things
that don't work and then give up. The key advantage that I have over
other people is my system of categorically exhaustive reasoning. This
system makes it possible to discover possibilities that were previously
overlooked.

Any system that divides all inputs into those having the pathological
self-reference(Olcott 2004) error and those not having this error does
refute Rice's theorem no matter how it accomplishes this feat.

I am working on creating the code for this.

olcott

unread,
Jul 28, 2021, 10:09:14 AMJul 28
to
On 7/27/2021 10:39 PM, André G. Isaak wrote:
> On 2021-07-27 21:11, olcott wrote:
>> On 7/27/2021 2:42 PM, André G. Isaak wrote:
>>> On 2021-07-27 11:31, olcott wrote:
>>>> On 7/27/2021 12:16 PM, André G. Isaak wrote:
>>>>> What exactly is the 'global simulator'?
>>>>>
>>>>> You used to have something called a 'global halt decider' but
>>>>> according to you this *also* wrongly decides that P(P) doesn't halt.
>>>>>
>>>>> And in previous posts you've claimed that a 'pure simulation' of
>>>>> P(P) doesn't halt. Now your saying that it *does* halt inside a
>>>>> 'global simulator'? So what's the difference between a 'global'
>>>>> simulator and a 'pure simulator'? Why do you claim it halts in one
>>>>> and not in the other?
>>>>>
>>>>>> When the local partial halt decider H reports that P(P) never halts
>>>>>> this is encoded here as H(P,P)==0
>>>>>>
>>>>>> When they are out-of-sync for inputs with the pathological
>>>>>> self-reference(Olcott 2004) error we say P(P) != H(P,P)
>>>>>>
>>>>>> We will show that this error is exactly the same as the Liar
>>>>>> Paradox in that both Boolean values are contradicted.
>>>>>>
>>>>>> When P(P) != H(P,P) if we change H(P,P)==0 to correspond with P(P)==1
>>>>>> then the P of int main(){ P(P); } never halts.
>>>>>
>>>>> Again, does P(P) != H(P,P) mean that the halting status of P(P)
>>>>> doesn't match H(P,P),
>>>>
>>>> Since I already totally explained this immediately above and your
>>>
>>> Not clearly, you didn't. P(P) != H(P, P) is an abuse of notation,
>>> because you're comparing apples and oranges. This should either mean
>>> 'the halting status of P(P) doesn't equal the halting status of H(P,P)'
>>
>> Simulate(P,P)==1 indicates that the global simulator embedded in the
>> x86utm operating system has determined that the function called by
>> main has reached its final state.
>
> 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.

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?
>
>> There will not actually be any function call Simulate(P,P) per 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.
> The problem is that H isn't doing the detecting. To the extent 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.

olcott

unread,
Jul 28, 2021, 12:01:45 PMJul 28
to
On 7/28/2021 10:23 AM, Ben Bacarisse wrote:
> olcott <No...@NoWhere.com> writes:
>
>> I have never been shown guilty of lying.
>
> It's hard, in your case, to distinguish between ignorance and deception,
> but here are some top candidates:
>
> "I now have an actual H that decides actual halting for an actual (Ĥ,
> Ĥ) input pair."
>

This still seems sufficiently true as elaborated below.

> "Everyone has claimed that H on input pair (Ĥ, Ĥ) meeting the Linz
> specs does not exist. I now have a fully encoded pair of Turing
> Machines H / Ĥ proving them wrong."
>

This uses a little poetic license in that what I actually had was the
sufficiently complete C code that correctly decides the impossible
counter-example inputs.

At the time I knew that it was computationally equivalent to Turing
machines yet was unaware that the concept of: "computationally
equivalent to Turing machines" was understood to exist.

As it currently stands I apparently did augment the conventional concept
of Turing equivalence making it broader to encompass all computations
that can be correctly completed in whatever memory is available.

> "I provide the exact ... states after the Linz H.q0 and after Ĥ.qx
> ... showing exactly how the actual Linz H would correctly decide the
> actual Linz (Ĥ, Ĥ)."
>

This idea is elaborated to a much greater extent when H(P,P) correctly
decides that its input cannot possibly reach its final state while H
remains a pure simulator of this input.

The same applies here: The input to H.qx(Ĥ, Ĥ) cannot possibly reach its
final state while H.qx remains a pure simulator of this input.

> "I really do have a halting decider."
>
> "The non-halting decider that I defined accepts any and all
> non-halting inputs and rejects any and all halting inputs."
>

When we apply my design to the halting problem the conventional proofs
utterly lose their entire basis thus no longer prove that a full halt
decider cannot exist.

> "Ĥ does not copy its input"
>
> Maybe you could point out which of these are simply mistakes and which
> are deliberate untruths?
>

Ĥ does copy its input.

olcott

unread,
Jul 28, 2021, 12:39:07 PMJul 28
to
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) per 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.
>>> The problem is that H isn't doing the detecting. To the extent 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é
>

I am not going to go down the path of infinitely nested operating systems.

olcott

unread,
Jul 28, 2021, 2:35:49 PMJul 28
to
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));

olcott

unread,
Jul 28, 2021, 3:07:45 PMJul 28
to
On 7/28/2021 1:47 PM, André G. Isaak 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.

olcott

unread,
Jul 28, 2021, 4:06:51 PMJul 28
to
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 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.

When we explicitly take into account the self-contradictory nature of
these two cases things are not as cut-and-dried.

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

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

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

As Ben has unequivocally agreed any simulation that only halts because
it was aborted is a non-halting computation.

>>> 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 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.
>>>>> The problem is that H isn't doing the detecting. To the extent 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.
>
> 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.
>>
>
>

The bottom line is that self-contradiction must be treated differently,
the conventional rules do not apply to self-contradiction.

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.

olcott

unread,
Jul 28, 2021, 11:26:05 PMJul 28
to
On 7/28/2021 6:25 PM, André G. Isaak wrote:
> 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é
>
>

This is an improvement over what anyone else has ever done:
Every input to a simulating halt decider that only stops running when
its simulation is aborted unequivocally specifies a computation that
never halts.

The P of int main(){ P(P); } is one of these inputs therefore H
correctly decides that it never halts.

olcott

unread,
Jul 28, 2021, 11:51:55 PMJul 28
to
On 7/28/2021 6:36 PM, André G. Isaak wrote:
> 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.

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

Every input to a simulating halt decider that only stops running when
its simulation is aborted unequivocally specifies a computation that
never halts.

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

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)

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

It is generally always the case that self-contradictory expressions of
language must always be treated differently than non self-contradictory
expressions of language.

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.

olcott

unread,
Jul 29, 2021, 12:31:58 AMJul 29
to
On 7/28/2021 11:15 PM, André G. Isaak wrote:
> 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.

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

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

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

This make perfect sense:
garbage in (self contradictory input)
garbage out (contradictory result).


> 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.
> You've raised this before. It's as meaningless now as it was when you
> first suggested it.
>

No it is not. It does perfectly address the issue of the liar paradox.

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

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.

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.

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.

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.

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.


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

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)

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)

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

olcott

unread,
Jul 29, 2021, 1:39:27 PMJul 29
to
On 7/29/2021 12:00 AM, André G. Isaak wrote:
> 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').
>

We have two different equally correct definitions of halting that have a
contradictory result thus proving garbage in garbage out.
Self-contradictory inputs derive contradictory conclusions.
> I asked you to show me a *definition* of UTM which refers to
> computational equivalence. The above is not a definition.

Perhaps you are proving that you are unqualified to evaluate my work?
...anything which can be “computed”, can also be computed by that one
universal machine. Conversely, any problem that is not computable by the
universal machine is considered to be uncomputable.
https://plato.stanford.edu/entries/turing-machine/#TuriUnivMach

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

Which is another way of saying:
Every input to a simulating halt decider that only stops running when
its simulation is aborted unequivocally specifies a computation that
never halts.

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

None-the-less my definitions are computationally equivalent to the
standard ones on this basis: UTM(P,I) ≡ P(I)

That you deny this seems to indicate that you do not know the subject
matter well enough to be qualified to evaluate my work.
> 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.

And in this exact same way the fact that the following sentence is not
true: "this sentence is not true" should make it true, but it does not.

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

When we encode the above in C and this function is executed with input:
P its behavior contradicts every halt status that H can return.

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


> André
>
> <snip remainder, including, asinine, juvenile repetition>

olcott

unread,
Jul 29, 2021, 2:15:24 PMJul 29
to
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.

olcott

unread,
Jul 29, 2021, 6:50:18 PMJul 29
to
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.

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

olcott

unread,
Jul 29, 2021, 8:54:59 PMJul 29
to
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:
>>> 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:

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.

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

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

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 H1(P2,P2)

[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 H2(P3,P3)
Local Halt Decider: Infinite Recursion Detected Simulation Stopped


> This is shown by the simple fact that the actual computation P(P) halts.
>
> André

olcott

unread,
Jul 30, 2021, 12:34:33 AMJul 30
to
On 7/29/2021 8:25 PM, André G. Isaak wrote:
> 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()
[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.

olcott

unread,
Jul 30, 2021, 11:58:20 AMJul 30
to
On 7/30/2021 9:54 AM, André G. Isaak wrote:
> Without knowing what happens at address 955, none of the above tells us
> anything at all about what happens in this code.
>
> André
>
>

That is very obviously flat out not true when we know that H is a
simulating partial halt decider. In this case H either continues to
simulate its input or stops simulating its input either way this input
never reaches its final state of 0x3cf.

olcott

unread,
Jul 31, 2021, 11:20:11 AMJul 31
to
On 7/31/2021 10:02 AM, wij wrote:
> 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:
>>>> 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.
>>>
>> _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 // 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 halt decider does not freaking fail on its freaking inputs.

We know with 100% perfect complete logical certainty that the halt
decider does correctly decide that its input never halts.

That the input cannot possibly ever reach its final state of 0xc3f
whether or not H aborts the simulation of this input conclusively proves
that this input never halts beyond all possible logically correct doubt.

If you don't know the x86 language then this may not be apparent.

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

olcott

unread,
Jul 31, 2021, 3:53:01 PMJul 31
to
On 7/31/2021 2:23 PM, Richard Damon wrote:
> 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.
>

You apparently are not bright enough to understand this.

People that are bright enough to understand this simply comprehend that
a pure simulator or a simulating halt decider in pure simulation mode
cannot possibly have any effect on the behavior of its input.

These same people understand that because it cannot possibly have any
effect on the behavior of its input that logically entails that it
cannot possibly have any effect on any halt status decision of the
behavior of this input.

Finally these same people that understand that the behavior of the
simulating halt decider while it is in pure simulation mode cannot not
have any effect on its halt status decision will understand that this
simulating halt decider can screen out its own address range and thus
ignore its own behavior in any halt status decision as long as it only
does this while it remains in pure simulation mode.

> 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.
Reply all
Reply to author
Forward
0 new messages