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

On 7/25/21 8:53 PM, olcott wrote:
> 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, you haven't. You just won't look at the arguemts about why you are
so wrong.
>
> 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.

Since that is the DEFINITION of what H is suppose to decide on, that
seems to be a reasonable thing to look at.

>
> 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 mean like you analyise the simulation based on the assumption that H
will NEVER abort its simulation, and then you have H abort that
simulation? THAT UNSOUND ARGUEMNT?

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

When you apply the critera of the problem you claim to be solving.

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

No, you have proved that you use UNSOUND logic.

You show that you do not understand what a Turing Machine is.

You insist on looking at the wrong version of H^ (which you want to call
P), that is built on the wrong H, because you seem to think that it
doesn't matter.

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)

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

André

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

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:

>> Anyway I would be with you on the "static" vs. operational (temporal)
>> process question, but we might both be outliers I guess. [Something
>> you said a few years back raised the possibility in my mind that
>> perhaps we had both studied at the same university, possibly even
>> around the same time. (Cambridge, 1979-1981.)]

> Blimey, yes. Peterhouse.

Hah! Emmanuel, 1976-1980. I had to content myself with a Junior
Optime, though.

> --
> Ben.

--
Alan Mackenzie (Nuremberg, Germany).

Alan Mackenzie <acm@muc.de> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>
>>> Anyway I would be with you on the "static" vs. operational (temporal)
>>> process question, but we might both be outliers I guess. [Something
>>> you said a few years back raised the possibility in my mind that
>>> perhaps we had both studied at the same university, possibly even
>>> around the same time. (Cambridge, 1979-1981.)]
>
>> Blimey, yes. Peterhouse.
>
> Hah! Emmanuel, 1976-1980. I had to content myself with a Junior
> Optime, though.

There's a clique, here!

I moved into the two-year Computer Science Tripos (the only way to do CS
at the time) so I avoided the silly titles!

--
Ben.

On Monday, 26 July 2021 at 14:17:53 UTC+1, Ben Bacarisse wrote:
> Alan Mackenzie <a...@muc.de> writes:
>
> > Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> >> Mike Terry <news.dead.p...@darjeeling.plus.com> writes:
> >
> >>> Anyway I would be with you on the "static" vs. operational (temporal)
> >>> process question, but we might both be outliers I guess. [Something
> >>> you said a few years back raised the possibility in my mind that
> >>> perhaps we had both studied at the same university, possibly even
> >>> around the same time. (Cambridge, 1979-1981.)]
> >
> >> Blimey, yes. Peterhouse.
> >
> > Hah! Emmanuel, 1976-1980. I had to content myself with a Junior
> > Optime, though.
> There's a clique, here!
>
> I moved into the two-year Computer Science Tripos (the only way to do CS
> at the time) so I avoided the silly titles!
>
So you do one year of the infamous Natural Sciences course, then two years
of Computer Science? Or do you start as a mathematician?

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Monday, 26 July 2021 at 14:17:53 UTC+1, Ben Bacarisse wrote:
>> Alan Mackenzie <a...@muc.de> writes:
>>
>> > Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>> >> Mike Terry <news.dead.p...@darjeeling.plus.com> writes:
>> >
>> >>> Anyway I would be with you on the "static" vs. operational (temporal)
>> >>> process question, but we might both be outliers I guess. [Something
>> >>> you said a few years back raised the possibility in my mind that
>> >>> perhaps we had both studied at the same university, possibly even
>> >>> around the same time. (Cambridge, 1979-1981.)]
>> >
>> >> Blimey, yes. Peterhouse.
>> >
>> > Hah! Emmanuel, 1976-1980. I had to content myself with a Junior
>> > Optime, though.
>> There's a clique, here!
>>
>> I moved into the two-year Computer Science Tripos (the only way to do CS
>> at the time) so I avoided the silly titles!
>>
> So you do one year of the infamous Natural Sciences course, then two years
> of Computer Science? Or do you start as a mathematician?

You could (theoretically) start with history. I started as a
mathematician.

--
Ben.

On Monday, 26 July 2021 at 14:32:05 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Monday, 26 July 2021 at 14:17:53 UTC+1, Ben Bacarisse wrote:
> >> Alan Mackenzie <a...@muc.de> writes:
> >>
> >> > Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> >> >> Mike Terry <news.dead.p...@darjeeling.plus.com> writes:
> >> >
> >> >>> Anyway I would be with you on the "static" vs. operational (temporal)
> >> >>> process question, but we might both be outliers I guess. [Something
> >> >>> you said a few years back raised the possibility in my mind that
> >> >>> perhaps we had both studied at the same university, possibly even
> >> >>> around the same time. (Cambridge, 1979-1981.)]
> >> >
> >> >> Blimey, yes. Peterhouse.
> >> >
> >> > Hah! Emmanuel, 1976-1980. I had to content myself with a Junior
> >> > Optime, though.
> >> There's a clique, here!
> >>
> >> I moved into the two-year Computer Science Tripos (the only way to do CS
> >> at the time) so I avoided the silly titles!
> >>
> > So you do one year of the infamous Natural Sciences course, then two years
> > of Computer Science? Or do you start as a mathematician?
> You could (theoretically) start with history. I started as a
> mathematician.
>
They must have had their reasons. But it's a bit odd to have a degree which you
can't apply for on admission, but only discover an interest after being admitted
to read another subject. Specialisation, of course, happens all the time, and
you could say that CS is a subset of mathematics.

Ben Bacarisse wrote:
> Alan Mackenzie <acm@muc.de> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>
>>>> Anyway I would be with you on the "static" vs. operational (temporal)
>>>> process question, but we might both be outliers I guess. [Something
>>>> you said a few years back raised the possibility in my mind that
>>>> perhaps we had both studied at the same university, possibly even
>>>> around the same time. (Cambridge, 1979-1981.)]
>>
>>> Blimey, yes. Peterhouse.
>>
>> Hah! Emmanuel, 1976-1980. I had to content myself with a Junior
>> Optime, though.
>
> There's a clique, here!

In the sense of graph theory?

>
> I moved into the two-year Computer Science Tripos (the only way to do CS
> at the time) so I avoided the silly titles!
>

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

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

--
Copyright 2021 Pete Olcott

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

On 7/25/2021 7:08 PM, Mike Terry wrote:
> On 25/07/2021 23:42, Ben Bacarisse wrote:
>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>
>>> On 25/07/2021 21:28, Mike Terry wrote:
>>> Pressed Send too soon. :(
>>>> On 25/07/2021 18:40, Malcolm McLean wrote:
>>>>> 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. However when we have, for
>>>>> example, the
>>>>> "H is the operating system" ruse, I do tend to say "that's a clever
>>>>> cheat"
>>>>> rather than "how could you make such a simple and obvious error?".
>>>>> Largely because it's a nicer way of conveying essentially the same
>>>>> information.
>>>>>
>>>>> I did say recently that PO had constructed his own paradox. It's
>>>>> this. If
>>>>> H is  simulating halt decider, and is called on H, it creates a
>>>>> series of
>>>>> nested recursions. If it doesn't detect the situation, it never
>>>>> halts. If
>>>>> it does detect the situation and terminates the simulations, it halts.
>>>>> However if it halts, the nested recursions were not infinite.
>>>> Right, that's a bit like something I pointed out to PO last year.  Such
>>>> an emulation-based (putative) decider may have a number of tests in
>>>> its stepping loop.  Some may be /sound/, like a properly implemented
>>>> tight-loop test, or a test might be unsound in that it incorrectly
>>>> decides halting for a non-halting input or vice-versa.  The sound tests
>>>> might match and make correct decisions when examining particular
>>>> inputs, BUT it's sort of weird that the when H examines (P,P), the
>>>> /sound/ tests
>>>> "mysteriously" never ever match!  The only tests that will ever
>>>> match are those that are unsound...  If there are /only/ sound tests
>>>> in the
>>>> loop, none of them will match and H(P,P) will never make its
>>>> decision and halt!  Of course that would disqualify H as a decider.
>>>> This applies for PO and his "detecting infinite recursions" test,
>>>> however much he believes his test to be sound...  I've told him that
>>>> a reviewer will
>>>
>>> ...expect to see a /proof/ of the soundness of any test in his loop,
>>> if he's going to expect them to take matching of the test as
>>> /evidence/ of halting status.  (Of course PO can't deliver such a
>>> proof.)
>>
>> Right.  And very well put.  But he's abandoned almost all pretence at
>> dealing with halting.  What makes a sound test has been defined to be
>> what H does.  This is the "adapted" criterion for halting.  Not halting,
>> but whatever it is he chooses to put into H.  When he says that its
>> "impossibly incorrect" (if that's the term, I try to forget such things)
>> this is what he means.
>
> Perhaps the root problem is that PO REALLY REALLY REALLY believes his
> "infinite recursive behaviour" test is sound, for whatever reason.  I
> mean that his intuition that it is sound is AS STRONG OR STRONGER than
> his recent understanding that a machine which runs and transitions into
> a halt state is a halting computation.
>
> So he has an example where both
> (a) the computation P(P) undeniably reaches a halt state (so is halting)
> (b) his test in H(P,P) matches the computation when it runs!!!!!!! so it
>     is UNDENIABLY "exhibiting infinite recursion" (WTM)
>
> Both principles are equally believed by PO, so both conclusions MUST be
> correct!  A "paradox"!!!  P(P) halts, and yet it exhibits infinite
> recursion and so "cannot halt", even though it does.  What to do?!
>

You have the paradox incorrectly. 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.

When H recognizes this infinite behavior pattern and stops simulating
its input, this input still never reaches its final state, thus never
halts.

Many thanks to André G. Isaak for pointing out the proper and best
definition of halting we no longer have the ambiguity between halting
(reaching its final state) and stopping running (simulation aborted).

> For 99.99999% of people, there would be no dilemma here.  Presented with
> (a), which is /the definition/ of halting as used in HP proofs, and
> given that (b) was an intuition for which they had /no proof/ of its
> correctness, the conclusion would be: (a) is correct, so the test in (b)
> hasn't worked for some reason.  It is unsound.
>
> And 99.3% of those people would be capable of resolving this - they'd
> track through the computation in (a), using it to pin down where they
> went astray in intuition (b).  End of story.
>
> All his recent posts seem to focus on a mixture of one or two totally
> banal claims (along the lines of "a computation which never reaches one
> of its halt states is a non-halting computation" (LOL), followed by a
> bogus claim like "my trace UNDENIABLY proves that the test in (b)
> MATCHED!!!!!! and any software engineer who understands x86 will confirm
> this - THEREFORE non-halting behaviour HAS been detected so non-halting
> is the right answer."  (Well, that's what you said with "halting is what
> H does", and I've rephrased it for you in 200 words for no real benefit
> hehe.)
>
> I don't see any more than that going on - an absolute faith in the
> correctness of his unsound (b) test, although he must realise he can't
> prove it is sound.  I guess he really thinks reviewers will accept it as
> obvious, and everybody here is just stupid or deliberately lying due to
> being "in rebuttal mode".
>
> Mike.
>

--
Copyright 2021 Pete Olcott

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Monday, 26 July 2021 at 14:32:05 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Monday, 26 July 2021 at 14:17:53 UTC+1, Ben Bacarisse wrote:
>> >> Alan Mackenzie <a...@muc.de> writes:
>> >>
>> >> > Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
>> >> >> Mike Terry <news.dead.p...@darjeeling.plus.com> writes:
>> >> >
>> >> >>> Anyway I would be with you on the "static" vs. operational (temporal)
>> >> >>> process question, but we might both be outliers I guess. [Something
>> >> >>> you said a few years back raised the possibility in my mind that
>> >> >>> perhaps we had both studied at the same university, possibly even
>> >> >>> around the same time. (Cambridge, 1979-1981.)]
>> >> >
>> >> >> Blimey, yes. Peterhouse.
>> >> >
>> >> > Hah! Emmanuel, 1976-1980. I had to content myself with a Junior
>> >> > Optime, though.
>> >> There's a clique, here!
>> >>
>> >> I moved into the two-year Computer Science Tripos (the only way to do CS
>> >> at the time) so I avoided the silly titles!
>> >>
>> > So you do one year of the infamous Natural Sciences course, then two years
>> > of Computer Science? Or do you start as a mathematician?
>>
>> You could (theoretically) start with history.

Come to think of it, I'm not 100% certain of this. There may well have
been a list of acceptable subjects.

>> I started as a mathematician.
>>
> They must have had their reasons.

In 1979 CS degrees were not that common, but I also suspect there was a
measure of snobbery involved -- CS was an upstart subject and could not,
surely, fill a whole honours degree.

> But it's a bit odd to have a degree which you can't apply for on
> admission, but only discover an interest after being admitted to read
> another subject.

At least as far as I was concerned that was not the case, though it's
true you couldn't "apply" for it in any way other than by expressing an
interest during interview.

The full-length CS degree started, I think, when I left.

--
Ben.

On 7/25/2021 5:42 PM, Ben Bacarisse wrote:
> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>
>> On 25/07/2021 21:28, Mike Terry wrote:
>> Pressed Send too soon. :(
>>> On 25/07/2021 18:40, Malcolm McLean wrote:
>>>> 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. However when we have, for example, the
>>>> "H is the operating system" ruse, I do tend to say "that's a clever cheat"
>>>> rather than "how could you make such a simple and obvious error?".
>>>> Largely because it's a nicer way of conveying essentially the same
>>>> information.
>>>>
>>>> I did say recently that PO had constructed his own paradox. It's this. If
>>>> H is  simulating halt decider, and is called on H, it creates a series of
>>>> nested recursions. If it doesn't detect the situation, it never halts. If
>>>> it does detect the situation and terminates the simulations, it halts.
>>>> However if it halts, the nested recursions were not infinite.
>>> Right, that's a bit like something I pointed out to PO last year.  Such
>>> an emulation-based (putative) decider may have a number of tests in its stepping loop.  Some may be /sound/, like a properly implemented
>>> tight-loop test, or a test might be unsound in that it incorrectly decides halting for a non-halting input or vice-versa.  The sound tests
>>> might match and make correct decisions when examining particular inputs, BUT it's sort of weird that the when H examines (P,P), the /sound/ tests
>>> "mysteriously" never ever match!  The only tests that will ever match are those that are unsound...  If there are /only/ sound tests in the
>>> loop, none of them will match and H(P,P) will never make its decision and halt!  Of course that would disqualify H as a decider.
>>> This applies for PO and his "detecting infinite recursions" test,
>>> however much he believes his test to be sound...  I've told him that a reviewer will
>>
>> ...expect to see a /proof/ of the soundness of any test in his loop,
>> if he's going to expect them to take matching of the test as
>> /evidence/ of halting status. (Of course PO can't deliver such a
>> proof.)
>
> Right. And very well put. But he's abandoned almost all pretence at
> dealing with halting. What makes a sound test has been defined to be
> what H does. This is the "adapted" criterion for halting. Not halting,
> but whatever it is he chooses to put into H. When he says that its
> "impossibly incorrect" (if that's the term, I try to forget such things)
> this is what he means.
>

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.

When H recognizes this infinite behavior pattern and stops simulating
its input, this input still never reaches its final state, thus never halts.

Many thanks to André G. Isaak for pointing out the proper and best
definition of halting we no longer have the ambiguity between halting
(reaching its final state) and stopping running (simulation aborted).

--
Copyright 2021 Pete Olcott

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

On 7/26/21 7:20 AM, 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.

Translation: H(P,P) is wrong because P(P) was designed so that H
couldn't get it right. I is improper to create inputs that disagree with
my ideas, so I will just define that they are wrong, even if they do exist.

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

Translation: I don't like that this exsits, so I refuse to accept it,
and have published some drivel that makes a flawed argument to show why
my falsehood are correct. Everybody else is wrong. It is unfair that
people can use real logic to show that I am wrong, so any such logic
must be incorrect, as I have 'proven' (stomp feet and yells).

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

Translation: I will redefine the meaning of things so that what I
believe can be true, and refuse to accept tha this logic is full of
contradictions, because I will just redefine things so that it isn't
one, at least in my own twisted mind. If needed I will accept that 0 ==
1 if that is needed to help prove that I am correct.

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

Translation: I want to believe my own delusions of what is true that the
actual reality.

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

Translation: I refuse to look at any of the arguments that I am wrong. I
refuse to accept that I am wrong, so everyone one else must be, even if
that means that I have to throw out the basics of logic.

>
>>
>> André
>>
>>
>
>

On 7/25/2021 3:46 PM, Mike Terry wrote:
> On 25/07/2021 21:28, Mike Terry wrote:
> Pressed Send too soon. :(
>> On 25/07/2021 18:40, Malcolm McLean wrote:
>>> 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. However when we have, for example, the
>>> "H is the operating system" ruse, I do tend to say "that's a clever
>>> cheat"
>>> rather than "how could you make such a simple and obvious error?".
>>> Largely because it's a nicer way of conveying essentially the same
>>> information.
>>>
>>> I did say recently that PO had constructed his own paradox. It's
>>> this. If
>>> H is  simulating halt decider, and is called on H, it creates a
>>> series of
>>> nested recursions. If it doesn't detect the situation, it never
>>> halts. If
>>> it does detect the situation and terminates the simulations, it halts.
>>> However if it halts, the nested recursions were not infinite.
>>
>> Right, that's a bit like something I pointed out to PO last year.
>> Such an emulation-based (putative) decider may have a number of tests
>> in its stepping loop.  Some may be /sound/, like a properly
>> implemented tight-loop test, or a test might be unsound in that it
>> incorrectly decides halting for a non-halting input or vice-versa.
>> The sound tests might match and make correct decisions when examining
>> particular inputs, BUT it's sort of weird that the when H examines
>> (P,P), the /sound/ tests "mysteriously" never ever match!  The only
>> tests that will ever match are those that are unsound...  If there are
>> /only/ sound tests in the loop, none of them will match and H(P,P)
>> will never make its decision and halt!  Of course that would
>> disqualify H as a decider.
>>
>> This applies for PO and his "detecting infinite recursions" test,
>> however much he believes his test to be sound...  I've told him that a
>> reviewer will
>
> ...expect to see a /proof/ of the soundness of any test in his loop, if
> he's going to expect them to take matching of the test as /evidence/ of
> halting status.  (Of course PO can't deliver such a proof.)
>

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

That you say the above is not proof that the input to H(P,P) cannot
possibly reach its final state of 0xc50 while H is in pure simulation
mode seems to be either gross ignorance or flat out dishonestly.

You have proven that you can do much better than this, what gives?

>>
>> Mike.
>>
>>>
>>> I do wonder if this could form the nucleus of an another proof that
>>> halting is undecidable.
>>>

--
Copyright 2021 Pete Olcott

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

On 7/26/21 7:32 AM, olcott wrote:
> On 7/25/2021 7:08 PM, Mike Terry wrote:
>> On 25/07/2021 23:42, Ben Bacarisse wrote:
>>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>>
>>>> On 25/07/2021 21:28, Mike Terry wrote:
>>>> Pressed Send too soon. :(
>>>>> On 25/07/2021 18:40, Malcolm McLean wrote:
>>>>>> 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. However when we have, for
>>>>>> example, the
>>>>>> "H is the operating system" ruse, I do tend to say "that's a
>>>>>> clever cheat"
>>>>>> rather than "how could you make such a simple and obvious error?".
>>>>>> Largely because it's a nicer way of conveying essentially the same
>>>>>> information.
>>>>>>
>>>>>> I did say recently that PO had constructed his own paradox. It's
>>>>>> this. If
>>>>>> H is  simulating halt decider, and is called on H, it creates a
>>>>>> series of
>>>>>> nested recursions. If it doesn't detect the situation, it never
>>>>>> halts. If
>>>>>> it does detect the situation and terminates the simulations, it
>>>>>> halts.
>>>>>> However if it halts, the nested recursions were not infinite.
>>>>> Right, that's a bit like something I pointed out to PO last year. 
>>>>> Such
>>>>> an emulation-based (putative) decider may have a number of tests in
>>>>> its stepping loop.  Some may be /sound/, like a properly implemented
>>>>> tight-loop test, or a test might be unsound in that it incorrectly
>>>>> decides halting for a non-halting input or vice-versa.  The sound
>>>>> tests
>>>>> might match and make correct decisions when examining particular
>>>>> inputs, BUT it's sort of weird that the when H examines (P,P), the
>>>>> /sound/ tests
>>>>> "mysteriously" never ever match!  The only tests that will ever
>>>>> match are those that are unsound...  If there are /only/ sound
>>>>> tests in the
>>>>> loop, none of them will match and H(P,P) will never make its
>>>>> decision and halt!  Of course that would disqualify H as a decider.
>>>>> This applies for PO and his "detecting infinite recursions" test,
>>>>> however much he believes his test to be sound...  I've told him
>>>>> that a reviewer will
>>>>
>>>> ...expect to see a /proof/ of the soundness of any test in his loop,
>>>> if he's going to expect them to take matching of the test as
>>>> /evidence/ of halting status.  (Of course PO can't deliver such a
>>>> proof.)
>>>
>>> Right.  And very well put.  But he's abandoned almost all pretence at
>>> dealing with halting.  What makes a sound test has been defined to be
>>> what H does.  This is the "adapted" criterion for halting.  Not halting,
>>> but whatever it is he chooses to put into H.  When he says that its
>>> "impossibly incorrect" (if that's the term, I try to forget such things)
>>> this is what he means.
>>
>> Perhaps the root problem is that PO REALLY REALLY REALLY believes his
>> "infinite recursive behaviour" test is sound, for whatever reason.  I
>> mean that his intuition that it is sound is AS STRONG OR STRONGER than
>> his recent understanding that a machine which runs and transitions
>> into a halt state is a halting computation.
>>
>> So he has an example where both
>> (a) the computation P(P) undeniably reaches a halt state (so is halting)
>> (b) his test in H(P,P) matches the computation when it runs!!!!!!! so it
>>      is UNDENIABLY "exhibiting infinite recursion" (WTM)
>>
>> Both principles are equally believed by PO, so both conclusions MUST
>> be correct!  A "paradox"!!!  P(P) halts, and yet it exhibits infinite
>> recursion and so "cannot halt", even though it does.  What to do?!
>>
>
> You have the paradox incorrectly. 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.
>
> When H recognizes this infinite behavior pattern and stops simulating
> its input, this input still never reaches its final state, thus never
> halts.
>
> Many thanks to André G. Isaak for pointing out the proper and best
> definition of halting we no longer have the ambiguity between halting
> (reaching its final state) and stopping running (simulation aborted).

The problem is you use wrong logic to look at this. Halting is that the
ACTAUL MACHINE halts. And P(P) Halts, as you agree.

It doesn't matter that H(P,P) doesn't reach this halting state, as all
that shows is that H terminates its simulation too soon.

What you proof ACTUALLY shows is that there is no version of H that has
the ability to simulate its own version of H^ to a Halting Conclusion.

If there was, then that would be a counter example for Linz, as if H
could simulate its H^ to the halting state, it could correctly answer
Halting.

As it is, it just shows that we have two classes of H that get wrong
answers.

There is the class Hn that doesn't abort the simulation, and this class
gets the problem H(P,P) wrong by not answering.

There is the other class Ha that does abort the simulation and returns
the decision that Pa is non-Halting, and then that same Pa takes that
answer and Halts, showing that Ha is wrong.

You logic is that since no H can prove that its input represents a
Halting Machine, then all P built from these can be a Halting
Computation which is false. This actually shows that your precious All
Truth is Provable is actualy a Lie.

H sees a pattern that exactly matches the pattern of the FINITE
computation that we get from running P(P), so that pattern CAN'T be a
definitively non-halting pattern. You claim this based on that UNSOUND
logic that you assume that H will not abort its simulation, and thus the
claim is NOT proven.

You ignore that P (really should be called H^) changes when you alter H
so arguments based on varying H so the behavior of a number of different Ps.

All you have shown is that Ha can correctly decider that Ha(Pn,Pn) is
correct in calling it non-halting, but the proof you want to apply it to
need for you to show that Hx(Px,Px) gets the right answer, not the right
answer to a DIFFERENT machine.

On 7/26/21 7:38 AM, olcott wrote:
> On 7/25/2021 5:42 PM, Ben Bacarisse wrote:
>> Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
>>
>>> On 25/07/2021 21:28, Mike Terry wrote:
>>> Pressed Send too soon. :(
>>>> On 25/07/2021 18:40, Malcolm McLean wrote:
>>>>> 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. However when we have, for
>>>>> example, the
>>>>> "H is the operating system" ruse, I do tend to say "that's a clever
>>>>> cheat"
>>>>> rather than "how could you make such a simple and obvious error?".
>>>>> Largely because it's a nicer way of conveying essentially the same
>>>>> information.
>>>>>
>>>>> I did say recently that PO had constructed his own paradox. It's
>>>>> this. If
>>>>> H is  simulating halt decider, and is called on H, it creates a
>>>>> series of
>>>>> nested recursions. If it doesn't detect the situation, it never
>>>>> halts. If
>>>>> it does detect the situation and terminates the simulations, it halts.
>>>>> However if it halts, the nested recursions were not infinite.
>>>> Right, that's a bit like something I pointed out to PO last year.  Such
>>>> an emulation-based (putative) decider may have a number of tests in
>>>> its stepping loop.  Some may be /sound/, like a properly implemented
>>>> tight-loop test, or a test might be unsound in that it incorrectly
>>>> decides halting for a non-halting input or vice-versa.  The sound tests
>>>> might match and make correct decisions when examining particular
>>>> inputs, BUT it's sort of weird that the when H examines (P,P), the
>>>> /sound/ tests
>>>> "mysteriously" never ever match!  The only tests that will ever
>>>> match are those that are unsound...  If there are /only/ sound tests
>>>> in the
>>>> loop, none of them will match and H(P,P) will never make its
>>>> decision and halt!  Of course that would disqualify H as a decider.
>>>> This applies for PO and his "detecting infinite recursions" test,
>>>> however much he believes his test to be sound...  I've told him that
>>>> a reviewer will
>>>
>>> ...expect to see a /proof/ of the soundness of any test in his loop,
>>> if he's going to expect them to take matching of the test as
>>> /evidence/ of halting status.  (Of course PO can't deliver such a
>>> proof.)
>>
>> Right.  And very well put.  But he's abandoned almost all pretence at
>> dealing with halting.  What makes a sound test has been defined to be
>> what H does.  This is the "adapted" criterion for halting.  Not halting,
>> but whatever it is he chooses to put into H.  When he says that its
>> "impossibly incorrect" (if that's the term, I try to forget such things)
>> this is what he means.
>>
>
> 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.

WRONG. UTM(P,P) will Halt. Thus we see that H just aborts its simulation
to soon and that the issue is that no H can be designed to simulate long
enough as each change in H to lengthen the time it runs also changes P
so that H needs to simulater for Even longer.

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

As shown above, since UTM(P,P) Halts, this doesn't prove what you think
it proves.

You just proved that no H can logically prove that its H^ is a halting
computation. That doesn't mean that no H^ is a halting computation, as
not all Truth is Provable.

>
> When H recognizes this infinite behavior pattern and stops simulating
> its input, this input still never reaches its final state, thus never
> halts.

It identify a pattern that it THINKS is an infinite behavior, but it
exactly matches the pattern of P(P) which IS a Halting computation (at
least for any P built on an H that does abort its simulation and returns
non-halting).

>
> Many thanks to André G. Isaak for pointing out the proper and best
> definition of halting we no longer have the ambiguity between halting
> (reaching its final state) and stopping running (simulation aborted).
>
>

Right, halting is that the ACTUAL MACHINE reaches its halting state in a
finite number of steps. That a simulation doesn't reach this state in
some smaller finite number of steps simulated doesn't actually prove
anything.

On 7/26/21 7:46 AM, olcott wrote:
> On 7/25/2021 3:46 PM, Mike Terry wrote:
>> On 25/07/2021 21:28, Mike Terry wrote:
>> Pressed Send too soon. :(
>>> On 25/07/2021 18:40, Malcolm McLean wrote:
>>>> 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. However when we have, for example,
>>>> the
>>>> "H is the operating system" ruse, I do tend to say "that's a clever
>>>> cheat"
>>>> rather than "how could you make such a simple and obvious error?".
>>>> Largely because it's a nicer way of conveying essentially the same
>>>> information.
>>>>
>>>> I did say recently that PO had constructed his own paradox. It's
>>>> this. If
>>>> H is  simulating halt decider, and is called on H, it creates a
>>>> series of
>>>> nested recursions. If it doesn't detect the situation, it never
>>>> halts. If
>>>> it does detect the situation and terminates the simulations, it halts.
>>>> However if it halts, the nested recursions were not infinite.
>>>
>>> Right, that's a bit like something I pointed out to PO last year. 
>>> Such an emulation-based (putative) decider may have a number of tests
>>> in its stepping loop.  Some may be /sound/, like a properly
>>> implemented tight-loop test, or a test might be unsound in that it
>>> incorrectly decides halting for a non-halting input or vice-versa. 
>>> The sound tests might match and make correct decisions when examining
>>> particular inputs, BUT it's sort of weird that the when H examines
>>> (P,P), the /sound/ tests "mysteriously" never ever match!  The only
>>> tests that will ever match are those that are unsound...  If there
>>> are /only/ sound tests in the loop, none of them will match and
>>> H(P,P) will never make its decision and halt!  Of course that would
>>> disqualify H as a decider.
>>>
>>> This applies for PO and his "detecting infinite recursions" test,
>>> however much he believes his test to be sound...  I've told him that
>>> a reviewer will
>>
>> ...expect to see a /proof/ of the soundness of any test in his loop,
>> if he's going to expect them to take matching of the test as
>> /evidence/ of halting status.  (Of course PO can't deliver such a proof.)
>>
>
> 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
>
> That you say the above is not proof that the input to H(P,P) cannot
> possibly reach its final state of 0xc50 while H is in pure simulation
> mode seems to be either gross ignorance or flat out dishonestly.
>
> You have proven that you can do much better than this, what gives?
>

BAD TRACE. BAD LOGIC.

The trace of int main() { P(P);}
has an identical section of trace, but it halts, thus this trace is NOT
proof of non-halting behavior.

On Monday, 26 July 2021 at 15:36:57 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > They must have had their reasons.
> In 1979 CS degrees were not that common, but I also suspect there was a
> measure of snobbery involved -- CS was an upstart subject and could not,
> surely, fill a whole honours degree.
>
I was the decade after you. So we got our own little microcomputers to
play with as children. That created the illusion that you knew far more than
you really did, because you could use an assembler whilst the adults
couldn't. However Oxbridge were wise to this, they were sceptical of
"code junkies".

I ended up doing English literature. But I returned to my microcomputer when
I neded to earn a living.

On 2021-07-26 08:32, olcott wrote:

> You have the paradox incorrectly. 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 The halting problem isn't concerned with the input to H(P, P), which
is simply a representation. It's concerned with the *actual* computation
which that input represents. That would be P(P) run independently, and,
like any other computation, there is exactly one correct answer to the
question 'does it halt'?

The input to H isn't a computation; it's just data on the tape. So it is
meaningless to ask whether the input to H halts. What happens inside
some simulation in some 'mode' isn't the question which the halting
problem asks.

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

Since a pure simulation of a computation must do *exactly* what the
actual computation does, if P(P) halts and your simulation does not,
then it is *not* a pure simulation.

> When H recognizes this infinite behavior pattern and stops simulating
> its input, this input still never reaches its final state, thus never
> halts.
>
> Many thanks to André G. Isaak for pointing out the proper and best
> definition of halting we no longer have the ambiguity between halting
> (reaching its final state) and stopping running (simulation aborted).

The fact that you keep acknowledging me for this is a good illustration
of the fundamental problem here. I never said anything insightful or
novel. The definition I gave was exactly the same one you should have
gotten from reading Linz or Sipser or any other introductory text on the
subject.

The fact that you are still requiring clarification on something as
basic as the definition of 'halting' after however many years of working
on your 'proof' clearly demonstrates that you simply lack the background
to make any claims at all about this problem.

Now perhaps you should refocus your attention from your 'proof' to
actually learning the subject which you claim to be talking about. Learn
what it means to halt. Learn what a computation is (hint: your P is
definitely *not* a computation). Learn what a proof is (hint: a trace
does not even remotely qualify as a proof of anything). Then come back
and review all the work you have done once you've actually learned the
subject matter.

André

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

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

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

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.

--
Copyright 2021 Pete Olcott

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

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

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.

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

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

On 26/07/2021 15:36, Ben Bacarisse wrote:
> In 1979 CS degrees were not that common, but I also suspect there was a
> measure of snobbery involved -- CS was an upstart subject and could not,
> surely, fill a whole honours degree.

There's a large element of truth in that. The last bit, that is.
To put it differently, computers then were mostly large, expensive things
that occupied large rooms if not entire buildings. Yeah, there were mini
computers, but they were widely regarded as toys. Playing games or music
or videos on computers was largely forbidden. The whole point of a
computer was to solve problems -- differential equations, things with
large matrices, simulations, timetabling, big data, that sort of thing.
So you needed (a) engineers who could install computers and keep them
running, (b) programmers who could understand a real-world problem and
turn it into computerese, and (c) people who could write compilers and
operating systems. For (a) you needed a substantial dollop of advanced
engineering. For (b) you needed a dollop of university maths/physics/
whatever to enable you to understand the problems and how to solve them
in computer terms. For (c) you needed substantial experience of
advanced computing. None of that was really "a whole honours degree",
esp given [in those days] a virtual absence of textbooks*.

It made more sense to set up a joint degree, eg maths and CS.
We [maths, Nott'm] had enough computing modules for that. But in the
end we were overtaken by politics. We "had" to have a full CS dept
and course, like it or not, or be left behind by our rivals. Once
you have such a dept/course, then the content expands to fill the
available time; but that's another matter. Computers today bear
little relationship to those of the 1970s, making it more sensible
to have full CS courses; and graduates thereof who know virtually
nothing about maths or physics or anything else beyond school level.

____
* There was a chicken-egg problem. In the absence, or only recent
establishment, of proper CS courses, few undergraduate CS texts
were produced or sold -- no market for them. In the absence of
proper texts, it was harder to set up good CS courses.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Coleridge-Taylor

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