On 4/10/22 11:40 AM, olcott wrote:
> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>
>>>>>> You state that for the H you are championing
>>>>>>
>>>>>>       Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>
>>>>>> To see why this H is not a halt decider, you must answer the two
>>>>>> questions you are studiously avoiding.  What state does H <Ĥ> <Ĥ>
>>>>>> transition to, and what string must be passed to H for H to tell us
>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>
>>>>> Is the input to embedded_H non-halting? YES
>>>> The only plausible meaning for whether a string, s, is non-halting is
>>>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts (according to you).
>>>
>>> embedded_H contains a fully functional UTM.
>>
>> So what?  It can contain a fully functional chess program for all anyone
>> cares.  What matters is what "is the input to embedded_H non-halting"
>> means.  The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>) halts, and
>> it does (according to you).
>>
>>> The correctly simulated input to embedded_H would never reach its own
>>> final state whether or not aborted by embedded_H.
>>
>> UTM(<Ĥ> <Ĥ>) halts (according to you).  Are you retracing that?  Or are
>> you now saying both at once?  We know you are quite happy to claim
>> flat-out contradictory facts at the same time.
>>
>
> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>
> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its final
> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever

Except it has been shown that the CORRECTLY simulated input to
embedded_H, ie <H^> <H^>, DOES Halt if embedded_H <H^> <H^> -> H.Qn

What doesn't get there is the PARTIAL simulation that embedded_H does.

>
> I will stop there you seem to get totally overwhelmed by even one single
> detail so I won't try and give you two details.

You have a long wait, since you state a FALSEHOOD.

>
> Your failure to show exactly how the simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
> embedded_H reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ will be taken
> to mean complete agreement that simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H
> never reaches its final state.
>
>

I have posted this several times, and you seem to be too dumb to
understand it.

First remember that ALL the numeric subscripts are actually irrelevent,
as all <H^ i> are the exact same string and thus all the H^ i are
identical machines as are all Hi machines.

H^ 0 is applied to <H^ 1>
H0 copies its input <H^ 1) to <H^ 2> then
H0 simulates <H^ 1> <H^ 2>
H0 THINKS these keep repeating (but they don't)
H^ 1 copies its input <H^ 2> to <H^ 3> then H1 simulates <H^ 2> <H^ 3>
H^ 2 copies its input <H^ 3> to <H^ 4> then H2 simulates <H^ 3> <H^ 4>
Then embedded_H0 rejects <H^ 1> <H^ 2>
going to your H.Qn
This is also H^ 0.Qn which is a final state of the machine H^ 0

H^ 0 applied to <H^ 1> is thus a HALTING COMPUTATION, and thus so the
input <H^ 0><H^ 1> represents one.

Note, behavior of the input is BY DEFINITION based on the behavior of
the ACTUAL MACHINE (or ACTUAL UTM Simulation) NOT the aborted simulation
of the decider.

Previously you claimed that you never said that embedded_H0 rejects the
input <H^ 1> <H^ 3> but if embedded_H rejects <H^ 0> <H^ 1>, then
embedded_H0 must reject <H^ 1> <H^ 2> as they are the exact same machine
with the exact same input, just different instances of it.

If you want to claim this basic property doesn't hold, you will need to
show PROOF of that, namely some actual Turing Machine where two copies
of it given the exact same input does different things.

FAIL.

On 4/10/2022 2:17 PM, André G. Isaak wrote:
> On 2022-04-10 10:35, olcott wrote:
>> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>>
>>>>>>>>> You state that for the H you are championing
>>>>>>>>>
>>>>>>>>>        Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>>
>>>>>>>>> To see why this H is not a halt decider, you must answer the two
>>>>>>>>> questions you are studiously avoiding.  What state does H <Ĥ> <Ĥ>
>>>>>>>>> transition to, and what string must be passed to H for H to
>>>>>>>>> tell us
>>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>>
>>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>>> The only plausible meaning for whether a string, s, is
>>>>>>> non-halting is
>>>>>>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts (according to
>>>>>>> you).
>>>>>>
>>>>>> embedded_H contains a fully functional UTM.
>>>>> So what?  It can contain a fully functional chess program for all
>>>>> anyone
>>>>> cares.  What matters is what "is the input to embedded_H non-halting"
>>>>> means.  The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>) halts,
>>>>> and
>>>>> it does (according to you).
>>>>>
>>>>>> The correctly simulated input to embedded_H would never reach its own
>>>>>> final state whether or not aborted by embedded_H.
>>>>>
>>>>> UTM(<Ĥ> <Ĥ>) halts (according to you).  Are you retracing that?  Or
>>>>> are
>>>>> you now saying both at once?  We know you are quite happy to claim
>>>>> flat-out contradictory facts at the same time.
>>>>
>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>
>>> No once cares about this math poem.  You have invented some names to
>>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk.  What
>>> matters is that
>>>
>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo  if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does not halt.
>>>
>>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its final
>>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>>>
>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.  But what string must be passed to H for H to tell
>>
>> The above means this:
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>
> Which is an entirely meaningless specification since you don't include
> the necessary conditions which determine when H.qy and H.qn are reached.
>
> Why this is so difficult for you to grasp is beyond me.
>
> And I don't think you really understand what 'UTM' means. A UTM is a TM
> which, when given a TM descroption <M> and an input string I determines
> what the *result* of applying <M> to I would be. It doesn't accept or
> reject its input based on whether it describes a halting computation, so
> claiming you can just replace your embedded_H with a UTM is nonsensical.
>
> André
>

Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn

If is the case that the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under
any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to specify a
non-halting sequence of configurations.

Ben knows that the above succinctly proves my point so he dismisses it
as a math poem because Ben only cares about rebuttal and does not care
about truth.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 4/10/2022 2:17 PM, André G. Isaak wrote:
> On 2022-04-10 10:35, olcott wrote:
>> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>>
>>>>>>>>> You state that for the H you are championing
>>>>>>>>>
>>>>>>>>>        Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>>
>>>>>>>>> To see why this H is not a halt decider, you must answer the two
>>>>>>>>> questions you are studiously avoiding.  What state does H <Ĥ> <Ĥ>
>>>>>>>>> transition to, and what string must be passed to H for H to
>>>>>>>>> tell us
>>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>>
>>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>>> The only plausible meaning for whether a string, s, is
>>>>>>> non-halting is
>>>>>>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts (according to
>>>>>>> you).
>>>>>>
>>>>>> embedded_H contains a fully functional UTM.
>>>>> So what?  It can contain a fully functional chess program for all
>>>>> anyone
>>>>> cares.  What matters is what "is the input to embedded_H non-halting"
>>>>> means.  The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>) halts,
>>>>> and
>>>>> it does (according to you).
>>>>>
>>>>>> The correctly simulated input to embedded_H would never reach its own
>>>>>> final state whether or not aborted by embedded_H.
>>>>>
>>>>> UTM(<Ĥ> <Ĥ>) halts (according to you).  Are you retracing that?  Or
>>>>> are
>>>>> you now saying both at once?  We know you are quite happy to claim
>>>>> flat-out contradictory facts at the same time.
>>>>
>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>
>>> No once cares about this math poem.  You have invented some names to
>>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk.  What
>>> matters is that
>>>
>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo  if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does not halt.
>>>
>>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its final
>>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>>>
>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.  But what string must be passed to H for H to tell
>>
>> The above means this:
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>
> Which is an entirely meaningless specification since you don't include
> the necessary conditions which determine when H.qy and H.qn are reached.
>
> Why this is so difficult for you to grasp is beyond me.
>
> And I don't think you really understand what 'UTM' means. A UTM is a TM
> which, when given a TM descroption <M> and an input string I determines
> what the *result* of applying <M> to I would be. It doesn't accept or
> reject its input based on whether it describes a halting computation, so
> claiming you can just replace your embedded_H with a UTM is nonsensical.
>
> André
>

Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn

IT IS THE CASE that the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under
any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to specify a
non-halting sequence of configurations.

Ben knows that the above succinctly proves my point so he dismisses it
as a math poem because Ben only cares about rebuttal and does not care
about truth.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 4/10/22 3:26 PM, olcott wrote:
> On 4/10/2022 2:17 PM, André G. Isaak wrote:
>> On 2022-04-10 10:35, olcott wrote:
>>> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>>>
>>>>>>>>>> You state that for the H you are championing
>>>>>>>>>>
>>>>>>>>>>        Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>>>
>>>>>>>>>> To see why this H is not a halt decider, you must answer the two
>>>>>>>>>> questions you are studiously avoiding.  What state does H <Ĥ> <Ĥ>
>>>>>>>>>> transition to, and what string must be passed to H for H to
>>>>>>>>>> tell us
>>>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>>>
>>>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>>>> The only plausible meaning for whether a string, s, is
>>>>>>>> non-halting is
>>>>>>>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts (according to
>>>>>>>> you).
>>>>>>>
>>>>>>> embedded_H contains a fully functional UTM.
>>>>>> So what?  It can contain a fully functional chess program for all
>>>>>> anyone
>>>>>> cares.  What matters is what "is the input to embedded_H non-halting"
>>>>>> means.  The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>)
>>>>>> halts, and
>>>>>> it does (according to you).
>>>>>>
>>>>>>> The correctly simulated input to embedded_H would never reach its
>>>>>>> own
>>>>>>> final state whether or not aborted by embedded_H.
>>>>>>
>>>>>> UTM(<Ĥ> <Ĥ>) halts (according to you).  Are you retracing that?
>>>>>> Or are
>>>>>> you now saying both at once?  We know you are quite happy to claim
>>>>>> flat-out contradictory facts at the same time.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>
>>>> No once cares about this math poem.  You have invented some names to
>>>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk.  What
>>>> matters is that
>>>>
>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo  if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does not halt.
>>>>
>>>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its final
>>>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>>>>
>>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.  But what string must be passed to H for H to tell
>>>
>>> The above means this:
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>
>> Which is an entirely meaningless specification since you don't include
>> the necessary conditions which determine when H.qy and H.qn are reached.
>>
>> Why this is so difficult for you to grasp is beyond me.
>>
>> And I don't think you really understand what 'UTM' means. A UTM is a
>> TM which, when given a TM descroption <M> and an input string I
>> determines what the *result* of applying <M> to I would be. It doesn't
>> accept or reject its input based on whether it describes a halting
>> computation, so claiming you can just replace your embedded_H with a
>> UTM is nonsensical.
>>
>> André
>>
>
> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>
> If is the case that the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
> embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under
> any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to specify a
> non-halting sequence of configurations.

Nope, the correct simulation of the input to H will halt if H <H^> <H^>
-> Qn, as I have show the trace.

FAIL

You keep confusing the simulation done by H with the correct simulation
of the input, if H aborts its simulation, it is BY DEFINTION not
correct, and if it doesn't, then H by definition fails to be a decider
for this input.

H has to chose which error it makes.

>
> Ben knows that the above succinctly proves my point so he dismisses it
> as a math poem because Ben only cares about rebuttal and does not care
> about truth.
>
>

Crank Peter Olcott wrote:
> ...As soon as it sees that the pure UTM simulation of its input
> would never reach the final state of this input it aborts this
> simulation and rejects this non-halting input.

Really Peter? Show the code able to do this.

On 2022-04-10 13:26, olcott wrote:
> On 4/10/2022 2:17 PM, André G. Isaak wrote:
>> On 2022-04-10 10:35, olcott wrote:
>>> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>>>
>>>>>>>>>> You state that for the H you are championing
>>>>>>>>>>
>>>>>>>>>>        Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>>>
>>>>>>>>>> To see why this H is not a halt decider, you must answer the two
>>>>>>>>>> questions you are studiously avoiding.  What state does H <Ĥ> <Ĥ>
>>>>>>>>>> transition to, and what string must be passed to H for H to
>>>>>>>>>> tell us
>>>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>>>
>>>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>>>> The only plausible meaning for whether a string, s, is
>>>>>>>> non-halting is
>>>>>>>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts (according to
>>>>>>>> you).
>>>>>>>
>>>>>>> embedded_H contains a fully functional UTM.
>>>>>> So what?  It can contain a fully functional chess program for all
>>>>>> anyone
>>>>>> cares.  What matters is what "is the input to embedded_H non-halting"
>>>>>> means.  The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>)
>>>>>> halts, and
>>>>>> it does (according to you).
>>>>>>
>>>>>>> The correctly simulated input to embedded_H would never reach its
>>>>>>> own
>>>>>>> final state whether or not aborted by embedded_H.
>>>>>>
>>>>>> UTM(<Ĥ> <Ĥ>) halts (according to you).  Are you retracing that?
>>>>>> Or are
>>>>>> you now saying both at once?  We know you are quite happy to claim
>>>>>> flat-out contradictory facts at the same time.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>
>>>> No once cares about this math poem.  You have invented some names to
>>>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk.  What
>>>> matters is that
>>>>
>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo  if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does not halt.
>>>>
>>>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its final
>>>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>>>>
>>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.  But what string must be passed to H for H to tell
>>>
>>> The above means this:
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>
>> Which is an entirely meaningless specification since you don't include
>> the necessary conditions which determine when H.qy and H.qn are reached.
>>
>> Why this is so difficult for you to grasp is beyond me.
>>
>> And I don't think you really understand what 'UTM' means. A UTM is a
>> TM which, when given a TM descroption <M> and an input string I
>> determines what the *result* of applying <M> to I would be. It doesn't
>> accept or reject its input based on whether it describes a halting
>> computation, so claiming you can just replace your embedded_H with a
>> UTM is nonsensical.
>>
>> André
>>
>
> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn

And once again you omit the crucial conditions...

You claim to want to be taken seriously. Using meaningless notation is
not the way to do this. The above could mean 'go to H.qy' if ⟨Ĥ0⟩ ⟨Ĥ1⟩
ends in the symbol 0 or if ⟨Ĥ0⟩ ⟨Ĥ1⟩ doesn't end in a 0 or if it is
raining or pretty much anything else you want it to mean. Without
specifying a condition this says nothing whatsoever about WHICH of the
two final states should be reached.

> If is the case that the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
> embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under
> any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to specify a
> non-halting sequence of configurations.

if you want to talk about "embedded_H" at least employ a specification
which contains embedded_H. The (incomplete) one you give above contains
H, but no "embedded_H".

> Ben knows that the above succinctly proves my point so he dismisses it
> as a math poem because Ben only cares about rebuttal and does not care
> about truth.

No, he dismisses it as a math poem because it is meaningless. You have
provided no conditions to define what this 'specification' is supposed
to mean. You're just improperly copying notation you've seen before with
no clue about what it actually means or how it is supposed to be used.

André

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

On 4/10/2022 2:50 PM, André G. Isaak wrote:
> On 2022-04-10 13:26, olcott wrote:
>> On 4/10/2022 2:17 PM, André G. Isaak wrote:
>>> On 2022-04-10 10:35, olcott wrote:
>>>> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>>>>
>>>>>>>>>>> You state that for the H you are championing
>>>>>>>>>>>
>>>>>>>>>>>        Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>>>>
>>>>>>>>>>> To see why this H is not a halt decider, you must answer the two
>>>>>>>>>>> questions you are studiously avoiding.  What state does H <Ĥ>
>>>>>>>>>>> <Ĥ>
>>>>>>>>>>> transition to, and what string must be passed to H for H to
>>>>>>>>>>> tell us
>>>>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>>>>
>>>>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>>>>> The only plausible meaning for whether a string, s, is
>>>>>>>>> non-halting is
>>>>>>>>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts (according
>>>>>>>>> to you).
>>>>>>>>
>>>>>>>> embedded_H contains a fully functional UTM.
>>>>>>> So what?  It can contain a fully functional chess program for all
>>>>>>> anyone
>>>>>>> cares.  What matters is what "is the input to embedded_H
>>>>>>> non-halting"
>>>>>>> means.  The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>)
>>>>>>> halts, and
>>>>>>> it does (according to you).
>>>>>>>
>>>>>>>> The correctly simulated input to embedded_H would never reach
>>>>>>>> its own
>>>>>>>> final state whether or not aborted by embedded_H.
>>>>>>>
>>>>>>> UTM(<Ĥ> <Ĥ>) halts (according to you).  Are you retracing that?
>>>>>>> Or are
>>>>>>> you now saying both at once?  We know you are quite happy to claim
>>>>>>> flat-out contradictory facts at the same time.
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>
>>>>> No once cares about this math poem.  You have invented some names to
>>>>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk.  What
>>>>> matters is that
>>>>>
>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo  if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does not halt.
>>>>>
>>>>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its final
>>>>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>>>>>
>>>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.  But what string must be passed to H for H to tell
>>>>
>>>> The above means this:
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>
>>> Which is an entirely meaningless specification since you don't
>>> include the necessary conditions which determine when H.qy and H.qn
>>> are reached.
>>>
>>> Why this is so difficult for you to grasp is beyond me.
>>>
>>> And I don't think you really understand what 'UTM' means. A UTM is a
>>> TM which, when given a TM descroption <M> and an input string I
>>> determines what the *result* of applying <M> to I would be. It
>>> doesn't accept or reject its input based on whether it describes a
>>> halting computation, so claiming you can just replace your embedded_H
>>> with a UTM is nonsensical.
>>>
>>> André
>>>
>>
>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>
> And once again you omit the crucial conditions...
>
> You claim to want to be taken seriously. Using meaningless notation is
> not the way to do this. The above could mean 'go to H.qy' if ⟨Ĥ0⟩ ⟨Ĥ1⟩
> ends in the symbol 0 or if ⟨Ĥ0⟩ ⟨Ĥ1⟩ doesn't end in a 0 or if it is
> raining or pretty much anything else you want it to mean. Without
> specifying a condition this says nothing whatsoever about WHICH of the
> two final states should be reached.
>
>> If is the case that the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>> embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩
>> under any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to
>> specify a non-halting sequence of configurations.
>
> if you want to talk about "embedded_H" at least employ a specification
> which contains embedded_H. The (incomplete) one you give above contains
> H, but no "embedded_H".

The copy of the Linz H that it embedded in Ĥ is what I mean by
embedded_H you deceitful bastard.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 2022-04-10 13:55, olcott wrote:
> On 4/10/2022 2:50 PM, André G. Isaak wrote:
>> On 2022-04-10 13:26, olcott wrote:
>>> On 4/10/2022 2:17 PM, André G. Isaak wrote:
>>>> On 2022-04-10 10:35, olcott wrote:
>>>>> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>>>>>
>>>>>>>>>>>> You state that for the H you are championing
>>>>>>>>>>>>
>>>>>>>>>>>>        Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>>>>>
>>>>>>>>>>>> To see why this H is not a halt decider, you must answer the
>>>>>>>>>>>> two
>>>>>>>>>>>> questions you are studiously avoiding.  What state does H
>>>>>>>>>>>> <Ĥ> <Ĥ>
>>>>>>>>>>>> transition to, and what string must be passed to H for H to
>>>>>>>>>>>> tell us
>>>>>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>>>>>
>>>>>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>>>>>> The only plausible meaning for whether a string, s, is
>>>>>>>>>> non-halting is
>>>>>>>>>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts (according
>>>>>>>>>> to you).
>>>>>>>>>
>>>>>>>>> embedded_H contains a fully functional UTM.
>>>>>>>> So what?  It can contain a fully functional chess program for
>>>>>>>> all anyone
>>>>>>>> cares.  What matters is what "is the input to embedded_H
>>>>>>>> non-halting"
>>>>>>>> means.  The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>)
>>>>>>>> halts, and
>>>>>>>> it does (according to you).
>>>>>>>>
>>>>>>>>> The correctly simulated input to embedded_H would never reach
>>>>>>>>> its own
>>>>>>>>> final state whether or not aborted by embedded_H.
>>>>>>>>
>>>>>>>> UTM(<Ĥ> <Ĥ>) halts (according to you).  Are you retracing that?
>>>>>>>> Or are
>>>>>>>> you now saying both at once?  We know you are quite happy to claim
>>>>>>>> flat-out contradictory facts at the same time.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>>
>>>>>> No once cares about this math poem.  You have invented some names to
>>>>>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk.  What
>>>>>> matters is that
>>>>>>
>>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo  if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
>>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does not
>>>>>> halt.
>>>>>>
>>>>>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its final
>>>>>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>>>>>>
>>>>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.  But what string must be passed to H for H to
>>>>>> tell
>>>>>
>>>>> The above means this:
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>
>>>> Which is an entirely meaningless specification since you don't
>>>> include the necessary conditions which determine when H.qy and H.qn
>>>> are reached.
>>>>
>>>> Why this is so difficult for you to grasp is beyond me.
>>>>
>>>> And I don't think you really understand what 'UTM' means. A UTM is a
>>>> TM which, when given a TM descroption <M> and an input string I
>>>> determines what the *result* of applying <M> to I would be. It
>>>> doesn't accept or reject its input based on whether it describes a
>>>> halting computation, so claiming you can just replace your
>>>> embedded_H with a UTM is nonsensical.
>>>>
>>>> André
>>>>
>>>
>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>
>> And once again you omit the crucial conditions...
>>
>> You claim to want to be taken seriously. Using meaningless notation is
>> not the way to do this. The above could mean 'go to H.qy' if ⟨Ĥ0⟩ ⟨Ĥ1⟩
>> ends in the symbol 0 or if ⟨Ĥ0⟩ ⟨Ĥ1⟩ doesn't end in a 0 or if it is
>> raining or pretty much anything else you want it to mean. Without
>> specifying a condition this says nothing whatsoever about WHICH of the
>> two final states should be reached.
>>
>>> If is the case that the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>>> embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩
>>> under any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to
>>> specify a non-halting sequence of configurations.
>>
>> if you want to talk about "embedded_H" at least employ a specification
>> which contains embedded_H. The (incomplete) one you give above
>> contains H, but no "embedded_H".
>
> The copy of the Linz H that it embedded in Ĥ is what I mean by
> embedded_H you deceitful bastard.

I'm trying to get you to write using correct and coherent notation.
That's one of the things you'll need to be able to do if you ever hope
to publish. That involves remembering to always include conditions and
using the same terms in your 'equations' as in your text.

Not sure how that makes me a 'deceitful bastard'.

André

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

On 4/10/2022 3:07 PM, André G. Isaak wrote:
> On 2022-04-10 13:55, olcott wrote:
>> On 4/10/2022 2:50 PM, André G. Isaak wrote:
>>> On 2022-04-10 13:26, olcott wrote:
>>>> On 4/10/2022 2:17 PM, André G. Isaak wrote:
>>>>> On 2022-04-10 10:35, olcott wrote:
>>>>>> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>>>>>>
>>>>>>>>>>>>> You state that for the H you are championing
>>>>>>>>>>>>>
>>>>>>>>>>>>>        Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>>>>>>
>>>>>>>>>>>>> To see why this H is not a halt decider, you must answer
>>>>>>>>>>>>> the two
>>>>>>>>>>>>> questions you are studiously avoiding.  What state does H
>>>>>>>>>>>>> <Ĥ> <Ĥ>
>>>>>>>>>>>>> transition to, and what string must be passed to H for H to
>>>>>>>>>>>>> tell us
>>>>>>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>>>>>>
>>>>>>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>>>>>>> The only plausible meaning for whether a string, s, is
>>>>>>>>>>> non-halting is
>>>>>>>>>>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts (according
>>>>>>>>>>> to you).
>>>>>>>>>>
>>>>>>>>>> embedded_H contains a fully functional UTM.
>>>>>>>>> So what?  It can contain a fully functional chess program for
>>>>>>>>> all anyone
>>>>>>>>> cares.  What matters is what "is the input to embedded_H
>>>>>>>>> non-halting"
>>>>>>>>> means.  The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>)
>>>>>>>>> halts, and
>>>>>>>>> it does (according to you).
>>>>>>>>>
>>>>>>>>>> The correctly simulated input to embedded_H would never reach
>>>>>>>>>> its own
>>>>>>>>>> final state whether or not aborted by embedded_H.
>>>>>>>>>
>>>>>>>>> UTM(<Ĥ> <Ĥ>) halts (according to you).  Are you retracing that?
>>>>>>>>> Or are
>>>>>>>>> you now saying both at once?  We know you are quite happy to claim
>>>>>>>>> flat-out contradictory facts at the same time.
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>>>
>>>>>>> No once cares about this math poem.  You have invented some names to
>>>>>>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk.  What
>>>>>>> matters is that
>>>>>>>
>>>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo  if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
>>>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does not
>>>>>>> halt.
>>>>>>>
>>>>>>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its final
>>>>>>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>>>>>>>
>>>>>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.  But what string must be passed to H for H to
>>>>>>> tell
>>>>>>
>>>>>> The above means this:
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>
>>>>> Which is an entirely meaningless specification since you don't
>>>>> include the necessary conditions which determine when H.qy and H.qn
>>>>> are reached.
>>>>>
>>>>> Why this is so difficult for you to grasp is beyond me.
>>>>>
>>>>> And I don't think you really understand what 'UTM' means. A UTM is
>>>>> a TM which, when given a TM descroption <M> and an input string I
>>>>> determines what the *result* of applying <M> to I would be. It
>>>>> doesn't accept or reject its input based on whether it describes a
>>>>> halting computation, so claiming you can just replace your
>>>>> embedded_H with a UTM is nonsensical.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>
>>> And once again you omit the crucial conditions...
>>>
>>> You claim to want to be taken seriously. Using meaningless notation
>>> is not the way to do this. The above could mean 'go to H.qy' if ⟨Ĥ0⟩
>>> ⟨Ĥ1⟩ ends in the symbol 0 or if ⟨Ĥ0⟩ ⟨Ĥ1⟩ doesn't end in a 0 or if it
>>> is raining or pretty much anything else you want it to mean. Without
>>> specifying a condition this says nothing whatsoever about WHICH of
>>> the two final states should be reached.
>>>
>>>> If is the case that the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>>>> embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩
>>>> under any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to
>>>> specify a non-halting sequence of configurations.
>>>
>>> if you want to talk about "embedded_H" at least employ a
>>> specification which contains embedded_H. The (incomplete) one you
>>> give above contains H, but no "embedded_H".
>>
>> The copy of the Linz H that it embedded in Ĥ is what I mean by
>> embedded_H you deceitful bastard.
>
> I'm trying to get you to write using correct and coherent notation.
> That's one of the things you'll need to be able to do if you ever hope
> to publish. That involves remembering to always include conditions and
> using the same terms in your 'equations' as in your text.
>
> Not sure how that makes me a 'deceitful bastard'.
>
> André
>

The you pretended to not know what I mean by embedded_H so that you
could artificially contrive a fake basis for rebuttal when no actual
basis for rebuttal exists makes you a deceitful bastard.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 4/10/2022 3:15 PM, olcott wrote:
> On 4/10/2022 3:07 PM, André G. Isaak wrote:
>> On 2022-04-10 13:55, olcott wrote:
>>> On 4/10/2022 2:50 PM, André G. Isaak wrote:
>>>> On 2022-04-10 13:26, olcott wrote:
>>>>> On 4/10/2022 2:17 PM, André G. Isaak wrote:
>>>>>> On 2022-04-10 10:35, olcott wrote:
>>>>>>> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> You state that for the H you are championing
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>        Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To see why this H is not a halt decider, you must answer
>>>>>>>>>>>>>> the two
>>>>>>>>>>>>>> questions you are studiously avoiding.  What state does H
>>>>>>>>>>>>>> <Ĥ> <Ĥ>
>>>>>>>>>>>>>> transition to, and what string must be passed to H for H
>>>>>>>>>>>>>> to tell us
>>>>>>>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>>>>>>>
>>>>>>>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>>>>>>>> The only plausible meaning for whether a string, s, is
>>>>>>>>>>>> non-halting is
>>>>>>>>>>>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts
>>>>>>>>>>>> (according to you).
>>>>>>>>>>>
>>>>>>>>>>> embedded_H contains a fully functional UTM.
>>>>>>>>>> So what?  It can contain a fully functional chess program for
>>>>>>>>>> all anyone
>>>>>>>>>> cares.  What matters is what "is the input to embedded_H
>>>>>>>>>> non-halting"
>>>>>>>>>> means.  The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>)
>>>>>>>>>> halts, and
>>>>>>>>>> it does (according to you).
>>>>>>>>>>
>>>>>>>>>>> The correctly simulated input to embedded_H would never reach
>>>>>>>>>>> its own
>>>>>>>>>>> final state whether or not aborted by embedded_H.
>>>>>>>>>>
>>>>>>>>>> UTM(<Ĥ> <Ĥ>) halts (according to you).  Are you retracing
>>>>>>>>>> that? Or are
>>>>>>>>>> you now saying both at once?  We know you are quite happy to
>>>>>>>>>> claim
>>>>>>>>>> flat-out contradictory facts at the same time.
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>>>>
>>>>>>>> No once cares about this math poem.  You have invented some
>>>>>>>> names to
>>>>>>>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk.  What
>>>>>>>> matters is that
>>>>>>>>
>>>>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo  if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
>>>>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does not
>>>>>>>> halt.
>>>>>>>>
>>>>>>>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its
>>>>>>>>> final
>>>>>>>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>>>>>>>>
>>>>>>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.  But what string must be passed to H for H
>>>>>>>> to tell
>>>>>>>
>>>>>>> The above means this:
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>
>>>>>> Which is an entirely meaningless specification since you don't
>>>>>> include the necessary conditions which determine when H.qy and
>>>>>> H.qn are reached.
>>>>>>
>>>>>> Why this is so difficult for you to grasp is beyond me.
>>>>>>
>>>>>> And I don't think you really understand what 'UTM' means. A UTM is
>>>>>> a TM which, when given a TM descroption <M> and an input string I
>>>>>> determines what the *result* of applying <M> to I would be. It
>>>>>> doesn't accept or reject its input based on whether it describes a
>>>>>> halting computation, so claiming you can just replace your
>>>>>> embedded_H with a UTM is nonsensical.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>
>>>> And once again you omit the crucial conditions...
>>>>
>>>> You claim to want to be taken seriously. Using meaningless notation
>>>> is not the way to do this. The above could mean 'go to H.qy' if ⟨Ĥ0⟩
>>>> ⟨Ĥ1⟩ ends in the symbol 0 or if ⟨Ĥ0⟩ ⟨Ĥ1⟩ doesn't end in a 0 or if
>>>> it is raining or pretty much anything else you want it to mean.
>>>> Without specifying a condition this says nothing whatsoever about
>>>> WHICH of the two final states should be reached.
>>>>
>>>>> If is the case that the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>>>>> embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩
>>>>> under any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to
>>>>> specify a non-halting sequence of configurations.
>>>>
>>>> if you want to talk about "embedded_H" at least employ a
>>>> specification which contains embedded_H. The (incomplete) one you
>>>> give above contains H, but no "embedded_H".
>>>
>>> The copy of the Linz H that it embedded in Ĥ is what I mean by
>>> embedded_H you deceitful bastard.
>>
>> I'm trying to get you to write using correct and coherent notation.
>> That's one of the things you'll need to be able to do if you ever hope
>> to publish. That involves remembering to always include conditions and
>> using the same terms in your 'equations' as in your text.
>>
>> Not sure how that makes me a 'deceitful bastard'.
>>
>> André
>>
>
> The you pretended to not know what I mean by embedded_H so that you
> could artificially contrive a fake basis for rebuttal when no actual
> basis for rebuttal exists makes you a deceitful bastard.

If is the case that the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under
any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to specify a
non-halting sequence of configurations.

Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn

On 4/10/2022 3:15 PM, olcott wrote:
> On 4/10/2022 3:07 PM, André G. Isaak wrote:
>> On 2022-04-10 13:55, olcott wrote:
>>> On 4/10/2022 2:50 PM, André G. Isaak wrote:
>>>> On 2022-04-10 13:26, olcott wrote:
>>>>> On 4/10/2022 2:17 PM, André G. Isaak wrote:
>>>>>> On 2022-04-10 10:35, olcott wrote:
>>>>>>> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>> You state that for the H you are championing
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>        Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To see why this H is not a halt decider, you must answer
>>>>>>>>>>>>>> the two
>>>>>>>>>>>>>> questions you are studiously avoiding.  What state does H
>>>>>>>>>>>>>> <Ĥ> <Ĥ>
>>>>>>>>>>>>>> transition to, and what string must be passed to H for H
>>>>>>>>>>>>>> to tell us
>>>>>>>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>>>>>>>
>>>>>>>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>>>>>>>> The only plausible meaning for whether a string, s, is
>>>>>>>>>>>> non-halting is
>>>>>>>>>>>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts
>>>>>>>>>>>> (according to you).
>>>>>>>>>>>
>>>>>>>>>>> embedded_H contains a fully functional UTM.
>>>>>>>>>> So what?  It can contain a fully functional chess program for
>>>>>>>>>> all anyone
>>>>>>>>>> cares.  What matters is what "is the input to embedded_H
>>>>>>>>>> non-halting"
>>>>>>>>>> means.  The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>)
>>>>>>>>>> halts, and
>>>>>>>>>> it does (according to you).
>>>>>>>>>>
>>>>>>>>>>> The correctly simulated input to embedded_H would never reach
>>>>>>>>>>> its own
>>>>>>>>>>> final state whether or not aborted by embedded_H.
>>>>>>>>>>
>>>>>>>>>> UTM(<Ĥ> <Ĥ>) halts (according to you).  Are you retracing
>>>>>>>>>> that? Or are
>>>>>>>>>> you now saying both at once?  We know you are quite happy to
>>>>>>>>>> claim
>>>>>>>>>> flat-out contradictory facts at the same time.
>>>>>>>>>
>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>>>>
>>>>>>>> No once cares about this math poem.  You have invented some
>>>>>>>> names to
>>>>>>>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk.  What
>>>>>>>> matters is that
>>>>>>>>
>>>>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo  if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
>>>>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does not
>>>>>>>> halt.
>>>>>>>>
>>>>>>>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its
>>>>>>>>> final
>>>>>>>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>>>>>>>>
>>>>>>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.  But what string must be passed to H for H
>>>>>>>> to tell
>>>>>>>
>>>>>>> The above means this:
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>
>>>>>> Which is an entirely meaningless specification since you don't
>>>>>> include the necessary conditions which determine when H.qy and
>>>>>> H.qn are reached.
>>>>>>
>>>>>> Why this is so difficult for you to grasp is beyond me.
>>>>>>
>>>>>> And I don't think you really understand what 'UTM' means. A UTM is
>>>>>> a TM which, when given a TM descroption <M> and an input string I
>>>>>> determines what the *result* of applying <M> to I would be. It
>>>>>> doesn't accept or reject its input based on whether it describes a
>>>>>> halting computation, so claiming you can just replace your
>>>>>> embedded_H with a UTM is nonsensical.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>
>>>> And once again you omit the crucial conditions...
>>>>
>>>> You claim to want to be taken seriously. Using meaningless notation
>>>> is not the way to do this. The above could mean 'go to H.qy' if ⟨Ĥ0⟩
>>>> ⟨Ĥ1⟩ ends in the symbol 0 or if ⟨Ĥ0⟩ ⟨Ĥ1⟩ doesn't end in a 0 or if
>>>> it is raining or pretty much anything else you want it to mean.
>>>> Without specifying a condition this says nothing whatsoever about
>>>> WHICH of the two final states should be reached.
>>>>
>>>>> If is the case that the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>>>>> embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩
>>>>> under any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to
>>>>> specify a non-halting sequence of configurations.
>>>>
>>>> if you want to talk about "embedded_H" at least employ a
>>>> specification which contains embedded_H. The (incomplete) one you
>>>> give above contains H, but no "embedded_H".
>>>
>>> The copy of the Linz H that it embedded in Ĥ is what I mean by
>>> embedded_H you deceitful bastard.
>>
>> I'm trying to get you to write using correct and coherent notation.
>> That's one of the things you'll need to be able to do if you ever hope
>> to publish. That involves remembering to always include conditions and
>> using the same terms in your 'equations' as in your text.
>>
>> Not sure how that makes me a 'deceitful bastard'.
>>
>> André
>>
>
> THAT you pretended to not know what I mean by embedded_H so that you
> could artificially contrive a fake basis for rebuttal when no actual
> basis for rebuttal exists makes you a deceitful bastard.

IT IS THE CASE THAT the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under
any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to specify a
non-halting sequence of configurations.

Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn

olcott <NoOne@NoWhere.com> writes:

> On 4/10/2022 10:52 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>> It is the case that the correctly simulated input to embedded_H can
>>>>>>>>>>>>>>> never possibly reach its own final state under any condition at all.
>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because I absolutely positively will not tolerate divergence from
>>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>>
>>>>>>>>>>>> But you have no choice but to tolerate it. If someone wants to talk
>>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>>
>>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) == false but P(P)
>>>>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ> transitions to
>>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to deny
>>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>>
>>>>>>>>>>> If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩
>>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>>
>>>>>>>>>> I believe what you've told me: that you claim that H(P,P)==false is
>>>>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>>>>
>>>>>>>>> If the input to H(P,P) cannot possibly reach its final state then this
>>>>>>>>> input is correctly rejected and nothing in the universe can possibly
>>>>>>>>> contradict this.
>>>>>>>>
>>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
>>>>>>>> either (indeed they come from you).
>>>>>> At least you don't contend these facts.
>>>>>>
>>>>>>>> Your new line in waffle is just an attempt to distract attention from a
>>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>
>>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>>
>>>>>>> A halt decider must compute the mapping from its inputs (not any damn
>>>>>>> thing else in the universe) to its own final state on the basis of the
>>>>>>> behavior specified by these inputs
>>>>>>
>>>>>> That's not counter intuitive, it's basic. Everyone knows this, though
>>>>>> it took you a while to get round to it. A halt decider accepts or
>>>>>> rejects a string based on the behaviour of the computation specified by
>>>>>> that string. Of course, you never got as far in my exercises as
>>>>>> specifying any TM that decides something on the basis of behaviour, so
>>>>>> you really don't know how it's actually done. That was, I thought, the
>>>>>> whole point of the exercises -- to see how TMs are specified to decide
>>>>>> properties of computations.
>>>>>
>>>>> You have to actually pay attention to this,
>>>>
>>>> Flip, flop! Back to being wrong about TMs rather than being wrong about
>>>> your old C junk. These uncontested facts: (1) H(P,P) == false, (2) P(P)
>>>> halts are why your H and P are wrong.
>>>
>>> If you are able to break the problem down to it micro component parts
>>> and carefully analyze each of these separately instead of simply
>>> slipping down the slide of intuition then you can see that I am
>>> correct.
>>>
>>> If it is true that the correct simulation input to H(P,P) cannot
>>> possibly reach its own final state then
>>>
>>> The input to H(P,P) is non-halting then
>> There is no "input to H(P,P)".
>
> The correct simulation of the input to H

Better. I still would not call it "input" (since these are C functions)
but you've got the hang of what am saying. Well done.

> cannot possibly ever reach it final state thus is a non-halting
> sequence of configurations even if everyone and everything in the
> universe disagrees.

The truth is not determined by who does or does not agree with
something. But to find the truth of the matter you must first stop
talking literal nonsense. The arguments to H (what you call the
"input") are two pointers. What does simulating two pointers mean?
What you mean, I hope, is simulating calling the first pointer with the
second as it's argument. That simulation, according to you, will halt
(or "reach it's final state" in your flamboyant, sciencey, language).
It will halt because the direct call P(P) halts. Everything here halts
(according to you). That's why H is wrong.

Your word games can't hide what you used to be perfectly clear about. A
call to H with pointers M and I is supposed to report on the halting or
otherwise of the call M(I). You know this. This is why you spent so
long trying to persuade everyone that the wrong answer was indeed right
because of what "would happen if line 15 were commented out".

>> But how long could it possibly take? Ten minutes, twenty? If takes you
>> more than a few minutes, I don't think there's any chance of making
>> significant progress. "Specify and write E" was supposed to be knocked
>> off quickly, just to get things rolling.
>
> It takes me more than a few minutes to read the 15 pages of
> documentation.

I thought you were using a simulator you were familiar with.

--
Ben.

On 4/10/2022 4:18 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/10/2022 10:52 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>>> It is the case that the correctly simulated input to embedded_H can
>>>>>>>>>>>>>>>> never possibly reach its own final state under any condition at all.
>>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject its input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yet you won't answer two simple questions! Why?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because I absolutely positively will not tolerate divergence from
>>>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But you have no choice but to tolerate it. If someone wants to talk
>>>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) == false but P(P)
>>>>>>>>>>>>> halts. You are wrong about your TM H because H <Ĥ> <Ĥ> transitions to
>>>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel free to deny
>>>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>>>
>>>>>>>>>>>> If you believe (against the verified facts) that the simulated ⟨Ĥ0⟩
>>>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>>>
>>>>>>>>>>> I believe what you've told me: that you claim that H(P,P)==false is
>>>>>>>>>>> correct despite the fact that P(P) halts. That's wrong.
>>>>>>>>>>
>>>>>>>>>> If the input to H(P,P) cannot possibly reach its final state then this
>>>>>>>>>> input is correctly rejected and nothing in the universe can possibly
>>>>>>>>>> contradict this.
>>>>>>>>>
>>>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts. You don't dispute
>>>>>>>>> either (indeed they come from you).
>>>>>>> At least you don't contend these facts.
>>>>>>>
>>>>>>>>> Your new line in waffle is just an attempt to distract attention from a
>>>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>>
>>>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>>>
>>>>>>>> A halt decider must compute the mapping from its inputs (not any damn
>>>>>>>> thing else in the universe) to its own final state on the basis of the
>>>>>>>> behavior specified by these inputs
>>>>>>>
>>>>>>> That's not counter intuitive, it's basic. Everyone knows this, though
>>>>>>> it took you a while to get round to it. A halt decider accepts or
>>>>>>> rejects a string based on the behaviour of the computation specified by
>>>>>>> that string. Of course, you never got as far in my exercises as
>>>>>>> specifying any TM that decides something on the basis of behaviour, so
>>>>>>> you really don't know how it's actually done. That was, I thought, the
>>>>>>> whole point of the exercises -- to see how TMs are specified to decide
>>>>>>> properties of computations.
>>>>>>
>>>>>> You have to actually pay attention to this,
>>>>>
>>>>> Flip, flop! Back to being wrong about TMs rather than being wrong about
>>>>> your old C junk. These uncontested facts: (1) H(P,P) == false, (2) P(P)
>>>>> halts are why your H and P are wrong.
>>>>
>>>> If you are able to break the problem down to it micro component parts
>>>> and carefully analyze each of these separately instead of simply
>>>> slipping down the slide of intuition then you can see that I am
>>>> correct.
>>>>
>>>> If it is true that the correct simulation input to H(P,P) cannot
>>>> possibly reach its own final state then
>>>>
>>>> The input to H(P,P) is non-halting then
>>> There is no "input to H(P,P)".
>>
>> The correct simulation of the input to H
>
> Better. I still would not call it "input" (since these are C functions)
> but you've got the hang of what am saying. Well done.
>
>> cannot possibly ever reach it final state thus is a non-halting
>> sequence of configurations even if everyone and everything in the
>> universe disagrees.
>
> The truth is not determined by who does or does not agree with
> something. But to find the truth of the matter you must first stop
> talking literal nonsense. The arguments to H (what you call the
> "input") are two pointers. What does simulating two pointers mean?
> What you mean, I hope, is simulating calling the first pointer with the
> second as it's argument. That simulation, according to you, will halt
> (or "reach it's final state" in your flamboyant, sciencey, language).
> It will halt because the direct call P(P) halts. Everything here halts
> (according to you). That's why H is wrong.
>

You simply are ignoring the actual execution trace that conclusively
proves that the simulated input to H cannot possibly reach its final own
state.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 4/10/22 3:55 PM, olcott wrote:
> On 4/10/2022 2:50 PM, André G. Isaak wrote:
>> On 2022-04-10 13:26, olcott wrote:
>>> On 4/10/2022 2:17 PM, André G. Isaak wrote:
>>>> On 2022-04-10 10:35, olcott wrote:
>>>>> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>>>>>
>>>>>>>>>>>> You state that for the H you are championing
>>>>>>>>>>>>
>>>>>>>>>>>>        Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>>>>>
>>>>>>>>>>>> To see why this H is not a halt decider, you must answer the
>>>>>>>>>>>> two
>>>>>>>>>>>> questions you are studiously avoiding.  What state does H
>>>>>>>>>>>> <Ĥ> <Ĥ>
>>>>>>>>>>>> transition to, and what string must be passed to H for H to
>>>>>>>>>>>> tell us
>>>>>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>>>>>
>>>>>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>>>>>> The only plausible meaning for whether a string, s, is
>>>>>>>>>> non-halting is
>>>>>>>>>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts (according
>>>>>>>>>> to you).
>>>>>>>>>
>>>>>>>>> embedded_H contains a fully functional UTM.
>>>>>>>> So what?  It can contain a fully functional chess program for
>>>>>>>> all anyone
>>>>>>>> cares.  What matters is what "is the input to embedded_H
>>>>>>>> non-halting"
>>>>>>>> means.  The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>)
>>>>>>>> halts, and
>>>>>>>> it does (according to you).
>>>>>>>>
>>>>>>>>> The correctly simulated input to embedded_H would never reach
>>>>>>>>> its own
>>>>>>>>> final state whether or not aborted by embedded_H.
>>>>>>>>
>>>>>>>> UTM(<Ĥ> <Ĥ>) halts (according to you).  Are you retracing that?
>>>>>>>> Or are
>>>>>>>> you now saying both at once?  We know you are quite happy to claim
>>>>>>>> flat-out contradictory facts at the same time.
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>>
>>>>>> No once cares about this math poem.  You have invented some names to
>>>>>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk.  What
>>>>>> matters is that
>>>>>>
>>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo  if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
>>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does not
>>>>>> halt.
>>>>>>
>>>>>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its final
>>>>>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>>>>>>
>>>>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.  But what string must be passed to H for H to
>>>>>> tell
>>>>>
>>>>> The above means this:
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>
>>>> Which is an entirely meaningless specification since you don't
>>>> include the necessary conditions which determine when H.qy and H.qn
>>>> are reached.
>>>>
>>>> Why this is so difficult for you to grasp is beyond me.
>>>>
>>>> And I don't think you really understand what 'UTM' means. A UTM is a
>>>> TM which, when given a TM descroption <M> and an input string I
>>>> determines what the *result* of applying <M> to I would be. It
>>>> doesn't accept or reject its input based on whether it describes a
>>>> halting computation, so claiming you can just replace your
>>>> embedded_H with a UTM is nonsensical.
>>>>
>>>> André
>>>>
>>>
>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>
>> And once again you omit the crucial conditions...
>>
>> You claim to want to be taken seriously. Using meaningless notation is
>> not the way to do this. The above could mean 'go to H.qy' if ⟨Ĥ0⟩ ⟨Ĥ1⟩
>> ends in the symbol 0 or if ⟨Ĥ0⟩ ⟨Ĥ1⟩ doesn't end in a 0 or if it is
>> raining or pretty much anything else you want it to mean. Without
>> specifying a condition this says nothing whatsoever about WHICH of the
>> two final states should be reached.
>>
>>> If is the case that the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>>> embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩
>>> under any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to
>>> specify a non-halting sequence of configurations.
>>
>> if you want to talk about "embedded_H" at least employ a specification
>> which contains embedded_H. The (incomplete) one you give above
>> contains H, but no "embedded_H".
>
> The copy of the Linz H that it embedded in Ĥ is what I mean by
> embedded_H you deceitful bastard.
>
>

Except that when we talk about H, you say there is no H.

You can't define 'embedded_H' as the copy of H that is embedded_H in H^
and then say talking about H is off topic because there is no H.

Doing THAT is just being deceitful.

FAIL.

On 4/10/2022 4:28 PM, olcott wrote:
> On 4/10/2022 4:18 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/10/2022 10:52 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject
>>>>>>>>>>>>>>>>> its input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yet you won't answer two simple questions!  Why?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because I absolutely positively will not tolerate
>>>>>>>>>>>>>>> divergence from
>>>>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But you have no choice but to tolerate it.  If someone
>>>>>>>>>>>>>> wants to talk
>>>>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) ==
>>>>>>>>>>>>>> false but P(P)
>>>>>>>>>>>>>> halts.  You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>>>>>> transitions to
>>>>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel
>>>>>>>>>>>>>> free to deny
>>>>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you believe (against the verified facts) that the
>>>>>>>>>>>>> simulated ⟨Ĥ0⟩
>>>>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>>>>
>>>>>>>>>>>> I believe what you've told me: that you claim that
>>>>>>>>>>>> H(P,P)==false is
>>>>>>>>>>>> correct despite the fact that P(P) halts.  That's wrong.
>>>>>>>>>>>
>>>>>>>>>>> If the input to H(P,P) cannot possibly reach its final state
>>>>>>>>>>> then this
>>>>>>>>>>> input is correctly rejected and nothing in the universe can
>>>>>>>>>>> possibly
>>>>>>>>>>> contradict this.
>>>>>>>>>>
>>>>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts.  You don't
>>>>>>>>>> dispute
>>>>>>>>>> either (indeed they come from you).
>>>>>>>> At least you don't contend these facts.
>>>>>>>>
>>>>>>>>>> Your new line in waffle is just an attempt to distract
>>>>>>>>>> attention from a
>>>>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>>>
>>>>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>>>>
>>>>>>>>> A halt decider must compute the mapping from its inputs (not
>>>>>>>>> any damn
>>>>>>>>> thing else in the universe) to its own final state on the basis
>>>>>>>>> of the
>>>>>>>>> behavior specified by these inputs
>>>>>>>>
>>>>>>>> That's not counter intuitive, it's basic.  Everyone knows this,
>>>>>>>> though
>>>>>>>> it took you a while to get round to it.  A halt decider accepts or
>>>>>>>> rejects a string based on the behaviour of the computation
>>>>>>>> specified by
>>>>>>>> that string.  Of course, you never got as far in my exercises as
>>>>>>>> specifying any TM that decides something on the basis of
>>>>>>>> behaviour, so
>>>>>>>> you really don't know how it's actually done.  That was, I
>>>>>>>> thought, the
>>>>>>>> whole point of the exercises -- to see how TMs are specified to
>>>>>>>> decide
>>>>>>>> properties of computations.
>>>>>>>
>>>>>>> You have to actually pay attention to this,
>>>>>>
>>>>>> Flip, flop!  Back to being wrong about TMs rather than being wrong
>>>>>> about
>>>>>> your old C junk.  These uncontested facts: (1) H(P,P) == false,
>>>>>> (2) P(P)
>>>>>> halts are why your H and P are wrong.
>>>>>
>>>>> If you are able to break the problem down to it micro component parts
>>>>> and carefully analyze each of these separately instead of simply
>>>>> slipping down the slide of intuition then you can see that I am
>>>>> correct.
>>>>>
>>>>> If it is true that the correct simulation input to H(P,P) cannot
>>>>> possibly reach its own final state then
>>>>>
>>>>> The input to H(P,P) is non-halting then
>>>> There is no "input to H(P,P)".
>>>
>>> The correct simulation of the input to H
>>
>> Better.  I still would not call it "input" (since these are C functions)
>> but you've got the hang of what am saying.  Well done.
>>
>>> cannot possibly ever reach it final state thus is a non-halting
>>> sequence of configurations even if everyone and everything in the
>>> universe disagrees.
>>
>> The truth is not determined by who does or does not agree with
>> something.  But to find the truth of the matter you must first stop
>> talking literal nonsense.  The arguments to H (what you call the
>> "input") are two pointers.  What does simulating two pointers mean?
>> What you mean, I hope, is simulating calling the first pointer with the
>> second as it's argument.  That simulation, according to you, will halt
>> (or "reach it's final state" in your flamboyant, sciencey, language).
>> It will halt because the direct call P(P) halts.  Everything here halts
>> (according to you).  That's why H is wrong.
>>
>
> You simply are ignoring the actual execution trace that conclusively
> proves that the simulated input to H cannot possibly reach its final own
> state.

On 4/10/22 5:28 PM, olcott wrote:
> On 4/10/2022 4:18 PM, Ben wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/10/2022 10:52 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject
>>>>>>>>>>>>>>>>> its input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yet you won't answer two simple questions!  Why?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because I absolutely positively will not tolerate
>>>>>>>>>>>>>>> divergence from
>>>>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But you have no choice but to tolerate it.  If someone
>>>>>>>>>>>>>> wants to talk
>>>>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) ==
>>>>>>>>>>>>>> false but P(P)
>>>>>>>>>>>>>> halts.  You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>>>>>> transitions to
>>>>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel
>>>>>>>>>>>>>> free to deny
>>>>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you believe (against the verified facts) that the
>>>>>>>>>>>>> simulated ⟨Ĥ0⟩
>>>>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>>>>
>>>>>>>>>>>> I believe what you've told me: that you claim that
>>>>>>>>>>>> H(P,P)==false is
>>>>>>>>>>>> correct despite the fact that P(P) halts.  That's wrong.
>>>>>>>>>>>
>>>>>>>>>>> If the input to H(P,P) cannot possibly reach its final state
>>>>>>>>>>> then this
>>>>>>>>>>> input is correctly rejected and nothing in the universe can
>>>>>>>>>>> possibly
>>>>>>>>>>> contradict this.
>>>>>>>>>>
>>>>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts.  You don't
>>>>>>>>>> dispute
>>>>>>>>>> either (indeed they come from you).
>>>>>>>> At least you don't contend these facts.
>>>>>>>>
>>>>>>>>>> Your new line in waffle is just an attempt to distract
>>>>>>>>>> attention from a
>>>>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>>>
>>>>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>>>>
>>>>>>>>> A halt decider must compute the mapping from its inputs (not
>>>>>>>>> any damn
>>>>>>>>> thing else in the universe) to its own final state on the basis
>>>>>>>>> of the
>>>>>>>>> behavior specified by these inputs
>>>>>>>>
>>>>>>>> That's not counter intuitive, it's basic.  Everyone knows this,
>>>>>>>> though
>>>>>>>> it took you a while to get round to it.  A halt decider accepts or
>>>>>>>> rejects a string based on the behaviour of the computation
>>>>>>>> specified by
>>>>>>>> that string.  Of course, you never got as far in my exercises as
>>>>>>>> specifying any TM that decides something on the basis of
>>>>>>>> behaviour, so
>>>>>>>> you really don't know how it's actually done.  That was, I
>>>>>>>> thought, the
>>>>>>>> whole point of the exercises -- to see how TMs are specified to
>>>>>>>> decide
>>>>>>>> properties of computations.
>>>>>>>
>>>>>>> You have to actually pay attention to this,
>>>>>>
>>>>>> Flip, flop!  Back to being wrong about TMs rather than being wrong
>>>>>> about
>>>>>> your old C junk.  These uncontested facts: (1) H(P,P) == false,
>>>>>> (2) P(P)
>>>>>> halts are why your H and P are wrong.
>>>>>
>>>>> If you are able to break the problem down to it micro component parts
>>>>> and carefully analyze each of these separately instead of simply
>>>>> slipping down the slide of intuition then you can see that I am
>>>>> correct.
>>>>>
>>>>> If it is true that the correct simulation input to H(P,P) cannot
>>>>> possibly reach its own final state then
>>>>>
>>>>> The input to H(P,P) is non-halting then
>>>> There is no "input to H(P,P)".
>>>
>>> The correct simulation of the input to H
>>
>> Better.  I still would not call it "input" (since these are C functions)
>> but you've got the hang of what am saying.  Well done.
>>
>>> cannot possibly ever reach it final state thus is a non-halting
>>> sequence of configurations even if everyone and everything in the
>>> universe disagrees.
>>
>> The truth is not determined by who does or does not agree with
>> something.  But to find the truth of the matter you must first stop
>> talking literal nonsense.  The arguments to H (what you call the
>> "input") are two pointers.  What does simulating two pointers mean?
>> What you mean, I hope, is simulating calling the first pointer with the
>> second as it's argument.  That simulation, according to you, will halt
>> (or "reach it's final state" in your flamboyant, sciencey, language).
>> It will halt because the direct call P(P) halts.  Everything here halts
>> (according to you).  That's why H is wrong.
>>
>
> You simply are ignoring the actual execution trace that conclusively
> proves that the simulated input to H cannot possibly reach its final own
> state.
>

On 4/10/22 5:00 PM, olcott wrote:
> On 4/10/2022 3:15 PM, olcott wrote:
>> On 4/10/2022 3:07 PM, André G. Isaak wrote:
>>> On 2022-04-10 13:55, olcott wrote:
>>>> On 4/10/2022 2:50 PM, André G. Isaak wrote:
>>>>> On 2022-04-10 13:26, olcott wrote:
>>>>>> On 4/10/2022 2:17 PM, André G. Isaak wrote:
>>>>>>> On 2022-04-10 10:35, olcott wrote:
>>>>>>>> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You state that for the H you are championing
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>        Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> To see why this H is not a halt decider, you must answer
>>>>>>>>>>>>>>> the two
>>>>>>>>>>>>>>> questions you are studiously avoiding.  What state does H
>>>>>>>>>>>>>>> <Ĥ> <Ĥ>
>>>>>>>>>>>>>>> transition to, and what string must be passed to H for H
>>>>>>>>>>>>>>> to tell us
>>>>>>>>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>>>>>>>>> The only plausible meaning for whether a string, s, is
>>>>>>>>>>>>> non-halting is
>>>>>>>>>>>>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts
>>>>>>>>>>>>> (according to you).
>>>>>>>>>>>>
>>>>>>>>>>>> embedded_H contains a fully functional UTM.
>>>>>>>>>>> So what?  It can contain a fully functional chess program for
>>>>>>>>>>> all anyone
>>>>>>>>>>> cares.  What matters is what "is the input to embedded_H
>>>>>>>>>>> non-halting"
>>>>>>>>>>> means.  The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>)
>>>>>>>>>>> halts, and
>>>>>>>>>>> it does (according to you).
>>>>>>>>>>>
>>>>>>>>>>>> The correctly simulated input to embedded_H would never
>>>>>>>>>>>> reach its own
>>>>>>>>>>>> final state whether or not aborted by embedded_H.
>>>>>>>>>>>
>>>>>>>>>>> UTM(<Ĥ> <Ĥ>) halts (according to you).  Are you retracing
>>>>>>>>>>> that? Or are
>>>>>>>>>>> you now saying both at once?  We know you are quite happy to
>>>>>>>>>>> claim
>>>>>>>>>>> flat-out contradictory facts at the same time.
>>>>>>>>>>
>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>>>>>
>>>>>>>>> No once cares about this math poem.  You have invented some
>>>>>>>>> names to
>>>>>>>>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk.
>>>>>>>>> What
>>>>>>>>> matters is that
>>>>>>>>>
>>>>>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo  if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
>>>>>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does
>>>>>>>>> not halt.
>>>>>>>>>
>>>>>>>>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its
>>>>>>>>>> final
>>>>>>>>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>>>>>>>>>
>>>>>>>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.  But what string must be passed to H for H
>>>>>>>>> to tell
>>>>>>>>
>>>>>>>> The above means this:
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>
>>>>>>> Which is an entirely meaningless specification since you don't
>>>>>>> include the necessary conditions which determine when H.qy and
>>>>>>> H.qn are reached.
>>>>>>>
>>>>>>> Why this is so difficult for you to grasp is beyond me.
>>>>>>>
>>>>>>> And I don't think you really understand what 'UTM' means. A UTM
>>>>>>> is a TM which, when given a TM descroption <M> and an input
>>>>>>> string I determines what the *result* of applying <M> to I would
>>>>>>> be. It doesn't accept or reject its input based on whether it
>>>>>>> describes a halting computation, so claiming you can just replace
>>>>>>> your embedded_H with a UTM is nonsensical.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>
>>>>> And once again you omit the crucial conditions...
>>>>>
>>>>> You claim to want to be taken seriously. Using meaningless notation
>>>>> is not the way to do this. The above could mean 'go to H.qy' if
>>>>> ⟨Ĥ0⟩ ⟨Ĥ1⟩ ends in the symbol 0 or if ⟨Ĥ0⟩ ⟨Ĥ1⟩ doesn't end in a 0
>>>>> or if it is raining or pretty much anything else you want it to
>>>>> mean. Without specifying a condition this says nothing whatsoever
>>>>> about WHICH of the two final states should be reached.
>>>>>
>>>>>> If is the case that the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>>>>>> embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩
>>>>>> under any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to
>>>>>> specify a non-halting sequence of configurations.
>>>>>
>>>>> if you want to talk about "embedded_H" at least employ a
>>>>> specification which contains embedded_H. The (incomplete) one you
>>>>> give above contains H, but no "embedded_H".
>>>>
>>>> The copy of the Linz H that it embedded in Ĥ is what I mean by
>>>> embedded_H you deceitful bastard.
>>>
>>> I'm trying to get you to write using correct and coherent notation.
>>> That's one of the things you'll need to be able to do if you ever
>>> hope to publish. That involves remembering to always include
>>> conditions and using the same terms in your 'equations' as in your text.
>>>
>>> Not sure how that makes me a 'deceitful bastard'.
>>>
>>> André
>>>
>>
>> THAT you pretended to not know what I mean by embedded_H so that you
>> could artificially contrive a fake basis for rebuttal when no actual
>> basis for rebuttal exists makes you a deceitful bastard.
>
> IT IS THE CASE THAT the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
> embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under
> any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to specify a
> non-halting sequence of configurations.
>
> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>
>

olcott <NoOne@NoWhere.com> writes:

> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>
>>>>>>>> You state that for the H you are championing
>>>>>>>>
>>>>>>>> Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>
>>>>>>>> To see why this H is not a halt decider, you must answer the two
>>>>>>>> questions you are studiously avoiding. What state does H <Ĥ> <Ĥ>
>>>>>>>> transition to, and what string must be passed to H for H to tell us
>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>
>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>> The only plausible meaning for whether a string, s, is non-halting is
>>>>>> whether UTM(s) is non-halting. UTM(<Ĥ> <Ĥ>) halts (according to you).
>>>>>
>>>>> embedded_H contains a fully functional UTM.
>>>> So what? It can contain a fully functional chess program for all anyone
>>>> cares. What matters is what "is the input to embedded_H non-halting"
>>>> means. The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>) halts, and
>>>> it does (according to you).
>>>>
>>>>> The correctly simulated input to embedded_H would never reach its own
>>>>> final state whether or not aborted by embedded_H.
>>>>
>>>> UTM(<Ĥ> <Ĥ>) halts (according to you). Are you retracing that? Or are
>>>> you now saying both at once? We know you are quite happy to claim
>>>> flat-out contradictory facts at the same time.
>>>
>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>> No once cares about this math poem. You have invented some names to
>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk. What
>> matters is that
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does not halt.
>>
>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its final
>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts. But what string must be passed to H for H to tell
>
> The above means this:
> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn

That's funny! You really have no idea what this notation means, do you?

> embedded_H is a simulating halt decider that has a full UTM embedded
> within it. As soon as it sees that the pure UTM simulation of its
> input would never reach the final state of this input it aborts this
> simulation and rejects this non-halting input.

So you had no business writing those two junk lines, did you? Or do you
really think that they are in some way compatible with that last
paragraph? Probably neither. I really think you see it much like
poetry. Meanings are supposed to be intuited from unusual, often
metaphorical, juxtapositions of symbols.

Anyway, you know what to do if you want to see why you are wrong. Just
say what string must be passed to H for H to tell us whether or not Ĥ
applied to ⟨Ĥ⟩ halts, and then say what state H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to.

(I did a quick check and we are up to 60 times asked and not answered --
and that's just from me!)

--
Ben.
"the fact that a computation halts does not entail that it is a halting
computation" Peter Olcott

On 4/10/22 3:29 PM, olcott wrote:
> On 4/10/2022 2:17 PM, André G. Isaak wrote:
>> On 2022-04-10 10:35, olcott wrote:
>>> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>>>
>>>>>>>>>> You state that for the H you are championing
>>>>>>>>>>
>>>>>>>>>>        Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>>>
>>>>>>>>>> To see why this H is not a halt decider, you must answer the two
>>>>>>>>>> questions you are studiously avoiding.  What state does H <Ĥ> <Ĥ>
>>>>>>>>>> transition to, and what string must be passed to H for H to
>>>>>>>>>> tell us
>>>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>>>
>>>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>>>> The only plausible meaning for whether a string, s, is
>>>>>>>> non-halting is
>>>>>>>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts (according to
>>>>>>>> you).
>>>>>>>
>>>>>>> embedded_H contains a fully functional UTM.
>>>>>> So what?  It can contain a fully functional chess program for all
>>>>>> anyone
>>>>>> cares.  What matters is what "is the input to embedded_H non-halting"
>>>>>> means.  The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>)
>>>>>> halts, and
>>>>>> it does (according to you).
>>>>>>
>>>>>>> The correctly simulated input to embedded_H would never reach its
>>>>>>> own
>>>>>>> final state whether or not aborted by embedded_H.
>>>>>>
>>>>>> UTM(<Ĥ> <Ĥ>) halts (according to you).  Are you retracing that?
>>>>>> Or are
>>>>>> you now saying both at once?  We know you are quite happy to claim
>>>>>> flat-out contradictory facts at the same time.
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>
>>>> No once cares about this math poem.  You have invented some names to
>>>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk.  What
>>>> matters is that
>>>>
>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo  if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does not halt.
>>>>
>>>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its final
>>>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>>>>
>>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.  But what string must be passed to H for H to tell
>>>
>>> The above means this:
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>
>> Which is an entirely meaningless specification since you don't include
>> the necessary conditions which determine when H.qy and H.qn are reached.
>>
>> Why this is so difficult for you to grasp is beyond me.
>>
>> And I don't think you really understand what 'UTM' means. A UTM is a
>> TM which, when given a TM descroption <M> and an input string I
>> determines what the *result* of applying <M> to I would be. It doesn't
>> accept or reject its input based on whether it describes a halting
>> computation, so claiming you can just replace your embedded_H with a
>> UTM is nonsensical.
>>
>> André
>>
>
> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>
> IT IS THE CASE that the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
> embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under
> any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to specify a
> non-halting sequence of configurations.
>
> Ben knows that the above succinctly proves my point so he dismisses it
> as a math poem because Ben only cares about rebuttal and does not care
> about truth.
>
>

Except it ISN'T the case that the CORRECTLY simulation of the input to H
/ embedded_H, <H^ 0> <H^ 1>, never reaches its own final state.

That correct simulation has been shown, and it reaches H.Qn and Halts.

SO, you statement is just false.

It confuses the simulation that embedded_H does with the correct
simulation, so it is based on bad logic.

FAIL.

On 2022-04-10 15:00, olcott wrote:
> On 4/10/2022 3:15 PM, olcott wrote:
>> On 4/10/2022 3:07 PM, André G. Isaak wrote:

>>> I'm trying to get you to write using correct and coherent notation.
>>> That's one of the things you'll need to be able to do if you ever
>>> hope to publish. That involves remembering to always include
>>> conditions and using the same terms in your 'equations' as in your text.
>>>
>>> Not sure how that makes me a 'deceitful bastard'.
>>>
>>> André
>>>
>>
>> THAT you pretended to not know what I mean by embedded_H so that you
>> could artificially contrive a fake basis for rebuttal when no actual
>> basis for rebuttal exists makes you a deceitful bastard.
>
> IT IS THE CASE THAT the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
> embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under
> any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to specify a
> non-halting sequence of configurations.
>
> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn

This is now the third reply you've made to the same post.

That post didn't make any arguments whatsoever about your claims. It
simply pointed out that you are misusing your notation and urged you to
correct it.

In two of your three replies you *repeated* the flawed notation. In none
of your replies did you say anything related to my actual post.

André

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

On 4/10/2022 4:41 PM, Richard Damon wrote:
> On 4/10/22 5:00 PM, olcott wrote:
>> On 4/10/2022 3:15 PM, olcott wrote:
>>> On 4/10/2022 3:07 PM, André G. Isaak wrote:
>>>> On 2022-04-10 13:55, olcott wrote:
>>>>> On 4/10/2022 2:50 PM, André G. Isaak wrote:
>>>>>> On 2022-04-10 13:26, olcott wrote:
>>>>>>> On 4/10/2022 2:17 PM, André G. Isaak wrote:
>>>>>>>> On 2022-04-10 10:35, olcott wrote:
>>>>>>>>> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You state that for the H you are championing
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>        Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> To see why this H is not a halt decider, you must answer
>>>>>>>>>>>>>>>> the two
>>>>>>>>>>>>>>>> questions you are studiously avoiding.  What state does
>>>>>>>>>>>>>>>> H <Ĥ> <Ĥ>
>>>>>>>>>>>>>>>> transition to, and what string must be passed to H for H
>>>>>>>>>>>>>>>> to tell us
>>>>>>>>>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>>>>>>>>>> The only plausible meaning for whether a string, s, is
>>>>>>>>>>>>>> non-halting is
>>>>>>>>>>>>>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts
>>>>>>>>>>>>>> (according to you).
>>>>>>>>>>>>>
>>>>>>>>>>>>> embedded_H contains a fully functional UTM.
>>>>>>>>>>>> So what?  It can contain a fully functional chess program
>>>>>>>>>>>> for all anyone
>>>>>>>>>>>> cares.  What matters is what "is the input to embedded_H
>>>>>>>>>>>> non-halting"
>>>>>>>>>>>> means.  The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>)
>>>>>>>>>>>> halts, and
>>>>>>>>>>>> it does (according to you).
>>>>>>>>>>>>
>>>>>>>>>>>>> The correctly simulated input to embedded_H would never
>>>>>>>>>>>>> reach its own
>>>>>>>>>>>>> final state whether or not aborted by embedded_H.
>>>>>>>>>>>>
>>>>>>>>>>>> UTM(<Ĥ> <Ĥ>) halts (according to you).  Are you retracing
>>>>>>>>>>>> that? Or are
>>>>>>>>>>>> you now saying both at once?  We know you are quite happy to
>>>>>>>>>>>> claim
>>>>>>>>>>>> flat-out contradictory facts at the same time.
>>>>>>>>>>>
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>>>>>>
>>>>>>>>>> No once cares about this math poem.  You have invented some
>>>>>>>>>> names to
>>>>>>>>>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk.
>>>>>>>>>> What
>>>>>>>>>> matters is that
>>>>>>>>>>
>>>>>>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo  if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts,
>>>>>>>>>> and
>>>>>>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does
>>>>>>>>>> not halt.
>>>>>>>>>>
>>>>>>>>>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its
>>>>>>>>>>> final
>>>>>>>>>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>>>>>>>>>>
>>>>>>>>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.  But what string must be passed to H for H
>>>>>>>>>> to tell
>>>>>>>>>
>>>>>>>>> The above means this:
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>>
>>>>>>>> Which is an entirely meaningless specification since you don't
>>>>>>>> include the necessary conditions which determine when H.qy and
>>>>>>>> H.qn are reached.
>>>>>>>>
>>>>>>>> Why this is so difficult for you to grasp is beyond me.
>>>>>>>>
>>>>>>>> And I don't think you really understand what 'UTM' means. A UTM
>>>>>>>> is a TM which, when given a TM descroption <M> and an input
>>>>>>>> string I determines what the *result* of applying <M> to I would
>>>>>>>> be. It doesn't accept or reject its input based on whether it
>>>>>>>> describes a halting computation, so claiming you can just
>>>>>>>> replace your embedded_H with a UTM is nonsensical.
>>>>>>>>
>>>>>>>> André
>>>>>>>>
>>>>>>>
>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>>
>>>>>> And once again you omit the crucial conditions...
>>>>>>
>>>>>> You claim to want to be taken seriously. Using meaningless
>>>>>> notation is not the way to do this. The above could mean 'go to
>>>>>> H.qy' if ⟨Ĥ0⟩ ⟨Ĥ1⟩ ends in the symbol 0 or if ⟨Ĥ0⟩ ⟨Ĥ1⟩ doesn't
>>>>>> end in a 0 or if it is raining or pretty much anything else you
>>>>>> want it to mean. Without specifying a condition this says nothing
>>>>>> whatsoever about WHICH of the two final states should be reached.
>>>>>>
>>>>>>> If is the case that the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>>>>>>> embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or
>>>>>>> ⟨Ĥ0.qn⟩ under any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is
>>>>>>> proved to specify a non-halting sequence of configurations.
>>>>>>
>>>>>> if you want to talk about "embedded_H" at least employ a
>>>>>> specification which contains embedded_H. The (incomplete) one you
>>>>>> give above contains H, but no "embedded_H".
>>>>>
>>>>> The copy of the Linz H that it embedded in Ĥ is what I mean by
>>>>> embedded_H you deceitful bastard.
>>>>
>>>> I'm trying to get you to write using correct and coherent notation.
>>>> That's one of the things you'll need to be able to do if you ever
>>>> hope to publish. That involves remembering to always include
>>>> conditions and using the same terms in your 'equations' as in your
>>>> text.
>>>>
>>>> Not sure how that makes me a 'deceitful bastard'.
>>>>
>>>> André
>>>>
>>>
>>> THAT you pretended to not know what I mean by embedded_H so that you
>>> could artificially contrive a fake basis for rebuttal when no actual
>>> basis for rebuttal exists makes you a deceitful bastard.
>>
>> IT IS THE CASE THAT the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>> embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩
>> under any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to
>> specify a non-halting sequence of configurations.
>>
>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>
>>
>
> Except it ISN'T the case that the CORRECTLY simulation of the input to
> embedded_H, <H^ 0> <H^ 1>, never reaches its own final state.
>

On 4/10/22 5:38 PM, olcott wrote:
> On 4/10/2022 4:28 PM, olcott wrote:
>> On 4/10/2022 4:18 PM, Ben wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/10/2022 10:52 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/9/2022 5:54 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/9/2022 7:20 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> On 4/8/2022 4:08 PM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/7/2022 8:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/7/2022 6:37 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4/7/2022 10:51 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> THIS PROVES THAT I AM CORRECT
>>>>>>>>>>>>>>>>>> It is the case that the correctly simulated input to
>>>>>>>>>>>>>>>>>> embedded_H can
>>>>>>>>>>>>>>>>>> never possibly reach its own final state under any
>>>>>>>>>>>>>>>>>> condition at all.
>>>>>>>>>>>>>>>>>> Therefore embedded_H is necessarily correct to reject
>>>>>>>>>>>>>>>>>> its input.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yet you won't answer two simple questions!  Why?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Because I absolutely positively will not tolerate
>>>>>>>>>>>>>>>> divergence from
>>>>>>>>>>>>>>>> validating my 17 years worth of work.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But you have no choice but to tolerate it.  If someone
>>>>>>>>>>>>>>> wants to talk
>>>>>>>>>>>>>>> about why you are wrong, they will do so.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are wrong (for the C version of H) because H(P,P) ==
>>>>>>>>>>>>>>> false but P(P)
>>>>>>>>>>>>>>> halts.  You are wrong about your TM H because H <Ĥ> <Ĥ>
>>>>>>>>>>>>>>> transitions to
>>>>>>>>>>>>>>> qn, but Ĥ applied to <Ĥ> is a halting computation. (Feel
>>>>>>>>>>>>>>> free to deny
>>>>>>>>>>>>>>> any of these facts if the mood takes you.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If you believe (against the verified facts) that the
>>>>>>>>>>>>>> simulated ⟨Ĥ0⟩
>>>>>>>>>>>>>> reaches its final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩...
>>>>>>>>>>>>>
>>>>>>>>>>>>> I believe what you've told me: that you claim that
>>>>>>>>>>>>> H(P,P)==false is
>>>>>>>>>>>>> correct despite the fact that P(P) halts.  That's wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> If the input to H(P,P) cannot possibly reach its final state
>>>>>>>>>>>> then this
>>>>>>>>>>>> input is correctly rejected and nothing in the universe can
>>>>>>>>>>>> possibly
>>>>>>>>>>>> contradict this.
>>>>>>>>>>>
>>>>>>>>>>> Agreed facts: (1) H(P,P) == false, (2) P(P) halts.  You don't
>>>>>>>>>>> dispute
>>>>>>>>>>> either (indeed they come from you).
>>>>>>>>> At least you don't contend these facts.
>>>>>>>>>
>>>>>>>>>>> Your new line in waffle is just an attempt to distract
>>>>>>>>>>> attention from a
>>>>>>>>>>> very simple claim: that the wrong answer is the right one.
>>>>>>>>>>
>>>>>>>>>> Even Linz got this wrong because it is counter-intuitive.
>>>>>>>>>>
>>>>>>>>>> A halt decider must compute the mapping from its inputs (not
>>>>>>>>>> any damn
>>>>>>>>>> thing else in the universe) to its own final state on the
>>>>>>>>>> basis of the
>>>>>>>>>> behavior specified by these inputs
>>>>>>>>>
>>>>>>>>> That's not counter intuitive, it's basic.  Everyone knows this,
>>>>>>>>> though
>>>>>>>>> it took you a while to get round to it.  A halt decider accepts or
>>>>>>>>> rejects a string based on the behaviour of the computation
>>>>>>>>> specified by
>>>>>>>>> that string.  Of course, you never got as far in my exercises as
>>>>>>>>> specifying any TM that decides something on the basis of
>>>>>>>>> behaviour, so
>>>>>>>>> you really don't know how it's actually done.  That was, I
>>>>>>>>> thought, the
>>>>>>>>> whole point of the exercises -- to see how TMs are specified to
>>>>>>>>> decide
>>>>>>>>> properties of computations.
>>>>>>>>
>>>>>>>> You have to actually pay attention to this,
>>>>>>>
>>>>>>> Flip, flop!  Back to being wrong about TMs rather than being
>>>>>>> wrong about
>>>>>>> your old C junk.  These uncontested facts: (1) H(P,P) == false,
>>>>>>> (2) P(P)
>>>>>>> halts are why your H and P are wrong.
>>>>>>
>>>>>> If you are able to break the problem down to it micro component parts
>>>>>> and carefully analyze each of these separately instead of simply
>>>>>> slipping down the slide of intuition then you can see that I am
>>>>>> correct.
>>>>>>
>>>>>> If it is true that the correct simulation input to H(P,P) cannot
>>>>>> possibly reach its own final state then
>>>>>>
>>>>>> The input to H(P,P) is non-halting then
>>>>> There is no "input to H(P,P)".
>>>>
>>>> The correct simulation of the input to H
>>>
>>> Better.  I still would not call it "input" (since these are C functions)
>>> but you've got the hang of what am saying.  Well done.
>>>
>>>> cannot possibly ever reach it final state thus is a non-halting
>>>> sequence of configurations even if everyone and everything in the
>>>> universe disagrees.
>>>
>>> The truth is not determined by who does or does not agree with
>>> something.  But to find the truth of the matter you must first stop
>>> talking literal nonsense.  The arguments to H (what you call the
>>> "input") are two pointers.  What does simulating two pointers mean?
>>> What you mean, I hope, is simulating calling the first pointer with the
>>> second as it's argument.  That simulation, according to you, will halt
>>> (or "reach it's final state" in your flamboyant, sciencey, language).
>>> It will halt because the direct call P(P) halts.  Everything here halts
>>> (according to you).  That's why H is wrong.
>>>
>>
>> You simply are ignoring the actual execution trace that conclusively
>> proves that the simulated input to H cannot possibly reach its final
>> own state.
>
> _P()
> [00000956](01)  55              push ebp
> [00000957](02)  8bec            mov ebp,esp
> [00000959](03)  8b4508          mov eax,[ebp+08]
> [0000095c](01)  50              push eax
> [0000095d](03)  8b4d08          mov ecx,[ebp+08]
> [00000960](01)  51              push ecx
> [00000961](05)  e8c0feffff      call 00000826
>
> // THE SIMULATED INPUT CAN'T POSSIBLY GET PAST THE ABOVE LINE
>
> [00000966](03)  83c408          add esp,+08
> [00000969](02)  85c0            test eax,eax
> [0000096b](02)  7402            jz 0000096f
> [0000096d](02)  ebfe            jmp 0000096d
> [0000096f](01)  5d              pop ebp
> [00000970](01)  c3              ret        // THIS IS THE FINAL STATE
> Size in bytes:(0027) [00000970]
>
>
>

On 4/10/2022 4:41 PM, Ben wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>>
>>>>>>>>> You state that for the H you are championing
>>>>>>>>>
>>>>>>>>> Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>>
>>>>>>>>> To see why this H is not a halt decider, you must answer the two
>>>>>>>>> questions you are studiously avoiding. What state does H <Ĥ> <Ĥ>
>>>>>>>>> transition to, and what string must be passed to H for H to tell us
>>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>>
>>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>>> The only plausible meaning for whether a string, s, is non-halting is
>>>>>>> whether UTM(s) is non-halting. UTM(<Ĥ> <Ĥ>) halts (according to you).
>>>>>>
>>>>>> embedded_H contains a fully functional UTM.
>>>>> So what? It can contain a fully functional chess program for all anyone
>>>>> cares. What matters is what "is the input to embedded_H non-halting"
>>>>> means. The only sane meaning is whether or not UTM(<Ĥ> <Ĥ>) halts, and
>>>>> it does (according to you).
>>>>>
>>>>>> The correctly simulated input to embedded_H would never reach its own
>>>>>> final state whether or not aborted by embedded_H.
>>>>>
>>>>> UTM(<Ĥ> <Ĥ>) halts (according to you). Are you retracing that? Or are
>>>>> you now saying both at once? We know you are quite happy to claim
>>>>> flat-out contradictory facts at the same time.
>>>>
>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>> No once cares about this math poem. You have invented some names to
>>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk. What
>>> matters is that
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts, and
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does not halt.
>>>
>>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches its final
>>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts. But what string must be passed to H for H to tell
>>
>> The above means this:
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>
> That's funny! You really have no idea what this notation means, do you?
>
>> embedded_H is a simulating halt decider that has a full UTM embedded
>> within it. As soon as it sees that the pure UTM simulation of its
>> input would never reach the final state of this input it aborts this
>> simulation and rejects this non-halting input.
>
> So you had no business writing those two junk lines, did you? Or do you
> really think that they are in some way compatible with that last
> paragraph? Probably neither. I really think you see it much like
> poetry. Meanings are supposed to be intuited from unusual, often
> metaphorical, juxtapositions of symbols.
>

Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn

THE CORRECT SIMULATION OF THE INPUT TO EMBEDDED_H NEVER REACHES ITS
FINAL STATE

CORRECTLY SIMULATED INPUT TO H(P,P)

_P()
[00000956](01) 55 push ebp
[00000957](02) 8bec mov ebp,esp
[00000959](03) 8b4508 mov eax,[ebp+08]
[0000095c](01) 50 push eax
[0000095d](03) 8b4d08 mov ecx,[ebp+08]
[00000960](01) 51 push ecx
[00000961](05) e8c0feffff call 00000826

NEVER GET PAST HERE

[00000966](03) 83c408 add esp,+08
[00000969](02) 85c0 test eax,eax
[0000096b](02) 7402 jz 0000096f
[0000096d](02) ebfe jmp 0000096d
[0000096f](01) 5d pop ebp

TO GET TO HERE
[00000970](01) c3 ret
Size in bytes:(0027) [00000970]

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 4/10/2022 4:49 PM, André G. Isaak wrote:
> On 2022-04-10 15:00, olcott wrote:
>> On 4/10/2022 3:15 PM, olcott wrote:
>>> On 4/10/2022 3:07 PM, André G. Isaak wrote:
>
>>>> I'm trying to get you to write using correct and coherent notation.
>>>> That's one of the things you'll need to be able to do if you ever
>>>> hope to publish. That involves remembering to always include
>>>> conditions and using the same terms in your 'equations' as in your
>>>> text.
>>>>
>>>> Not sure how that makes me a 'deceitful bastard'.
>>>>
>>>> André
>>>>
>>>
>>> THAT you pretended to not know what I mean by embedded_H so that you
>>> could artificially contrive a fake basis for rebuttal when no actual
>>> basis for rebuttal exists makes you a deceitful bastard.
>>
>> IT IS THE CASE THAT the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>> embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩
>> under any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to
>> specify a non-halting sequence of configurations.
>>
>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>
> This is now the third reply you've made to the same post.
>
> That post didn't make any arguments whatsoever about your claims. It
> simply pointed out that you are misusing your notation and urged you to
> correct it.
>

THE NOTATION IS A STIPULATIVE DEFINITION THUS DISAGREEMENT IS INCORRECT.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer

On 4/10/22 5:51 PM, olcott wrote:
> On 4/10/2022 4:41 PM, Richard Damon wrote:
>> On 4/10/22 5:00 PM, olcott wrote:
>>> On 4/10/2022 3:15 PM, olcott wrote:
>>>> On 4/10/2022 3:07 PM, André G. Isaak wrote:
>>>>> On 2022-04-10 13:55, olcott wrote:
>>>>>> On 4/10/2022 2:50 PM, André G. Isaak wrote:
>>>>>>> On 2022-04-10 13:26, olcott wrote:
>>>>>>>> On 4/10/2022 2:17 PM, André G. Isaak wrote:
>>>>>>>>> On 2022-04-10 10:35, olcott wrote:
>>>>>>>>>> On 4/10/2022 11:14 AM, Ben Bacarisse wrote:
>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>
>>>>>>>>>>>> On 4/10/2022 10:22 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/9/2022 7:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4/9/2022 5:25 PM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You state that for the H you are championing
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>        Ĥ.q0 <Ĥ> ⊦* Ĥ.qx <Ĥ> <Ĥ> ⊦* Ĥ.qn.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> To see why this H is not a halt decider, you must
>>>>>>>>>>>>>>>>> answer the two
>>>>>>>>>>>>>>>>> questions you are studiously avoiding.  What state does
>>>>>>>>>>>>>>>>> H <Ĥ> <Ĥ>
>>>>>>>>>>>>>>>>> transition to, and what string must be passed to H for
>>>>>>>>>>>>>>>>> H to tell us
>>>>>>>>>>>>>>>>> whether or not Ĥ applied to <Ĥ> halts or not?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is the input to embedded_H non-halting? YES
>>>>>>>>>>>>>>> The only plausible meaning for whether a string, s, is
>>>>>>>>>>>>>>> non-halting is
>>>>>>>>>>>>>>> whether UTM(s) is non-halting.  UTM(<Ĥ> <Ĥ>) halts
>>>>>>>>>>>>>>> (according to you).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> embedded_H contains a fully functional UTM.
>>>>>>>>>>>>> So what?  It can contain a fully functional chess program
>>>>>>>>>>>>> for all anyone
>>>>>>>>>>>>> cares.  What matters is what "is the input to embedded_H
>>>>>>>>>>>>> non-halting"
>>>>>>>>>>>>> means.  The only sane meaning is whether or not UTM(<Ĥ>
>>>>>>>>>>>>> <Ĥ>) halts, and
>>>>>>>>>>>>> it does (according to you).
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The correctly simulated input to embedded_H would never
>>>>>>>>>>>>>> reach its own
>>>>>>>>>>>>>> final state whether or not aborted by embedded_H.
>>>>>>>>>>>>>
>>>>>>>>>>>>> UTM(<Ĥ> <Ĥ>) halts (according to you).  Are you retracing
>>>>>>>>>>>>> that? Or are
>>>>>>>>>>>>> you now saying both at once?  We know you are quite happy
>>>>>>>>>>>>> to claim
>>>>>>>>>>>>> flat-out contradictory facts at the same time.
>>>>>>>>>>>>
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>>>>>>>
>>>>>>>>>>> No once cares about this math poem.  You have invented some
>>>>>>>>>>> names to
>>>>>>>>>>> cloak your mistakes, but unless ⟨Ĥ0⟩=⟨Ĥ1⟩=⟨Ĥ2⟩=⟨Ĥ⟩ it's junk.
>>>>>>>>>>> What
>>>>>>>>>>> matters is that
>>>>>>>>>>>
>>>>>>>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy ⊦* oo  if UTM(⟨Ĥ⟩ ⟨Ĥ⟩)
>>>>>>>>>>> halts, and
>>>>>>>>>>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn        if UTM(⟨Ĥ⟩ ⟨Ĥ⟩) does
>>>>>>>>>>> not halt.
>>>>>>>>>>>
>>>>>>>>>>>> The simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to embedded_H never reaches
>>>>>>>>>>>> its final
>>>>>>>>>>>> state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩ under any condition what-so-ever
>>>>>>>>>>>
>>>>>>>>>>> UTM(⟨Ĥ⟩ ⟨Ĥ⟩) halts.  But what string must be passed to H for
>>>>>>>>>>> H to tell
>>>>>>>>>>
>>>>>>>>>> The above means this:
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qy
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* UTM ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>>>>>
>>>>>>>>> Which is an entirely meaningless specification since you don't
>>>>>>>>> include the necessary conditions which determine when H.qy and
>>>>>>>>> H.qn are reached.
>>>>>>>>>
>>>>>>>>> Why this is so difficult for you to grasp is beyond me.
>>>>>>>>>
>>>>>>>>> And I don't think you really understand what 'UTM' means. A UTM
>>>>>>>>> is a TM which, when given a TM descroption <M> and an input
>>>>>>>>> string I determines what the *result* of applying <M> to I
>>>>>>>>> would be. It doesn't accept or reject its input based on
>>>>>>>>> whether it describes a halting computation, so claiming you can
>>>>>>>>> just replace your embedded_H with a UTM is nonsensical.
>>>>>>>>>
>>>>>>>>> André
>>>>>>>>>
>>>>>>>>
>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>>>>>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>>>>>
>>>>>>> And once again you omit the crucial conditions...
>>>>>>>
>>>>>>> You claim to want to be taken seriously. Using meaningless
>>>>>>> notation is not the way to do this. The above could mean 'go to
>>>>>>> H.qy' if ⟨Ĥ0⟩ ⟨Ĥ1⟩ ends in the symbol 0 or if ⟨Ĥ0⟩ ⟨Ĥ1⟩ doesn't
>>>>>>> end in a 0 or if it is raining or pretty much anything else you
>>>>>>> want it to mean. Without specifying a condition this says nothing
>>>>>>> whatsoever about WHICH of the two final states should be reached.
>>>>>>>
>>>>>>>> If is the case that the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>>>>>>>> embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or
>>>>>>>> ⟨Ĥ0.qn⟩ under any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is
>>>>>>>> proved to specify a non-halting sequence of configurations.
>>>>>>>
>>>>>>> if you want to talk about "embedded_H" at least employ a
>>>>>>> specification which contains embedded_H. The (incomplete) one you
>>>>>>> give above contains H, but no "embedded_H".
>>>>>>
>>>>>> The copy of the Linz H that it embedded in Ĥ is what I mean by
>>>>>> embedded_H you deceitful bastard.
>>>>>
>>>>> I'm trying to get you to write using correct and coherent notation.
>>>>> That's one of the things you'll need to be able to do if you ever
>>>>> hope to publish. That involves remembering to always include
>>>>> conditions and using the same terms in your 'equations' as in your
>>>>> text.
>>>>>
>>>>> Not sure how that makes me a 'deceitful bastard'.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> THAT you pretended to not know what I mean by embedded_H so that you
>>>> could artificially contrive a fake basis for rebuttal when no actual
>>>> basis for rebuttal exists makes you a deceitful bastard.
>>>
>>> IT IS THE CASE THAT the correctly simulated input ⟨Ĥ0⟩ ⟨Ĥ1⟩ to
>>> embedded_H never reaches its own final state of ⟨Ĥ0.qy⟩ or ⟨Ĥ0.qn⟩
>>> under any condition what-so-ever therefore ⟨Ĥ0⟩ ⟨Ĥ1⟩ is proved to
>>> specify a non-halting sequence of configurations.
>>>
>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ1⟩ ⊢* H.qy
>>> Ĥ.q0 ⟨Ĥ0⟩ ⊢* H ⟨Ĥ0⟩ ⟨Ĥ2⟩ ⊢* H.qn
>>>
>>>
>>
>> Except it ISN'T the case that the CORRECTLY simulation of the input to
>> embedded_H, <H^ 0> <H^ 1>, never reaches its own final state.
>>
>
> It is simply over your head.
>
> _P()
> [00000956](01)  55              push ebp
> [00000957](02)  8bec            mov ebp,esp
> [00000959](03)  8b4508          mov eax,[ebp+08]
> [0000095c](01)  50              push eax
> [0000095d](03)  8b4d08          mov ecx,[ebp+08]
> [00000960](01)  51              push ecx
> [00000961](05)  e8c0feffff      call 00000826  // CALL H(P,P)
>
> THE CORRECT SIMULATION OF P NEVER GETS PAST HERE
>
> [00000966](03)  83c408          add esp,+08
> [00000969](02)  85c0            test eax,eax
> [0000096b](02)  7402            jz 0000096f
> [0000096d](02)  ebfe            jmp 0000096d
> [0000096f](01)  5d              pop ebp
> [00000970](01)  c3              ret   // THIS IS THE FINAL STATE
> Size in bytes:(0027) [00000970]
>
>
>