On 8/2/21 7:11 PM, olcott wrote:
> On 8/2/2021 8:45 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/2/2021 7:11 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>
>> (I'm going to ignore errors that I've already pointed out.)
>>
>>> If you really do sincerely want an actual honest dialogue you would
>>> carefully work through all the steps to confirm that the input ⟨Ĥ⟩ ⟨Ĥ⟩
>>> to Ĥ.qx never halts.
>>
>> If you want me to comment on that, write it without the errors.  It has
>> two, both of which I've commented on before.  If you are sincere, you
>> will want to write clearly and without errors.
>>
>>> Once we have mutual agreement that Ĥ.qx correctly decides that its
>>> input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts and Ĥ does halt, then we have the basis to
>>> go to the next step and resolve the actual paradox.
>>
>> There is no paradox.  That Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn when Ĥ applied to ⟨Ĥ⟩
>> clearly halts is not paradoxical.  It's just not the sort of TM the
>> proof is talking about.  And how could it be?  The "Linz Ĥ" is as
>> illogical as a cat that is a dog.
>>
>>> As long as it is simply dismissed out-of-hand as a contradiction the
>>> paradox remains unresolved.
>>
>> There is no contradiction or paradox.  You Ĥ is just the wrong sort of
>> TM.  The proof you want to "refute" is talking about this sort of Ĥ:
>>
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
>>    if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
>>
>
> Ĥ.qx correctly decides that its input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
> Ĥ.qx correctly decides that its input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
> Ĥ.qx correctly decides that its input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
> Ĥ.qx correctly decides that its input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts
>
> In computability theory, the halting problem is the problem of
> determining, from a description of an arbitrary computer program and an
> input, whether the program will finish running, or continue to run
> forever https://en.wikipedia.org/wiki/Halting_problem
>
>

But it doesn't.

Right, so H(P,I) has the problem to determine what the machine with
input represented by the deciders input would do. Will that machine,
whose represenentation is given to it, Halt in a finite number of steps
or not.

I.e. H((H^),(H^)) needs to decide what H^(H^) will do.

NOT what its partial simulation will do, what the ACTUAL machines will do.

H gets it wrong, as H((H^),(H^)) says non-Halting when H^(H^) is .halting.

On 8/2/21 6:01 PM, olcott wrote:
> On 8/2/2021 7:20 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/2/2021 11:31 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/1/2021 5:39 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 7/31/2021 4:54 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> It matters not what I had.
>>>>>>>> Because you can't justify it the honest debate you claim to want.
>>>>>>>>
>>>>>>>>> It only matters what I have.
>>>>>>>> I.e. nothing of any interest.  You make it plain in a previous
>>>>>>>> reply
>>>>>>>> that you've had nothing of interest going right back to the
>>>>>>>> original
>>>>>>>> deceptive claim.
>>>>>>>>
>>>>>>>>> If you are sincere about an honest dialogue then we must quit
>>>>>>>>> focusing
>>>>>>>>> on details of obsolete technology.
>>>>>>>> And yet you skipped the big picture part:
>>>>>>>>
>>>>>>>>>> (5) You said you had "an H that decides (Ĥ, Ĥ)".  What
>>>>>>>>>> decision did your
>>>>>>>>>>         Dec 2018 code come to about "(Ĥ, Ĥ)"?
>>>>>>>>>
>>>>>>>>> The 2018 version Halts(H_Hat, H_Hat)==0 in the exact same way that
>>>>>>>>> H(P,P)==0 now except that the never halting criteria is much more
>>>>>>>>> elaborate. The initial criteria was very crude.
>>>>>>>>
>>>>>>>> Ah, so you never had H and H_Hat that do anything that anyone
>>>>>>>> would say
>>>>>>>> is impossible.  Had you said, back in Dec 2018, "I have C code
>>>>>>>> such that
>>>>>>>> H(H_Hat, H_Hat) == 0 but H_Hat(H_Hat) halts" no one would have been
>>>>>>>> interested.
>>>>>>>
>>>>>>> If you are sincere about an honest dialogue then we must quit
>>>>>>> focusing
>>>>>>> on details of obsolete technology.
>>>>>>
>>>>>> Ah, an honest dialogue requires me to ignore your past deception? 
>>>>>> Well,
>>>>>> I can accommodate that: you /currently/ don't have anything that
>>>>>> anyone
>>>>>> would consider to be impossible or even interesting.  An H/H_Hat pair
>>>>>> such that H(H_Hat, H_Hat) == 0 and H_Hat(H_Hat) halts is of no
>>>>>> interest
>>>>>> to anyone.  Is that better?
>>>>>
>>>>> When H is a simulating partial halt decider and the halt decider
>>>>> embedded in Ĥ at Ĥ.qx is a simulating halt decider then:
>>>>>
>>>>> It is the case that the input to H(P,P) and the input to Ĥ(⟨Ĥ⟩) cannot
>>>>> possibly ever reach their final state and must have their simulation
>>>>> aborted to prevent the infinite execution of P and Ĥ.
>>>>>
>>>>> Let's have an honest dialogue about that.
>>>>
>>>> Yes, let's.  Here's how to say what happens without all those vague
>>>> (and, frankly, incorrect) words:
>>>>     Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>> If you don't mean
>>>>     Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>> can you say what you do mean formally?  Formally means using some
>>>> formal notation like Linz does.
>>>
>>> As Linz already specifies yet does not encode in his notation there
>>> are at least three separate and distinct instances of Ĥ.
>>
>> You are not replying to my remarks.  Anyway, I've posted at more length
>> elsewhere the same point that you keep side-stepping.  I think the
>> pattern is set: I'll keep accepting (even when it's wrong) what you say
>> happens /before/ Ĥ(⟨Ĥ⟩) transitions to Ĥ.qn, and you'll keep ignoring
>> why Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn shows your Ĥ is irrelevant.
>>
>> I don't think progress can be made like that.
>>
>
> As long as you keep thinking of it as a resolved contradiction the
> actual paradox remains unresolved.
>
> I proved that Ĥ.qx does correctly decide that its input ⟨Ĥ⟩ ⟨Ĥ⟩ never
> halts it is also equally proven that Ĥ halts thus a paradox and not a
> contradiction is formed.
>
> My current answer to this is GIGO self-contradictory input <IN>
> contractory output <OUT>. There may be a better answer.
>

No.

Since H aborts its simulation, the mere fact that its simulation did not
reach a halting state actually proves NOTHING.

ALL versions of H^ are the same algorithm, so will do the EXACT SAME
BEHAVIOR, at least if actually run to completion.

The fact that H incorrectly decides (since it works from the FALSE
premise that H will never abort its simulation) that H^((H^)) is
non-halting and thus aborts the simulation doesn't mean that it is
non-halting, in fact from the H^[0] result we know that ALL H^((H^))
computations are Halting. (Not just H^[0]).

It is a FUNDAMENTAL, DEFINITIONAL fact that ALL instances of a given
machine/input will behave identically.

On Tuesday, 3 August 2021 at 02:01:14 UTC+1, olcott wrote:
> On 8/2/2021 7:20 PM, Ben Bacarisse wrote:
>
> As long as you keep thinking of it as a resolved contradiction the
> actual paradox remains unresolved.
>
> I proved that Ĥ.qx does correctly decide that its input ⟨Ĥ⟩ ⟨Ĥ⟩ never
> halts it is also equally proven that Ĥ halts thus a paradox and not a
> contradiction is formed.
>
> My current answer to this is GIGO self-contradictory input <IN>
> contractory output <OUT>. There may be a better answer.
>
With your H, H_Hat <H_Hat> halts. That's common ground.
With your H H<H_Hat><H_Hat> returns false (non-halting). That's also
common ground.

So one positive in this is that you are clearly being honest about the
behaviour of your code.
But don't you see that this behaviour is exactly what Linz says would
happen? H_Hat<H_Hat> is a case that H cannot classify correctly.

You're trying to claim that H_Hat<H_Hat> doens't really halt because
the recursion of H instances is terminated by H. This leads us down
a rabbit hole of talking of the "inner" and "outer" H or H1, H2 and so on.
But what Linz is saying is that the internal details of H don't matter. It
can be a simulating halt decider, a control graph anlyser, or even just
a stub machine that returns a flag. However cleverly or simply it is
written, it classifies H_Hat<H_Hat> wrongly.

I think it's high time to wind up these threads.

On 8/3/2021 12:29 AM, Malcolm McLean wrote:
> On Tuesday, 3 August 2021 at 02:01:14 UTC+1, olcott wrote:
>> On 8/2/2021 7:20 PM, Ben Bacarisse wrote:
>>
>> As long as you keep thinking of it as a resolved contradiction the
>> actual paradox remains unresolved.
>>
>> I proved that Ĥ.qx does correctly decide that its input ⟨Ĥ⟩ ⟨Ĥ⟩ never
>> halts it is also equally proven that Ĥ halts thus a paradox and not a
>> contradiction is formed.
>>
>> My current answer to this is GIGO self-contradictory input <IN>
>> contractory output <OUT>. There may be a better answer.
>>
> With your H, H_Hat <H_Hat> halts. That's common ground.
> With your H H<H_Hat><H_Hat> returns false (non-halting). That's also
> common ground.
>
> So one positive in this is that you are clearly being honest about the
> behaviour of your code.
> But don't you see that this behaviour is exactly what Linz says would
> happen? H_Hat<H_Hat> is a case that H cannot classify correctly.
>

On pages 4-6 I proves that H(P,P) does correctly decide that its input
never halts.

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

Thus meeting this criteria:
In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and an
input, whether the program will finish running, or continue to run
forever. https://en.wikipedia.org/wiki/Halting_problem

> You're trying to claim that H_Hat<H_Hat> doens't really halt because
> the recursion of H instances is terminated by H.

No I have never been saying that. I am claiming that the input to H(P,P)
never halts whether or not H terminates its simulation of this input.

No I have never been saying that. I am claiming that the input to H(P,P)
never halts whether or not H terminates its simulation of this input.

No I have never been saying that. I am claiming that the input to H(P,P)
never halts whether or not H terminates its simulation of this input.

No I have never been saying that. I am claiming that the input to H(P,P)
never halts whether or not H terminates its simulation of this input.

> This leads us down
> a rabbit hole of talking of the "inner" and "outer" H or H1, H2 and so on.

None-the-less if this is where the actual truth is we can't simply
dismiss it out-of-hand.

> But what Linz is saying is that the internal details of H don't matter. It
> can be a simulating halt decider, a control graph anlyser, or even just
> a stub machine that returns a flag. However cleverly or simply it is
> written, it classifies H_Hat<H_Hat> wrongly.
>

We can see that the input to H(P,P) never halts therefore H IS NOT WRONG.

> I think it's high time to wind up these threads.
>

I think that it is high time that people actually pay complete attention.

--
Copyright 2021 Pete Olcott

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

On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
> On 8/3/2021 12:29 AM, Malcolm McLean wrote:
> >
> > You're trying to claim that H_Hat<H_Hat> doens't really halt because
> > the recursion of H instances is terminated by H.
> No I have never been saying that. I am claiming that the input to H(P,P)
> never halts whether or not H terminates its simulation of this input.
>
We agree that P(P) halts.
So now you're drawing a distinction between P(P) and "the input to H(P,P)".
ThIs is nonsense..
> >
> We can see that the input to H(P,P) never halts therefore H IS NOT WRONG.
> > I think it's high time to wind up these threads.
> >
> I think that it is high time that people actually pay complete attention.
>
You can't complain about lack of attention.

On 8/3/21 6:00 AM, olcott wrote:
> On 8/3/2021 12:29 AM, Malcolm McLean wrote:
>> On Tuesday, 3 August 2021 at 02:01:14 UTC+1, olcott wrote:
>>> On 8/2/2021 7:20 PM, Ben Bacarisse wrote:
>>>
>>> As long as you keep thinking of it as a resolved contradiction the
>>> actual paradox remains unresolved.
>>>
>>> I proved that Ĥ.qx does correctly decide that its input ⟨Ĥ⟩ ⟨Ĥ⟩ never
>>> halts it is also equally proven that Ĥ halts thus a paradox and not a
>>> contradiction is formed.
>>>
>>> My current answer to this is GIGO self-contradictory input <IN>
>>> contractory output <OUT>. There may be a better answer.
>>>
>> With your H, H_Hat <H_Hat> halts. That's common ground.
>> With your H H<H_Hat><H_Hat> returns false (non-halting). That's also
>> common ground.
>>
>> So one positive in this is that you are clearly being honest about the
>> behaviour of your code.
>> But don't you see that this behaviour is exactly what Linz says would
>> happen? H_Hat<H_Hat> is a case that H cannot classify correctly.
>>
>
> On pages 4-6 I proves that H(P,P) does correctly decide that its input
> never halts.

Except that the trace shows that the top level P(P) does halt by
reaching its terminal return instruction, and thus we see that H stopped
its simulation and said the pattern it sees 'must halt' when the exact
same trace when continued longer is shown to halt.

>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
> Thus meeting this criteria:
> In computability theory, the halting problem is the problem of
> determining, from a description of an arbitrary computer program and an
> input, whether the program will finish running, or continue to run
> forever. https://en.wikipedia.org/wiki/Halting_problem
>
>> You're trying to claim that H_Hat<H_Hat> doens't really halt because
>> the recursion of H instances is terminated by H.
>
> No I have never been saying that. I am claiming that the input to H(P,P)
> never halts whether or not H terminates its simulation of this input.
>
> No I have never been saying that. I am claiming that the input to H(P,P)
> never halts whether or not H terminates its simulation of this input.
>
> No I have never been saying that. I am claiming that the input to H(P,P)
> never halts whether or not H terminates its simulation of this input.
>
> No I have never been saying that. I am claiming that the input to H(P,P)
> never halts whether or not H terminates its simulation of this input.

Repeat after me: Inputs don't halt, Machines Halt.

The fact that the simulation of the input was stopped before it reaches
the halting state says NOTHING about the halting of the machine being
simulated.

The 'logic' used to decide that it must not halt is flawed, as it assume
that H doesn't halt its simulation, when it does, and thus is UNSOUND.

>
>> This leads us down
>> a rabbit hole of talking of the "inner" and "outer" H or H1, H2 and so
>> on.
>
> None-the-less if this is where the actual truth is we can't simply
> dismiss it out-of-hand.

Rigth. P(P) Halts, so the ONLY right answer for H(P,P) is Halting, so
when it says non-halting, it is wWRONG.

>
>> But what Linz is saying is that the internal details of H don't
>> matter. It
>> can be a simulating halt decider, a control graph anlyser, or even just
>> a stub machine that returns a flag. However cleverly or simply it is
>> written, it classifies H_Hat<H_Hat> wrongly.
>>
>
> We can see that the input to H(P,P) never halts therefore H IS NOT WRONG.

INPUTS DON'T HALT, MACHINES HALT. P(P) is shown to halt, so the machibe
specified by the inputs Halts.

>
>> I think it's high time to wind up these threads.
>>
>
> I think that it is high time that people actually pay complete attention.
>

Maybe YOU should pay attention.

If you want to disagree with what I said, point out my error, as I have
pointed out yours. (If you just repeat your FALSE statements, you just
show you have nothing).

On 8/3/2021 9:33 AM, Malcolm McLean wrote:
> On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
>> On 8/3/2021 12:29 AM, Malcolm McLean wrote:
>>>
>>> You're trying to claim that H_Hat<H_Hat> doens't really halt because
>>> the recursion of H instances is terminated by H.
>> No I have never been saying that. I am claiming that the input to H(P,P)
>> never halts whether or not H terminates its simulation of this input.
>>
> We agree that P(P) halts.
> So now you're drawing a distinction between P(P) and "the input to H(P,P)".
> ThIs is nonsense..

Try and find any error in (a)(b)(c)(d) on page 6

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

>>>
>> We can see that the input to H(P,P) never halts therefore H IS NOT WRONG.
>>> I think it's high time to wind up these threads.
>>>
>> I think that it is high time that people actually pay complete attention.
>>
> You can't complain about lack of attention.
>

--
Copyright 2021 Pete Olcott

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

On 2021-08-03 09:21, olcott wrote:
> On 8/3/2021 9:33 AM, Malcolm McLean wrote:
>> On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
>>> On 8/3/2021 12:29 AM, Malcolm McLean wrote:
>>>>
>>>> You're trying to claim that H_Hat<H_Hat> doens't really halt because
>>>> the recursion of H instances is terminated by H.
>>> No I have never been saying that. I am claiming that the input to H(P,P)
>>> never halts whether or not H terminates its simulation of this input.
>>>
>> We agree that P(P) halts.
>> So now you're drawing a distinction between P(P) and "the input to
>> H(P,P)".
>> ThIs is nonsense..
>
> Try and find any error in (a)(b)(c)(d) on page 6
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

The error, which has been pointed out repeatedly, is in your (b).

You claim "there are no control flow instructions in the execution trace
that would escape the infinite recursion", but there *are* flow control
instructions. But your trace is incomplete and skips over the call to
B82 where these flow control instructions reside.

The code at B82 is *part* of the computation performed by P. It *must*
be included in any trace of P which purports to be a complete and honest
trace.

You don't seem to grasp the fact that *all* code executed by a
particular computation from the moment the computation begins to the
time it halts (assuming it halts) is part of that computation. It
doesn't matter whether the code in question is shared by some other
routine, or is operating system code or whatever. These are purely
artificial distinctions which play no role in the theory of computation.

André

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

On 8/3/2021 12:11 PM, André G. Isaak wrote:
> On 2021-08-03 09:21, olcott wrote:
>> On 8/3/2021 9:33 AM, Malcolm McLean wrote:
>>> On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
>>>> On 8/3/2021 12:29 AM, Malcolm McLean wrote:
>>>>>
>>>>> You're trying to claim that H_Hat<H_Hat> doens't really halt because
>>>>> the recursion of H instances is terminated by H.
>>>> No I have never been saying that. I am claiming that the input to
>>>> H(P,P)
>>>> never halts whether or not H terminates its simulation of this input.
>>>>
>>> We agree that P(P) halts.
>>> So now you're drawing a distinction between P(P) and "the input to
>>> H(P,P)".
>>> ThIs is nonsense..
>>
>> Try and find any error in (a)(b)(c)(d) on page 6
>>
>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
>
> The error, which has been pointed out repeatedly, is in your (b).
>
> You claim "there are no control flow instructions in the execution trace
> that would escape the infinite recursion", but there *are* flow control
> instructions. But your trace is incomplete and skips over the call to
> B82 where these flow control instructions reside.
>

Whether H aborts its simulation of P or not P never reaches its final
state.

The conditional instructions are merely the aspect of H aborting its
simulation of P.

Because P never reaches its final state whether H aborts its simulation
of P or not we know that P never halts.

> The code at B82 is *part* of the computation performed by P. It *must*
> be included in any trace of P which purports to be a complete and honest
> trace.
>
> You don't seem to grasp the fact that *all* code executed by a
> particular computation from the moment the computation begins to the
> time it halts (assuming it halts) is part of that computation. It
> doesn't matter whether the code in question is shared by some other
> routine, or is operating system code or whatever. These are purely
> artificial distinctions which play no role in the theory of computation.
>
> André
>

--
Copyright 2021 Pete Olcott

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

On 2021-08-03 13:26, olcott wrote:
> On 8/3/2021 12:11 PM, André G. Isaak wrote:
>> On 2021-08-03 09:21, olcott wrote:
>>> On 8/3/2021 9:33 AM, Malcolm McLean wrote:
>>>> On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
>>>>> On 8/3/2021 12:29 AM, Malcolm McLean wrote:
>>>>>>
>>>>>> You're trying to claim that H_Hat<H_Hat> doens't really halt because
>>>>>> the recursion of H instances is terminated by H.
>>>>> No I have never been saying that. I am claiming that the input to
>>>>> H(P,P)
>>>>> never halts whether or not H terminates its simulation of this input.
>>>>>
>>>> We agree that P(P) halts.
>>>> So now you're drawing a distinction between P(P) and "the input to
>>>> H(P,P)".
>>>> ThIs is nonsense..
>>>
>>> Try and find any error in (a)(b)(c)(d) on page 6
>>>
>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>
>>
>>
>>
>> The error, which has been pointed out repeatedly, is in your (b).
>>
>> You claim "there are no control flow instructions in the execution
>> trace that would escape the infinite recursion", but there *are* flow
>> control instructions. But your trace is incomplete and skips over the
>> call to B82 where these flow control instructions reside.
>>
>
> Whether H aborts its simulation of P or not P never reaches its final
> state.

But H's simulation of P is *not* a computation.

When we run H(P, P) the only computation being performed is H(P, P), and
if H aborts its simulation of P(P), then control returns to H which then
Halts.

When we run P(P) as a computation, again, the only computation being
performed is P(P). Any simulations performed by P are *not*
computations, and when some simulation is aborted control returns to the
outermost P which then halts. And the behaviour of the actual
independent computation P determines the *only* correct answer to the
question 'does P(P) halt?'.

The question which H(P, P) is supposed to answer *isn't* about some
internal simulation. It's supposed to answer a question about an actual
computation, P(P) and we know that that computation halts. What occurs
in some internal simulation isn't relevant to the answer to this question.

> The conditional instructions are merely the aspect of H aborting its
> simulation of P.

Which then allows the *actual* computation being performed to halt. The
halting problem is *only* concerned with actual computations.

> Because P never reaches its final state whether H aborts its simulation
> of P or not we know that P never halts.

Again, the question being asked isn't concerned with the simulation but
with the actual computation. The simulation is *part* of that
computation. The fact that the simulation gets aborted is *also* part of
the computation, and that allows the *whole* computation to halt. The
halting problem isn't interested in some part of a computation, only the
computation as a whole.

>> The code at B82 is *part* of the computation performed by P. It *must*
>> be included in any trace of P which purports to be a complete and
>> honest trace.

Again, if you stopped omitting a portion of your traces, things would be
clearer to you.

Remember that the halting problem is concerned with computations, not
with subroutines. Since you insist on using C rather than actual Turing
Machines, though, this minimally requires that your H and your P be
*separate* programs. That means each one should have its own source file
with its own main. Each should be compiled and linked separately. Your
insistence on sticking everything into a single source file is a cheat
which you need to abandon.

H needs to take as input a complete *program*, not just some function
which is part of the same source file as H.

André

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

On 8/3/2021 3:08 PM, André G. Isaak wrote:
> On 2021-08-03 13:26, olcott wrote:
>> On 8/3/2021 12:11 PM, André G. Isaak wrote:
>>> On 2021-08-03 09:21, olcott wrote:
>>>> On 8/3/2021 9:33 AM, Malcolm McLean wrote:
>>>>> On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
>>>>>> On 8/3/2021 12:29 AM, Malcolm McLean wrote:
>>>>>>>
>>>>>>> You're trying to claim that H_Hat<H_Hat> doens't really halt because
>>>>>>> the recursion of H instances is terminated by H.
>>>>>> No I have never been saying that. I am claiming that the input to
>>>>>> H(P,P)
>>>>>> never halts whether or not H terminates its simulation of this input.
>>>>>>
>>>>> We agree that P(P) halts.
>>>>> So now you're drawing a distinction between P(P) and "the input to
>>>>> H(P,P)".
>>>>> ThIs is nonsense..
>>>>
>>>> Try and find any error in (a)(b)(c)(d) on page 6
>>>>
>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>
>>>
>>>
>>>
>>>
>>> The error, which has been pointed out repeatedly, is in your (b).
>>>
>>> You claim "there are no control flow instructions in the execution
>>> trace that would escape the infinite recursion", but there *are* flow
>>> control instructions. But your trace is incomplete and skips over the
>>> call to B82 where these flow control instructions reside.
>>>
>>
>> Whether H aborts its simulation of P or not P never reaches its final
>> state.
>
> But H's simulation of P is *not* a computation.
>

Sure it is.
The pure simulation of a computation on its input is computationally
equivalent to the direct execution of this same computation on its input.

> When we run H(P, P) the only computation being performed is H(P, P), and
> if H aborts its simulation of P(P), then control returns to H which then
> Halts.
>

The job of a halt decider is to correctly predict the future behavior of
its input. Because the input to H(P,P) does not transition to its final
state whether or not H aborts the simulation of this input we know that
this input never halts.

In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and an
input, whether the program will finish running, or continue to run
forever. https://en.wikipedia.org/wiki/Halting_problem

Because the P that halts is not: "a description of an arbitrary computer
program" it is not in the scope of the Halting Problem. Only the input
to P is in scope of the halting problem.

> When we run P(P) as a computation, again, the only computation being
> performed is P(P). Any simulations performed by P are *not*
> computations, and when some simulation is aborted control returns to the
> outermost P which then halts. And the behaviour of the actual
> independent computation P determines the *only* correct answer to the
> question 'does P(P) halt?'.
>
> The question which H(P, P) is supposed to answer *isn't* about some
> internal simulation. It's supposed to answer a question about an actual
> computation, P(P) and we know that that computation halts. What occurs
> in some internal simulation isn't relevant to the answer to this question.
>
>> The conditional instructions are merely the aspect of H aborting its
>> simulation of P.
>
> Which then allows the *actual* computation being performed to halt. The
> halting problem is *only* concerned with actual computations.
>
>> Because P never reaches its final state whether H aborts its
>> simulation of P or not we know that P never halts.
>
> Again, the question being asked isn't concerned with the simulation but
> with the actual computation. The simulation is *part* of that
> computation. The fact that the simulation gets aborted is *also* part of
> the computation, and that allows the *whole* computation to halt. The
> halting problem isn't interested in some part of a computation, only the
> computation as a whole.
>
>>> The code at B82 is *part* of the computation performed by P. It
>>> *must* be included in any trace of P which purports to be a complete
>>> and honest trace.
>
> Again, if you stopped omitting a portion of your traces, things would be
> clearer to you.
>
> Remember that the halting problem is concerned with computations, not
> with subroutines. Since you insist on using C rather than actual Turing
> Machines, though, this minimally requires that your H and your P be
> *separate* programs. That means each one should have its own source file
> with its own main. Each should be compiled and linked separately. Your
> insistence on sticking everything into a single source file is a cheat
> which you need to abandon.
>
> H needs to take as input a complete *program*, not just some function
> which is part of the same source file as H.
>
> André
>
>

--
Copyright 2021 Pete Olcott

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

On 2021-08-03 14:47, olcott wrote:
> On 8/3/2021 3:08 PM, André G. Isaak wrote:
>> On 2021-08-03 13:26, olcott wrote:
>>> On 8/3/2021 12:11 PM, André G. Isaak wrote:
>>>> On 2021-08-03 09:21, olcott wrote:
>>>>> On 8/3/2021 9:33 AM, Malcolm McLean wrote:
>>>>>> On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
>>>>>>> On 8/3/2021 12:29 AM, Malcolm McLean wrote:
>>>>>>>>
>>>>>>>> You're trying to claim that H_Hat<H_Hat> doens't really halt
>>>>>>>> because
>>>>>>>> the recursion of H instances is terminated by H.
>>>>>>> No I have never been saying that. I am claiming that the input to
>>>>>>> H(P,P)
>>>>>>> never halts whether or not H terminates its simulation of this
>>>>>>> input.
>>>>>>>
>>>>>> We agree that P(P) halts.
>>>>>> So now you're drawing a distinction between P(P) and "the input to
>>>>>> H(P,P)".
>>>>>> ThIs is nonsense..
>>>>>
>>>>> Try and find any error in (a)(b)(c)(d) on page 6
>>>>>
>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The error, which has been pointed out repeatedly, is in your (b).
>>>>
>>>> You claim "there are no control flow instructions in the execution
>>>> trace that would escape the infinite recursion", but there *are*
>>>> flow control instructions. But your trace is incomplete and skips
>>>> over the call to B82 where these flow control instructions reside.
>>>>
>>>
>>> Whether H aborts its simulation of P or not P never reaches its final
>>> state.
>>
>> But H's simulation of P is *not* a computation.
>>
>
> Sure it is.
> The pure simulation of a computation on its input is computationally
> equivalent to the direct execution of this same computation on its input.

No. It isn't. A computation is a free-standing, self-contained piece of
code. When you run H(P, P) the computation P(P) isn't being computed.
It's being evaluated. H(P, P) is the only computation being run in this
case.

And your H *doesn't* perform a pure simulation of its input, so we can't
even talk about the simulation as being 'computationally equivalent' to
some computation.

>> When we run H(P, P) the only computation being performed is H(P, P),
>> and if H aborts its simulation of P(P), then control returns to H
>> which then Halts.
>>
>
> The job of a halt decider is to correctly predict the future behavior of
> its input. Because the input to H(P,P) does not transition to its final
> state whether or not H aborts the simulation of this input we know that
> this input never halts.
>
> In computability theory, the halting problem is the problem of
> determining, from a description of an arbitrary computer program and an
> input, whether the program will finish running, or continue to run
> forever. https://en.wikipedia.org/wiki/Halting_problem
>
> Because the P that halts is not: "a description of an arbitrary computer
> program" it is not in the scope of the Halting Problem. Only the input
> to P is in scope of the halting problem.

Here you're very confused. The "P that halts" *is* the computation which
the input to H describes. A halt decider takes a description of an
arbitrary program and answers *about the program described by that
description*. The "input to P" isn't a computation. It's a description
of a computation. Halting applies to actual computations, not to
descriptions.

André

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

On 8/3/2021 3:56 PM, André G. Isaak wrote:
> On 2021-08-03 14:47, olcott wrote:
>> On 8/3/2021 3:08 PM, André G. Isaak wrote:
>>> On 2021-08-03 13:26, olcott wrote:
>>>> On 8/3/2021 12:11 PM, André G. Isaak wrote:
>>>>> On 2021-08-03 09:21, olcott wrote:
>>>>>> On 8/3/2021 9:33 AM, Malcolm McLean wrote:
>>>>>>> On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
>>>>>>>> On 8/3/2021 12:29 AM, Malcolm McLean wrote:
>>>>>>>>>
>>>>>>>>> You're trying to claim that H_Hat<H_Hat> doens't really halt
>>>>>>>>> because
>>>>>>>>> the recursion of H instances is terminated by H.
>>>>>>>> No I have never been saying that. I am claiming that the input
>>>>>>>> to H(P,P)
>>>>>>>> never halts whether or not H terminates its simulation of this
>>>>>>>> input.
>>>>>>>>
>>>>>>> We agree that P(P) halts.
>>>>>>> So now you're drawing a distinction between P(P) and "the input
>>>>>>> to H(P,P)".
>>>>>>> ThIs is nonsense..
>>>>>>
>>>>>> Try and find any error in (a)(b)(c)(d) on page 6
>>>>>>
>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The error, which has been pointed out repeatedly, is in your (b).
>>>>>
>>>>> You claim "there are no control flow instructions in the execution
>>>>> trace that would escape the infinite recursion", but there *are*
>>>>> flow control instructions. But your trace is incomplete and skips
>>>>> over the call to B82 where these flow control instructions reside.
>>>>>
>>>>
>>>> Whether H aborts its simulation of P or not P never reaches its
>>>> final state.
>>>
>>> But H's simulation of P is *not* a computation.
>>>
>>
>> Sure it is.
>> The pure simulation of a computation on its input is computationally
>> equivalent to the direct execution of this same computation on its input.
>
> No. It isn't. A computation is a free-standing, self-contained piece of
> code. When you run H(P, P) the computation P(P) isn't being computed.
> It's being evaluated. H(P, P) is the only computation being run in this
> case.
>

So you don't understand how UTMs work.

> And your H *doesn't* perform a pure simulation of its input, so we can't
> even talk about the simulation as being 'computationally equivalent' to
> some computation.
>

The fact that the first seven instructions of P keep repeating while H
is in pure simulation mode proves that H is doing pure simulation mode
correctly.

>>> When we run H(P, P) the only computation being performed is H(P, P),
>>> and if H aborts its simulation of P(P), then control returns to H
>>> which then Halts.
>>>
>>
>> The job of a halt decider is to correctly predict the future behavior
>> of its input. Because the input to H(P,P) does not transition to its
>> final state whether or not H aborts the simulation of this input we
>> know that this input never halts.
>>
>> In computability theory, the halting problem is the problem of
>> determining, from a description of an arbitrary computer program and
>> an input, whether the program will finish running, or continue to run
>> forever. https://en.wikipedia.org/wiki/Halting_problem
>>
>> Because the P that halts is not: "a description of an arbitrary
>> computer program" it is not in the scope of the Halting Problem. Only
>> the input to P is in scope of the halting problem.
>
> Here you're very confused. The "P that halts" *is* the computation which
> the input to H describes. A halt decider takes a description of an
> arbitrary program and answers *about the program described by that
> description*. The "input to P" isn't a computation. It's a description
> of a computation. Halting applies to actual computations, not to
> descriptions.
>
> André
>
>

The key point is that if it is not AN INPUT the it doesn't count.
The simulation of inputs is not forbidden.

--
Copyright 2021 Pete Olcott

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

On 2021-08-03 15:03, olcott wrote:
> On 8/3/2021 3:56 PM, André G. Isaak wrote:
>> On 2021-08-03 14:47, olcott wrote:
>>> On 8/3/2021 3:08 PM, André G. Isaak wrote:
>>>> On 2021-08-03 13:26, olcott wrote:
>>>>> On 8/3/2021 12:11 PM, André G. Isaak wrote:
>>>>>> On 2021-08-03 09:21, olcott wrote:
>>>>>>> On 8/3/2021 9:33 AM, Malcolm McLean wrote:
>>>>>>>> On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
>>>>>>>>> On 8/3/2021 12:29 AM, Malcolm McLean wrote:
>>>>>>>>>>
>>>>>>>>>> You're trying to claim that H_Hat<H_Hat> doens't really halt
>>>>>>>>>> because
>>>>>>>>>> the recursion of H instances is terminated by H.
>>>>>>>>> No I have never been saying that. I am claiming that the input
>>>>>>>>> to H(P,P)
>>>>>>>>> never halts whether or not H terminates its simulation of this
>>>>>>>>> input.
>>>>>>>>>
>>>>>>>> We agree that P(P) halts.
>>>>>>>> So now you're drawing a distinction between P(P) and "the input
>>>>>>>> to H(P,P)".
>>>>>>>> ThIs is nonsense..
>>>>>>>
>>>>>>> Try and find any error in (a)(b)(c)(d) on page 6
>>>>>>>
>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The error, which has been pointed out repeatedly, is in your (b).
>>>>>>
>>>>>> You claim "there are no control flow instructions in the execution
>>>>>> trace that would escape the infinite recursion", but there *are*
>>>>>> flow control instructions. But your trace is incomplete and skips
>>>>>> over the call to B82 where these flow control instructions reside.
>>>>>>
>>>>>
>>>>> Whether H aborts its simulation of P or not P never reaches its
>>>>> final state.
>>>>
>>>> But H's simulation of P is *not* a computation.
>>>>
>>>
>>> Sure it is.
>>> The pure simulation of a computation on its input is computationally
>>> equivalent to the direct execution of this same computation on its
>>> input.
>>
>> No. It isn't. A computation is a free-standing, self-contained piece
>> of code. When you run H(P, P) the computation P(P) isn't being
>> computed. It's being evaluated. H(P, P) is the only computation being
>> run in this case.
>>
>
> So you don't understand how UTMs work.

I'm well aware of how UTMs work. I am also aware that an x86 simulator
is not the same thing as a UTM.

>> And your H *doesn't* perform a pure simulation of its input, so we
>> can't even talk about the simulation as being 'computationally
>> equivalent' to some computation.
>>
>
> The fact that the first seven instructions of P keep repeating while H
> is in pure simulation mode proves that H is doing pure simulation mode
> correctly.

The problem is that your 'pure simulation mode' is a cheat.

Your H and P *need* to be independent, self-contained programs. They
need to both be compiled and linked separately resulting in two
different executables. This means that the copy of H contained in P will
be *distinct* from program H. It will be at an entirely different
address and any code inside H which tells it to ignore its 'own code'
will not result in it ignoring the H contained in P.

That also means that any change in the "mode" in which the main H runs
*cannot* have any effect on what the H contained in P does.

Your 'pure simulation mode' is only valid as a test if it applies *only*
to the behaviour of H, and not to the behaviour of the H contained inside P.

If you change what the H inside P does, you are then talking about an
*entirely different* computation which has no bearing on the halting
behaviour of P.

You can't evaluate whether P halts by considering what some modified
version of P does, which is in effect what you are doing.

André

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

On 8/3/2021 4:26 PM, André G. Isaak wrote:
> On 2021-08-03 15:03, olcott wrote:
>> On 8/3/2021 3:56 PM, André G. Isaak wrote:
>>> On 2021-08-03 14:47, olcott wrote:
>>>> On 8/3/2021 3:08 PM, André G. Isaak wrote:
>>>>> On 2021-08-03 13:26, olcott wrote:
>>>>>> On 8/3/2021 12:11 PM, André G. Isaak wrote:
>>>>>>> On 2021-08-03 09:21, olcott wrote:
>>>>>>>> On 8/3/2021 9:33 AM, Malcolm McLean wrote:
>>>>>>>>> On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
>>>>>>>>>> On 8/3/2021 12:29 AM, Malcolm McLean wrote:
>>>>>>>>>>>
>>>>>>>>>>> You're trying to claim that H_Hat<H_Hat> doens't really halt
>>>>>>>>>>> because
>>>>>>>>>>> the recursion of H instances is terminated by H.
>>>>>>>>>> No I have never been saying that. I am claiming that the input
>>>>>>>>>> to H(P,P)
>>>>>>>>>> never halts whether or not H terminates its simulation of this
>>>>>>>>>> input.
>>>>>>>>>>
>>>>>>>>> We agree that P(P) halts.
>>>>>>>>> So now you're drawing a distinction between P(P) and "the input
>>>>>>>>> to H(P,P)".
>>>>>>>>> ThIs is nonsense..
>>>>>>>>
>>>>>>>> Try and find any error in (a)(b)(c)(d) on page 6
>>>>>>>>
>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The error, which has been pointed out repeatedly, is in your (b).
>>>>>>>
>>>>>>> You claim "there are no control flow instructions in the
>>>>>>> execution trace that would escape the infinite recursion", but
>>>>>>> there *are* flow control instructions. But your trace is
>>>>>>> incomplete and skips over the call to B82 where these flow
>>>>>>> control instructions reside.
>>>>>>>
>>>>>>
>>>>>> Whether H aborts its simulation of P or not P never reaches its
>>>>>> final state.
>>>>>
>>>>> But H's simulation of P is *not* a computation.
>>>>>
>>>>
>>>> Sure it is.
>>>> The pure simulation of a computation on its input is computationally
>>>> equivalent to the direct execution of this same computation on its
>>>> input.
>>>
>>> No. It isn't. A computation is a free-standing, self-contained piece
>>> of code. When you run H(P, P) the computation P(P) isn't being
>>> computed. It's being evaluated. H(P, P) is the only computation being
>>> run in this case.
>>>
>>
>> So you don't understand how UTMs work.
>
> I'm well aware of how UTMs work. I am also aware that an x86 simulator
> is not the same thing as a UTM.
>

It is equivalent. In any case my exactly same reasoning directly applies
to the Linz proof.

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

When Ĥ is applied to its own Turing Machine description ⟨Ĥ⟩ the embedded
halt decider at Ĥ.qx correctly decides that its input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.

>>> And your H *doesn't* perform a pure simulation of its input, so we
>>> can't even talk about the simulation as being 'computationally
>>> equivalent' to some computation.
>>>
>>
>> The fact that the first seven instructions of P keep repeating while H
>> is in pure simulation mode proves that H is doing pure simulation mode
>> correctly.
>
> The problem is that your 'pure simulation mode' is a cheat.
>

That the execution trace of the simulation of P precisely corresponds to
its source-code proves beyond all possible doubt that the pure
simulation of P by H is correct. There is no way to wiggle out of this.

> Your H and P *need* to be independent, self-contained programs. They
> need to both be compiled and linked separately resulting in two
> different executables. This means that the copy of H contained in P will
> be *distinct* from program H. It will be at an entirely different
> address and any code inside H which tells it to ignore its 'own code'
> will not result in it ignoring the H contained in P.
>
> That also means that any change in the "mode" in which the main H runs
> *cannot* have any effect on what the H contained in P does.
>
> Your 'pure simulation mode' is only valid as a test if it applies *only*
> to the behaviour of H, and not to the behaviour of the H contained
> inside P.
>
> If you change what the H inside P does, you are then talking about an
> *entirely different* computation which has no bearing on the halting
> behaviour of P.
>
> You can't evaluate whether P halts by considering what some modified
> version of P does, which is in effect what you are doing.
>
> André
>

That the execution trace of the simulation of P precisely corresponds to
its source-code proves beyond all possible doubt that the pure
simulation of P by H is correct. There is no way to wiggle out of this.

--
Copyright 2021 Pete Olcott

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

On 2021-08-03 15:50, olcott wrote:
> On 8/3/2021 4:26 PM, André G. Isaak wrote:
>> On 2021-08-03 15:03, olcott wrote:
>>> On 8/3/2021 3:56 PM, André G. Isaak wrote:
>>>> On 2021-08-03 14:47, olcott wrote:
>>>>> On 8/3/2021 3:08 PM, André G. Isaak wrote:
>>>>>> On 2021-08-03 13:26, olcott wrote:
>>>>>>> On 8/3/2021 12:11 PM, André G. Isaak wrote:
>>>>>>>> On 2021-08-03 09:21, olcott wrote:
>>>>>>>>> On 8/3/2021 9:33 AM, Malcolm McLean wrote:
>>>>>>>>>> On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
>>>>>>>>>>> On 8/3/2021 12:29 AM, Malcolm McLean wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> You're trying to claim that H_Hat<H_Hat> doens't really halt
>>>>>>>>>>>> because
>>>>>>>>>>>> the recursion of H instances is terminated by H.
>>>>>>>>>>> No I have never been saying that. I am claiming that the
>>>>>>>>>>> input to H(P,P)
>>>>>>>>>>> never halts whether or not H terminates its simulation of
>>>>>>>>>>> this input.
>>>>>>>>>>>
>>>>>>>>>> We agree that P(P) halts.
>>>>>>>>>> So now you're drawing a distinction between P(P) and "the
>>>>>>>>>> input to H(P,P)".
>>>>>>>>>> ThIs is nonsense..
>>>>>>>>>
>>>>>>>>> Try and find any error in (a)(b)(c)(d) on page 6
>>>>>>>>>
>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The error, which has been pointed out repeatedly, is in your (b).
>>>>>>>>
>>>>>>>> You claim "there are no control flow instructions in the
>>>>>>>> execution trace that would escape the infinite recursion", but
>>>>>>>> there *are* flow control instructions. But your trace is
>>>>>>>> incomplete and skips over the call to B82 where these flow
>>>>>>>> control instructions reside.
>>>>>>>>
>>>>>>>
>>>>>>> Whether H aborts its simulation of P or not P never reaches its
>>>>>>> final state.
>>>>>>
>>>>>> But H's simulation of P is *not* a computation.
>>>>>>
>>>>>
>>>>> Sure it is.
>>>>> The pure simulation of a computation on its input is
>>>>> computationally equivalent to the direct execution of this same
>>>>> computation on its input.
>>>>
>>>> No. It isn't. A computation is a free-standing, self-contained piece
>>>> of code. When you run H(P, P) the computation P(P) isn't being
>>>> computed. It's being evaluated. H(P, P) is the only computation
>>>> being run in this case.
>>>>
>>>
>>> So you don't understand how UTMs work.
>>
>> I'm well aware of how UTMs work. I am also aware that an x86 simulator
>> is not the same thing as a UTM.
>>
>
> It is equivalent. In any case my exactly same reasoning directly applies
> to the Linz proof.

No, it isn't equivalent. A UTM takes a description of a *Turing Machine*
as its input. A description of an x86 program is not a Turing Machine.
How can two computations which take entirely distinct inputs be equivalent?

> Ĥ.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
>
> When Ĥ is applied to its own Turing Machine description ⟨Ĥ⟩ the embedded
> halt decider at Ĥ.qx correctly decides that its input ⟨Ĥ⟩ ⟨Ĥ⟩ never halts.

Inputs neither halt nor don't halt. Only computations halt.

And Ĥ.qx isn't an 'embedded halt decider'. It is a state.

>>>> And your H *doesn't* perform a pure simulation of its input, so we
>>>> can't even talk about the simulation as being 'computationally
>>>> equivalent' to some computation.
>>>>
>>>
>>> The fact that the first seven instructions of P keep repeating while
>>> H is in pure simulation mode proves that H is doing pure simulation
>>> mode correctly.
>>
>> The problem is that your 'pure simulation mode' is a cheat.
>>
>
> That the execution trace of the simulation of P precisely corresponds to
> its source-code proves beyond all possible doubt that the pure
> simulation of P by H is correct. There is no way to wiggle out of this.

No. It doesn't 'precisely correspond' to its source code because your
trace *omits* a big chunk of code.

>> Your H and P *need* to be independent, self-contained programs. They
>> need to both be compiled and linked separately resulting in two
>> different executables. This means that the copy of H contained in P
>> will be *distinct* from program H. It will be at an entirely different
>> address and any code inside H which tells it to ignore its 'own code'
>> will not result in it ignoring the H contained in P.
>>
>> That also means that any change in the "mode" in which the main H runs
>> *cannot* have any effect on what the H contained in P does.
>>
>> Your 'pure simulation mode' is only valid as a test if it applies
>> *only* to the behaviour of H, and not to the behaviour of the H
>> contained inside P.
>>
>> If you change what the H inside P does, you are then talking about an
>> *entirely different* computation which has no bearing on the halting
>> behaviour of P.
>>
>> You can't evaluate whether P halts by considering what some modified
>> version of P does, which is in effect what you are doing.
>>
>> André
>>
>
> That the execution trace of the simulation of P precisely corresponds to
> its source-code proves beyond all possible doubt that the pure
> simulation of P by H is correct. There is no way to wiggle out of this.

No. It doesn't 'precisely correspond' to its source code because your
trace *omits* a big chunk of code.

Come back and post a complete trace once you've actually set up your H
and P *properly*. i.e. as two *separate* programs which have been
compiled and linked two form two separate, *complete* executables where
P does not call any code contained in H. If there is code in common, it
must be *duplicated* so that each executable contains its own copy of
this code.

There is no point discussing your implementation where your H and P are
contained in a single executable. That's not how 'TM equivalents' work,
nor is it how the Linz Proof constructs H_Hat, and no conclusions which
you draw from such a mangled implementation can possibly shed any light
on the halting problem.

If you don't grasp why what you are doing is illegitimate, then I
suggest you go and actually learn what the term 'computation' means.
That would involve actually reading Linz and/or Sipser *from the
beginning*. Your notion than you can somehow overcome a well-established
proof without even grasping the fundamentals of the subject matter is
mystifying to say the least.

André

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

On 8/3/2021 5:35 PM, André G. Isaak wrote:
> On 2021-08-03 15:50, olcott wrote:
>> On 8/3/2021 4:26 PM, André G. Isaak wrote:
>>> On 2021-08-03 15:03, olcott wrote:
>>>> On 8/3/2021 3:56 PM, André G. Isaak wrote:
>>>>> On 2021-08-03 14:47, olcott wrote:
>>>>>> On 8/3/2021 3:08 PM, André G. Isaak wrote:
>>>>>>> On 2021-08-03 13:26, olcott wrote:
>>>>>>>> On 8/3/2021 12:11 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-08-03 09:21, olcott wrote:
>>>>>>>>>> On 8/3/2021 9:33 AM, Malcolm McLean wrote:
>>>>>>>>>>> On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
>>>>>>>>>>>> On 8/3/2021 12:29 AM, Malcolm McLean wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> You're trying to claim that H_Hat<H_Hat> doens't really
>>>>>>>>>>>>> halt because
>>>>>>>>>>>>> the recursion of H instances is terminated by H.
>>>>>>>>>>>> No I have never been saying that. I am claiming that the
>>>>>>>>>>>> input to H(P,P)
>>>>>>>>>>>> never halts whether or not H terminates its simulation of
>>>>>>>>>>>> this input.
>>>>>>>>>>>>
>>>>>>>>>>> We agree that P(P) halts.
>>>>>>>>>>> So now you're drawing a distinction between P(P) and "the
>>>>>>>>>>> input to H(P,P)".
>>>>>>>>>>> ThIs is nonsense..
>>>>>>>>>>
>>>>>>>>>> Try and find any error in (a)(b)(c)(d) on page 6
>>>>>>>>>>
>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The error, which has been pointed out repeatedly, is in your (b).
>>>>>>>>>
>>>>>>>>> You claim "there are no control flow instructions in the
>>>>>>>>> execution trace that would escape the infinite recursion", but
>>>>>>>>> there *are* flow control instructions. But your trace is
>>>>>>>>> incomplete and skips over the call to B82 where these flow
>>>>>>>>> control instructions reside.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Whether H aborts its simulation of P or not P never reaches its
>>>>>>>> final state.
>>>>>>>
>>>>>>> But H's simulation of P is *not* a computation.
>>>>>>>
>>>>>>
>>>>>> Sure it is.
>>>>>> The pure simulation of a computation on its input is
>>>>>> computationally equivalent to the direct execution of this same
>>>>>> computation on its input.
>>>>>
>>>>> No. It isn't. A computation is a free-standing, self-contained
>>>>> piece of code. When you run H(P, P) the computation P(P) isn't
>>>>> being computed. It's being evaluated. H(P, P) is the only
>>>>> computation being run in this case.
>>>>>
>>>>
>>>> So you don't understand how UTMs work.
>>>
>>> I'm well aware of how UTMs work. I am also aware that an x86
>>> simulator is not the same thing as a UTM.
>>>
>>
>> It is equivalent. In any case my exactly same reasoning directly
>> applies to the Linz proof.
>
> No, it isn't equivalent. A UTM takes a description of a *Turing Machine*
> as its input. A description of an x86 program is not a Turing Machine.
> How can two computations which take entirely distinct inputs be equivalent?
>

Apparently you don't understand computational equivalence either.

>> Ĥ.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
>>
>> When Ĥ is applied to its own Turing Machine description ⟨Ĥ⟩ the
>> embedded halt decider at Ĥ.qx correctly decides that its input ⟨Ĥ⟩ ⟨Ĥ⟩

Specifies a computation that halts.

>> never halts.
>
> Inputs neither halt nor don't halt. Only computations halt. >
> And Ĥ.qx isn't an 'embedded halt decider'. It is a state.
>

Linz stipulates that it <is> Turing machine H.

>>>>> And your H *doesn't* perform a pure simulation of its input, so we
>>>>> can't even talk about the simulation as being 'computationally
>>>>> equivalent' to some computation.
>>>>>
>>>>
>>>> The fact that the first seven instructions of P keep repeating while
>>>> H is in pure simulation mode proves that H is doing pure simulation
>>>> mode correctly.
>>>
>>> The problem is that your 'pure simulation mode' is a cheat.
>>>
>>
>> That the execution trace of the simulation of P precisely corresponds
>> to its source-code proves beyond all possible doubt that the pure
>> simulation of P by H is correct. There is no way to wiggle out of this.
>
> No. It doesn't 'precisely correspond' to its source code because your
> trace *omits* a big chunk of code.
>

*What details of this paragraph do you feel are incorrect (and why)*

Because H only acts as a pure simulator of its input until after its
halt status decision has been made it has no behavior that can possibly
effect the behavior of its input. Because of this H screens out its own
address range in every execution trace that it examines. This is why we
never see any instructions of H in any execution trace after an input
calls H.

>>> Your H and P *need* to be independent, self-contained programs. They
>>> need to both be compiled and linked separately resulting in two
>>> different executables. This means that the copy of H contained in P
>>> will be *distinct* from program H. It will be at an entirely
>>> different address and any code inside H which tells it to ignore its
>>> 'own code' will not result in it ignoring the H contained in P.
>>>
>>> That also means that any change in the "mode" in which the main H
>>> runs *cannot* have any effect on what the H contained in P does.
>>>
>>> Your 'pure simulation mode' is only valid as a test if it applies
>>> *only* to the behaviour of H, and not to the behaviour of the H
>>> contained inside P.
>>>
>>> If you change what the H inside P does, you are then talking about an
>>> *entirely different* computation which has no bearing on the halting
>>> behaviour of P.
>>>
>>> You can't evaluate whether P halts by considering what some modified
>>> version of P does, which is in effect what you are doing.
>>>
>>> André
>>>
>>
>> That the execution trace of the simulation of P precisely corresponds
>> to its source-code proves beyond all possible doubt that the pure
>> simulation of P by H is correct. There is no way to wiggle out of this.
>
> No. It doesn't 'precisely correspond' to its source code because your
> trace *omits* a big chunk of code.
>

*What details of this paragraph do you feel are incorrect (and why)*

Because H only acts as a pure simulator of its input until after its
halt status decision has been made it has no behavior that can possibly
effect the behavior of its input. Because of this H screens out its own
address range in every execution trace that it examines. This is why we
never see any instructions of H in any execution trace after an input
calls H.

> Come back and post a complete trace once you've actually set up your H
> and P *properly*. i.e. as two *separate* programs which have been
> compiled and linked two form two separate, *complete* executables where
> P does not call any code contained in H. If there is code in common, it
> must be *duplicated* so that each executable contains its own copy of
> this code.
>
> There is no point discussing your implementation where your H and P are
> contained in a single executable. That's not how 'TM equivalents' work,
> nor is it how the Linz Proof constructs H_Hat, and no conclusions which
> you draw from such a mangled implementation can possibly shed any light
> on the halting problem.
>

On 2021-08-03 18:42, olcott wrote:
> On 8/3/2021 5:35 PM, André G. Isaak wrote:
>> On 2021-08-03 15:50, olcott wrote:
>>> On 8/3/2021 4:26 PM, André G. Isaak wrote:
>>>> On 2021-08-03 15:03, olcott wrote:
>>>>> On 8/3/2021 3:56 PM, André G. Isaak wrote:
>>>>>> On 2021-08-03 14:47, olcott wrote:
>>>>>>> On 8/3/2021 3:08 PM, André G. Isaak wrote:
>>>>>>>> On 2021-08-03 13:26, olcott wrote:
>>>>>>>>> On 8/3/2021 12:11 PM, André G. Isaak wrote:
>>>>>>>>>> On 2021-08-03 09:21, olcott wrote:
>>>>>>>>>>> On 8/3/2021 9:33 AM, Malcolm McLean wrote:
>>>>>>>>>>>> On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
>>>>>>>>>>>>> On 8/3/2021 12:29 AM, Malcolm McLean wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You're trying to claim that H_Hat<H_Hat> doens't really
>>>>>>>>>>>>>> halt because
>>>>>>>>>>>>>> the recursion of H instances is terminated by H.
>>>>>>>>>>>>> No I have never been saying that. I am claiming that the
>>>>>>>>>>>>> input to H(P,P)
>>>>>>>>>>>>> never halts whether or not H terminates its simulation of
>>>>>>>>>>>>> this input.
>>>>>>>>>>>>>
>>>>>>>>>>>> We agree that P(P) halts.
>>>>>>>>>>>> So now you're drawing a distinction between P(P) and "the
>>>>>>>>>>>> input to H(P,P)".
>>>>>>>>>>>> ThIs is nonsense..
>>>>>>>>>>>
>>>>>>>>>>> Try and find any error in (a)(b)(c)(d) on page 6
>>>>>>>>>>>
>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The error, which has been pointed out repeatedly, is in your (b).
>>>>>>>>>>
>>>>>>>>>> You claim "there are no control flow instructions in the
>>>>>>>>>> execution trace that would escape the infinite recursion", but
>>>>>>>>>> there *are* flow control instructions. But your trace is
>>>>>>>>>> incomplete and skips over the call to B82 where these flow
>>>>>>>>>> control instructions reside.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Whether H aborts its simulation of P or not P never reaches its
>>>>>>>>> final state.
>>>>>>>>
>>>>>>>> But H's simulation of P is *not* a computation.
>>>>>>>>
>>>>>>>
>>>>>>> Sure it is.
>>>>>>> The pure simulation of a computation on its input is
>>>>>>> computationally equivalent to the direct execution of this same
>>>>>>> computation on its input.
>>>>>>
>>>>>> No. It isn't. A computation is a free-standing, self-contained
>>>>>> piece of code. When you run H(P, P) the computation P(P) isn't
>>>>>> being computed. It's being evaluated. H(P, P) is the only
>>>>>> computation being run in this case.
>>>>>>
>>>>>
>>>>> So you don't understand how UTMs work.
>>>>
>>>> I'm well aware of how UTMs work. I am also aware that an x86
>>>> simulator is not the same thing as a UTM.
>>>>
>>>
>>> It is equivalent. In any case my exactly same reasoning directly
>>> applies to the Linz proof.
>>
>> No, it isn't equivalent. A UTM takes a description of a *Turing
>> Machine* as its input. A description of an x86 program is not a Turing
>> Machine. How can two computations which take entirely distinct inputs
>> be equivalent?
>>
>
> Apparently you don't understand computational equivalence either.
>
>>> Ĥ.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
>>>
>>> When Ĥ is applied to its own Turing Machine description ⟨Ĥ⟩ the
>>> embedded halt decider at Ĥ.qx correctly decides that its input ⟨Ĥ⟩ ⟨Ĥ⟩
>
> Specifies a computation that halts.
>
>>> never halts.
>>
>> Inputs neither halt nor don't halt. Only computations halt. >
>> And Ĥ.qx isn't an 'embedded halt decider'. It is a state.
>>
>
> Linz stipulates that it <is> Turing machine H.

No he doesn't. Maybe you should learn what his notation actually means.
The copy of H includes all of the states from Ĥ.q0 through Ĥ.qx, not
just Ĥ.qx.

>>>>>> And your H *doesn't* perform a pure simulation of its input, so we
>>>>>> can't even talk about the simulation as being 'computationally
>>>>>> equivalent' to some computation.
>>>>>>
>>>>>
>>>>> The fact that the first seven instructions of P keep repeating
>>>>> while H is in pure simulation mode proves that H is doing pure
>>>>> simulation mode correctly.
>>>>
>>>> The problem is that your 'pure simulation mode' is a cheat.
>>>>
>>>
>>> That the execution trace of the simulation of P precisely corresponds
>>> to its source-code proves beyond all possible doubt that the pure
>>> simulation of P by H is correct. There is no way to wiggle out of this.
>>
>> No. It doesn't 'precisely correspond' to its source code because your
>> trace *omits* a big chunk of code.
>>
>
> *What details of this paragraph do you feel are incorrect (and why)*
>
> Because H only acts as a pure simulator of its input until after its
> halt status decision has been made it has no behavior that can possibly
> effect the behavior of its input. Because of this H screens out its own
> address range in every execution trace that it examines. This is why we
> never see any instructions of H in any execution trace after an input
> calls H.

The copy of H inside P is *not* the 'address range' of the Halt Decider.
It is part of P.

Rewrite your P as an actual *computation*. It isn't one as you've
written it. It therefore is *not* the H_Hat of Linz.

To accomplish this you minimally need to compile and link both H and P
separately to produce two complete *self-contained* executables. You
can't have both contained in the same executable.

I strongly suspect that your H is also not a computation, but since
you've never supplied the code for it I can't be sure.

>>>> Your H and P *need* to be independent, self-contained programs. They
>>>> need to both be compiled and linked separately resulting in two
>>>> different executables. This means that the copy of H contained in P
>>>> will be *distinct* from program H. It will be at an entirely
>>>> different address and any code inside H which tells it to ignore its
>>>> 'own code' will not result in it ignoring the H contained in P.
>>>>
>>>> That also means that any change in the "mode" in which the main H
>>>> runs *cannot* have any effect on what the H contained in P does.
>>>>
>>>> Your 'pure simulation mode' is only valid as a test if it applies
>>>> *only* to the behaviour of H, and not to the behaviour of the H
>>>> contained inside P.
>>>>
>>>> If you change what the H inside P does, you are then talking about
>>>> an *entirely different* computation which has no bearing on the
>>>> halting behaviour of P.
>>>>
>>>> You can't evaluate whether P halts by considering what some modified
>>>> version of P does, which is in effect what you are doing.
>>>>
>>>> André
>>>>
>>>
>>> That the execution trace of the simulation of P precisely corresponds
>>> to its source-code proves beyond all possible doubt that the pure
>>> simulation of P by H is correct. There is no way to wiggle out of this.
>>
>> No. It doesn't 'precisely correspond' to its source code because your
>> trace *omits* a big chunk of code.
>>
>
> *What details of this paragraph do you feel are incorrect (and why)*
>
> Because H only acts as a pure simulator of its input until after its
> halt status decision has been made it has no behavior that can possibly
> effect the behavior of its input. Because of this H screens out its own
> address range in every execution trace that it examines. This is why we
> never see any instructions of H in any execution trace after an input
> calls H.
>
>> Come back and post a complete trace once you've actually set up your H
>> and P *properly*. i.e. as two *separate* programs which have been
>> compiled and linked two form two separate, *complete* executables
>> where P does not call any code contained in H. If there is code in
>> common, it must be *duplicated* so that each executable contains its
>> own copy of this code.
>>
>> There is no point discussing your implementation where your H and P
>> are contained in a single executable. That's not how 'TM equivalents'
>> work, nor is it how the Linz Proof constructs H_Hat, and no
>> conclusions which you draw from such a mangled implementation can
>> possibly shed any light on the halting problem.
>>
>
> So when your reasoning fails to show that my H is incorrect you change
> the subject. It is true that the input to H(P,P) never halts therefore
> H(P,P)==0 is correct.
>
>> If you don't grasp why what you are doing is illegitimate, then I
>> suggest you go and actually learn what the term 'computation' means.
>
> The standard formal definition of computation, repeated in all the major
> textbooks, derives from these early ideas. Computation is defined as the
> execution sequences of halting Turing machines (or their equivalents).
> An execution sequence is the sequence of total configurations of the
> machine, including states of memory and control unit.

On 8/3/2021 8:00 PM, André G. Isaak wrote:
> On 2021-08-03 18:42, olcott wrote:
>> On 8/3/2021 5:35 PM, André G. Isaak wrote:
>>> On 2021-08-03 15:50, olcott wrote:
>>>> On 8/3/2021 4:26 PM, André G. Isaak wrote:
>>>>> On 2021-08-03 15:03, olcott wrote:
>>>>>> On 8/3/2021 3:56 PM, André G. Isaak wrote:
>>>>>>> On 2021-08-03 14:47, olcott wrote:
>>>>>>>> On 8/3/2021 3:08 PM, André G. Isaak wrote:
>>>>>>>>> On 2021-08-03 13:26, olcott wrote:
>>>>>>>>>> On 8/3/2021 12:11 PM, André G. Isaak wrote:
>>>>>>>>>>> On 2021-08-03 09:21, olcott wrote:
>>>>>>>>>>>> On 8/3/2021 9:33 AM, Malcolm McLean wrote:
>>>>>>>>>>>>> On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
>>>>>>>>>>>>>> On 8/3/2021 12:29 AM, Malcolm McLean wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You're trying to claim that H_Hat<H_Hat> doens't really
>>>>>>>>>>>>>>> halt because
>>>>>>>>>>>>>>> the recursion of H instances is terminated by H.
>>>>>>>>>>>>>> No I have never been saying that. I am claiming that the
>>>>>>>>>>>>>> input to H(P,P)
>>>>>>>>>>>>>> never halts whether or not H terminates its simulation of
>>>>>>>>>>>>>> this input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> We agree that P(P) halts.
>>>>>>>>>>>>> So now you're drawing a distinction between P(P) and "the
>>>>>>>>>>>>> input to H(P,P)".
>>>>>>>>>>>>> ThIs is nonsense..
>>>>>>>>>>>>
>>>>>>>>>>>> Try and find any error in (a)(b)(c)(d) on page 6
>>>>>>>>>>>>
>>>>>>>>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The error, which has been pointed out repeatedly, is in your
>>>>>>>>>>> (b).
>>>>>>>>>>>
>>>>>>>>>>> You claim "there are no control flow instructions in the
>>>>>>>>>>> execution trace that would escape the infinite recursion",
>>>>>>>>>>> but there *are* flow control instructions. But your trace is
>>>>>>>>>>> incomplete and skips over the call to B82 where these flow
>>>>>>>>>>> control instructions reside.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Whether H aborts its simulation of P or not P never reaches
>>>>>>>>>> its final state.
>>>>>>>>>
>>>>>>>>> But H's simulation of P is *not* a computation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Sure it is.
>>>>>>>> The pure simulation of a computation on its input is
>>>>>>>> computationally equivalent to the direct execution of this same
>>>>>>>> computation on its input.
>>>>>>>
>>>>>>> No. It isn't. A computation is a free-standing, self-contained
>>>>>>> piece of code. When you run H(P, P) the computation P(P) isn't
>>>>>>> being computed. It's being evaluated. H(P, P) is the only
>>>>>>> computation being run in this case.
>>>>>>>
>>>>>>
>>>>>> So you don't understand how UTMs work.
>>>>>
>>>>> I'm well aware of how UTMs work. I am also aware that an x86
>>>>> simulator is not the same thing as a UTM.
>>>>>
>>>>
>>>> It is equivalent. In any case my exactly same reasoning directly
>>>> applies to the Linz proof.
>>>
>>> No, it isn't equivalent. A UTM takes a description of a *Turing
>>> Machine* as its input. A description of an x86 program is not a
>>> Turing Machine. How can two computations which take entirely distinct
>>> inputs be equivalent?
>>>
>>
>> Apparently you don't understand computational equivalence either.
>>
>>>> Ĥ.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
>>>>
>>>> When Ĥ is applied to its own Turing Machine description ⟨Ĥ⟩ the
>>>> embedded halt decider at Ĥ.qx correctly decides that its input ⟨Ĥ⟩ ⟨Ĥ⟩
>>
>> Specifies a computation that halts.
>>
>>>> never halts.
>>>
>>> Inputs neither halt nor don't halt. Only computations halt. >
>>> And Ĥ.qx isn't an 'embedded halt decider'. It is a state.
>>>
>>
>> Linz stipulates that it <is> Turing machine H.
>
> No he doesn't. Maybe you should learn what his notation actually means.
> The copy of H includes all of the states from Ĥ.q0 through Ĥ.qx, not
> just Ĥ.qx.
>

I corrected the Linz notation, Linz has two start states.
Linz has no Ĥ.qx, that is my correction. It indicates H.q0.

>>>>>>> And your H *doesn't* perform a pure simulation of its input, so
>>>>>>> we can't even talk about the simulation as being 'computationally
>>>>>>> equivalent' to some computation.
>>>>>>>
>>>>>>
>>>>>> The fact that the first seven instructions of P keep repeating
>>>>>> while H is in pure simulation mode proves that H is doing pure
>>>>>> simulation mode correctly.
>>>>>
>>>>> The problem is that your 'pure simulation mode' is a cheat.
>>>>>
>>>>
>>>> That the execution trace of the simulation of P precisely
>>>> corresponds to its source-code proves beyond all possible doubt that
>>>> the pure simulation of P by H is correct. There is no way to wiggle
>>>> out of this.
>>>
>>> No. It doesn't 'precisely correspond' to its source code because your
>>> trace *omits* a big chunk of code.
>>>
>>
>> *What details of this paragraph do you feel are incorrect (and why)*
>>
>> Because H only acts as a pure simulator of its input until after its
>> halt status decision has been made it has no behavior that can
>> possibly effect the behavior of its input. Because of this H screens
>> out its own address range in every execution trace that it examines.
>> This is why we never see any instructions of H in any execution trace
>> after an input calls H.
>
> The copy of H inside P is *not* the 'address range' of the Halt Decider.
> It is part of P.
>

When I refer to my C code I use H/P when I refer to the Linz code I only
use Ĥ.

> Rewrite your P as an actual *computation*. It isn't one as you've
> written it. It therefore is *not* the H_Hat of Linz.
>
> To accomplish this you minimally need to compile and link both H and P
> separately to produce two complete *self-contained* executables. You
> can't have both contained in the same executable.
>
> I strongly suspect that your H is also not a computation, but since
> you've never supplied the code for it I can't be sure.
>
>>>>> Your H and P *need* to be independent, self-contained programs.
>>>>> They need to both be compiled and linked separately resulting in
>>>>> two different executables. This means that the copy of H contained
>>>>> in P will be *distinct* from program H. It will be at an entirely
>>>>> different address and any code inside H which tells it to ignore
>>>>> its 'own code' will not result in it ignoring the H contained in P.
>>>>>
>>>>> That also means that any change in the "mode" in which the main H
>>>>> runs *cannot* have any effect on what the H contained in P does.
>>>>>
>>>>> Your 'pure simulation mode' is only valid as a test if it applies
>>>>> *only* to the behaviour of H, and not to the behaviour of the H
>>>>> contained inside P.
>>>>>
>>>>> If you change what the H inside P does, you are then talking about
>>>>> an *entirely different* computation which has no bearing on the
>>>>> halting behaviour of P.
>>>>>
>>>>> You can't evaluate whether P halts by considering what some
>>>>> modified version of P does, which is in effect what you are doing.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> That the execution trace of the simulation of P precisely
>>>> corresponds to its source-code proves beyond all possible doubt that
>>>> the pure simulation of P by H is correct. There is no way to wiggle
>>>> out of this.
>>>
>>> No. It doesn't 'precisely correspond' to its source code because your
>>> trace *omits* a big chunk of code.
>>>
>>
>> *What details of this paragraph do you feel are incorrect (and why)*
>>
>> Because H only acts as a pure simulator of its input until after its
>> halt status decision has been made it has no behavior that can
>> possibly effect the behavior of its input. Because of this H screens
>> out its own address range in every execution trace that it examines.
>> This is why we never see any instructions of H in any execution trace
>> after an input calls H.
>>
>>> Come back and post a complete trace once you've actually set up your
>>> H and P *properly*. i.e. as two *separate* programs which have been
>>> compiled and linked two form two separate, *complete* executables
>>> where P does not call any code contained in H. If there is code in
>>> common, it must be *duplicated* so that each executable contains its
>>> own copy of this code.
>>>
>>> There is no point discussing your implementation where your H and P
>>> are contained in a single executable. That's not how 'TM equivalents'
>>> work, nor is it how the Linz Proof constructs H_Hat, and no
>>> conclusions which you draw from such a mangled implementation can
>>> possibly shed any light on the halting problem.
>>>
>>
>> So when your reasoning fails to show that my H is incorrect you change
>> the subject. It is true that the input to H(P,P) never halts therefore
>> H(P,P)==0 is correct.
>>
>>> If you don't grasp why what you are doing is illegitimate, then I
>>> suggest you go and actually learn what the term 'computation' means.
>>
>> The standard formal definition of computation, repeated in all the
>> major textbooks, derives from these early ideas. Computation is
>> defined as the execution sequences of halting Turing machines (or
>> their equivalents). An execution sequence is the sequence of total
>> configurations of the machine, including states of memory and control
>> unit.
>
> A computation is entirely *self-contained*. Your P is not. It calls H as
> an external function call.
>

On 2021-08-03 19:24, olcott wrote:
> On 8/3/2021 8:00 PM, André G. Isaak wrote:

>> The copy of H inside P is *not* the 'address range' of the Halt
>> Decider. It is part of P.
>>
>
> When I refer to my C code I use H/P when I refer to the Linz code I only
> use Ĥ.

But you claim your P stands in the same relation to H as Linz's H_Hat
does. It does not.

>> A computation is entirely *self-contained*. Your P is not. It calls H
>> as an external function call.
>>
>
> Nit-picking over the use of words does not show that H does not decide P
> correctly. Once you are honest enough to acknowledge that H(P,P)==0 is
> correct then and only then can we change the subject.

This is hardly nit-picking over the use of words. It points to a
fundamental flaw in your whole approach. If you want to claim that your
argument has *any* relevance to Linz's proof, your P *must* be an actual
computation constructed from H in the same manner as Linz's H_Hat.

And I can't acknowledge a claim that is false.

P(P) halts. H(P, P) is supposed to describe the behaviour of P(P). It
does not.

>> To be a computation, P must contain *all* of the code which it relies
>> on. It needs its own copy of H which is distinct from your halt decider.

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

On 8/2/2021 7:11 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/2/2021 2:10 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/1/2021 5:54 AM, Ben Bacarisse wrote:
>>>
>>>>> I am happy you have a notation you like. Are you prepared to address
>>>>> that fact that your H^ is not "as in Linz"?
>>>>
>>>> My Ĥ is exactly the Linz Ĥ with the additional elaboration that the
>>>> second wildcard state transition ⊢* is defined to be a simulating halt
>>>> decider.
>>> No. I've explained many times now why your Ĥ is not at all "the Linz
>>> Ĥ". Do you see any point in my doing so again?
>
> I suspect not. You certainly have not asked a single question that
> could help you to understand why your Ĥ is irrelevant.
>
>>>>> We all know you are declaring that to be correct. Here's why your Ĥ is
>>>>> not "as in Linz". Linz requires that
>>>>>
>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>> if M applied to wM does not halt
>>>>>
>>>>> Any Ĥ that eventually transitions to Ĥ.qn on input wM must do so
>>>>> if, and only if, the encoded M applied to wM does not halt. But you've
>>>>> given us a case where your Ĥ is not like this:
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> And when we eliminate the fallacy of equivocation error we have
>>>>
>>>> Ĥ[0].q0 ⟨Ĥ⟩ ⊢* Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ ⊢* Ĥ[0].qn
>>> The only thing I think you are equivocating on is pretending that Ĥ[0]
>>> is not Ĥ, and it doesn't look as if you've removed that error. I think
>>> you /should/ remove it so that you can be saying something of value
>>> about Ĥ.
>>
>> It is clear from the text that Linz does specify at least three
>> different instances of Ĥ, The TM the TMD input ⟨Ĥ⟩ and a copy of this
>> TMD input.
>
> Still equivocating. Either Ĥ[0] = Ĥ or you are wasting everyone's time.
>
> (This is mathematical equality. Ĥ is a tuple of sets. If Ĥ[0] is not
> exactly identical in every way to Ĥ then I don't care about it. Note
> that I'm not disputing your right, for ease of explanation, to give
> identical things more than one name. But the same permission allows me
> to use any of the names because they name the same thing.)
>
> You are wrong because
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> where Linz requires that
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
> if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
>

You have the above incorrectly in these two
M refers to the Turing Machine described by wM.

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

This is *NOT* the Ĥ that is executed.
This is only the Turing Machine description ⟨Ĥ⟩ input.

In computability theory, the halting problem is the
problem of determining, from a description of an
arbitrary computer program and an input, whether
the program will finish running, or continue to run forever.
https://en.wikipedia.org/wiki/Halting_problem

The key point is that only the input to the halt decider is within the
scope of the halting problem.

As long as the halt decider correctly decides its input what these same
programs do what they are not inputs to the halt decider make no
difference to the actual halting problem.

--
Copyright 2021 Pete Olcott

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

On 8/3/2021 10:00 PM, André G. Isaak wrote:
> On 2021-08-03 19:24, olcott wrote:
>> On 8/3/2021 8:00 PM, André G. Isaak wrote:
>
>>> The copy of H inside P is *not* the 'address range' of the Halt
>>> Decider. It is part of P.
>>>
>>
>> When I refer to my C code I use H/P when I refer to the Linz code I
>> only use Ĥ.
>
> But you claim your P stands in the same relation to H as Linz's H_Hat
> does. It does not.
>

The only point that I will focus on is showing that H(P,P)==0 is
correct. An honest dialogue requires progress towards closure
point-by-point. I dishonest dialogue active thwarts closure on as many
points as possible.

>>> A computation is entirely *self-contained*. Your P is not. It calls H
>>> as an external function call.
>>>
>>
>> Nit-picking over the use of words does not show that H does not decide
>> P correctly. Once you are honest enough to acknowledge that H(P,P)==0
>> is correct then and only then can we change the subject.
>
> This is hardly nit-picking over the use of words. It points to a
> fundamental flaw in your whole approach. If you want to claim that your
> argument has *any* relevance to Linz's proof, your P *must* be an actual
> computation constructed from H in the same manner as Linz's H_Hat.
>
> And I can't acknowledge a claim that is false.
>

If you can't acknowledge my claim as true then you can stay focusing on
this single point and carefully critique every element of my support
case for this point. If you are dishonest then you won't be able to do
this.

> P(P) halts. H(P, P) is supposed to describe the behaviour of P(P). It
> does not.
>

I have proven point-by-point that H(P,P)==0 is correct. That you keep
changing the subject can't be tolerated within an honest dialogue.

>>> To be a computation, P must contain *all* of the code which it relies
>>> on. It needs its own copy of H which is distinct from your halt decider.
>
>
>

--
Copyright 2021 Pete Olcott

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

On 8/3/21 8:23 PM, olcott wrote:
> On 8/2/2021 7:11 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/2/2021 2:10 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/1/2021 5:54 AM, Ben Bacarisse wrote:
>>>>
>>>>>> I am happy you have a notation you like.  Are you prepared to address
>>>>>> that fact that your H^ is not "as in Linz"?
>>>>>
>>>>> My Ĥ is exactly the Linz Ĥ with the additional elaboration that the
>>>>> second wildcard state transition ⊢* is defined to be a simulating halt
>>>>> decider.
>>>> No.  I've explained many times now why your Ĥ is not at all "the Linz
>>>> Ĥ".  Do you see any point in my doing so again?
>>
>> I suspect not.  You certainly have not asked a single question that
>> could help you to understand why your Ĥ is irrelevant.
>>
>>>>>> We all know you are declaring that to be correct.  Here's why your
>>>>>> Ĥ is
>>>>>> not "as in Linz".  Linz requires that
>>>>>>
>>>>>>      Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>>      if M applied to wM does not halt
>>>>>>
>>>>>> Any Ĥ that eventually transitions to Ĥ.qn on input wM must do so
>>>>>> if, and only if, the encoded M applied to wM does not halt.  But
>>>>>> you've
>>>>>> given us a case where your Ĥ is not like this:
>>>>>>
>>>>>>      Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> And when we eliminate the fallacy of equivocation error we have
>>>>>
>>>>> Ĥ[0].q0 ⟨Ĥ⟩ ⊢* Ĥ[0].qx ⟨Ĥ[1]⟩ ⟨Ĥ[2]⟩ ⊢* Ĥ[0].qn
>>>> The only thing I think you are equivocating on is pretending that Ĥ[0]
>>>> is not Ĥ, and it doesn't look as if you've removed that error.  I think
>>>> you /should/ remove it so that you can be saying something of value
>>>> about Ĥ.
>>>
>>> It is clear from the text that Linz does specify at least three
>>> different instances of Ĥ, The TM the TMD input ⟨Ĥ⟩ and a copy of this
>>> TMD input.
>>
>> Still equivocating.  Either Ĥ[0] = Ĥ or you are wasting everyone's time.
>>
>> (This is mathematical equality.  Ĥ is a tuple of sets.  If Ĥ[0] is not
>> exactly identical in every way to Ĥ then I don't care about it.  Note
>> that I'm not disputing your right, for ease of explanation, to give
>> identical things more than one name.  But the same permission allows me
>> to use any of the names because they name the same thing.)
>>
>> You are wrong because
>>
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> where Linz requires that
>>
>>   Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
>>   if (and only if) Ĥ applied to ⟨Ĥ⟩ does not halt.
>>
>
> You have the above incorrectly in these two
> M refers to the Turing Machine described by wM.
>
> Ĥ.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
>
> This is *NOT* the Ĥ that is executed.
> This is only the Turing Machine description ⟨Ĥ⟩ input.
>
>      In computability theory, the halting problem is the
>      problem of determining, from a description of an
>      arbitrary computer program and an input, whether
>      the program will finish running, or continue to run forever.
>      https://en.wikipedia.org/wiki/Halting_problem
>
> The key point is that only the input to the halt decider is within the
> scope of the halting problem.
>
> As long as the halt decider correctly decides its input what these same
> programs do what they are not inputs to the halt decider make no
> difference to the actual halting problem.
>
>

WRONG.

The thing that is 'in scope' is the Turing Machine that the input is a
representation of.

To see if H is right, we need to compare what H predicts to what the
ACTUAL machine with that input does.

I.E the test of H(P,I) is to compare its answer to the actual behavior
of P(I)

'Inputs' don't have behavior, only the Computations (Machine/Input) they
represent do.

If a 'simulation' of the input doesn't match the behavior of the ACTUAL
machine, then the simulation is WRONG.

H^(H^) is a Halting Computation, as you admit, thus any supposed
simulation that doesn't show it halting is incorrect. An aborted
simulation before it halts might not be wrong, but doesn't show the
actual machine in non-halting. The fact that the actual machine Halts,
shows that the simulation actually will halt, and even in how many step.

It seems you don't understand that basic property of computers.

On 8/3/21 1:47 PM, olcott wrote:
> On 8/3/2021 3:08 PM, André G. Isaak wrote:
>> On 2021-08-03 13:26, olcott wrote:
>>> On 8/3/2021 12:11 PM, André G. Isaak wrote:
>>>> On 2021-08-03 09:21, olcott wrote:
>>>>> On 8/3/2021 9:33 AM, Malcolm McLean wrote:
>>>>>> On Tuesday, 3 August 2021 at 14:00:28 UTC+1, olcott wrote:
>>>>>>> On 8/3/2021 12:29 AM, Malcolm McLean wrote:
>>>>>>>>
>>>>>>>> You're trying to claim that H_Hat<H_Hat> doens't really halt
>>>>>>>> because
>>>>>>>> the recursion of H instances is terminated by H.
>>>>>>> No I have never been saying that. I am claiming that the input to
>>>>>>> H(P,P)
>>>>>>> never halts whether or not H terminates its simulation of this
>>>>>>> input.
>>>>>>>
>>>>>> We agree that P(P) halts.
>>>>>> So now you're drawing a distinction between P(P) and "the input to
>>>>>> H(P,P)".
>>>>>> ThIs is nonsense..
>>>>>
>>>>> Try and find any error in (a)(b)(c)(d) on page 6
>>>>>
>>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The error, which has been pointed out repeatedly, is in your (b).
>>>>
>>>> You claim "there are no control flow instructions in the execution
>>>> trace that would escape the infinite recursion", but there *are*
>>>> flow control instructions. But your trace is incomplete and skips
>>>> over the call to B82 where these flow control instructions reside.
>>>>
>>>
>>> Whether H aborts its simulation of P or not P never reaches its final
>>> state.
>>
>> But H's simulation of P is *not* a computation.
>>
>
> Sure it is.
> The pure simulation of a computation on its input is computationally
> equivalent to the direct execution of this same computation on its input.

But that requires it to BE a PURE simulation, i.e. one that NEVER halts
until the machine it is simulating does.

Since H will abort its simulation, it isn't a PURE simulator.

You 'invented' a phrase 'a pure simulation until ...'. but that ISN'T a
Pure simulation,

>
>> When we run H(P, P) the only computation being performed is H(P, P),
>> and if H aborts its simulation of P(P), then control returns to H
>> which then Halts.
>>
>
> The job of a halt decider is to correctly predict the future behavior of
> its input. Because the input to H(P,P) does not transition to its final
> state whether or not H aborts the simulation of this input we know that
> this input never halts.
>
> In computability theory, the halting problem is the problem of
> determining, from a description of an arbitrary computer program and an
> input, whether the program will finish running, or continue to run
> forever. https://en.wikipedia.org/wiki/Halting_problem

RIGHT, THE ACTUAL MACHINE, not a partial simulation of it.
>
> Because the P that halts is not: "a description of an arbitrary computer
> program" it is not in the scope of the Halting Problem. Only the input
> to P is in scope of the halting problem.

But it isn't the description that needs to halt.

Read your statement above:

determining *FROM* a description .. whether *THE PROGRAM* will finish
running...

The description is what the decider is given, the answer is about the
machine the the input is a description of.

The machine that your description is of is the H^(H^) that you say isn't
in scope, it is EXACTLY the scope of the quesiton.

Maybe you need to take basic English.

On 2021-08-03 21:23, olcott wrote:

> The key point is that only the input to the halt decider is within the
> scope of the halting problem.
>
> As long as the halt decider correctly decides its input what these same
> programs do what they are not inputs to the halt decider make no
> difference to the actual halting problem.

You have this completely back-assward.

How the TM described by the input to a halt decider behaves when they
are run as *independent* computations (i.e. not as inputs to the halt
decider) is the question a halt decider is supposed to answer by the
very definition of a 'halt decider'. If the answer provided by the
decider does not match the behavior of the *independent* computation,
then that answer is wrong.

Talking about how the description behaves "as an input" isn't even
coherent. Inputs don't behave like anything. They are just data.

André

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