On 8/23/21 10:08 AM, olcott wrote:
> On 8/23/2021 8:27 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/23/2021 5:33 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/22/2021 5:17 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/22/2021 3:09 PM, Ben Bacarisse wrote:
>>>>
>>>>>>>> To wrap up this sub-thread, let's just say that you currently
>>>>>>>> can't see
>>>>>>>> how to meet my specification.
>>>>>>>
>>>>>>> Let's just say that it is not cost effective for me to untangle any
>>>>>>> more convoluted paraphrase of the exact same things that I have
>>>>>>> already been saying without a specific high level overview of
>>>>>>> material
>>>>>>> differences that seem to be non-existent.
>>>>>>
>>>>>> I wondered why you posted a trace showing the wrong behaviour,
>>>>>
>>>>> It is the actual behavior that the code specifies.
>>>> A rather obvious thing to say.  Code does what it does.  It's the
>>>> behaviour I specified that's impossible.  No algorithm can determine
>>>> that a function call will return just as no algorithm can determine
>>>> if a
>>>> program will halt.
>>>
>>> I show a program that does this in the "impossible" case.
>>
>> You pretended to be able to meet my challenge by, rather oddly, posting
>> a trace that showed the wrong behaviour.
>>
>
> That you fail to comprhend that it is the correct behavior provides zero
> evidence that it is the wrong behavior.
>
>> You could score big here without any need for waffle or ambiguity by
>> simply posting a function that does what I specified.  The test code is
>> ready -- just link your function to the translation unit I provided and
>> you can prove, beyond a doubt that you've have a candidate.  Would that
>> not be wonderful?  No more arguments, just C code that does what was
>> asked of it and that I say is impossible?
>>
>
> I have already proved that I am correct with a much simpler example.
> Unless you can find fault with my example my proof stands.

YOu mean your 'Proof' where your Halt Decider declairs that P(P) is
non-halting while whem we run P(P) it halts.

You make some crasy claim that it must be right, as its trace never
reached the halting state, which is as absurd as turning off the TV as
your team is getting trounced so you can claim that they didn't lose as
you never saw the end of the game.

Remember, the question has ALWAYS been about the behavior of the Actual
Machine, not what the simulation does. The fact that the simulation is
terminated before the simulation sees that the machine will halt does
NOT make the machine non-halting.

>
> // Simplified Linz Ĥ (Linz:1990:319)
> // Strachey(1965) CPL translated to C
> void P(u32 x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H((u32)P, (u32)P));
>   P((u32)P);
> }
>
> It is the same case with the above.
> The execution of P(P) is not under the dominion of H yet the input to
> the simulation of H(P,P) is under the dominion of H.
>
> This makes these two pairs of computations distinctly different from
> each other. Distinctly different computations can have different
> behavior without contradiction.

NO ONE has said that H(P,P) and P(P) are the same computation.

The key is that H(P,P) is ASKING what P(P) does, and if we put its input
into a real accurate simulator, UTM(P,P) will exactly mimic P(P) and Halt.

That H(P,P) doesn't, just shows that H was incorrect in its logic about
P(P) and didn't do a fully accurate simulation.
>
>> (I say candidate because it's trivial to produce the right output simply
>> by cheating.  The specification requires another check -- the "equal
>> arguments" check.  But I'll grant you this: you have shown not desire to
>> produce a cheating "solution".)
>>
>
>

olcott <NoOne@NoWhere.com> writes:

> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:

> I ignore dishonest dodges away from the point at hand.

OK, let's do that:

"⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"

is wrong. You wrote that immediately after a line showing that Ĥ
applied to ⟨Ĥ⟩ halts. Everything since then has just been dodging this
error.

> When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
> instead of a simulating halt decider then we can see that Ĵ applied to
> ⟨Ĵ⟩ never halts.

The details are mess, but basically, yes. Detail errors (that would get
your paper rejected out of hand) available if you ask really nicely.

> There is an infinite cycle from Ĵ.qx to Ĵ.q0.

No, but that's just because you've never written a UTM so you don't know
how such a TM would work. Ĵ applied to ⟨Ĵ⟩ is non-halting but there
will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]

> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn

Eh? You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting. Do you know
what this notation means?

And you have another problem which shows how shallow your thinking is.
What is the state qn supposed to mean when J is a UTM? Presumably you
agree with my wording and, in fact, J is a UTM that can only halt when
simulating halting computations. So what's qn doing there? (J must
have a qn for Ĵ to have qn.)

> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĥ.qn

Typo: H.qn not Ĥ.qn.

> When we apply the original H to ⟨Ĵ⟩ ⟨Ĵ⟩ it transitions to its final
> state of H.qn

If you say so. I can't know because you are hiding H (well, you don't
actually have a TM H we are just playing pretend here). For all I know,
your H gets this case wrong as well, but I am prepared to accept what
you say about it.

> Can you understand that the direct execution of Ĵ on input ⟨Ĵ⟩ is not
> computationally equivalent to simulating halt decider H applied to ⟨Ĵ⟩
> ⟨Ĵ⟩ ?

I am not going to answer trivial, patronising questions.

The above discussion is a contradictory mess and does not address why
you are wrong. You are wrong because ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
computation.

[1] Actually it would be possible, with a lot mucking about, to arrange
this to happen, but the tape would not be as you imagine it because it
would have to be used to make q0 and qx behave differently. You think
such a loop would occur naturally like the endless calling of a
recursive function.

--
Ben.

On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>
>> I ignore dishonest dodges away from the point at hand.
>
> OK, let's do that:
>
> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
>
> is wrong. You wrote that immediately after a line showing that Ĥ
> applied to ⟨Ĥ⟩ halts. Everything since then has just been dodging this
> error.
>
>> When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
>> instead of a simulating halt decider then we can see that Ĵ applied to
>> ⟨Ĵ⟩ never halts.
>
> The details are mess, but basically, yes. Detail errors (that would get
> your paper rejected out of hand) available if you ask really nicely.
>

Which details do you think are incorrect?

>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>
> No, but that's just because you've never written a UTM so you don't know
> how such a TM would work. Ĵ applied to ⟨Ĵ⟩ is non-halting but there
> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>
>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>
> Eh? You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting. Do you know
> what this notation means?
>
> And you have another problem which shows how shallow your thinking is.
> What is the state qn supposed to mean when J is a UTM?

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt

Is it really that difficult to understand that I merely swapped Ĵ for Ĥ
in the Ĥ template to create the Ĵ tempate?

> Presumably you
> agree with my wording and, in fact, J is a UTM that can only halt when
> simulating halting computations. So what's qn doing there? (J must
> have a qn for Ĵ to have qn.)

Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
Ĵ0.q0 copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then Ĵ0.qx simulates Ĵ1 with the
⟨Ĵ2⟩ copy then
Ĵ1.q0 copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then Ĵ1.qx simulates Ĵ2 with the
⟨Ĵ3⟩ copy then
Ĵ2.q0 copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then Ĵ2.qx simulates Ĵ3 with the
⟨Ĵ4⟩ copy then ...

>> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĥ.qn
>
> Typo: H.qn not Ĥ.qn.
>

Yes, typo.

>> When we apply the original H to ⟨Ĵ⟩ ⟨Ĵ⟩ it transitions to its final
>> state of H.qn
>
> If you say so. I can't know because you are hiding H

It is the Linz H.

> (well, you don't
> actually have a TM H we are just playing pretend here). For all I know,
> your H gets this case wrong as well, but I am prepared to accept what
> you say about it.
>

It is the Linz H: Nitwit !!!

>> Can you understand that the direct execution of Ĵ on input ⟨Ĵ⟩ is not
>> computationally equivalent to simulating halt decider H applied to ⟨Ĵ⟩
>> ⟨Ĵ⟩ ?
>
> I am not going to answer trivial, patronising questions.
>

It it a mandatory prerequisite to the next step of my proof that you are
persistently (intentionally ?) failing to understand.

If you understand that the direct execution of Ĵ on input ⟨Ĵ⟩ is not
computationally equivalent to simulating halt decider H applied to ⟨Ĵ⟩ ⟨Ĵ⟩

then you should be able to understand that

the direct execution of Ĥ on input ⟨Ĥ⟩ is not computationally equivalent
to simulating halt decider at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.

> The above discussion is a contradictory mess and does not address why
> you are wrong. You are wrong because ⟨Ĥ⟩ ⟨Ĥ⟩ encodes a halting
> computation.
>
> [1] Actually it would be possible, with a lot mucking about, to arrange
> this to happen, but the tape would not be as you imagine it because it
> would have to be used to make q0 and qx behave differently. You think
> such a loop would occur naturally like the endless calling of a
> recursive function.
>

--
Copyright 2021 Pete Olcott

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

On 8/23/21 7:26 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:

>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>
> Eh? You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting. Do you know
> what this notation means?
>

It has been fairly clear that he does not. He as seen some uses of this
sort of notation, and based on 'First Principles' he as defined for
himself what this means, even if it doesn't actually mean that.

Since he rejects that any 'Rules' from some authority he doesn't want to
accept has no meaning, and everything just means what it seems to mean,
TO HIM, by the 'obvious' meaning of the words, this makes total logic
.... to HIM.

olcott <NoOne@NoWhere.com> writes:

> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>
>>> I ignore dishonest dodges away from the point at hand.
>> OK, let's do that:
>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
>> is wrong. You wrote that immediately after a line showing that Ĥ
>> applied to ⟨Ĥ⟩ halts. Everything since then has just been dodging this
>> error.
>>
>>> When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
>>> instead of a simulating halt decider then we can see that Ĵ applied to
>>> ⟨Ĵ⟩ never halts.
>> The details are mess, but basically, yes. Detail errors (that would get
>> your paper rejected out of hand) available if you ask really nicely.
>
> Which details do you think are incorrect?

A UTM is not a decider so the hat construction can't be applied to it.
And if we make a "UTM-decider" (a TM that is a pure simulator except
that is accepts those computations whose simulations terminate) we still
can't apply the hat construction because it won't have a rejecting
state. Thus your use of "exactly like Ĥ except..." is, at best,
disingenuous. The differences must be greater than the "except..."
clause suggests.

>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>> No, but that's just because you've never written a UTM so you don't know
>> how such a TM would work. Ĵ applied to ⟨Ĵ⟩ is non-halting but there
>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>
>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>
>> Eh? You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting. Do you know
>> what this notation means?
>> And you have another problem which shows how shallow your thinking is.
>> What is the state qn supposed to mean when J is a UTM?
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>
> Is it really that difficult to understand that I merely swapped Ĵ for
> Ĥ in the Ĥ template to create the Ĵ tempate?

I understand that you think you can just say that, but I also understand
the "template" better than you appear to.

>> Presumably you
>> agree with my wording and, in fact, J is a UTM that can only halt when
>> simulating halting computations. So what's qn doing there? (J must
>> have a qn for Ĵ to have qn.)
>
> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn

Do you know this means that you are claiming that Ĵ applied to ⟨Ĵ⟩
halts? You just claimed the opposite. I think you are just typing
symbols because they look good.

> Ĵ0.q0 copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then Ĵ0.qx simulates Ĵ1 with the ⟨Ĵ2⟩ copy then
> Ĵ1.q0 copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then Ĵ1.qx simulates Ĵ2 with the ⟨Ĵ3⟩ copy then
> Ĵ2.q0 copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then Ĵ2.qx simulates Ĵ3 with the
> ⟨Ĵ4⟩ copy then ...

No. Totally wrong. Your understanding of how a UTM works is
embarrassingly shallow and I simply don't have time to explain it to
you. In addition, you appear resistant to learning, so it would also be
pointless. I can only suggest you change you attitude to learning and
then read a book, Linz for example.

>>> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĥ.qn
>> Typo: H.qn not Ĥ.qn.
>
> Yes, typo.
>
>>> When we apply the original H to ⟨Ĵ⟩ ⟨Ĵ⟩ it transitions to its final
>>> state of H.qn
>> If you say so. I can't know because you are hiding H
>
> It is the Linz H.

Since, against my repeated advice, you chose to use the same symbol for
your actual TM as Linz does for his empty class of TMs you need to be
more careful distinguishing them. "The original H" is not clear and
discussion of it should be phrased hypothetically. You should talk
about what Linz's H is specified to do, not what it does.

But since you brought up Linz's H, here's a question (get your avoidance
waffle ready!). What is Linz's H specified to do when applied to your
⟨Ĥ⟩ ⟨Ĥ⟩? For clarity, let Linz's H be called L just for now. What goes
after the ⊢* here:

L.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ?

I really expect an answer to this. If you can't answer, be honest and
say you can't.

>> (well, you don't
>> actually have a TM H we are just playing pretend here). For all I know,
>> your H gets this case wrong as well, but I am prepared to accept what
>> you say about it.
>
> It is the Linz H: Nitwit !!!

You should give some thought to being more respectful.

>>> Can you understand that the direct execution of Ĵ on input ⟨Ĵ⟩ is not
>>> computationally equivalent to simulating halt decider H applied to ⟨Ĵ⟩
>>> ⟨Ĵ⟩ ?
>>
>> I am not going to answer trivial, patronising questions.
>
> It it a mandatory prerequisite to the next step of my proof that you
> are persistently (intentionally ?) failing to understand.

Don't be daft. You can present your argument whether or not I answer
your patronising questions. If you choose not to, that suits me better
because there will be fewer errors to point out if you keep it to
yourself.

> If you understand that the direct execution of Ĵ on input ⟨Ĵ⟩ is not
> computationally equivalent to simulating halt decider H applied to ⟨Ĵ⟩ ⟨Ĵ⟩
>
> then you should be able to understand that
>
> the direct execution of Ĥ on input ⟨Ĥ⟩ is not computationally
> equivalent to simulating halt decider at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.

That is beyond absurd. I leave it to you spot the silly error in your
reasoning (though you almost certainly won't be able to). And you will
need to account for the fact that both

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn (via Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩)

and

Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

and how that can be true of computations that are not "computationally
equivalent". (You don't give the final state of the tape but it will be
the same in both cases.) Let me be clear: the reasoning is silly (how
you go from one assertion to the next) and the conclusion is wrong.
This is not "failing to understand" it is "knowing more about the
subject than you do".

Your understanding of TM computations is woefully inadequate to discuss
these matters. Almost everything you say contains errors, many of them
huge errors that render your arguments null and void. Even so, nothing
you say addresses the reason why your H is not a halt decider. Your H
(not Linz's H) rejects a string that encodes a halting computation.
It's as simple as that.

--
Ben.

On 8/23/2021 10:09 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> I ignore dishonest dodges away from the point at hand.
>>> OK, let's do that:
>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
>>> is wrong. You wrote that immediately after a line showing that Ĥ
>>> applied to ⟨Ĥ⟩ halts. Everything since then has just been dodging this
>>> error.
>>>
>>>> When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
>>>> instead of a simulating halt decider then we can see that Ĵ applied to
>>>> ⟨Ĵ⟩ never halts.
>>> The details are mess, but basically, yes. Detail errors (that would get
>>> your paper rejected out of hand) available if you ask really nicely.
>>
>> Which details do you think are incorrect?
>
> A UTM is not a decider so the hat construction can't be applied to it.
> And if we make a "UTM-decider" (a TM that is a pure simulator except
> that is accepts those computations whose simulations terminate) we still
> can't apply the hat construction because it won't have a rejecting
> state. Thus your use of "exactly like Ĥ except..." is, at best,
> disingenuous. The differences must be greater than the "except..."
> clause suggests.
>

My whole purpose was to simply show what happens when the simulating
halt decide at Ĥ.qx only simulates its input.

We can still have the same final states, except now that are unreachable
dead code.

>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>>> No, but that's just because you've never written a UTM so you don't know
>>> how such a TM would work. Ĵ applied to ⟨Ĵ⟩ is non-halting but there
>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>>
>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>
>>> Eh? You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting. Do you know
>>> what this notation means?
>>> And you have another problem which shows how shallow your thinking is.
>>> What is the state qn supposed to mean when J is a UTM?
>>
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>
>> Is it really that difficult to understand that I merely swapped Ĵ for
>> Ĥ in the Ĥ template to create the Ĵ tempate?
>
> I understand that you think you can just say that, but I also understand
> the "template" better than you appear to.
>
>>> Presumably you
>>> agree with my wording and, in fact, J is a UTM that can only halt when
>>> simulating halting computations. So what's qn doing there? (J must
>>> have a qn for Ĵ to have qn.)
>>
>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>
> Do you know this means that you are claiming that Ĵ applied to ⟨Ĵ⟩
> halts?

I am not claiming that. I am making a single change to Ĥ that now has
some unreachable dead code states.

> You just claimed the opposite. I think you are just typing
> symbols because they look good.
>
>> Ĵ0.q0 copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then Ĵ0.qx simulates Ĵ1 with the ⟨Ĵ2⟩ copy then
>> Ĵ1.q0 copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then Ĵ1.qx simulates Ĵ2 with the ⟨Ĵ3⟩ copy then
>> Ĵ2.q0 copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then Ĵ2.qx simulates Ĵ3 with the
>> ⟨Ĵ4⟩ copy then ...
>
> No. Totally wrong. Your understanding of how a UTM works is
> embarrassingly shallow and I simply don't have time to explain it to
> you. In addition, you appear resistant to learning, so it would also be
> pointless. I can only suggest you change you attitude to learning and
> then read a book, Linz for example.

If the Ĥ template stipulates that those actions occur then they occur
when Ĥ has the one single modification of changing the simulating halt
decider at Ĥ.qx to a UTM.

>>>> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĥ.qn
>>> Typo: H.qn not Ĥ.qn.
>>
>> Yes, typo.
>>
>>>> When we apply the original H to ⟨Ĵ⟩ ⟨Ĵ⟩ it transitions to its final
>>>> state of H.qn
>>> If you say so. I can't know because you are hiding H
>>
>> It is the Linz H.
>
> Since, against my repeated advice, you chose to use the same symbol for
> your actual TM as Linz does for his empty class of TMs you need to be
> more careful distinguishing them.

Apparently most all of the textbooks call this H.

> "The original H" is not clear and
> discussion of it should be phrased hypothetically. You should talk
> about what Linz's H is specified to do, not what it does.
>

Yes that makes sense.

> But since you brought up Linz's H, here's a question (get your avoidance
> waffle ready!). What is Linz's H specified to do when applied to your
> ⟨Ĥ⟩ ⟨Ĥ⟩? For clarity, let Linz's H be called L just for now. What goes
> after the ⊢* here:
>

I am breaking that analysis down to its simpler components. We take the
Linz Ĥ and change the simulating halt decider at Ĥ.qx to a UTM and
rename this new machine Ĵ. The new machine has come dead code staes that
are never reached.

Now we apply the Linz H to ⟨Ĵ⟩ ⟨Ĵ⟩ and H transitions to its final state
of H.qn indicating that Ĵ applied to ⟨Ĵ⟩ never halts.

> L.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ?
>
> I really expect an answer to this. If you can't answer, be honest and
> say you can't.

Maybe it is easier now.

>
>>> (well, you don't
>>> actually have a TM H we are just playing pretend here). For all I know,
>>> your H gets this case wrong as well, but I am prepared to accept what
>>> you say about it.
>>
>> It is the Linz H: Nitwit !!!
>
> You should give some thought to being more respectful.

I only call people a nitwit when they seem to being too disrespectful to
me. Richard disrespectfully fails to distinguish between the words
"before" and "after" so I gave up on him.

I cannot believe that he actually fails to understand what all grade
school kids understand, he is merely playing head games beyond my
tolerance threshold.

>
>>>> Can you understand that the direct execution of Ĵ on input ⟨Ĵ⟩ is not
>>>> computationally equivalent to simulating halt decider H applied to ⟨Ĵ⟩
>>>> ⟨Ĵ⟩ ?
>>>
>>> I am not going to answer trivial, patronising questions.
>>
>> It it a mandatory prerequisite to the next step of my proof that you
>> are persistently (intentionally ?) failing to understand.
>
> Don't be daft. You can present your argument whether or not I answer
> your patronising questions. If you choose not to, that suits me better
> because there will be fewer errors to point out if you keep it to
> yourself.
>
>> If you understand that the direct execution of Ĵ on input ⟨Ĵ⟩ is not
>> computationally equivalent to simulating halt decider H applied to ⟨Ĵ⟩ ⟨Ĵ⟩
>>
>> then you should be able to understand that
>>
>> the direct execution of Ĥ on input ⟨Ĥ⟩ is not computationally
>> equivalent to simulating halt decider at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>
> That is beyond absurd. I leave it to you spot the silly error in your
> reasoning (though you almost certainly won't be able to). And you will
> need to account for the fact that both
>

My only "error" is that you very persistently and thus disrespectfully
fail to bother to pay attention to my proof that this is correct.

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

int main()
{ Output("Input_Halts = ", H((u32)P, (u32)P));
Output("Input_Halts = ", H1((u32)P, (u32)P));
P((u32)P);
}

The fact that the first line of main() does produce different results
than the second line of main conclusively proves that these two
computations are computationally distinct different computations.

On 8/23/21 11:52 PM, olcott wrote:
> On 8/23/2021 10:09 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> I ignore dishonest dodges away from the point at hand.
>>>> OK, let's do that:
>>>>     "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
>>>> is wrong.  You wrote that immediately after a line showing that Ĥ
>>>> applied to ⟨Ĥ⟩ halts.  Everything since then has just been dodging this
>>>> error.
>>>>
>>>>> When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
>>>>> instead of a simulating halt decider then we can see that Ĵ applied to
>>>>> ⟨Ĵ⟩ never halts.
>>>> The details are mess, but basically, yes.  Detail errors (that would
>>>> get
>>>> your paper rejected out of hand) available if you ask really nicely.
>>>
>>> Which details do you think are incorrect?
>>
>> A UTM is not a decider so the hat construction can't be applied to it.
>> And if we make a "UTM-decider" (a TM that is a pure simulator except
>> that is accepts those computations whose simulations terminate) we still
>> can't apply the hat construction because it won't have a rejecting
>> state.  Thus your use of "exactly like Ĥ except..." is, at best,
>> disingenuous.  The differences must be greater than the "except..."
>> clause suggests.
>>
>
> My whole purpose was to simply show what happens when the simulating
> halt decide at Ĥ.qx only simulates its input.
>
> We can still have the same final states, except now that are unreachable
> dead code.

But the key point is that your Decider is NOT 'just like' a UTM in that
it will possibly decide to abort its simulation, and when it does so it
behaves different than a UTM would, and thus that changes the behavior
of the machine that calls it.

This means you can't treat a copy of this decider that you see as if it
was a UTM, because it isn't.

THAT is ONE of your fatal flaws in your arguement.

>
>>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>>>> No, but that's just because you've never written a UTM so you don't
>>>> know
>>>> how such a TM would work.  Ĵ applied to ⟨Ĵ⟩ is non-halting but there
>>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>>>
>>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>
>>>> Eh?  You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting.  Do you
>>>> know
>>>> what this notation means?
>>>> And you have another problem which shows how shallow your thinking is.
>>>> What is the state qn supposed to mean when J is a UTM?
>>>
>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>
>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>
>>> Is it really that difficult to understand that I merely swapped Ĵ for
>>> Ĥ in the Ĥ template to create the Ĵ tempate?
>>
>> I understand that you think you can just say that, but I also understand
>> the "template" better than you appear to.
>>
>>>> Presumably you
>>>> agree with my wording and, in fact, J is a UTM that can only halt when
>>>> simulating halting computations.  So what's qn doing there?  (J must
>>>> have a qn for Ĵ to have qn.)
>>>
>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>
>> Do you know this means that you are claiming that Ĵ applied to ⟨Ĵ⟩
>> halts? 
>
> I am not claiming that. I am making a single change to Ĥ that now has
> some unreachable dead code states.

And since H is not J, this new Hj^ is not H^ and doesn't act that same
way as it does.
>
>> You just claimed the opposite.  I think you are just typing
>> symbols because they look good.
>>
>>> Ĵ0.q0 copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then Ĵ0.qx simulates Ĵ1 with the
>>> ⟨Ĵ2⟩ copy then
>>> Ĵ1.q0 copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then Ĵ1.qx simulates Ĵ2 with the
>>> ⟨Ĵ3⟩ copy then
>>> Ĵ2.q0 copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then Ĵ2.qx simulates Ĵ3 with the
>>> ⟨Ĵ4⟩ copy then ...
>>
>> No.  Totally wrong.  Your understanding of how a UTM works is
>> embarrassingly shallow and I simply don't have time to explain it to
>> you.  In addition, you appear resistant to learning, so it would also be
>> pointless.  I can only suggest you change you attitude to learning and
>> then read a book, Linz for example.
>
> If the Ĥ template stipulates that those actions occur then they occur
> when Ĥ has the one single modification of changing the simulating halt
> decider at Ĥ.qx to a UTM.
>

Right, so this J^ is NOT the H^ that you had before. J^ isn't H^ so just
because J^ behaves one way doesn't mean that H^ will.

Take your car and make the minor change of removing a section of the
brake line. That doesn't mean the car still behaves in the same way.

>>>>> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĥ.qn
>>>> Typo: H.qn not Ĥ.qn.
>>>
>>> Yes, typo.
>>>
>>>>> When we apply the original H to ⟨Ĵ⟩ ⟨Ĵ⟩ it transitions to its final
>>>>> state of H.qn
>>>> If you say so.  I can't know because you are hiding H
>>>
>>> It is the Linz H.
>>
>> Since, against my repeated advice, you chose to use the same symbol for
>> your actual TM as Linz does for his empty class of TMs you need to be
>> more careful distinguishing them.
>
> Apparently most all of the textbooks call this H.
>
>>  "The original H" is not clear and
>> discussion of it should be phrased hypothetically.  You should talk
>> about what Linz's H is specified to do, not what it does.
>>
>
> Yes that makes sense.
>
>> But since you brought up Linz's H, here's a question (get your avoidance
>> waffle ready!).  What is Linz's H specified to do when applied to your
>> ⟨Ĥ⟩ ⟨Ĥ⟩?  For clarity, let Linz's H be called L just for now.  What goes
>> after the ⊢* here:
>>
>
> I am breaking that analysis down to its simpler components. We take the
> Linz Ĥ and change the simulating halt decider at Ĥ.qx to a UTM and
> rename this new machine Ĵ. The new machine has come dead code staes that
> are never reached.
>
> Now we apply the Linz H to ⟨Ĵ⟩ ⟨Ĵ⟩ and H transitions to its final state
> of H.qn indicating that Ĵ applied to ⟨Ĵ⟩ never halts.

Ok, so H can correctly decide that J^ is none halting. so what. It still
gets H^ wrong

>
>>    L.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ?
>>
>> I really expect an answer to this.  If you can't answer, be honest and
>> say you can't.
>
> Maybe it is easier now.
>
>>
>>>> (well, you don't
>>>> actually have a TM H we are just playing pretend here).  For all I
>>>> know,
>>>> your H gets this case wrong as well, but I am prepared to accept what
>>>> you say about it.
>>>
>>> It is the Linz H: Nitwit !!!
>>
>> You should give some thought to being more respectful.
>
> I only call people a nitwit when they seem to being too disrespectful to
> me. Richard disrespectfully fails to distinguish between the words
> "before" and "after" so I gave up on him.

WRONG.

LIAR.

I reject that something can be a pure simulator and abort its
simulation. If something can abort its simulation, it is by defintion
NOT a pure simulator.

Before and After aren't attributes that can be added to non-tempral
qualities. Can you describe what you were before you were Human, or
after you stopped being Human. That is a meaningless statement.

Same for a Pure Simulator. Something is a Pure Simulator, simulating to
the inputs final state, or it isn't. If it does anything to deviate from
this requirement, it isn't a pure simuator.

One other thing that I just thought about which may be part of your
confusion.

Remember that for this theory, a Computation was the results that came
out of a Computer, but that Computer wasn't what you think of today, but
was a PERSON, who had a list of instructions to perform, written on
paper (and unchangable), a simple adding machine, maybe some scrap paper
for notes, and a input table.

The 'Computer' would precisely follow the instructions on the sheet,
taking data as needed from the input table, perform the calculations as
described, and then at the end fill out the results.

The proper computation started with a cleared adding machine (so a
previous calculation didn't affect it) and effectively a blank sheet of
scrap paper (If it wasn't actually blank, you wouldn't use anything that
was already on the paper).

When these theories were created, what you think of as a computer wasn't
even in the thoughts of most people.

When applied to a modern computer, a 'computation' has as a prerequisite
that everything that affects the results needs to be defined as either
part of the algorithm (code) or explicit input (data). Since the stored
program machine intertwines these, it is easy to make a mistake and have
values used that aren't defined as either, and this makes that operation
NOT a true computation.

olcott <NoOne@NoWhere.com> writes:

> On 8/23/2021 10:09 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> I ignore dishonest dodges away from the point at hand.
>>>> OK, let's do that:
>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
>>>> is wrong. You wrote that immediately after a line showing that Ĥ
>>>> applied to ⟨Ĥ⟩ halts. Everything since then has just been dodging this
>>>> error.
>>>>
>>>>> When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
>>>>> instead of a simulating halt decider then we can see that Ĵ applied to
>>>>> ⟨Ĵ⟩ never halts.
>>>> The details are mess, but basically, yes. Detail errors (that would get
>>>> your paper rejected out of hand) available if you ask really nicely.
>>>
>>> Which details do you think are incorrect?
>>
>> A UTM is not a decider so the hat construction can't be applied to it.
>> And if we make a "UTM-decider" (a TM that is a pure simulator except
>> that is accepts those computations whose simulations terminate) we still
>> can't apply the hat construction because it won't have a rejecting
>> state. Thus your use of "exactly like Ĥ except..." is, at best,
>> disingenuous. The differences must be greater than the "except..."
>> clause suggests.
>
> My whole purpose was to simply show what happens when the simulating
> halt decide at Ĥ.qx only simulates its input.

I know, but you wanted to know what details you'd got wrong.

> We can still have the same final states, except now that are
> unreachable dead code.

Except you show below this unreachable state being reached:

Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn

The TM at Ĵ.qx is your "UTM-decider" with an unreachable reject state.
Do you see why I don't think you know what you are saying?

>>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>>>> No, but that's just because you've never written a UTM so you don't know
>>>> how such a TM would work. Ĵ applied to ⟨Ĵ⟩ is non-halting but there
>>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>>>
>>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>
>>>> Eh? You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting.

This needs to be addressed.

>>>> And you have another problem which shows how shallow your thinking is.
>>>> What is the state qn supposed to mean when J is a UTM?
>>>
>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>
>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>
>>> Is it really that difficult to understand that I merely swapped Ĵ for
>>> Ĥ in the Ĥ template to create the Ĵ tempate?
>> I understand that you think you can just say that, but I also understand
>> the "template" better than you appear to.
>>
>>>> Presumably you
>>>> agree with my wording and, in fact, J is a UTM that can only halt when
>>>> simulating halting computations. So what's qn doing there? (J must
>>>> have a qn for Ĵ to have qn.)
>>>
>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>
>> Do you know this means that you are claiming that Ĵ applied to ⟨Ĵ⟩
>> halts?
>
> I am not claiming that.

So why did you write Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn? You wrote a
formal description of something that is impossible (qn is unreachable if
it exists at all) and which even if it were possible is not what Ĵ
applied to ⟨Ĵ⟩ does? No, you wrote something daft without thinking or
maybe without know what it meant.

> I am making a single change to Ĥ that now has some unreachable dead
> code states.

Which state? Ĵ.qn? The one you show Ĵ.q0 ⟨Ĵ⟩ transitioning to? Yeah,
sure.

>>> Ĵ0.q0 copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then Ĵ0.qx simulates Ĵ1 with the ⟨Ĵ2⟩ copy then
>>> Ĵ1.q0 copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then Ĵ1.qx simulates Ĵ2 with the ⟨Ĵ3⟩ copy then
>>> Ĵ2.q0 copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then Ĵ2.qx simulates Ĵ3 with the
>>> ⟨Ĵ4⟩ copy then ...
>> No. Totally wrong. Your understanding of how a UTM works is
>> embarrassingly shallow and I simply don't have time to explain it to
>> you. In addition, you appear resistant to learning, so it would also be
>> pointless. I can only suggest you change you attitude to learning and
>> then read a book, Linz for example.
>
> If the Ĥ template stipulates that those actions occur then they occur
> when Ĥ has the one single modification of changing the simulating halt
> decider at Ĥ.qx to a UTM.

No. Give this up. You don't understand what a UTM is, and I can't
possibly teach you. You have the result you want: the "other TM
computation" is non-halting but it does not do that in the way you
think, but if you keep giving details, I'll have to keep replying that
you are wrong.

>>>>> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĥ.qn
>>>> Typo: H.qn not Ĥ.qn.
>>>
>>> Yes, typo.
....
>>> It is the Linz H.
>>
>> Since, against my repeated advice, you chose to use the same symbol for
>> your actual TM as Linz does for his empty class of TMs you need to be
>> more careful distinguishing them.
>
> Apparently most all of the textbooks call this H.

Which is further evidence that you should not. These books use H to
refer to a hypothetical member of an empty class of TMs. Your H is
real. It does stuff. It is not a member of an empty set. And gets at
least one instance of the halting problem wrong because your H rejects
the string ⟨Ĥ⟩ ⟨Ĥ⟩.

>> But since you brought up Linz's H, here's a question (get your avoidance
>> waffle ready!). What is Linz's H specified to do when applied to your
>> ⟨Ĥ⟩ ⟨Ĥ⟩? For clarity, let Linz's H be called L just for now. What goes
>> after the ⊢* here:
>>
>
> I am breaking that analysis down to its simpler components.

So you are not going to answer. OK, it was a lot to expect -- a direct
answer to a simple question.

> We take the Linz Ĥ and change the simulating halt decider at Ĥ.qx to a
> UTM and rename this new machine Ĵ. The new machine has come dead code
> staes that are never reached.

That won't help you say what Linz's H specified to do when applied to
/your/ ⟨Ĥ⟩ ⟨Ĥ⟩. Note: to your ⟨Ĥ⟩ ⟨Ĥ⟩.

> Now we apply the Linz H to ⟨Ĵ⟩ ⟨Ĵ⟩ and H transitions to its final
> state of H.qn indicating that Ĵ applied to ⟨Ĵ⟩ never halts.

Which is not what I was asking about.

>> L.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* ?
>>
>> I really expect an answer to this. If you can't answer, be honest and
>> say you can't.
>
> Maybe it is easier now.

For who? I already know the answer. I am asking you because you can't
(or dare not) say.

>>> If you understand that the direct execution of Ĵ on input ⟨Ĵ⟩ is not
>>> computationally equivalent to simulating halt decider H applied to ⟨Ĵ⟩ ⟨Ĵ⟩
>>>
>>> then you should be able to understand that
>>>
>>> the direct execution of Ĥ on input ⟨Ĥ⟩ is not computationally
>>> equivalent to simulating halt decider at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>> That is beyond absurd. I leave it to you spot the silly error in your
>> reasoning (though you almost certainly won't be able to).
>
> My only "error" is that you very persistently and thus disrespectfully
> fail to bother to pay attention to my proof that this is correct.

I have never seen anything remotely resembling a proof from you. And
you reasoning above is absurd. It's absurd and it results in an
incorrect conclusion.

<aside>
Part of the problem is that you don't know what a proof is. I mean that
literally. Your ancient error about entailment suggests that you think
you can just add "stipulations" that make theorems into non-theorems.
It means you think you don't need to address the original argument
because you think you can invalidate it with other "true" things. You
may not know it, but this makes your "arguments" laughable in the eyes
of educated readers. Some will find not paying attention to them the
most respectful thing they can do.
</aside>

On 8/24/2021 9:09 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/23/2021 10:09 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> I ignore dishonest dodges away from the point at hand.
>>>>> OK, let's do that:
>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
>>>>> is wrong. You wrote that immediately after a line showing that Ĥ
>>>>> applied to ⟨Ĥ⟩ halts. Everything since then has just been dodging this
>>>>> error.
>>>>>
>>>>>> When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
>>>>>> instead of a simulating halt decider then we can see that Ĵ applied to
>>>>>> ⟨Ĵ⟩ never halts.
>>>>> The details are mess, but basically, yes. Detail errors (that would get
>>>>> your paper rejected out of hand) available if you ask really nicely.
>>>>
>>>> Which details do you think are incorrect?
>>>
>>> A UTM is not a decider so the hat construction can't be applied to it.
>>> And if we make a "UTM-decider" (a TM that is a pure simulator except
>>> that is accepts those computations whose simulations terminate) we still
>>> can't apply the hat construction because it won't have a rejecting
>>> state. Thus your use of "exactly like Ĥ except..." is, at best,
>>> disingenuous. The differences must be greater than the "except..."
>>> clause suggests.
>>
>> My whole purpose was to simply show what happens when the simulating
>> halt decide at Ĥ.qx only simulates its input.
>
> I know, but you wanted to know what details you'd got wrong.
>

If my plan was to swap the simulating halt decider at Ĥ.qx with a UTM
and then rename this machine to Ĵ and I did swap swap the simulating
halt decider at Ĥ.qx with a UTM and rename this machine to Ĵ then it is
a God damned lie that I got anything wrong.

>> We can still have the same final states, except now that are
>> unreachable dead code.
>
> Except you show below this unreachable state being reached:
>

No I do frigging not. The code is still there but the infinite cycle
from Ĵ.qx to Ĵ.q0 prevents it from ever being reached.

> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>
> The TM at Ĵ.qx is your "UTM-decider" with an unreachable reject state.
> Do you see why I don't think you know what you are saying?

The you imagine what I mean to say instead of examining what I actually
say is your mistake.

This machine
Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn

is transformed into this machine:
Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn // a machine stuck in
infinitely nested simulation

>>>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>>>>> No, but that's just because you've never written a UTM so you don't know
>>>>> how such a TM would work. Ĵ applied to ⟨Ĵ⟩ is non-halting but there
>>>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>>>>
>>>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>>
>>>>> Eh? You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting.
>
> This needs to be addressed.

That you don't believe that there is a cycle from Ĵ.qx to Ĵ.q0 is flatly
wrong. The design of Ĥ as a simulating halt decider stipulates that
there is a cycle from Ĥ.qx to Ĥ.q0. Changing the simulating halt decider
at Ĥ.qx to a UTM at Ĵ.qx makes this cycle infinite.

>>>>> And you have another problem which shows how shallow your thinking is.
>>>>> What is the state qn supposed to mean when J is a UTM?
>>>>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qy ∞
>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ halts, and
>>>>
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>> if the simulated ⟨Ĥ1⟩ applied to ⟨Ĥ2⟩ does not halt
>>>>
>>>> Is it really that difficult to understand that I merely swapped Ĵ for
>>>> Ĥ in the Ĥ template to create the Ĵ tempate?
>>> I understand that you think you can just say that, but I also understand
>>> the "template" better than you appear to.
>>>
>>>>> Presumably you
>>>>> agree with my wording and, in fact, J is a UTM that can only halt when
>>>>> simulating halting computations. So what's qn doing there? (J must
>>>>> have a qn for Ĵ to have qn.)
>>>>
>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>
>>> Do you know this means that you are claiming that Ĵ applied to ⟨Ĵ⟩
>>> halts?
>>
>> I am not claiming that.
>
> So why did you write Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn?

Because that <is> the Ĥ code with the single adaptation of swapping the
simulating halt decider at Ĥ.qx with a UTM at Ĵ.qx.

> You wrote a
> formal description of something that is impossible (qn is unreachable if
> it exists at all) and which even if it were possible is not what Ĵ
> applied to ⟨Ĵ⟩ does? No, you wrote something daft without thinking or
> maybe without know what it meant.

I wanted to make a single change to Ĥ so that I could show that the
input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ really does specify an infinite cycle that must
be aborted by its simulating halt decider. You seemed to be having an
impossibly difficult time understanding this.

>> I am making a single change to Ĥ that now has some unreachable dead
>> code states.
>
> Which state? Ĵ.qn? The one you show Ĵ.q0 ⟨Ĵ⟩ transitioning to? Yeah,
> sure.
>
>>>> Ĵ0.q0 copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then Ĵ0.qx simulates Ĵ1 with the ⟨Ĵ2⟩ copy then
>>>> Ĵ1.q0 copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then Ĵ1.qx simulates Ĵ2 with the ⟨Ĵ3⟩ copy then
>>>> Ĵ2.q0 copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then Ĵ2.qx simulates Ĵ3 with the
>>>> ⟨Ĵ4⟩ copy then ...
>>> No. Totally wrong. Your understanding of how a UTM works is
>>> embarrassingly shallow and I simply don't have time to explain it to
>>> you. In addition, you appear resistant to learning, so it would also be
>>> pointless. I can only suggest you change you attitude to learning and
>>> then read a book, Linz for example.
>>
>> If the Ĥ template stipulates that those actions occur then they occur
>> when Ĥ has the one single modification of changing the simulating halt
>> decider at Ĥ.qx to a UTM.
>
> No. Give this up. You don't understand what a UTM is, and I can't
> possibly teach you. You have the result you want: the "other TM
> computation" is non-halting but it does not do that in the way you
> think, but if you keep giving details, I'll have to keep replying that
> you are wrong.
>
>>>>>> H.q0 ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĥ.qn
>>>>> Typo: H.qn not Ĥ.qn.
>>>>
>>>> Yes, typo.
> ...
>>>> It is the Linz H.
>>>
>>> Since, against my repeated advice, you chose to use the same symbol for
>>> your actual TM as Linz does for his empty class of TMs you need to be
>>> more careful distinguishing them.
>>
>> Apparently most all of the textbooks call this H.
>
> Which is further evidence that you should not. These books use H to
> refer to a hypothetical member of an empty class of TMs. Your H is
> real. It does stuff. It is not a member of an empty set. And gets at
> least one instance of the halting problem wrong because your H rejects
> the string ⟨Ĥ⟩ ⟨Ĥ⟩.
>

When I refer to the Linz H it is still hypothetical because I do not
show all of the steps.

>>> But since you brought up Linz's H, here's a question (get your avoidance
>>> waffle ready!). What is Linz's H specified to do when applied to your
>>> ⟨Ĥ⟩ ⟨Ĥ⟩? For clarity, let Linz's H be called L just for now. What goes
>>> after the ⊢* here:
>>>
>>
>> I am breaking that analysis down to its simpler components.
>
> So you are not going to answer. OK, it was a lot to expect -- a direct
> answer to a simple question.
>

olcott <NoOne@NoWhere.com> writes:

> On 8/24/2021 9:09 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/23/2021 10:09 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> I ignore dishonest dodges away from the point at hand.
>>>>>> OK, let's do that:
>>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
>>>>>> is wrong. You wrote that immediately after a line showing that Ĥ
>>>>>> applied to ⟨Ĥ⟩ halts. Everything since then has just been dodging this
>>>>>> error.
>>>>>>
>>>>>>> When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
>>>>>>> instead of a simulating halt decider then we can see that Ĵ applied to
>>>>>>> ⟨Ĵ⟩ never halts.
>>>>>> The details are mess, but basically, yes. Detail errors (that would get
>>>>>> your paper rejected out of hand) available if you ask really nicely.
>>>>>
>>>>> Which details do you think are incorrect?
>>>>
>>>> A UTM is not a decider so the hat construction can't be applied to it.
>>>> And if we make a "UTM-decider" (a TM that is a pure simulator except
>>>> that is accepts those computations whose simulations terminate) we still
>>>> can't apply the hat construction because it won't have a rejecting
>>>> state. Thus your use of "exactly like Ĥ except..." is, at best,
>>>> disingenuous. The differences must be greater than the "except..."
>>>> clause suggests.
>>>
>>> My whole purpose was to simply show what happens when the simulating
>>> halt decide at Ĥ.qx only simulates its input.
>> I know, but you wanted to know what details you'd got wrong.
>>
>
> If my plan was to swap the simulating halt decider at Ĥ.qx with a UTM
> and then rename this machine to Ĵ and I did swap swap the simulating
> halt decider at Ĥ.qx with a UTM and rename this machine to Ĵ then it
> is a God damned lie that I got anything wrong.

No. You won't get it unless you really try.

>>> We can still have the same final states, except now that are
>>> unreachable dead code.
>> Except you show below this unreachable state being reached:
>
> No I do frigging not.

Yes you did. I quoted you: Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn.

> The code is still there but the infinite cycle
> from Ĵ.qx to Ĵ.q0 prevents it from ever being reached.

No. You are totally at sea. I did my best to explain but you'd have to
want to learn to make any progress.

>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>> The TM at Ĵ.qx is your "UTM-decider" with an unreachable reject state.
>> Do you see why I don't think you know what you are saying?
>
> The you imagine what I mean to say instead of examining what I
> actually say is your mistake.
>
> This machine
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>
> is transformed into this machine:
> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn // a machine stuck in
> infinitely nested simulation

You don't know what this notation means. I don't think I can help you
with this.

>>>>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>>>>>> No, but that's just because you've never written a UTM so you don't know
>>>>>> how such a TM would work. Ĵ applied to ⟨Ĵ⟩ is non-halting but there
>>>>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>>>>>
>>>>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>>>
>>>>>> Eh? You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting.
>> This needs to be addressed.
>
> That you don't believe that there is a cycle from Ĵ.qx to Ĵ.q0 is
> flatly wrong.

No, I'm right about that. But you are piling errors on errors now so
responding is getting harder. What you are not responding to is the
contraction. Even though there is no cycle from Ĵ.qx to Ĵ.q0, Ĵ applied
to ⟨Ĵ⟩ is indeed non-halting you keep showing that it halts. Even if
there were a cycle from Ĵ.qx to Ĵ.q0 you would still be contradicting
yourself.

> The design of Ĥ as a simulating halt decider stipulates that there is
> a cycle from Ĥ.qx to Ĥ.q0. Changing the simulating halt decider at
> Ĥ.qx to a UTM at Ĵ.qx makes this cycle infinite.

No. I'll try to explain again if you can convince me you really want to
learn because otherwise it's just a tar pit of wasted effort.

>>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>
>>>> Do you know this means that you are claiming that Ĵ applied to ⟨Ĵ⟩
>>>> halts?
>>>
>>> I am not claiming that.
>> So why did you write Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn?
>
> Because that <is> the Ĥ code with the single adaptation of swapping
> the simulating halt decider at Ĥ.qx with a UTM at Ĵ.qx.

I don't think you even know that this does not answer my question. I
really have no idea what you think this notation means because you keep
using it and then denying or contradicting what you've said using it.

>> You wrote a
>> formal description of something that is impossible (qn is unreachable if
>> it exists at all) and which even if it were possible is not what Ĵ
>> applied to ⟨Ĵ⟩ does? No, you wrote something daft without thinking or
>> maybe without know what it meant.
>
> I wanted to make a single change to Ĥ so that I could show that the
> input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ really does specify an infinite cycle that
> must be aborted by its simulating halt decider. You seemed to be
> having an impossibly difficult time understanding this.

Yes, you wanted to do this but you are someone who does not understand
TMs, UTMs or the notation used to describe their behaviour. The result
is not at all what you wanted, but a pile of nonsense.

>>>> But since you brought up Linz's H, here's a question (get your avoidance
>>>> waffle ready!). What is Linz's H specified to do when applied to your
>>>> ⟨Ĥ⟩ ⟨Ĥ⟩? For clarity, let Linz's H be called L just for now. What goes
>>>> after the ⊢* here:
>>>
>>> I am breaking that analysis down to its simpler components.
>>
>> So you are not going to answer. OK, it was a lot to expect -- a direct
>> answer to a simple question.
>
> Do you think that the Linz H might possibly do what Linz specified or
> do you think that maybe I mean for it to go to the store and buy some
> groceries? It is a very disingenuous question.

No answer. More evasion. That anyone still reading sees you duck and
dive and do everything to avoid answering is probably the best I can
hope for. You either can't answer (because you don't understand the
question) or you can but you don't dare.

> Beside that I am freaking applying the Linz H to ⟨Ĵ⟩ ⟨Ĵ⟩, not ⟨Ĥ⟩ ⟨Ĥ⟩.

And there is agreement on L(⟨Ĵ⟩ ⟨Ĵ⟩). It's a done deal. It's L(⟨Ĥ⟩
⟨Ĥ⟩) you must work hard to avoid talking about because you don't want
give the right answer.

>>> We take the Linz Ĥ and change the simulating halt decider at Ĥ.qx to a
>>> UTM and rename this new machine Ĵ. The new machine has come dead code
>>> staes that are never reached.
>> That won't help you say what Linz's H specified to do when applied to
>> /your/ ⟨Ĥ⟩ ⟨Ĥ⟩. Note: to your ⟨Ĥ⟩ ⟨Ĥ⟩.
>
> The question is off-topic.
> I am only applying Ĥ to ⟨Ĥ⟩ or H to ⟨Ĵ⟩.

Evasion. "I don't like this trivial question so it's off topic". No it
is not. The answer is exactly why you are wrong about the halting
problem. This is probably why you a using every trick in the crank tool
box to avoid it. You'll be saying you've already answered it next!

>>>>> If you understand that the direct execution of Ĵ on input ⟨Ĵ⟩ is not
>>>>> computationally equivalent to simulating halt decider H applied to ⟨Ĵ⟩ ⟨Ĵ⟩
>>>>>
>>>>> then you should be able to understand that
>>>>>
>>>>> the direct execution of Ĥ on input ⟨Ĥ⟩ is not computationally
>>>>> equivalent to simulating halt decider at Ĥ.qx applied to ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>> That is beyond absurd. I leave it to you spot the silly error in your
>>>> reasoning (though you almost certainly won't be able to).
>>>
>>> My only "error" is that you very persistently and thus disrespectfully
>>> fail to bother to pay attention to my proof that this is correct.
>> I have never seen anything remotely resembling a proof from you. And
>> you reasoning above is absurd. It's absurd and it results in an
>> incorrect conclusion.
>
> The proofs are what the H/P code actually does and why it does this.

On 8/24/2021 7:35 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/24/2021 9:09 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/23/2021 10:09 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> I ignore dishonest dodges away from the point at hand.
>>>>>>> OK, let's do that:
>>>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
>>>>>>> is wrong. You wrote that immediately after a line showing that Ĥ
>>>>>>> applied to ⟨Ĥ⟩ halts. Everything since then has just been dodging this
>>>>>>> error.
>>>>>>>
>>>>>>>> When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
>>>>>>>> instead of a simulating halt decider then we can see that Ĵ applied to
>>>>>>>> ⟨Ĵ⟩ never halts.
>>>>>>> The details are mess, but basically, yes. Detail errors (that would get
>>>>>>> your paper rejected out of hand) available if you ask really nicely.
>>>>>>
>>>>>> Which details do you think are incorrect?
>>>>>
>>>>> A UTM is not a decider so the hat construction can't be applied to it.
>>>>> And if we make a "UTM-decider" (a TM that is a pure simulator except
>>>>> that is accepts those computations whose simulations terminate) we still
>>>>> can't apply the hat construction because it won't have a rejecting
>>>>> state. Thus your use of "exactly like Ĥ except..." is, at best,
>>>>> disingenuous. The differences must be greater than the "except..."
>>>>> clause suggests.
>>>>
>>>> My whole purpose was to simply show what happens when the simulating
>>>> halt decide at Ĥ.qx only simulates its input.
>>> I know, but you wanted to know what details you'd got wrong.
>>>
>>
>> If my plan was to swap the simulating halt decider at Ĥ.qx with a UTM
>> and then rename this machine to Ĵ and I did swap swap the simulating
>> halt decider at Ĥ.qx with a UTM and rename this machine to Ĵ then it
>> is a God damned lie that I got anything wrong.
>
> No. You won't get it unless you really try.
>
>>>> We can still have the same final states, except now that are
>>>> unreachable dead code.
>>> Except you show below this unreachable state being reached:
>>
>> No I do frigging not.
>
> Yes you did. I quoted you: Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn.
>
>> The code is still there but the infinite cycle
>> from Ĵ.qx to Ĵ.q0 prevents it from ever being reached.
>
> No. You are totally at sea. I did my best to explain but you'd have to
> want to learn to make any progress.
>
>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>> The TM at Ĵ.qx is your "UTM-decider" with an unreachable reject state.
>>> Do you see why I don't think you know what you are saying?
>>
>> The you imagine what I mean to say instead of examining what I
>> actually say is your mistake.
>>
>> This machine
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>
>> is transformed into this machine:
>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn // a machine stuck in
>> infinitely nested simulation
>
> You don't know what this notation means. I don't think I can help you
> with this.
>
>>>>>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>>>>>>> No, but that's just because you've never written a UTM so you don't know
>>>>>>> how such a TM would work. Ĵ applied to ⟨Ĵ⟩ is non-halting but there
>>>>>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>>>>>>
>>>>>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>>>>
>>>>>>> Eh? You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting.
>>> This needs to be addressed.
>>
>> That you don't believe that there is a cycle from Ĵ.qx to Ĵ.q0 is
>> flatly wrong.
>
> No, I'm right about that. But you are piling errors on errors now so
> responding is getting harder. What you are not responding to is the
> contraction. Even though there is no cycle from Ĵ.qx to Ĵ.q0, Ĵ applied
> to ⟨Ĵ⟩ is indeed non-halting you keep showing that it halts. Even if
> there were a cycle from Ĵ.qx to Ĵ.q0 you would still be contradicting
> yourself.
>

This is a static program, not a dynamic execution trace
Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn // a machine stuck in

That you seem to know very little about actual software development
causes you to confuse a static computer program with its dynamic
execution trace.

This is the dynamic execution trace of Ĵ applied to ⟨Ĵ⟩

Ĵ copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩
Ĵ.qx simulates ⟨Ĵ1⟩ with the ⟨Ĵ2⟩

Ĵ1 copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩
Ĵ2.qx simulates ⟨Ĵ2⟩ with the ⟨Ĵ3⟩
.... it never reaches any final state.

>> The design of Ĥ as a simulating halt decider stipulates that there is
>> a cycle from Ĥ.qx to Ĥ.q0. Changing the simulating halt decider at
>> Ĥ.qx to a UTM at Ĵ.qx makes this cycle infinite.
>
> No. I'll try to explain again if you can convince me you really want to
> learn because otherwise it's just a tar pit of wasted effort.
>

You can't even tell the difference between a static computer program and
the dynamic execution trace of this same program.

--
Copyright 2021 Pete Olcott

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

On 8/24/2021 9:06 PM, olcott wrote:
> On 8/24/2021 7:35 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/24/2021 9:09 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/23/2021 10:09 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> I ignore dishonest dodges away from the point at hand.
>>>>>>>> OK, let's do that:
>>>>>>>>       "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
>>>>>>>> is wrong.  You wrote that immediately after a line showing that Ĥ
>>>>>>>> applied to ⟨Ĥ⟩ halts.  Everything since then has just been
>>>>>>>> dodging this
>>>>>>>> error.
>>>>>>>>
>>>>>>>>> When we define Ĵ to be exactly like Ĥ except that it has a UTM
>>>>>>>>> at Ĵ.qx
>>>>>>>>> instead of a simulating halt decider then we can see that Ĵ
>>>>>>>>> applied to
>>>>>>>>> ⟨Ĵ⟩ never halts.
>>>>>>>> The details are mess, but basically, yes.  Detail errors (that
>>>>>>>> would get
>>>>>>>> your paper rejected out of hand) available if you ask really
>>>>>>>> nicely.
>>>>>>>
>>>>>>> Which details do you think are incorrect?
>>>>>>
>>>>>> A UTM is not a decider so the hat construction can't be applied to
>>>>>> it.
>>>>>> And if we make a "UTM-decider" (a TM that is a pure simulator except
>>>>>> that is accepts those computations whose simulations terminate) we
>>>>>> still
>>>>>> can't apply the hat construction because it won't have a rejecting
>>>>>> state.  Thus your use of "exactly like Ĥ except..." is, at best,
>>>>>> disingenuous.  The differences must be greater than the "except..."
>>>>>> clause suggests.
>>>>>
>>>>> My whole purpose was to simply show what happens when the simulating
>>>>> halt decide at Ĥ.qx only simulates its input.
>>>> I know, but you wanted to know what details you'd got wrong.
>>>>
>>>
>>> If my plan was to swap the simulating halt decider at Ĥ.qx with a UTM
>>> and then rename this machine to Ĵ and I did swap swap the simulating
>>> halt decider at Ĥ.qx with a UTM and rename this machine to Ĵ then it
>>> is a God damned lie that I got anything wrong.
>>
>> No.  You won't get it unless you really try.
>>
>>>>> We can still have the same final states, except now that are
>>>>> unreachable dead code.
>>>> Except you show below this unreachable state being reached:
>>>
>>> No I do frigging not.
>>
>> Yes you did.  I quoted you: Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn.
>>
>>> The code is still there but the infinite cycle
>>> from Ĵ.qx to Ĵ.q0 prevents it from ever being reached.
>>
>> No.  You are totally at sea.  I did my best to explain but you'd have to
>> want to learn to make any progress.
>>
>>>>     Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>> The TM at Ĵ.qx is your "UTM-decider" with an unreachable reject state.
>>>> Do you see why I don't think you know what you are saying?
>>>
>>> The you imagine what I mean to say instead of examining what I
>>> actually say is your mistake.
>>>
>>> This machine
>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>
>>> is transformed into this machine:
>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn // a machine stuck in
>>> infinitely nested simulation
>>
>> You don't know what this notation means.  I don't think I can help you
>> with this.
>>
>>>>>>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>>>>>>>> No, but that's just because you've never written a UTM so you
>>>>>>>> don't know
>>>>>>>> how such a TM would work.  Ĵ applied to ⟨Ĵ⟩ is non-halting but
>>>>>>>> there
>>>>>>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>>>>>>>
>>>>>>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>>>>>
>>>>>>>> Eh?  You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting.
>>>> This needs to be addressed.
>>>
>>> That you don't believe that there is a cycle from Ĵ.qx to Ĵ.q0 is
>>> flatly wrong.
>>
>> No, I'm right about that.  But you are piling errors on errors now so
>> responding is getting harder.  What you are not responding to is the
>> contraction.  Even though there is no cycle from Ĵ.qx to Ĵ.q0, Ĵ applied
>> to ⟨Ĵ⟩ is indeed non-halting you keep showing that it halts.  Even if
>> there were a cycle from Ĵ.qx to Ĵ.q0 you would still be contradicting
>> yourself.
>>
>
> This is a static program, not a dynamic execution trace
> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn // a machine stuck in
>
> That you seem to know very little about actual software development
> causes you to confuse a static computer program with its dynamic
> execution trace.
>
> This is the dynamic execution trace of Ĵ applied to ⟨Ĵ⟩
>
> Ĵ copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩
> Ĵ.qx simulates ⟨Ĵ1⟩ with the ⟨Ĵ2⟩
>
> Ĵ1 copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩
> Ĵ2.qx simulates ⟨Ĵ2⟩ with the ⟨Ĵ3⟩
> ... it never reaches any final state.
>
>>> The design of Ĥ as a simulating halt decider stipulates that there is
>>> a cycle from Ĥ.qx to Ĥ.q0. Changing the simulating halt decider at
>>> Ĥ.qx to a UTM at Ĵ.qx makes this cycle infinite.
>>
>> No.  I'll try to explain again if you can convince me you really want to
>> learn because otherwise it's just a tar pit of wasted effort.
>>
>
> You can't even tell the difference between a static computer program and
> the dynamic execution trace of this same program.

// a machine stuck in infinitely nested simulation
Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn

Here is what I was saying to someone that is not clueless about actual
software development.

int Simulate(u32 P, u32 I)
{ ((int(*)(int))P)(I);
return 1;
}

void J(u32 x)
{ Simulate(x, x);
OutputString("J stopped running");
}

int main()
{ J((u32)J);
}

_Simulate()
[00000e86](01) 55 push ebp
[00000e87](02) 8bec mov ebp,esp
[00000e89](03) 8b450c mov eax,[ebp+0c]
[00000e8c](01) 50 push eax
[00000e8d](03) ff5508 call dword [ebp+08]
[00000e90](03) 83c404 add esp,+04
[00000e93](05) b801000000 mov eax,00000001
[00000e98](01) 5d pop ebp
[00000e99](01) c3 ret
Size in bytes:(0020) [00000e99]

_Y()
[00000ea6](01) 55 push ebp
[00000ea7](02) 8bec mov ebp,esp
[00000ea9](03) 8b4508 mov eax,[ebp+08]
[00000eac](01) 50 push eax
[00000ead](03) 8b4d08 mov ecx,[ebp+08]
[00000eb0](01) 51 push ecx
[00000eb1](05) e8d0ffffff call 00000e86
[00000eb6](03) 83c408 add esp,+08
[00000eb9](05) 6823030000 push 00000323
[00000ebe](05) e893f4ffff call 00000356
[00000ec3](03) 83c404 add esp,+04
[00000ec6](01) 5d pop ebp
[00000ec7](01) c3 ret
Size in bytes:(0034) [00000ec7]

_main()
[00000ed6](01) 55 push ebp
[00000ed7](02) 8bec mov ebp,esp
[00000ed9](05) 68a60e0000 push 00000ea6
[00000ede](05) e8c3ffffff call 00000ea6
[00000ee3](03) 83c404 add esp,+04
[00000ee6](05) 68660e0000 push 00000e66
[00000eeb](05) 68660e0000 push 00000e66
[00000ef0](05) e831fcffff call 00000b26
[00000ef5](03) 83c408 add esp,+08
[00000ef8](01) 50 push eax
[00000ef9](05) 6837030000 push 00000337
[00000efe](05) e863f4ffff call 00000366
[00000f03](03) 83c408 add esp,+08
[00000f06](02) 33c0 xor eax,eax
[00000f08](01) 5d pop ebp
[00000f09](01) c3 ret
Size in bytes:(0052) [00000f09]

On 8/24/2021 7:35 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/24/2021 9:09 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/23/2021 10:09 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> I ignore dishonest dodges away from the point at hand.
>>>>>>> OK, let's do that:
>>>>>>> "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
>>>>>>> is wrong. You wrote that immediately after a line showing that Ĥ
>>>>>>> applied to ⟨Ĥ⟩ halts. Everything since then has just been dodging this
>>>>>>> error.
>>>>>>>
>>>>>>>> When we define Ĵ to be exactly like Ĥ except that it has a UTM at Ĵ.qx
>>>>>>>> instead of a simulating halt decider then we can see that Ĵ applied to
>>>>>>>> ⟨Ĵ⟩ never halts.
>>>>>>> The details are mess, but basically, yes. Detail errors (that would get
>>>>>>> your paper rejected out of hand) available if you ask really nicely.
>>>>>>
>>>>>> Which details do you think are incorrect?
>>>>>
>>>>> A UTM is not a decider so the hat construction can't be applied to it.
>>>>> And if we make a "UTM-decider" (a TM that is a pure simulator except
>>>>> that is accepts those computations whose simulations terminate) we still
>>>>> can't apply the hat construction because it won't have a rejecting
>>>>> state. Thus your use of "exactly like Ĥ except..." is, at best,
>>>>> disingenuous. The differences must be greater than the "except..."
>>>>> clause suggests.
>>>>
>>>> My whole purpose was to simply show what happens when the simulating
>>>> halt decide at Ĥ.qx only simulates its input.
>>> I know, but you wanted to know what details you'd got wrong.
>>>
>>
>> If my plan was to swap the simulating halt decider at Ĥ.qx with a UTM
>> and then rename this machine to Ĵ and I did swap swap the simulating
>> halt decider at Ĥ.qx with a UTM and rename this machine to Ĵ then it
>> is a God damned lie that I got anything wrong.
>
> No. You won't get it unless you really try.
>
>>>> We can still have the same final states, except now that are
>>>> unreachable dead code.
>>> Except you show below this unreachable state being reached:
>>
>> No I do frigging not.
>
> Yes you did. I quoted you: Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn.
>
>> The code is still there but the infinite cycle
>> from Ĵ.qx to Ĵ.q0 prevents it from ever being reached.
>
> No. You are totally at sea. I did my best to explain but you'd have to
> want to learn to make any progress.
>
>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>> The TM at Ĵ.qx is your "UTM-decider" with an unreachable reject state.
>>> Do you see why I don't think you know what you are saying?
>>
>> The you imagine what I mean to say instead of examining what I
>> actually say is your mistake.
>>
>> This machine
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>
>> is transformed into this machine:
>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn // a machine stuck in
>> infinitely nested simulation
>
> You don't know what this notation means. I don't think I can help you
> with this.
>
>>>>>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>>>>>>> No, but that's just because you've never written a UTM so you don't know
>>>>>>> how such a TM would work. Ĵ applied to ⟨Ĵ⟩ is non-halting but there
>>>>>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>>>>>>
>>>>>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>>>>
>>>>>>> Eh? You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting.
>>> This needs to be addressed.
>>
>> That you don't believe that there is a cycle from Ĵ.qx to Ĵ.q0 is
>> flatly wrong.
>
> No, I'm right about that.

Try and exaplain how you are right about that.

> But you are piling errors on errors now so
> responding is getting harder. What you are not responding to is the
> contraction. Even though there is no cycle from Ĵ.qx to Ĵ.q0, Ĵ applied
> to ⟨Ĵ⟩ is indeed non-halting you keep showing that it halts. Even if
> there were a cycle from Ĵ.qx to Ĵ.q0 you would still be contradicting
> yourself.

--
Copyright 2021 Pete Olcott

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

On 8/24/21 11:17 PM, olcott wrote:
> On 8/24/2021 9:06 PM, olcott wrote:
>> On 8/24/2021 7:35 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/24/2021 9:09 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/23/2021 10:09 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> I ignore dishonest dodges away from the point at hand.
>>>>>>>>> OK, let's do that:
>>>>>>>>>       "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
>>>>>>>>> is wrong.  You wrote that immediately after a line showing that Ĥ
>>>>>>>>> applied to ⟨Ĥ⟩ halts.  Everything since then has just been
>>>>>>>>> dodging this
>>>>>>>>> error.
>>>>>>>>>
>>>>>>>>>> When we define Ĵ to be exactly like Ĥ except that it has a UTM
>>>>>>>>>> at Ĵ.qx
>>>>>>>>>> instead of a simulating halt decider then we can see that Ĵ
>>>>>>>>>> applied to
>>>>>>>>>> ⟨Ĵ⟩ never halts.
>>>>>>>>> The details are mess, but basically, yes.  Detail errors (that
>>>>>>>>> would get
>>>>>>>>> your paper rejected out of hand) available if you ask really
>>>>>>>>> nicely.
>>>>>>>>
>>>>>>>> Which details do you think are incorrect?
>>>>>>>
>>>>>>> A UTM is not a decider so the hat construction can't be applied
>>>>>>> to it.
>>>>>>> And if we make a "UTM-decider" (a TM that is a pure simulator except
>>>>>>> that is accepts those computations whose simulations terminate)
>>>>>>> we still
>>>>>>> can't apply the hat construction because it won't have a rejecting
>>>>>>> state.  Thus your use of "exactly like Ĥ except..." is, at best,
>>>>>>> disingenuous.  The differences must be greater than the "except..."
>>>>>>> clause suggests.
>>>>>>
>>>>>> My whole purpose was to simply show what happens when the simulating
>>>>>> halt decide at Ĥ.qx only simulates its input.
>>>>> I know, but you wanted to know what details you'd got wrong.
>>>>>
>>>>
>>>> If my plan was to swap the simulating halt decider at Ĥ.qx with a UTM
>>>> and then rename this machine to Ĵ and I did swap swap the simulating
>>>> halt decider at Ĥ.qx with a UTM and rename this machine to Ĵ then it
>>>> is a God damned lie that I got anything wrong.
>>>
>>> No.  You won't get it unless you really try.
>>>
>>>>>> We can still have the same final states, except now that are
>>>>>> unreachable dead code.
>>>>> Except you show below this unreachable state being reached:
>>>>
>>>> No I do frigging not.
>>>
>>> Yes you did.  I quoted you: Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn.
>>>
>>>> The code is still there but the infinite cycle
>>>> from Ĵ.qx to Ĵ.q0 prevents it from ever being reached.
>>>
>>> No.  You are totally at sea.  I did my best to explain but you'd have to
>>> want to learn to make any progress.
>>>
>>>>>     Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>> The TM at Ĵ.qx is your "UTM-decider" with an unreachable reject state.
>>>>> Do you see why I don't think you know what you are saying?
>>>>
>>>> The you imagine what I mean to say instead of examining what I
>>>> actually say is your mistake.
>>>>
>>>> This machine
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>
>>>> is transformed into this machine:
>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn // a machine stuck in
>>>> infinitely nested simulation
>>>
>>> You don't know what this notation means.  I don't think I can help you
>>> with this.
>>>
>>>>>>>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>>>>>>>>> No, but that's just because you've never written a UTM so you
>>>>>>>>> don't know
>>>>>>>>> how such a TM would work.  Ĵ applied to ⟨Ĵ⟩ is non-halting but
>>>>>>>>> there
>>>>>>>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>>>>>>>>
>>>>>>>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>>>>>>
>>>>>>>>> Eh?  You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting.
>>>>> This needs to be addressed.
>>>>
>>>> That you don't believe that there is a cycle from Ĵ.qx to Ĵ.q0 is
>>>> flatly wrong.
>>>
>>> No, I'm right about that.  But you are piling errors on errors now so
>>> responding is getting harder.  What you are not responding to is the
>>> contraction.  Even though there is no cycle from Ĵ.qx to Ĵ.q0, Ĵ applied
>>> to ⟨Ĵ⟩ is indeed non-halting you keep showing that it halts.  Even if
>>> there were a cycle from Ĵ.qx to Ĵ.q0 you would still be contradicting
>>> yourself.
>>>
>>
>> This is a static program, not a dynamic execution trace
>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn // a machine stuck in
>>
>> That you seem to know very little about actual software development
>> causes you to confuse a static computer program with its dynamic
>> execution trace.
>>
>> This is the dynamic execution trace of Ĵ applied to ⟨Ĵ⟩
>>
>> Ĵ copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩
>> Ĵ.qx simulates ⟨Ĵ1⟩ with the ⟨Ĵ2⟩
>>
>> Ĵ1 copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩
>> Ĵ2.qx simulates ⟨Ĵ2⟩ with the ⟨Ĵ3⟩
>> ... it never reaches any final state.
>>
>>>> The design of Ĥ as a simulating halt decider stipulates that there is
>>>> a cycle from Ĥ.qx to Ĥ.q0. Changing the simulating halt decider at
>>>> Ĥ.qx to a UTM at Ĵ.qx makes this cycle infinite.
>>>
>>> No.  I'll try to explain again if you can convince me you really want to
>>> learn because otherwise it's just a tar pit of wasted effort.
>>>
>>
>> You can't even tell the difference between a static computer program
>> and the dynamic execution trace of this same program.
>
> // a machine stuck in infinitely nested simulation
> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>
> Here is what I was saying to someone that is not clueless about actual
> software development.
>

And where does this code have a path that it goes to a halting state
when the machine it is simulating is non-halting.

THAT is what you are implying with ⊢* Ĵ.qn

THAT doesn't exist, so your line is incorrect.

No, maybe you are doing your normal crazy thing and J.qn is the state
that J goes to when the machine it is simulating actually halts.

if so, maybe that is your problem, you have non-halting and halting
confused in your mind.

> int Simulate(u32 P, u32 I)
> {
>   ((int(*)(int))P)(I);
>   return 1;
> }
>
> void J(u32 x)
> {
>   Simulate(x, x);
>   OutputString("J stopped running");
> }
>
>
> int main()
> {
>   J((u32)J);
> }
>
> _Simulate()
> [00000e86](01)  55          push ebp
> [00000e87](02)  8bec        mov ebp,esp
> [00000e89](03)  8b450c      mov eax,[ebp+0c]
> [00000e8c](01)  50          push eax
> [00000e8d](03)  ff5508      call dword [ebp+08]
> [00000e90](03)  83c404      add esp,+04
> [00000e93](05)  b801000000  mov eax,00000001
> [00000e98](01)  5d          pop ebp
> [00000e99](01)  c3          ret
> Size in bytes:(0020) [00000e99]
>
> _Y()
> [00000ea6](01)  55          push ebp
> [00000ea7](02)  8bec        mov ebp,esp
> [00000ea9](03)  8b4508      mov eax,[ebp+08]
> [00000eac](01)  50          push eax
> [00000ead](03)  8b4d08      mov ecx,[ebp+08]
> [00000eb0](01)  51          push ecx
> [00000eb1](05)  e8d0ffffff  call 00000e86
> [00000eb6](03)  83c408      add esp,+08
> [00000eb9](05)  6823030000  push 00000323
> [00000ebe](05)  e893f4ffff  call 00000356
> [00000ec3](03)  83c404      add esp,+04
> [00000ec6](01)  5d          pop ebp
> [00000ec7](01)  c3          ret
> Size in bytes:(0034) [00000ec7]
>
> _main()
> [00000ed6](01)  55          push ebp
> [00000ed7](02)  8bec        mov ebp,esp
> [00000ed9](05)  68a60e0000  push 00000ea6
> [00000ede](05)  e8c3ffffff  call 00000ea6
> [00000ee3](03)  83c404      add esp,+04
> [00000ee6](05)  68660e0000  push 00000e66
> [00000eeb](05)  68660e0000  push 00000e66
> [00000ef0](05)  e831fcffff  call 00000b26
> [00000ef5](03)  83c408      add esp,+08
> [00000ef8](01)  50          push eax
> [00000ef9](05)  6837030000  push 00000337
> [00000efe](05)  e863f4ffff  call 00000366
> [00000f03](03)  83c408      add esp,+08
> [00000f06](02)  33c0        xor eax,eax
> [00000f08](01)  5d          pop ebp
> [00000f09](01)  c3          ret
> Size in bytes:(0052) [00000f09]
>
>     machine   stack     stack     machine     assembly
>     address   address   data      code        language
>     ========  ========  ========  =========   =============
> ...[00000ed6][00101b78][00000000] 55          push ebp
> ...[00000ed7][00101b78][00000000] 8bec        mov ebp,esp
> ...[00000ed9][00101b74][00000ea6] 68a60e0000  push 00000ea6
> ...[00000ede][00101b70][00000ee3] e8c3ffffff  call 00000ea6
> ...[00000ea6][00101b6c][00101b78] 55          push ebp
> ...[00000ea7][00101b6c][00101b78] 8bec        mov ebp,esp
> ...[00000ea9][00101b6c][00101b78] 8b4508      mov eax,[ebp+08]
> ...[00000eac][00101b68][00000ea6] 50          push eax
> ...[00000ead][00101b68][00000ea6] 8b4d08      mov ecx,[ebp+08]
> ...[00000eb0][00101b64][00000ea6] 51          push ecx
> ...[00000eb1][00101b60][00000eb6] e8d0ffffff  call 00000e86
> ...[00000e86][00101b5c][00101b6c] 55          push ebp
> ...[00000e87][00101b5c][00101b6c] 8bec        mov ebp,esp
> ...[00000e89][00101b5c][00101b6c] 8b450c      mov eax,[ebp+0c]
> ...[00000e8c][00101b58][00000ea6] 50          push eax
> Calling:_J()
> ...[00000e8d][00101b54][00000e90] ff5508      call dword [ebp+08]
> ...[00000ea6][00101b50][00101b5c] 55          push ebp
> ...[00000ea7][00101b50][00101b5c] 8bec        mov ebp,esp
> ...[00000ea9][00101b50][00101b5c] 8b4508      mov eax,[ebp+08]
> ...[00000eac][00101b4c][00000ea6] 50          push eax
> ...[00000ead][00101b4c][00000ea6] 8b4d08      mov ecx,[ebp+08]
> ...[00000eb0][00101b48][00000ea6] 51          push ecx
> ...[00000eb1][00101b44][00000eb6] e8d0ffffff  call 00000e86
> ...[00000e86][00101b40][00101b50] 55          push ebp
> ...[00000e87][00101b40][00101b50] 8bec        mov ebp,esp
> ...[00000e89][00101b40][00101b50] 8b450c      mov eax,[ebp+0c]
> ...[00000e8c][00101b3c][00000ea6] 50          push eax
> Calling:_J()
> ...[00000e8d][00101b38][00000e90] ff5508      call dword [ebp+08]
> ...[00000ea6][00101b34][00101b40] 55          push ebp
> ...[00000ea7][00101b34][00101b40] 8bec        mov ebp,esp
> ...[00000ea9][00101b34][00101b40] 8b4508      mov eax,[ebp+08]
> ...[00000eac][00101b30][00000ea6] 50          push eax
> ...[00000ead][00101b30][00000ea6] 8b4d08      mov ecx,[ebp+08]
> ...[00000eb0][00101b2c][00000ea6] 51          push ecx
> ...[00000eb1][00101b28][00000eb6] e8d0ffffff  call 00000e86
> ...[00000e86][00101b24][00101b34] 55          push ebp
> ...[00000e87][00101b24][00101b34] 8bec        mov ebp,esp
> ...[00000e89][00101b24][00101b34] 8b450c      mov eax,[ebp+0c]
> ...[00000e8c][00101b20][00000ea6] 50          push eax
> Calling:_J()
> ...[00000e8d][00101b1c][00000e90] ff5508      call dword [ebp+08]
> ...[00000ea6][00101b18][00101b24] 55          push ebp
> ...[00000ea7][00101b18][00101b24] 8bec        mov ebp,esp
> ...[00000ea9][00101b18][00101b24] 8b4508      mov eax,[ebp+08]
> ...[00000eac][00101b14][00000ea6] 50          push eax
> ...[00000ead][00101b14][00000ea6] 8b4d08      mov ecx,[ebp+08]
> ...[00000eb0][00101b10][00000ea6] 51          push ecx
> ...[00000eb1][00101b0c][00000eb6] e8d0ffffff  call 00000e86
> ...[00000e86][00101b08][00101b18] 55          push ebp
> ...[00000e87][00101b08][00101b18] 8bec        mov ebp,esp
> ...[00000e89][00101b08][00101b18] 8b450c      mov eax,[ebp+0c]
> ...[00000e8c][00101b04][00000ea6] 50          push eax
> Calling:_J() ...
>
>
>

On 8/24/21 11:53 PM, olcott wrote:
> On 8/24/2021 7:35 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/24/2021 9:09 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/23/2021 10:09 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> I ignore dishonest dodges away from the point at hand.
>>>>>>>> OK, let's do that:
>>>>>>>>       "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
>>>>>>>> is wrong.  You wrote that immediately after a line showing that Ĥ
>>>>>>>> applied to ⟨Ĥ⟩ halts.  Everything since then has just been
>>>>>>>> dodging this
>>>>>>>> error.
>>>>>>>>
>>>>>>>>> When we define Ĵ to be exactly like Ĥ except that it has a UTM
>>>>>>>>> at Ĵ.qx
>>>>>>>>> instead of a simulating halt decider then we can see that Ĵ
>>>>>>>>> applied to
>>>>>>>>> ⟨Ĵ⟩ never halts.
>>>>>>>> The details are mess, but basically, yes.  Detail errors (that
>>>>>>>> would get
>>>>>>>> your paper rejected out of hand) available if you ask really
>>>>>>>> nicely.
>>>>>>>
>>>>>>> Which details do you think are incorrect?
>>>>>>
>>>>>> A UTM is not a decider so the hat construction can't be applied to
>>>>>> it.
>>>>>> And if we make a "UTM-decider" (a TM that is a pure simulator except
>>>>>> that is accepts those computations whose simulations terminate) we
>>>>>> still
>>>>>> can't apply the hat construction because it won't have a rejecting
>>>>>> state.  Thus your use of "exactly like Ĥ except..." is, at best,
>>>>>> disingenuous.  The differences must be greater than the "except..."
>>>>>> clause suggests.
>>>>>
>>>>> My whole purpose was to simply show what happens when the simulating
>>>>> halt decide at Ĥ.qx only simulates its input.
>>>> I know, but you wanted to know what details you'd got wrong.
>>>>
>>>
>>> If my plan was to swap the simulating halt decider at Ĥ.qx with a UTM
>>> and then rename this machine to Ĵ and I did swap swap the simulating
>>> halt decider at Ĥ.qx with a UTM and rename this machine to Ĵ then it
>>> is a God damned lie that I got anything wrong.
>>
>> No.  You won't get it unless you really try.
>>
>>>>> We can still have the same final states, except now that are
>>>>> unreachable dead code.
>>>> Except you show below this unreachable state being reached:
>>>
>>> No I do frigging not.
>>
>> Yes you did.  I quoted you: Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn.
>>
>>> The code is still there but the infinite cycle
>>> from Ĵ.qx to Ĵ.q0 prevents it from ever being reached.
>>
>> No.  You are totally at sea.  I did my best to explain but you'd have to
>> want to learn to make any progress.
>>
>>>>     Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>> The TM at Ĵ.qx is your "UTM-decider" with an unreachable reject state.
>>>> Do you see why I don't think you know what you are saying?
>>>
>>> The you imagine what I mean to say instead of examining what I
>>> actually say is your mistake.
>>>
>>> This machine
>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>
>>> is transformed into this machine:
>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn // a machine stuck in
>>> infinitely nested simulation
>>
>> You don't know what this notation means.  I don't think I can help you
>> with this.
>>
>>>>>>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>>>>>>>> No, but that's just because you've never written a UTM so you
>>>>>>>> don't know
>>>>>>>> how such a TM would work.  Ĵ applied to ⟨Ĵ⟩ is non-halting but
>>>>>>>> there
>>>>>>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>>>>>>>
>>>>>>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>>>>>
>>>>>>>> Eh?  You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting.
>>>> This needs to be addressed.
>>>
>>> That you don't believe that there is a cycle from Ĵ.qx to Ĵ.q0 is
>>> flatly wrong.
>>
>> No, I'm right about that. 
>
> Try and exaplain how you are right about that.

The fact that the code for J (or P) has absolutely no path to go from
the state qx to the state q0 OF THE SAME EXECUTION (which is what the
diagram is showing).

Yes, there is a 'virtual' connection from qx of one invocation to a q0
of a simulated embedded invocation, but that state is NOT the outer q0.

Turing Machine P or J NEVER go back to their own q0 state.

You could perhaps say we have a nesting of

P0.q0 -> P0.qx -> P1.q0 -> P1.qx ...

But that is a NESTING, not a LOOP.

They are different.

>
>
>> But you are piling errors on errors now so
>> responding is getting harder.  What you are not responding to is the
>> contraction.  Even though there is no cycle from Ĵ.qx to Ĵ.q0, Ĵ applied
>> to ⟨Ĵ⟩ is indeed non-halting you keep showing that it halts.  Even if
>> there were a cycle from Ĵ.qx to Ĵ.q0 you would still be contradicting
>> yourself.
>

On 8/25/2021 7:19 AM, Richard Damon wrote:
> On 8/24/21 11:53 PM, olcott wrote:
>> On 8/24/2021 7:35 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/24/2021 9:09 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/23/2021 10:09 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 8/23/2021 2:30 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> I ignore dishonest dodges away from the point at hand.
>>>>>>>>> OK, let's do that:
>>>>>>>>>       "⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation"
>>>>>>>>> is wrong.  You wrote that immediately after a line showing that Ĥ
>>>>>>>>> applied to ⟨Ĥ⟩ halts.  Everything since then has just been
>>>>>>>>> dodging this
>>>>>>>>> error.
>>>>>>>>>
>>>>>>>>>> When we define Ĵ to be exactly like Ĥ except that it has a UTM
>>>>>>>>>> at Ĵ.qx
>>>>>>>>>> instead of a simulating halt decider then we can see that Ĵ
>>>>>>>>>> applied to
>>>>>>>>>> ⟨Ĵ⟩ never halts.
>>>>>>>>> The details are mess, but basically, yes.  Detail errors (that
>>>>>>>>> would get
>>>>>>>>> your paper rejected out of hand) available if you ask really
>>>>>>>>> nicely.
>>>>>>>>
>>>>>>>> Which details do you think are incorrect?
>>>>>>>
>>>>>>> A UTM is not a decider so the hat construction can't be applied to
>>>>>>> it.
>>>>>>> And if we make a "UTM-decider" (a TM that is a pure simulator except
>>>>>>> that is accepts those computations whose simulations terminate) we
>>>>>>> still
>>>>>>> can't apply the hat construction because it won't have a rejecting
>>>>>>> state.  Thus your use of "exactly like Ĥ except..." is, at best,
>>>>>>> disingenuous.  The differences must be greater than the "except..."
>>>>>>> clause suggests.
>>>>>>
>>>>>> My whole purpose was to simply show what happens when the simulating
>>>>>> halt decide at Ĥ.qx only simulates its input.
>>>>> I know, but you wanted to know what details you'd got wrong.
>>>>>
>>>>
>>>> If my plan was to swap the simulating halt decider at Ĥ.qx with a UTM
>>>> and then rename this machine to Ĵ and I did swap swap the simulating
>>>> halt decider at Ĥ.qx with a UTM and rename this machine to Ĵ then it
>>>> is a God damned lie that I got anything wrong.
>>>
>>> No.  You won't get it unless you really try.
>>>
>>>>>> We can still have the same final states, except now that are
>>>>>> unreachable dead code.
>>>>> Except you show below this unreachable state being reached:
>>>>
>>>> No I do frigging not.
>>>
>>> Yes you did.  I quoted you: Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn.
>>>
>>>> The code is still there but the infinite cycle
>>>> from Ĵ.qx to Ĵ.q0 prevents it from ever being reached.
>>>
>>> No.  You are totally at sea.  I did my best to explain but you'd have to
>>> want to learn to make any progress.
>>>
>>>>>     Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>> The TM at Ĵ.qx is your "UTM-decider" with an unreachable reject state.
>>>>> Do you see why I don't think you know what you are saying?
>>>>
>>>> The you imagine what I mean to say instead of examining what I
>>>> actually say is your mistake.
>>>>
>>>> This machine
>>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>>
>>>> is transformed into this machine:
>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn // a machine stuck in
>>>> infinitely nested simulation
>>>
>>> You don't know what this notation means.  I don't think I can help you
>>> with this.
>>>
>>>>>>>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>>>>>>>>> No, but that's just because you've never written a UTM so you
>>>>>>>>> don't know
>>>>>>>>> how such a TM would work.  Ĵ applied to ⟨Ĵ⟩ is non-halting but
>>>>>>>>> there
>>>>>>>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>>>>>>>>
>>>>>>>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>>>>>>
>>>>>>>>> Eh?  You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting.
>>>>> This needs to be addressed.
>>>>
>>>> That you don't believe that there is a cycle from Ĵ.qx to Ĵ.q0 is
>>>> flatly wrong.
>>>
>>> No, I'm right about that.
>>
>> Try and exaplain how you are right about that.
>
> The fact that the code for J (or P) has absolutely no path to go from
> the state qx to the state q0 OF THE SAME EXECUTION (which is what the
> diagram is showing).
>
> Yes, there is a 'virtual' connection from qx of one invocation to a q0
> of a simulated embedded invocation, but that state is NOT the outer q0.
>
> Turing Machine P or J NEVER go back to their own q0 state.
>
> You could perhaps say we have a nesting of
>
> P0.q0 -> P0.qx -> P1.q0 -> P1.qx ...
>
> But that is a NESTING, not a LOOP.
>
> They are different.

None-the-less we have infinitely nested simulation that would never halt
unless the simulating halt decider aborts its simulation of its input.

This conclusively proves that the simulating halt decider at Ĥ.qx ⟨Ĥ1⟩
⟨Ĥ2⟩ must abort the simulation of this input which conclusively proves
that this input never halts.

>
>>
>>
>>> But you are piling errors on errors now so
>>> responding is getting harder.  What you are not responding to is the
>>> contraction.  Even though there is no cycle from Ĵ.qx to Ĵ.q0, Ĵ applied
>>> to ⟨Ĵ⟩ is indeed non-halting you keep showing that it halts.  Even if
>>> there were a cycle from Ĵ.qx to Ĵ.q0 you would still be contradicting
>>> yourself.
>>
>

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 8/24/2021 7:35 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/24/2021 9:09 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/23/2021 10:09 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:

>>>>>>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>>>>>>>>
>>>>>>>> No, but that's just because you've never written a UTM so you don't know
>>>>>>>> how such a TM would work. Ĵ applied to ⟨Ĵ⟩ is non-halting but there
>>>>>>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>>>>>>>
>>>>>>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>>>>>
>>>>>>>> Eh? You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting.
>>>>
>>>> This needs to be addressed.
>>>
>>> That you don't believe that there is a cycle from Ĵ.qx to Ĵ.q0 is
>>> flatly wrong.
>>
>> No, I'm right about that.
>
> Try and exaplain how you are right about that.

It follows directly from the "hat" construction. The TM "at" Ĵ.qx is
(in effect) J. None of entries in J's state transition function can
refer to state Ĵ.q0 because that is a new stated added (along with a few
others) with the sole purpose of doing the copy of the input. There is
simply no path from Ĵ.qx to Ĵ.q0.

And, similarly, since J is a UTM with only an accepting state (qy) the
line you keep writing

Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn

is bogus. You can add states to a TM at will, so J or Ĵ can be
(pointlessly) given a rejecting state qn, but there can't be any
configuration sequences that end in it.

And the line is bogus for another reason. You are correct that Ĵ
applied to ⟨Ĵ⟩ is non-halting (thought not because of the cycle you
imagine was there) and this line directly contradicts that fact. You
need to write

Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* ∞

or, if you don't need to show the one and only literal string copying
step, just Ĵ.q0 ⟨Ĵ⟩ ⊢* ∞.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> // a machine stuck in infinitely nested simulation
> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn

There are too may errors in your recent posts to track them all now, and
you are not responding to my questions that were intended to show up the
problems in what you claim (which it probably exactly why you don't
answer them) so I am going to reset this discussion of Turning machine
halting.

> Here is what I was saying to someone that is not clueless about actual
> software development.

And here, for anyone not clueless about actual Turing machines, is why
you are wrong about the perfectly valid halting theorem.

The halting problem is about the existence of a TM that accept those
string pairs (and only those string pairs) that encode halting
computations. All other strings are to be rejected. The halting
theorem states that no TM is a such a decider -- every TM fails to
correctly classify at least one string pair.

You claim to have a TM, unfortunately called H, which is a halt decider.
(Yes, you sometimes deny it is a general halt decider but you keep
quoting me saying your algorithm is one, so I presume you agree that it
must be one.)

You tell us, again and again, that the computation of Ĥ applied to the
encoding of Ĥ (written ⟨Ĥ⟩) is a halting computation. You are quick to
jump in and say that it "only halts because... reason", but it's a
halting computation whatever the reason.

That halting computation is encoded as the string pair ⟨Ĥ⟩ ⟨Ĥ⟩. (I
prefer a notation that makes the pairing of an encoded TM and some input
explicit, but that boat sailed years ago.)

You also tell is that H rejects the string pair ⟨Ĥ⟩ ⟨Ĥ⟩. I.e. you tell
us everything we need to know to be sure that H is wrong about at least
this one halting problem instance.

The only fact you have not explicitly endorsed is the fact that the
computation of Ĥ applied to ⟨Ĥ⟩ is encoded as the string pair ⟨Ĥ⟩ ⟨Ĥ⟩
but you can't dodge that fact -- it's part of the definition of the
halting problem and defined by the "hat" construction. If the encoding
of Ĥ applied to ⟨Ĥ⟩ is not string pair ⟨Ĥ⟩ ⟨Ĥ⟩, then you are using the
wrong "hat" construction for the chosen encoding.

--
Ben.

On 8/25/2021 10:19 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/24/2021 7:35 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/24/2021 9:09 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 8/23/2021 10:09 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>
>>>>>>>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>>>>>>>>>
>>>>>>>>> No, but that's just because you've never written a UTM so you don't know
>>>>>>>>> how such a TM would work. Ĵ applied to ⟨Ĵ⟩ is non-halting but there
>>>>>>>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>>>>>>>>
>>>>>>>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>>>>>>
>>>>>>>>> Eh? You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting.
>>>>>
>>>>> This needs to be addressed.
>>>>
>>>> That you don't believe that there is a cycle from Ĵ.qx to Ĵ.q0 is
>>>> flatly wrong.
>>>
>>> No, I'm right about that.
>>
>> Try and exaplain how you are right about that.
>
> It follows directly from the "hat" construction. The TM "at" Ĵ.qx is
> (in effect) J. None of entries in J's state transition function can
> refer to state Ĵ.q0 because that is a new stated added (along with a few
> others) with the sole purpose of doing the copy of the input. There is
> simply no path from Ĵ.qx to Ĵ.q0.
>

There is a path from Ĵ.qx to the Ĵ.q0 of another instance.
infinitely nested simulation with copying is a little less like infinite
recursion than infinitely nested simulation without copying,
none-the-less it is still obviously infinite.

> And, similarly, since J is a UTM with only an accepting state (qy) the
> line you keep writing
>
> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>
> is bogus.

Like I said before it is not bogus. A machine can possibly be defined
with unreachable states. When Ĥ is converted to Ĵ by a single change to
Ĥ this new Ĵ has unreachable states.

I wanted to make a single change to Ĥ to derive Ĵ to make the single
point that Ĥ never stops running unless its aborts the simulation of its
input at Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ thus conclusively proving that this input never
halts according to this criteria:

Simulating Halt Decider Theorem (Olcott 2020):
A simulating halt decider correctly decides that any input that never
halts unless the simulating halt decider aborts its simulation of this
input is an input that never halts.

Although I call it a theorem it is actually a little stronger than that
because it is self-evidently true.

the·o·rem
/ˈTHēərəm,ˈTHirəm/
a general proposition not self-evident but proved by a chain of
reasoning; a truth established by means of accepted truths.

> You can add states to a TM at will, so J or Ĵ can be
> (pointlessly) given a rejecting state qn, but there can't be any
> configuration sequences that end in it.
>

Of course it is the case that any states following infinitely nested
simulation will never be reached. I knew that when I derived the
specification for Ĵ by making a single change to Ĥ.

You seems to have trouble with more than one step so I limited my change
to a single step.

> And the line is bogus for another reason. You are correct that Ĵ
> applied to ⟨Ĵ⟩ is non-halting (thought not because of the cycle you
> imagine was there) and this line directly contradicts that fact. You
> need to write
>

There is a cycle following Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ to another instance of Ĵ.q0.
It is a cycle within the Ĵ template.

Ĵ copies its input ⟨Ĵ1⟩ to ⟨Ĵ2⟩ then
simulates this input Ĵ1 with its input ⟨Ĵ2⟩

which copies its input ⟨Ĵ2⟩ to ⟨Ĵ3⟩ then
simulates this input Ĵ2 with its input ⟨Ĵ3⟩

which copies its input ⟨Ĵ3⟩ to ⟨Ĵ4⟩ then...

> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* ∞
>
> or, if you don't need to show the one and only literal string copying
> step, just Ĵ.q0 ⟨Ĵ⟩ ⊢* ∞.
>

--
Copyright 2021 Pete Olcott

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

On 8/25/2021 10:56 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> // a machine stuck in infinitely nested simulation
>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>
> There are too may errors in your recent posts to track them all now, and
> you are not responding to my questions that were intended to show up the
> problems in what you claim (which it probably exactly why you don't
> answer them) so I am going to reset this discussion of Turning machine
> halting.
>

As I have explained it is your mistake construing these things as errors.

>> Here is what I was saying to someone that is not clueless about actual
>> software development.
>
> And here, for anyone not clueless about actual Turing machines, is why
> you are wrong about the perfectly valid halting theorem.
>

A program with dead code simply never reaches this dead code. Is it the
same with a TM with dead-code.

> The halting problem is about the existence of a TM that accept those
> string pairs (and only those string pairs) that encode halting
> computations. All other strings are to be rejected. The halting
> theorem states that no TM is a such a decider -- every TM fails to
> correctly classify at least one string pair.
>
> You claim to have a TM, unfortunately called H, which is a halt decider.
> (Yes, you sometimes deny it is a general halt decider but you keep
> quoting me saying your algorithm is one, so I presume you agree that it
> must be one.)
>
> You tell us, again and again, that the computation of Ĥ applied to the
> encoding of Ĥ (written ⟨Ĥ⟩) is a halting computation. You are quick to
> jump in and say that it "only halts because... reason", but it's a
> halting computation whatever the reason.
>
> That halting computation is encoded as the string pair ⟨Ĥ⟩ ⟨Ĥ⟩. (I
> prefer a notation that makes the pairing of an encoded TM and some input
> explicit, but that boat sailed years ago.)
>
> You also tell is that H rejects the string pair ⟨Ĥ⟩ ⟨Ĥ⟩. I.e. you tell
> us everything we need to know to be sure that H is wrong about at least
> this one halting problem instance.
>

Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn

Until you understand that the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ is not a halting
computation there is no sense continuing this one way dialogue.

(a) While the halt decider at Ĥ.qx remains in pure simulation mode its
input ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.

(b) Every computation that never halts while its simulating halt decider
remains in pure simulation mode is a computation that never halts.

If X > Y and Y > Z, then X > Z even if you vehemently disagree.

> The only fact you have not explicitly endorsed is the fact that the
> computation of Ĥ applied to ⟨Ĥ⟩ is encoded as the string pair ⟨Ĥ⟩ ⟨Ĥ⟩
> but you can't dodge that fact -- it's part of the definition of the
> halting problem and defined by the "hat" construction. If the encoding
> of Ĥ applied to ⟨Ĥ⟩ is not string pair ⟨Ĥ⟩ ⟨Ĥ⟩, then you are using the
> wrong "hat" construction for the chosen encoding.
>

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 8/25/2021 10:56 AM, Ben Bacarisse wrote:

>> The halting problem is about the existence of a TM that accept those
>> string pairs (and only those string pairs) that encode halting
>> computations. All other strings are to be rejected. The halting
>> theorem states that no TM is a such a decider -- every TM fails to
>> correctly classify at least one string pair.
>>
>> You claim to have a TM, unfortunately called H, which is a halt decider.
>> (Yes, you sometimes deny it is a general halt decider but you keep
>> quoting me saying your algorithm is one, so I presume you agree that it
>> must be one.)

So you are indeed claiming to have a general halt decider! That's a
grand boast! (You need to say "no" if you don't want this to be taken
as your real position.)

>> You tell us, again and again, that the computation of Ĥ applied to the
>> encoding of Ĥ (written ⟨Ĥ⟩) is a halting computation. You are quick to
>> jump in and say that it "only halts because... reason", but it's a
>> halting computation whatever the reason.
>> 
>> That halting computation is encoded as the string pair ⟨Ĥ⟩ ⟨Ĥ⟩. (I
>> prefer a notation that makes the pairing of an encoded TM and some input
>> explicit, but that boat sailed years ago.)
>> 
>> You also tell is that H rejects the string pair ⟨Ĥ⟩ ⟨Ĥ⟩. I.e. you tell
>> us everything we need to know to be sure that H is wrong about at least
>> this one halting problem instance.
>
> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>
> Until you understand that the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ is not a halting
> computation there is no sense continuing this one way dialogue.

Until you understand that ⟨Ĥ1⟩ ⟨Ĥ2⟩ equals ⟨Ĥ⟩ ⟨Ĥ⟩ and that ⟨Ĥ⟩ ⟨Ĥ⟩ is a
string that should be accepted you are just blowing smoke.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 8/25/2021 10:19 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/24/2021 7:35 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/24/2021 9:09 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/23/2021 10:09 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 8/23/2021 6:26 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>
>>>>>>>>>>> There is an infinite cycle from Ĵ.qx to Ĵ.q0.
>>>>>>>>>>
>>>>>>>>>> No, but that's just because you've never written a UTM so you don't know
>>>>>>>>>> how such a TM would work. Ĵ applied to ⟨Ĵ⟩ is non-halting but there
>>>>>>>>>> will not be a cycle from Ĵ.q0 -> Ĵ.qx -> Ĵ.q0...[1]
>>>>>>>>>>
>>>>>>>>>>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>>>>>>>>>>
>>>>>>>>>> Eh? You've just said that Ĵ applied to ⟨Ĵ⟩ is non-halting.
>>>>>>
>>>>>> This needs to be addressed.
>>>>>
>>>>> That you don't believe that there is a cycle from Ĵ.qx to Ĵ.q0 is
>>>>> flatly wrong.
>>>>
>>>> No, I'm right about that.
>>>
>>> Try and exaplain how you are right about that.
>>
>> It follows directly from the "hat" construction. The TM "at" Ĵ.qx is
>> (in effect) J. None of entries in J's state transition function can
>> refer to state Ĵ.q0 because that is a new stated added (along with a few
>> others) with the sole purpose of doing the copy of the input. There is
>> simply no path from Ĵ.qx to Ĵ.q0.
>
> There is a path from Ĵ.qx to the Ĵ.q0 of another instance.

Using metaphors does not later the facts. It would be good if you just
acknowledged the error: there is no transition in the delta function of
Ĵ that has q0 as a target.

>> And, similarly, since J is a UTM with only an accepting state (qy) the
>> line you keep writing
>> Ĵ.q0 ⟨Ĵ⟩ ⊢* Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ ⊢* Ĵ.qn
>> is bogus.
>
> Like I said before it is not bogus.

It's bogus. I'll try once more but I don't hold out much hope for you...

>> You can add states to a TM at will, so J or Ĵ can be
>> (pointlessly) given a rejecting state qn, but there can't be any
>> configuration sequences that end in it.
>
> Of course it is the case that any states following infinitely nested
> simulation will never be reached.

No clue. None at all. Ĵ.qn can't be reached because there is no
element of Ĵ's transition function that has it as a target, yet you show
Ĵ.qn being reached. /In addition/ the infinite execution will prevent
/any/ final state being reached yet you show Ĵ.qn being reached. The
line is bogus².

>> And the line is bogus for another reason. You are correct that Ĵ
>> applied to ⟨Ĵ⟩ is non-halting (thought not because of the cycle you
>> imagine was there) and this line directly contradicts that fact. You
>> need to write
>
> There is a cycle following Ĵ.qx ⟨Ĵ⟩ ⟨Ĵ⟩ to another instance of Ĵ.q0.

If you are content with such waffle, I'll be happy to you leave you to
it, but if you want to be accurate, no computation involving Ĵ can
transition to q0.

If you could accept this fact, you might get some help with the best way
to talk about these metaphorical "instances". Until then, I am inclined
just to point out where you are wrong.

None of which alters the fact that your supposed halting decider H
rejects the string pair ⟨Ĥ⟩ ⟨Ĥ⟩ despite that fact that that string
encodes the halting computation of Ĥ applied to ⟨Ĥ⟩.

--
Ben.

On 8/25/2021 1:55 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/25/2021 10:56 AM, Ben Bacarisse wrote:
>
>>> The halting problem is about the existence of a TM that accept those
>>> string pairs (and only those string pairs) that encode halting
>>> computations. All other strings are to be rejected. The halting
>>> theorem states that no TM is a such a decider -- every TM fails to
>>> correctly classify at least one string pair.
>>>
>>> You claim to have a TM, unfortunately called H, which is a halt decider.
>>> (Yes, you sometimes deny it is a general halt decider but you keep
>>> quoting me saying your algorithm is one, so I presume you agree that it
>>> must be one.)
>
> So you are indeed claiming to have a general halt decider! That's a
> grand boast! (You need to say "no" if you don't want this to be taken
> as your real position.)
>
>>> You tell us, again and again, that the computation of Ĥ applied to the
>>> encoding of Ĥ (written ⟨Ĥ⟩) is a halting computation. You are quick to
>>> jump in and say that it "only halts because... reason", but it's a
>>> halting computation whatever the reason.
>>>
>>> That halting computation is encoded as the string pair ⟨Ĥ⟩ ⟨Ĥ⟩. (I
>>> prefer a notation that makes the pairing of an encoded TM and some input
>>> explicit, but that boat sailed years ago.)
>>>
>>> You also tell is that H rejects the string pair ⟨Ĥ⟩ ⟨Ĥ⟩. I.e. you tell
>>> us everything we need to know to be sure that H is wrong about at least
>>> this one halting problem instance.
>>
>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>
>> Until you understand that the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ is not a halting
>> computation there is no sense continuing this one way dialogue.
>
> Until you understand that ⟨Ĥ1⟩ ⟨Ĥ2⟩ equals ⟨Ĥ⟩ ⟨Ĥ⟩ and that ⟨Ĥ⟩ ⟨Ĥ⟩ is a
> string that should be accepted you are just blowing smoke.
>

(a) While the simulating halt decider at Ĥ.qx remains in pure simulation
mode its input ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.

(b) Every computation that never halts while its simulating halt decider
remains in pure simulation mode is a computation that never halts.

Too disingenuous to continue. You utterly refuse to directly examine my
proof provided immediately above that is not the sign of an honest
dialogue.

--
Copyright 2021 Pete Olcott

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

On 8/25/21 3:06 PM, olcott wrote:
> On 8/25/2021 1:55 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/25/2021 10:56 AM, Ben Bacarisse wrote:
>>
>>>> The halting problem is about the existence of a TM that accept those
>>>> string pairs (and only those string pairs) that encode halting
>>>> computations.  All other strings are to be rejected.  The halting
>>>> theorem states that no TM is a such a decider -- every TM fails to
>>>> correctly classify at least one string pair.
>>>>
>>>> You claim to have a TM, unfortunately called H, which is a halt
>>>> decider.
>>>> (Yes, you sometimes deny it is a general halt decider but you keep
>>>> quoting me saying your algorithm is one, so I presume you agree that it
>>>> must be one.)
>>
>> So you are indeed claiming to have a general halt decider!  That's a
>> grand boast!  (You need to say "no" if you don't want this to be taken
>> as your real position.)
>>
>>>> You tell us, again and again, that the computation of Ĥ applied to the
>>>> encoding of Ĥ (written ⟨Ĥ⟩) is a halting computation.  You are quick to
>>>> jump in and say that it "only halts because... reason", but it's a
>>>> halting computation whatever the reason.
>>>>   That halting computation is encoded as the string pair ⟨Ĥ⟩ ⟨Ĥ⟩.  (I
>>>> prefer a notation that makes the pairing of an encoded TM and some
>>>> input
>>>> explicit, but that boat sailed years ago.)
>>>>   You also tell is that H rejects the string pair ⟨Ĥ⟩ ⟨Ĥ⟩.  I.e. you
>>>> tell
>>>> us everything we need to know to be sure that H is wrong about at least
>>>> this one halting problem instance.
>>>
>>> Ĥ.q0 ⟨Ĥ1⟩ ⊢* Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ ⊢* Ĥ.qn
>>>
>>> Until you understand that the input to Ĥ.qx ⟨Ĥ1⟩ ⟨Ĥ2⟩ is not a halting
>>> computation there is no sense continuing this one way dialogue.
>>
>> Until you understand that ⟨Ĥ1⟩ ⟨Ĥ2⟩ equals ⟨Ĥ⟩ ⟨Ĥ⟩ and that ⟨Ĥ⟩ ⟨Ĥ⟩ is a
>> string that should be accepted you are just blowing smoke.
>>
>
> (a) While the simulating halt decider at Ĥ.qx remains in pure simulation
> mode its input ⟨Ĥ1⟩ ⟨Ĥ2⟩ never halts.

Because H happens to stop the simulation too soon.

Put that exact same input into a compatible UTM, and it will run to a Halt.

THEREFORE, H WAS WRONG to abort the simulation and declair non-halting.

>
> (b) Every computation that never halts while its simulating halt decider
> remains in pure simulation mode is a computation that never halts.

FALSE STATEMENT. PERIOD>

>
> Too disingenuous to continue. You utterly refuse to directly examine my
> proof provided immediately above that is not the sign of an honest
> dialogue.
>