On 8/11/2021 5:40 PM, olcott wrote:
> On 8/11/2021 6:32 PM, Jeff Barnett wrote:
>> On 8/11/2021 5:04 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>
>>> I see you are in "paste the same text" again mode.  If you think I can
>>> help in any way, do let me know.
>>
>> That's not nice. Aren't you afraid that he'll develop carpal tunnel
>> syndrome? That along with all of his other deficiencies will surely do
>> him in. Perhaps we can invent shortcuts a la LaTeX macros and font
>> switches to help him cut down the strain. He wont be insulted and will
>> take to it as a pig to mud. Just think, he'll have yet another
>> notation to misuse and abuse.
>
> Ben finally acknowledged the point that I was making:
>
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
> if M applied to wM halts, and
>
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
> if M applied to wM does not halt
>
> // M refers to the TM of the first wM parameter to Ĥ.qx
>
> My proof requires a whole inference chain that cannot proceed to the
> next point until the current point is accepted as correct.

In addition to carpal tunnel, you are delusional. I get the vague
impression reading the above that you are having a schizoid episode.
There is a complete and total discount between what others say to you
and your replies. I suggest you cut out some of the examples you like
best and show them to your therapist. You do have one, don't you? It may
lead to better, more effective treatment. We are all hoping you get
better but schizoid episodes are hard to suppress. I assume meds have
been prescribed for your condition. Are you taking them? Or are you
refusing medical help just as you refuse to allow Ben to heal your
ignorance. A little trust in your betters will go a long way towards
recovery and a cure. Start now before it's to late. God speed to you.
--
Jeff Barnett

On Thursday, 12 August 2021 at 06:11:30 UTC+1, Jeff Barnett wrote:
> On 8/11/2021 5:40 PM, olcott wrote:
> > On 8/11/2021 6:32 PM, Jeff Barnett wrote:
> >> On 8/11/2021 5:04 PM, Ben Bacarisse wrote:
> >>> olcott <No...@NoWhere.com> writes:
> >>>
> >>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
> >>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
> >>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
> >>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
> >>>
> >>> I see you are in "paste the same text" again mode. If you think I can
> >>> help in any way, do let me know.
> >>
> >> That's not nice. Aren't you afraid that he'll develop carpal tunnel
> >> syndrome? That along with all of his other deficiencies will surely do
> >> him in. Perhaps we can invent shortcuts a la LaTeX macros and font
> >> switches to help him cut down the strain. He wont be insulted and will
> >> take to it as a pig to mud. Just think, he'll have yet another
> >> notation to misuse and abuse.
> >
> > Ben finally acknowledged the point that I was making:
> >
> > Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
> > if M applied to wM halts, and
> >
> > Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
> > if M applied to wM does not halt
> >
> > // M refers to the TM of the first wM parameter to Ĥ.qx
> >
> > My proof requires a whole inference chain that cannot proceed to the
> > next point until the current point is accepted as correct.
> In addition to carpal tunnel, you are delusional. I get the vague
> impression reading the above that you are having a schizoid episode.
> There is a complete and total discount between what others say to you
> and your replies. I suggest you cut out some of the examples you like
> best and show them to your therapist. You do have one, don't you? It may
> lead to better, more effective treatment. We are all hoping you get
> better but schizoid episodes are hard to suppress. I assume meds have
> been prescribed for your condition. Are you taking them? Or are you
> refusing medical help just as you refuse to allow Ben to heal your
> ignorance. A little trust in your betters will go a long way towards
> recovery and a cure. Start now before it's to late. God speed to you.
> -
YOu might be right, but I think it's just frustration. His execution trace shows
what appears to be an infinitely recursive process aborted, and everyone is
just ignoring that and focusing on the other reality that his H does not
return the result that matches the behaviour of the input when run independently.

The attempt to use formal math notation when he doesn't understand it
doesn't help. That can create the impression of mental incoherence, but in fact
it's not that.

Despite a mass of posting, we still don't have a good idea how H works.
Academics answer questions about how their programs work. However there's
also politeness. I once sat in a lecture where the lecturer was claiming
marvellous properties for his substance - I think it was an ogliopeptide.
I made the remark quietly to a friend "he'll be claiming it cures cancer next".
Sure enough, we then heard a claim that the ogliopeptide had anti-cancer
properties. I discussed it with my friend over lunch. We agreed that no-one
believed him, and no-one said that. So I asked where the results came from.
My friend said he suspected he was using extremely high concentrations and
measuring marginal effects - in biochemical terms, that basically means that
your results aren't meaningful. However, again, no-one said that.

However if PO is ill, he should seek help.

On 8/11/21 10:28 AM, olcott wrote:
> On 8/10/2021 9:26 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/10/2021 8:41 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/10/2021 7:42 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 8/7/2021 7:34 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> On 8/5/2021 9:36 PM, Ben Bacarisse wrote:
>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>
>>>>>>>>>>> On 8/5/2021 5:14 PM, Ben Bacarisse wrote:
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>>      
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>
>>>>>>>>>>>>> The question is not: Does Ĥ halt on its input?
>>>>>>>>>>>> Yes it is.
>>>>>>>>>>>
>>>>>>>>>>> The question is:
>>>>>>>>>>> Does the Ĥ specified by the first ⟨Ĥ⟩ halt on its input ⟨Ĥ⟩ ?
>>>>>>>>>>> The ansswer to this question is provably no!
>>>>>>>>>> The question is: does Ĥ applied to ⟨Ĥ⟩ halt.  It does:
>>>>>>>>>>
>>>>>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn  THIS IS NOT A CONTRADICTION
>>>>>>>>>> Indeed.  There is no contradiction.  Just an Ĥ that does not
>>>>>>>>>> meet Linz
>>>>>>>>>> spec.
>>>>>>>>>
>>>>>>>>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn is correct and forms no contradiction.
>>>>>>>>> Because it is correct it meets the Linz spec.
>>>>>>>> I find it startling that you think that, but then it seems you
>>>>>>>> don't yet
>>>>>>>> know what the key words mean:
>>>>>>>>
>>>>>>>>> if M applied to wM does not halt
>>>>>>>>> means if the execution of the machine of the first ⟨Ĥ⟩ on its
>>>>>>>>> input of
>>>>>>>>> the seocond ⟨Ĥ⟩ does not halt then ⊢* Ĥ.qn
>>>>>>>> No.  Would you like to know "what M applied to wM does not halt"
>>>>>>>> means?
>>>>>>>> Do you need help to see that "Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn" is clearly a
>>>>>>>> case of "M
>>>>>>>> applied to wM halts"?
>>>>>>>
>>>>>>>         the Turing machine halting problem. Simply stated, the
>>>>>>> problem
>>>>>>>         is: given the description of a Turing machine M and an
>>>>>>> input w,
>>>>>>>         does M, when started in the initial configuration q0w,
>>>>>>> perform a
>>>>>>>         computation that eventually halts? (Linz:1990:317).
>>>>>> Yes.  I was offering to help you understand the key words in that
>>>>>> text.
>>>>>>
>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>> You've missed off the key lines yet again.  Is that deliberate?  They
>>>>>> are the lines that show you are wrong so I am suspicious that you
>>>>>> keep
>>>>>> omitting them.
>>>>>>
>>>>>>> When Ĥ is applied to ⟨Ĥ⟩ the description of the Turing Machine
>>>>>>> and its
>>>>>>> input are specified as: ⟨Ĥ⟩ ⟨Ĥ⟩ for the embedded halt decider at
>>>>>>> Ĥ.qx.
>>>>>> Ungrammatical.
>>>>>>
>>>>>>> When Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn this is not a final state of the simulated
>>>>>>> input it is a final state of the executed Ĥ.
>>>>>> Yes.  You don't seem to know why that's wrong.
>>>>>
>>>>> What is your basis for believing that is wrong?
>>>> Ah, a question about what I'm saying.  I can help there.  The basis is
>>>> what Linz says about Ĥ.  He says that (translating to your notation)
>>>>     Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>> should be the case "if Ĥ applied to ⟨Ĥ⟩ does not halt".  But, as you
>>>> can
>>>> see, your Ĥ does halt when applied to ⟨Ĥ⟩ (qn is a halting or final
>>>> state).  Your Ĥ is not doing what it should in this one crucial case.
>>>>
>>>
>>>     the Turing machine halting problem. Simply stated, the problem
>>>     is: given the description of a Turing machine M and an input w,
>>>     does M, when started in the initial configuration q0w, perform a
>>>     computation that eventually halts? (Linz:1990:317).
>>
>> and so on.  Same old stuff.
>>
>
> When the challenge to support one's assertion with reasoning is simply
> ignored as you are ignoring it right now one can reasonably construe a
> deceptive intent.
>
> -- the Turing machine halting problem. Simply stated, the problem
> -- is: given the description of a Turing machine M and an input w,
> -- does M, when started in the initial configuration q0w, perform a
> -- computation that eventually halts? (Linz:1990:317).
>
> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>
> The input to H will be the description (encoded in some form) of M, say
> WM, as well as the input w. (Linz:1990:318)
>
> H.q0 WM w ⊢* H.qn
> if M applied to W does not halt.
>
>   becomes
>
> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
> if Ĥ applied to ⟨Ĥ⟩ does not halt.
>
>
> Pages of the Linz text to verify the above quotes in their full context:
> http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>
> M STILL REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO Ĥ.qx
> M STILL REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO Ĥ.qx
> M STILL REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO Ĥ.qx
> M STILL REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO Ĥ.qx
>
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
> if M applied to wM does not halt
>
> When we know that M refers to the Turing machine specified by the first
> wM then when Ĥ transitions to its final state of Ĥ.qn there is no direct
> contradiction formed.
>
> Can you admit when you are wrong when you really are wrong?
> Can you admit when you are wrong when you really are wrong?
> Can you admit when you are wrong when you really are wrong?
> Can you admit when you are wrong when you really are wrong?
>
> if M applied to wM does not halt (see above for definition of M)
> means when the Turing machine of ⟨Ĥ⟩ applied to ⟨Ĥ⟩ does not halt.
>
> Ĥ.q0 ⟨Ĥ⟩  ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> Ĥ.qx correctly transitions to its final state when the Ĥ.qx acts as a
> UTM and simulates ⟨Ĥ⟩ ⟨Ĥ⟩ and determines that this input never halts.
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>

But that input is also supposed to be the representation of H^, as that
is basic question being asked in the proof, can H give the right answer
for predicting what the machine H^(<H^>) does.

Since from the run of H^, we see that starting at H^.q0 <H^> we end up
at the halting state of H^.qn, we KNOW that H^(<H^>) is a Halting
computation, and thus that the input given to H represents a Halting
computation, thus the fact that H.q0 <H^> <H^> ends up at H.qn is a
wrong answer.

On 8/12/2021 3:36 AM, Malcolm McLean wrote:
> On Thursday, 12 August 2021 at 06:11:30 UTC+1, Jeff Barnett wrote:
>> On 8/11/2021 5:40 PM, olcott wrote:
>>> On 8/11/2021 6:32 PM, Jeff Barnett wrote:
>>>> On 8/11/2021 5:04 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>>>
>>>>> I see you are in "paste the same text" again mode. If you think I can
>>>>> help in any way, do let me know.
>>>>
>>>> That's not nice. Aren't you afraid that he'll develop carpal tunnel
>>>> syndrome? That along with all of his other deficiencies will surely do
>>>> him in. Perhaps we can invent shortcuts a la LaTeX macros and font
>>>> switches to help him cut down the strain. He wont be insulted and will
>>>> take to it as a pig to mud. Just think, he'll have yet another
>>>> notation to misuse and abuse.
>>>
>>> Ben finally acknowledged the point that I was making:
>>>
>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>> if M applied to wM halts, and
>>>
>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>> if M applied to wM does not halt
>>>
>>> // M refers to the TM of the first wM parameter to Ĥ.qx
>>>
>>> My proof requires a whole inference chain that cannot proceed to the
>>> next point until the current point is accepted as correct.
>> In addition to carpal tunnel, you are delusional. I get the vague
>> impression reading the above that you are having a schizoid episode.
>> There is a complete and total discount between what others say to you
>> and your replies. I suggest you cut out some of the examples you like
>> best and show them to your therapist. You do have one, don't you? It may
>> lead to better, more effective treatment. We are all hoping you get
>> better but schizoid episodes are hard to suppress. I assume meds have
>> been prescribed for your condition. Are you taking them? Or are you
>> refusing medical help just as you refuse to allow Ben to heal your
>> ignorance. A little trust in your betters will go a long way towards
>> recovery and a cure. Start now before it's to late. God speed to you.
>> -
> YOu might be right, but I think it's just frustration. His execution trace shows
> what appears to be an infinitely recursive process aborted, and everyone is
> just ignoring that and focusing on the other reality that his H does not
> return the result that matches the behaviour of the input when run independently.
>
> The attempt to use formal math notation when he doesn't understand it
> doesn't help. That can create the impression of mental incoherence, but in fact
> it's not that.
>
> Despite a mass of posting, we still don't have a good idea how H works.

_P()
[00000d02](01) 55 push ebp
[00000d03](02) 8bec mov ebp,esp
[00000d05](03) 8b4508 mov eax,[ebp+08]
[00000d08](01) 50 push eax // push 2nd Param
[00000d09](03) 8b4d08 mov ecx,[ebp+08]
[00000d0c](01) 51 push ecx // push 1st Param
[00000d0d](05) e870feffff call 00000b82 // call H
[00000d12](03) 83c408 add esp,+08
[00000d15](02) 85c0 test eax,eax
[00000d17](02) 7402 jz 00000d1b
[00000d19](02) ebfe jmp 00000d19
[00000d1b](01) 5d pop ebp
[00000d1c](01) c3 ret
Size in bytes:(0027) [00000d1c]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00000d0d][00101829][00000d12] e870feffff call 00000b82 // call H

Begin Local Halt Decider Simulation at Machine Address:d02
....[00000d02][002118f1][002118f5] 55 push ebp
....[00000d03][002118f1][002118f5] 8bec mov ebp,esp
....[00000d05][002118f1][002118f5] 8b4508 mov eax,[ebp+08]
....[00000d08][002118ed][00000d02] 50 push eax // push P
....[00000d09][002118ed][00000d02] 8b4d08 mov ecx,[ebp+08]
....[00000d0c][002118e9][00000d02] 51 push ecx // push P
....[00000d0d][002118e5][00000d12] e870feffff call 00000b82 // call H

....[00000d02][0025c319][0025c31d] 55 push ebp
....[00000d03][0025c319][0025c31d] 8bec mov ebp,esp
....[00000d05][0025c319][0025c31d] 8b4508 mov eax,[ebp+08]
....[00000d08][0025c315][00000d02] 50 push eax // push P
....[00000d09][0025c315][00000d02] 8b4d08 mov ecx,[ebp+08]
....[00000d0c][0025c311][00000d02] 51 push ecx // push P
....[00000d0d][0025c30d][00000d12] e870feffff call 00000b82 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

If this means that you are telling me that:
(1) You know the x86 language very well.

(2) Can't begin to understand why P would be stuck in infinitely nested
simulation while H acts as a pure simulator?

I would say that you must be a liar.

> Academics answer questions about how their programs work. However there's
> also politeness. I once sat in a lecture where the lecturer was claiming
> marvellous properties for his substance - I think it was an ogliopeptide.
> I made the remark quietly to a friend "he'll be claiming it cures cancer next".
> Sure enough, we then heard a claim that the ogliopeptide had anti-cancer
> properties. I discussed it with my friend over lunch. We agreed that no-one
> believed him, and no-one said that. So I asked where the results came from.
> My friend said he suspected he was using extremely high concentrations and
> measuring marginal effects - in biochemical terms, that basically means that
> your results aren't meaningful. However, again, no-one said that.
>
> However if PO is ill, he should seek help.
>

--
Copyright 2021 Pete Olcott

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

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

> On Thursday, 12 August 2021 at 06:11:30 UTC+1, Jeff Barnett wrote:
>> On 8/11/2021 5:40 PM, olcott wrote:
>> > On 8/11/2021 6:32 PM, Jeff Barnett wrote:
>> >> On 8/11/2021 5:04 PM, Ben Bacarisse wrote:
>> >>> olcott <No...@NoWhere.com> writes:
>> >>>
>> >>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>> >>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>> >>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>> >>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>> >>>
>> >>> I see you are in "paste the same text" again mode. If you think I can
>> >>> help in any way, do let me know.
>> >>
>> >> That's not nice. Aren't you afraid that he'll develop carpal tunnel
>> >> syndrome? That along with all of his other deficiencies will surely do
>> >> him in. Perhaps we can invent shortcuts a la LaTeX macros and font
>> >> switches to help him cut down the strain. He wont be insulted and will
>> >> take to it as a pig to mud. Just think, he'll have yet another
>> >> notation to misuse and abuse.
>> >
>> > Ben finally acknowledged the point that I was making:
>> >
>> > Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>> > if M applied to wM halts, and
>> >
>> > Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>> > if M applied to wM does not halt
>> >
>> > // M refers to the TM of the first wM parameter to Ĥ.qx
>> >
>> > My proof requires a whole inference chain that cannot proceed to the
>> > next point until the current point is accepted as correct.
>> In addition to carpal tunnel, you are delusional. I get the vague
>> impression reading the above that you are having a schizoid episode.
>> There is a complete and total discount between what others say to you
>> and your replies. I suggest you cut out some of the examples you like
>> best and show them to your therapist. You do have one, don't you? It may
>> lead to better, more effective treatment. We are all hoping you get
>> better but schizoid episodes are hard to suppress. I assume meds have
>> been prescribed for your condition. Are you taking them? Or are you
>> refusing medical help just as you refuse to allow Ben to heal your
>> ignorance. A little trust in your betters will go a long way towards
>> recovery and a cure. Start now before it's to late. God speed to you.
>> -
> YOu might be right, but I think it's just frustration. His execution
> trace shows what appears to be an infinitely recursive process
> aborted, and everyone is just ignoring that and focusing on the other
> reality that his H does not return the result that matches the
> behaviour of the input when run independently.

Not everyone. I don't care about the traces (exact the one, never to be
repeated, that confirmed that H_Hat(H_Hat) halts) but they have been
picked over in great detail by many people. Even you remarked on them
not showing what he claimed.

> The attempt to use formal math notation when he doesn't understand it
> doesn't help. That can create the impression of mental incoherence,
> but in fact it's not that.

I think this is spot on. He writes formulas in a sort of poetic way,
where the intention is to hint at what he wants to communicate. Others
(like me) then come along and assume he meant what the formula
actually says.

And I've recently become convinced that the same is true of his use of
technical words. It's a mistake to assume that when he says "an actual
Turing machine" he is talking about an actual Turing machine. Halting
is a special kind of stopping, not what you or I would call halting. A
TM computation is probably "something that happens following rules"
rather than a sequence of TM configurations. He's admitted to using
poetic license, but it's deeper than that. Words, even technical ones,
are used to hint and suggest rather than to convey unambiguous meaning.

> Despite a mass of posting, we still don't have a good idea how H
> works.

There is no H, at least not in any final form. He does not know how to
nest invocations of the x86 simulator, so what he has right now is not
what he claims. His current "sketch" of H almost certainly just makes
calls, and something else detects the recursion (that's "the OS is the
halt detector"). He's sure that he can work the code into H one day and
everything will be fine.

> Academics answer questions about how their programs work. However there's
> also politeness.

And, for the most part, honesty. PO has failed at all of these. He
won't show H, he's not polite and he's not being honest. He has no
claim to be doing anything anyone would consider academic research.

> However if PO is ill, he should seek help.

Not only is he deluded but he has cancer (apparently). I really think
anything would be better for him than posting here. I know we could all
help by stopping posting ourselves, but it's just so tempting when one
is called a liar and/or ignorant (which it why cranks always do that).
Every now and then I fell bad for "poking the bear" and then he alters a
thread subject line to publicly impugn my character.

--
Ben.

On 8/12/2021 10:15 AM, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Thursday, 12 August 2021 at 06:11:30 UTC+1, Jeff Barnett wrote:
>>> On 8/11/2021 5:40 PM, olcott wrote:
>>>> On 8/11/2021 6:32 PM, Jeff Barnett wrote:
>>>>> On 8/11/2021 5:04 PM, Ben Bacarisse wrote:
>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>
>>>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>>>>
>>>>>> I see you are in "paste the same text" again mode. If you think I can
>>>>>> help in any way, do let me know.
>>>>>
>>>>> That's not nice. Aren't you afraid that he'll develop carpal tunnel
>>>>> syndrome? That along with all of his other deficiencies will surely do
>>>>> him in. Perhaps we can invent shortcuts a la LaTeX macros and font
>>>>> switches to help him cut down the strain. He wont be insulted and will
>>>>> take to it as a pig to mud. Just think, he'll have yet another
>>>>> notation to misuse and abuse.
>>>>
>>>> Ben finally acknowledged the point that I was making:
>>>>
>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>> if M applied to wM halts, and
>>>>
>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>> if M applied to wM does not halt
>>>>
>>>> // M refers to the TM of the first wM parameter to Ĥ.qx
>>>>
>>>> My proof requires a whole inference chain that cannot proceed to the
>>>> next point until the current point is accepted as correct.
>>> In addition to carpal tunnel, you are delusional. I get the vague
>>> impression reading the above that you are having a schizoid episode.
>>> There is a complete and total discount between what others say to you
>>> and your replies. I suggest you cut out some of the examples you like
>>> best and show them to your therapist. You do have one, don't you? It may
>>> lead to better, more effective treatment. We are all hoping you get
>>> better but schizoid episodes are hard to suppress. I assume meds have
>>> been prescribed for your condition. Are you taking them? Or are you
>>> refusing medical help just as you refuse to allow Ben to heal your
>>> ignorance. A little trust in your betters will go a long way towards
>>> recovery and a cure. Start now before it's to late. God speed to you.
>>> -
>> YOu might be right, but I think it's just frustration. His execution
>> trace shows what appears to be an infinitely recursive process
>> aborted, and everyone is just ignoring that and focusing on the other
>> reality that his H does not return the result that matches the
>> behaviour of the input when run independently.
>
> Not everyone. I don't care about the traces (exact the one, never to be
> repeated, that confirmed that H_Hat(H_Hat) halts) but they have been
> picked over in great detail by many people. Even you remarked on them
> not showing what he claimed.
>
>> The attempt to use formal math notation when he doesn't understand it
>> doesn't help. That can create the impression of mental incoherence,
>> but in fact it's not that.
>
> I think this is spot on. He writes formulas in a sort of poetic way,
> where the intention is to hint at what he wants to communicate. Others
> (like me) then come along and assume he meant what the formula
> actually says.
>
> And I've recently become convinced that the same is true of his use of
> technical words. It's a mistake to assume that when he says "an actual
> Turing machine" he is talking about an actual Turing machine. Halting
> is a special kind of stopping, not what you or I would call halting. A
> TM computation is probably "something that happens following rules"
> rather than a sequence of TM configurations. He's admitted to using
> poetic license, but it's deeper than that. Words, even technical ones,
> are used to hint and suggest rather than to convey unambiguous meaning.
>
>> Despite a mass of posting, we still don't have a good idea how H
>> works.
>

My response to Malcolm is quite succinct:

_P()
[00000d02](01) 55 push ebp
[00000d03](02) 8bec mov ebp,esp
[00000d05](03) 8b4508 mov eax,[ebp+08]
[00000d08](01) 50 push eax // push 2nd Param
[00000d09](03) 8b4d08 mov ecx,[ebp+08]
[00000d0c](01) 51 push ecx // push 1st Param
[00000d0d](05) e870feffff call 00000b82 // call H
[00000d12](03) 83c408 add esp,+08
[00000d15](02) 85c0 test eax,eax
[00000d17](02) 7402 jz 00000d1b
[00000d19](02) ebfe jmp 00000d19
[00000d1b](01) 5d pop ebp
[00000d1c](01) c3 ret
Size in bytes:(0027) [00000d1c]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00000d0d][00101829][00000d12] e870feffff call 00000b82 // call H

Begin Local Halt Decider Simulation at Machine Address:d02
....[00000d02][002118f1][002118f5] 55 push ebp
....[00000d03][002118f1][002118f5] 8bec mov ebp,esp
....[00000d05][002118f1][002118f5] 8b4508 mov eax,[ebp+08]
....[00000d08][002118ed][00000d02] 50 push eax // push P
....[00000d09][002118ed][00000d02] 8b4d08 mov ecx,[ebp+08]
....[00000d0c][002118e9][00000d02] 51 push ecx // push P
....[00000d0d][002118e5][00000d12] e870feffff call 00000b82 // call H

....[00000d02][0025c319][0025c31d] 55 push ebp
....[00000d03][0025c319][0025c31d] 8bec mov ebp,esp
....[00000d05][0025c319][0025c31d] 8b4508 mov eax,[ebp+08]
....[00000d08][0025c315][00000d02] 50 push eax // push P
....[00000d09][0025c315][00000d02] 8b4d08 mov ecx,[ebp+08]
....[00000d0c][0025c311][00000d02] 51 push ecx // push P
....[00000d0d][0025c30d][00000d12] e870feffff call 00000b82 // call H
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

If this means that you are telling me that:
(1) You know the x86 language very well.

(2) Can't begin to understand why P would be stuck in infinitely nested
simulation while H acts as a pure simulator?

I would say that you must be a liar.

> There is no H, at least not in any final form. He does not know how to
> nest invocations of the x86 simulator, so what he has right now is not
> what he claims. His current "sketch" of H almost certainly just makes
> calls, and something else detects the recursion (that's "the OS is the
> halt detector"). He's sure that he can work the code into H one day and
> everything will be fine.
>
>> Academics answer questions about how their programs work. However there's
>> also politeness.
>
> And, for the most part, honesty. PO has failed at all of these. He
> won't show H, he's not polite and he's not being honest. He has no
> claim to be doing anything anyone would consider academic research.
>
>> However if PO is ill, he should seek help.
>
> Not only is he deluded but he has cancer (apparently). I really think
> anything would be better for him than posting here. I know we could all
> help by stopping posting ourselves, but it's just so tempting when one
> is called a liar and/or ignorant (which it why cranks always do that).
> Every now and then I fell bad for "poking the bear" and then he alters a
> thread subject line to publicly impugn my character.
>

--
Copyright 2021 Pete Olcott

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

On Thursday, 12 August 2021 at 13:24:46 UTC+1, olcott wrote:
> On 8/12/2021 3:36 AM, Malcolm McLean wrote:
> > On Thursday, 12 August 2021 at 06:11:30 UTC+1, Jeff Barnett wrote:
> >> On 8/11/2021 5:40 PM, olcott wrote:
> >>> On 8/11/2021 6:32 PM, Jeff Barnett wrote:
> >>>> On 8/11/2021 5:04 PM, Ben Bacarisse wrote:
> >>>>> olcott <No...@NoWhere.com> writes:
> >>>>>
> >>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
> >>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
> >>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
> >>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
> >>>>>
> >>>>> I see you are in "paste the same text" again mode. If you think I can
> >>>>> help in any way, do let me know.
> >>>>
> >>>> That's not nice. Aren't you afraid that he'll develop carpal tunnel
> >>>> syndrome? That along with all of his other deficiencies will surely do
> >>>> him in. Perhaps we can invent shortcuts a la LaTeX macros and font
> >>>> switches to help him cut down the strain. He wont be insulted and will
> >>>> take to it as a pig to mud. Just think, he'll have yet another
> >>>> notation to misuse and abuse.
> >>>
> >>> Ben finally acknowledged the point that I was making:
> >>>
> >>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
> >>> if M applied to wM halts, and
> >>>
> >>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
> >>> if M applied to wM does not halt
> >>>
> >>> // M refers to the TM of the first wM parameter to Ĥ.qx
> >>>
> >>> My proof requires a whole inference chain that cannot proceed to the
> >>> next point until the current point is accepted as correct.
> >> In addition to carpal tunnel, you are delusional. I get the vague
> >> impression reading the above that you are having a schizoid episode.
> >> There is a complete and total discount between what others say to you
> >> and your replies. I suggest you cut out some of the examples you like
> >> best and show them to your therapist. You do have one, don't you? It may
> >> lead to better, more effective treatment. We are all hoping you get
> >> better but schizoid episodes are hard to suppress. I assume meds have
> >> been prescribed for your condition. Are you taking them? Or are you
> >> refusing medical help just as you refuse to allow Ben to heal your
> >> ignorance. A little trust in your betters will go a long way towards
> >> recovery and a cure. Start now before it's to late. God speed to you.
> >> -
> > YOu might be right, but I think it's just frustration. His execution trace shows
> > what appears to be an infinitely recursive process aborted, and everyone is
> > just ignoring that and focusing on the other reality that his H does not
> > return the result that matches the behaviour of the input when run independently.
> >
> > The attempt to use formal math notation when he doesn't understand it
> > doesn't help. That can create the impression of mental incoherence, but in fact
> > it's not that.
> >
> > Despite a mass of posting, we still don't have a good idea how H works.
> _P()
> [00000d02](01) 55 push ebp
> [00000d03](02) 8bec mov ebp,esp
> [00000d05](03) 8b4508 mov eax,[ebp+08]
> [00000d08](01) 50 push eax // push 2nd Param
> [00000d09](03) 8b4d08 mov ecx,[ebp+08]
> [00000d0c](01) 51 push ecx // push 1st Param
> [00000d0d](05) e870feffff call 00000b82 // call H
> [00000d12](03) 83c408 add esp,+08
> [00000d15](02) 85c0 test eax,eax
> [00000d17](02) 7402 jz 00000d1b
> [00000d19](02) ebfe jmp 00000d19
> [00000d1b](01) 5d pop ebp
> [00000d1c](01) c3 ret
> Size in bytes:(0027) [00000d1c]
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= ============> ...[00000d0d][00101829][00000d12] e870feffff call 00000b82 // call H
>
> Begin Local Halt Decider Simulation at Machine Address:d02
> ...[00000d02][002118f1][002118f5] 55 push ebp
> ...[00000d03][002118f1][002118f5] 8bec mov ebp,esp
> ...[00000d05][002118f1][002118f5] 8b4508 mov eax,[ebp+08]
> ...[00000d08][002118ed][00000d02] 50 push eax // push P
> ...[00000d09][002118ed][00000d02] 8b4d08 mov ecx,[ebp+08]
> ...[00000d0c][002118e9][00000d02] 51 push ecx // push P
> ...[00000d0d][002118e5][00000d12] e870feffff call 00000b82 // call H
>
> ...[00000d02][0025c319][0025c31d] 55 push ebp
> ...[00000d03][0025c319][0025c31d] 8bec mov ebp,esp
> ...[00000d05][0025c319][0025c31d] 8b4508 mov eax,[ebp+08]
> ...[00000d08][0025c315][00000d02] 50 push eax // push P
> ...[00000d09][0025c315][00000d02] 8b4d08 mov ecx,[ebp+08]
> ...[00000d0c][0025c311][00000d02] 51 push ecx // push P
> ...[00000d0d][0025c30d][00000d12] e870feffff call 00000b82 // call H
> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
> If this means that you are telling me that:
> (1) You know the x86 language very well.
>
> (2) Can't begin to understand why P would be stuck in infinitely nested
> simulation while H acts as a pure simulator?
>
OK, so let's start.
There's a line which says "Begin Local Halt Decider Simulation at Machine
Address:d02". Is that part of the execution trace, or is it a commented added
by hand? If it is part of the execution trace, why doesn't this line appear
before the second line with the label 0d02?
>
> I would say that you must be a liar.
>
I have a PhD. PhD holder attach a very high value to honesty, in particular
with respect to their subjects. But also more generally. I always draw attention
if I'm given too much change at the pub, for example, not becaue I'm better
than other people, but because I'm a doctor, and a doctor can't be seen to
take money that doesn't belong to him.

On 8/12/2021 10:40 AM, Malcolm McLean wrote:
> On Thursday, 12 August 2021 at 13:24:46 UTC+1, olcott wrote:
>> On 8/12/2021 3:36 AM, Malcolm McLean wrote:
>>> On Thursday, 12 August 2021 at 06:11:30 UTC+1, Jeff Barnett wrote:
>>>> On 8/11/2021 5:40 PM, olcott wrote:
>>>>> On 8/11/2021 6:32 PM, Jeff Barnett wrote:
>>>>>> On 8/11/2021 5:04 PM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>>
>>>>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>>>>>
>>>>>>> I see you are in "paste the same text" again mode. If you think I can
>>>>>>> help in any way, do let me know.
>>>>>>
>>>>>> That's not nice. Aren't you afraid that he'll develop carpal tunnel
>>>>>> syndrome? That along with all of his other deficiencies will surely do
>>>>>> him in. Perhaps we can invent shortcuts a la LaTeX macros and font
>>>>>> switches to help him cut down the strain. He wont be insulted and will
>>>>>> take to it as a pig to mud. Just think, he'll have yet another
>>>>>> notation to misuse and abuse.
>>>>>
>>>>> Ben finally acknowledged the point that I was making:
>>>>>
>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>>> if M applied to wM halts, and
>>>>>
>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>> if M applied to wM does not halt
>>>>>
>>>>> // M refers to the TM of the first wM parameter to Ĥ.qx
>>>>>
>>>>> My proof requires a whole inference chain that cannot proceed to the
>>>>> next point until the current point is accepted as correct.
>>>> In addition to carpal tunnel, you are delusional. I get the vague
>>>> impression reading the above that you are having a schizoid episode.
>>>> There is a complete and total discount between what others say to you
>>>> and your replies. I suggest you cut out some of the examples you like
>>>> best and show them to your therapist. You do have one, don't you? It may
>>>> lead to better, more effective treatment. We are all hoping you get
>>>> better but schizoid episodes are hard to suppress. I assume meds have
>>>> been prescribed for your condition. Are you taking them? Or are you
>>>> refusing medical help just as you refuse to allow Ben to heal your
>>>> ignorance. A little trust in your betters will go a long way towards
>>>> recovery and a cure. Start now before it's to late. God speed to you.
>>>> -
>>> YOu might be right, but I think it's just frustration. His execution trace shows
>>> what appears to be an infinitely recursive process aborted, and everyone is
>>> just ignoring that and focusing on the other reality that his H does not
>>> return the result that matches the behaviour of the input when run independently.
>>>
>>> The attempt to use formal math notation when he doesn't understand it
>>> doesn't help. That can create the impression of mental incoherence, but in fact
>>> it's not that.
>>>
>>> Despite a mass of posting, we still don't have a good idea how H works.
>> _P()
>> [00000d02](01) 55 push ebp
>> [00000d03](02) 8bec mov ebp,esp
>> [00000d05](03) 8b4508 mov eax,[ebp+08]
>> [00000d08](01) 50 push eax // push 2nd Param
>> [00000d09](03) 8b4d08 mov ecx,[ebp+08]
>> [00000d0c](01) 51 push ecx // push 1st Param
>> [00000d0d](05) e870feffff call 00000b82 // call H
>> [00000d12](03) 83c408 add esp,+08
>> [00000d15](02) 85c0 test eax,eax
>> [00000d17](02) 7402 jz 00000d1b
>> [00000d19](02) ebfe jmp 00000d19
>> [00000d1b](01) 5d pop ebp
>> [00000d1c](01) c3 ret
>> Size in bytes:(0027) [00000d1c]
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> ...[00000d0d][00101829][00000d12] e870feffff call 00000b82 // call H
>>
>> Begin Local Halt Decider Simulation at Machine Address:d02
>> ...[00000d02][002118f1][002118f5] 55 push ebp
>> ...[00000d03][002118f1][002118f5] 8bec mov ebp,esp
>> ...[00000d05][002118f1][002118f5] 8b4508 mov eax,[ebp+08]
>> ...[00000d08][002118ed][00000d02] 50 push eax // push P
>> ...[00000d09][002118ed][00000d02] 8b4d08 mov ecx,[ebp+08]
>> ...[00000d0c][002118e9][00000d02] 51 push ecx // push P
>> ...[00000d0d][002118e5][00000d12] e870feffff call 00000b82 // call H
>>
>> ...[00000d02][0025c319][0025c31d] 55 push ebp
>> ...[00000d03][0025c319][0025c31d] 8bec mov ebp,esp
>> ...[00000d05][0025c319][0025c31d] 8b4508 mov eax,[ebp+08]
>> ...[00000d08][0025c315][00000d02] 50 push eax // push P
>> ...[00000d09][0025c315][00000d02] 8b4d08 mov ecx,[ebp+08]
>> ...[00000d0c][0025c311][00000d02] 51 push ecx // push P
>> ...[00000d0d][0025c30d][00000d12] e870feffff call 00000b82 // call H
>> Local Halt Decider: Infinite Recursion Detected Simulation Stopped
>> If this means that you are telling me that:
>> (1) You know the x86 language very well.
>>
>> (2) Can't begin to understand why P would be stuck in infinitely nested
>> simulation while H acts as a pure simulator?
>>
> OK, so let's start.
> There's a line which says "Begin Local Halt Decider Simulation at Machine
> Address:d02". Is that part of the execution trace, or is it a commented added
> by hand? If it is part of the execution trace, why doesn't this line appear
> before the second line with the label 0d02?

The halt decider automatically writes this when it begins the simulation
that its halt analysis is based on.

>>
>> I would say that you must be a liar.
>>
> I have a PhD. PhD holder attach a very high value to honesty, in particular
> with respect to their subjects. But also more generally. I always draw attention
> if I'm given too much change at the pub, for example, not becaue I'm better
> than other people, but because I'm a doctor, and a doctor can't be seen to
> take money that doesn't belong to him.
>

So do (1) and (2) apply to you?

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
> if M applied to wM halts, and
>
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
> if M applied to wM does not halt
>
> // M refers to the TM of the first wM parameter to Ĥ.qx
>
> Now that you accept that the above is true...

I don't. It's a garbled formula arising from a silly error on your
part. I'd like to know where (you think) I said I accept this nonsense
so I can correct any such impression.

> ... we can move on to the next point. My proof must proceed exactly
> one point at a time an cannot possibly move to the next point until
> the current point is fully accepted.

It would be simpler if we worked though the reasons you are wrong
because there are fewer steps.

You've stated that

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

and you accept (at least you keep quoting) that Linz requires that this
should be the case only if Ĥ applied to ⟨Ĥ⟩ does not halt. QED.

> That you believe that the fact that Ĥ applied to ⟨Ĥ⟩ transitions to
> its final state of Ĥ.qn and halts nullifies the fact that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
> does correctly decide that its input never halts is the next point.

⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation as shown a few
lines above. That Ĥ applied to ⟨Ĥ⟩ halts does not "nullify" anything,
it's just wrong as clearly stated by Linz.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 8/11/2021 8:20 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/11/2021 6:04 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/11/2021 10:04 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>>>> I went point by point. If I am actually incorrect then you can go
>>>>>>> point by point and point out each individual error step by step.
>>>>>> You fail at the first hurdle. You can't hope to persuade anyone that an
>>>>>> add function with add(2, 3) == 9 is operating as specified simply by
>>>>>> detailing, step by step, exactly how you implement the wrong behaviour.
>>>>>> In your case, it's simply that Ĥ.q0 ⟨Ĥ⟩ transitions to Ĥ.qn (via Ĥ.qx
>>>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ as you pointlessly keep insisting) when Linz says it should not.
>>>>>> Your add function is entirely correct in that is does exactly what you
>>>>>> intend it to do. As far as I am concerned there is no significant error
>>>>>> in how you arrive at add(2, 3) == 9. The problem is that Linz says your
>>>>>> code should add numbers and not do whatever it is your code does with
>>>>>> 100% correctness. Do you follow?
>>>>>>
>>>>>>> Of course
>>>>>>> everyone knows that this is impossible if I am totally correct.
>>>>>> Then stop wasting time and try to publish! You'll need lots of time to
>>>>>> explain away why every editor simply laughs at the paper.
>>>>>>
>>>>>>> H.q0 WM w ⊢* Ĥ.qn
>>>>>>> becomes
>>>>>>> H.q0 ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* H.qn
>>>>>> Yes, we all know that. It's exactly why your Ĥ does not meet Linz's
>>>>>> specification (for this case -- you don't claim to have a halt decider).
>>>>>>
>>>>>>> Can you admit when you are wrong when you really are wrong?
>>>>>> Yes. I am wrong all the time. In this case I'm having trouble working
>>>>>> out how I could be clearer about your Ĥ. Maybe if you didn't keep
>>>>>> removing the key text from Linz's explanations it might sink in?
>>>>>>
>>>>>
>>>>> Pages of the Linz text to verify the above quotes in their full context:
>>>>> http://www.liarparadox.org/Peter_Linz_HP(Pages_315-320).pdf
>>>>>
>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>>> PROOF THAT M REFERS TO THE TURING MACHINE DESCRIPTION PARAMETER WM TO H
>>>> I see you are in "paste the same text" again mode. If you think I can
>>>> help in any way, do let me know.
>>>
>>> I just noticed that you acknowledged that M refers to the TM
>>> represented by the first input parameter to Ĥ.qx wM wM
>> Did I? Oh dear. It's garbage. Where did I "acknowledge" it? I'd like
>> to go back and point out that it's mathematical junk.
>>
>>> so we can move to the next point:
>>>
>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>> if M applied to wM halts, and
>> This is just a metaphorical math poem. You've taken a mathematical
>> statement and substituted for only some on the occurrences of a
>> variable. That is a schoolboy error.
>
> That seems to be a very stupid thing to say when it only clarifies and
> corrects Linz.

I got about half way through a reply to this (and all the stuff that
follows), but almost everything you said was wrong one way or another
and I don't have time.

Instead, I posted (yet again) the basic reason why you are wrong in
another thread. If you think any of the comments you made here would
really benefit from a response, point them out and see if I have time to
reply.

--
Ben.

On 8/12/2021 3:00 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>> if M applied to wM halts, and
>>
>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>> if M applied to wM does not halt
>>
>> // M refers to the TM of the first wM parameter to Ĥ.qx
>>
>> Now that you accept that the above is true...
>
> I don't. It's a garbled formula arising from a silly error on your
> part. I'd like to know where (you think) I said I accept this nonsense
> so I can correct any such impression.
>
>> ... we can move on to the next point. My proof must proceed exactly
>> one point at a time an cannot possibly move to the next point until
>> the current point is fully accepted.
>
> It would be simpler if we worked though the reasons you are wrong
> because there are fewer steps.
>
> You've stated that
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> and you accept (at least you keep quoting) that Linz requires that this
> should be the case only if Ĥ applied to ⟨Ĥ⟩ does not halt. QED.
>
>> That you believe that the fact that Ĥ applied to ⟨Ĥ⟩ transitions to
>> its final state of Ĥ.qn and halts nullifies the fact that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>> does correctly decide that its input never halts is the next point.
>
> ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation as shown a few
> lines above. That Ĥ applied to ⟨Ĥ⟩ halts does not "nullify" anything,
> it's just wrong as clearly stated by Linz.
>

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation.

Ĥ is a TM that halts only because
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input never halts.

When you examine this in its x86utm equivalent of H(P,P) there are no
loopholes that can slip through the cracks because every detail is
explicitly encoded in the x86 language.

When we examine this as Ĥ applied to ⟨Ĥ⟩ there are millions of pages of
Turing machine code that cannot be explicitly specified.

None-the-less the key element of all this is the fact that if we assume
that the simulating halt decider at Ĥ.qx is simply a UTM then it becomes
quite obvious that we have an infinite cycle from Ĥ.qx to Ĥ.q0.

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

If we know that we have an infinite cycle then this knowledge all by
itself proves that the simulating halt decider at Ĥ.qx must abort the
simulation of its input which proves that this input never halts.

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 8/12/2021 3:00 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>> if M applied to wM halts, and
>>>
>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>> if M applied to wM does not halt
>>>
>>> // M refers to the TM of the first wM parameter to Ĥ.qx
>>>
>>> Now that you accept that the above is true...
>>
>> I don't. It's a garbled formula arising from a silly error on your
>> part. I'd like to know where (you think) I said I accept this nonsense
>> so I can correct any such impression.

I'd like to know, please.

>>> ... we can move on to the next point. My proof must proceed exactly
>>> one point at a time an cannot possibly move to the next point until
>>> the current point is fully accepted.
>> It would be simpler if we worked though the reasons you are wrong
>> because there are fewer steps.
>> You've stated that
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> and you accept (at least you keep quoting) that Linz requires that this
>> should be the case only if Ĥ applied to ⟨Ĥ⟩ does not halt. QED.

You need to come clean. You keep stating that Ĥ.q0 ⟨Ĥ⟩ transitions to
Ĥ.qn but you can't admit that Linz says this should only happen if Ĥ
applied to ⟨Ĥ⟩ does not halt. You can't keep scrolling past this
problem in order to say other stuff. No other stuff can change either
what Linz says, nor what happens when Ĥ is applied to ⟨Ĥ⟩.

>>> That you believe that the fact that Ĥ applied to ⟨Ĥ⟩ transitions to
>>> its final state of Ĥ.qn and halts nullifies the fact that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>>> does correctly decide that its input never halts is the next point.
>>
>> ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation as shown a few
>> lines above. That Ĥ applied to ⟨Ĥ⟩ halts does not "nullify" anything,
>> it's just wrong as clearly stated by Linz.
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> ⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation.

Ah. You are just going to write one line that shows that ⟨Ĥ⟩ ⟨Ĥ⟩ is a
string that encodes a halting computation and immediately follow it with
a statement to the contrary. That's an odd strategy.

You are flat-out wrong about that second line: ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that
encodes a halting computation, and until you accept that you are just
spouting nonsense.

By the way, this is not why your Ĥ is not as Linz specifies. That is
shown by the first line along with the accompanying text from Linz. The
fact that you are wrong about the string ⟨Ĥ⟩ ⟨Ĥ⟩ is just an aside to the
main argument that you keep skipping over.

> Ĥ is a TM that halts only because
> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input never halts.

⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation, specifically the
computation consisting of Ĥ applied to ⟨Ĥ⟩.

> When you examine this in its x86utm equivalent...

Don't you think you should find out why you are wrong about TMs first?
After all, the argument is just a few lines.

--
Ben.

On 8/12/2021 4:10 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/12/2021 3:00 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>> if M applied to wM halts, and
>>>>
>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>> if M applied to wM does not halt
>>>>
>>>> // M refers to the TM of the first wM parameter to Ĥ.qx
>>>>
>>>> Now that you accept that the above is true...
>>>
>>> I don't. It's a garbled formula arising from a silly error on your
>>> part. I'd like to know where (you think) I said I accept this nonsense
>>> so I can correct any such impression.
>
> I'd like to know, please.

The above is a cut-and-paste of the same corrected and clarified version
of Linz that I have been referring to for over a year. I didn't change it.

I added this one line:
// M refers to the TM of the first wM parameter to Ĥ.qx

>
>>>> ... we can move on to the next point. My proof must proceed exactly
>>>> one point at a time an cannot possibly move to the next point until
>>>> the current point is fully accepted.
>>> It would be simpler if we worked though the reasons you are wrong
>>> because there are fewer steps.
>>> You've stated that
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> and you accept (at least you keep quoting) that Linz requires that this
>>> should be the case only if Ĥ applied to ⟨Ĥ⟩ does not halt. QED.
>
> You need to come clean. You keep stating that Ĥ.q0 ⟨Ĥ⟩ transitions to
> Ĥ.qn but you can't admit that Linz says this should only happen if Ĥ
> applied to ⟨Ĥ⟩ does not halt. You can't keep scrolling past this
> problem in order to say other stuff. No other stuff can change either
> what Linz says, nor what happens when Ĥ is applied to ⟨Ĥ⟩.
>
>>>> That you believe that the fact that Ĥ applied to ⟨Ĥ⟩ transitions to
>>>> its final state of Ĥ.qn and halts nullifies the fact that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>>>> does correctly decide that its input never halts is the next point.
>>>
>>> ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation as shown a few
>>> lines above. That Ĥ applied to ⟨Ĥ⟩ halts does not "nullify" anything,
>>> it's just wrong as clearly stated by Linz.
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> ⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation.
>
> Ah. You are just going to write one line that shows that ⟨Ĥ⟩ ⟨Ĥ⟩ is a
> string that encodes a halting computation and immediately follow it with
> a statement to the contrary. That's an odd strategy.
>
> You are flat-out wrong about that second line: ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that
> encodes a halting computation, and until you accept that you are just
> spouting nonsense.
>
> By the way, this is not why your Ĥ is not as Linz specifies. That is
> shown by the first line along with the accompanying text from Linz. The
> fact that you are wrong about the string ⟨Ĥ⟩ ⟨Ĥ⟩ is just an aside to the
> main argument that you keep skipping over.
>
>> Ĥ is a TM that halts only because
>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ correctly decides that its input never halts.
>
> ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation, specifically the
> computation consisting of Ĥ applied to ⟨Ĥ⟩.
>
>> When you examine this in its x86utm equivalent...
>
> Don't you think you should find out why you are wrong about TMs first?
> After all, the argument is just a few lines.
>

Let move one step at a time:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Can you see that the above never halts if Ĥ.qx us a UTM?

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 8/12/2021 4:10 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/12/2021 3:00 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>>> if M applied to wM halts, and
>>>>>
>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>> if M applied to wM does not halt
>>>>>
>>>>> // M refers to the TM of the first wM parameter to Ĥ.qx
>>>>>
>>>>> Now that you accept that the above is true...
>>>>
>>>> I don't. It's a garbled formula arising from a silly error on your
>>>> part. I'd like to know where (you thinkq) I said I accept this nonsense
>>>> so I can correct any such impression.
>>
>> I'd like to know, please.
>
> The above is a cut-and-paste of the same corrected and clarified
> version of Linz that I have been referring to for over a year. I
> didn't change it.

I can't find any example (in an exchange with me) older than 8 weeks.
Anyway, I can't correct the impression if you can't point to the post
that made you think I accepted this bizarre set of symbols.

>>>>> ... we can move on to the next point. My proof must proceed exactly
>>>>> one point at a time an cannot possibly move to the next point until
>>>>> the current point is fully accepted.
>>>> It would be simpler if we worked though the reasons you are wrong
>>>> because there are fewer steps.
>>>> You've stated that
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>> and you accept (at least you keep quoting) that Linz requires that this
>>>> should be the case only if Ĥ applied to ⟨Ĥ⟩ does not halt. QED.
>>
>> You need to come clean. You keep stating that Ĥ.q0 ⟨Ĥ⟩ transitions to
>> Ĥ.qn but you can't admit that Linz says this should only happen if Ĥ
>> applied to ⟨Ĥ⟩ does not halt. You can't keep scrolling past this
>> problem in order to say other stuff. No other stuff can change either
>> what Linz says, nor what happens when Ĥ is applied to ⟨Ĥ⟩.

You just scroll past a succinct demonstration that you are wrong in
order to play some games later on. That won't wash. This is the
*first* thing you will be told in the rejection letter for your paper.

>>>>> That you believe that the fact that Ĥ applied to ⟨Ĥ⟩ transitions to
>>>>> its final state of Ĥ.qn and halts nullifies the fact that Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>> does correctly decide that its input never halts is the next point.
>>>>
>>>> ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that encodes a halting computation as shown a few
>>>> lines above. That Ĥ applied to ⟨Ĥ⟩ halts does not "nullify" anything,
>>>> it's just wrong as clearly stated by Linz.
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> ⟨Ĥ⟩ ⟨Ĥ⟩ is not a string that encodes a halting computation.
>>
>> Ah. You are just going to write one line that shows that ⟨Ĥ⟩ ⟨Ĥ⟩ is a
>> string that encodes a halting computation and immediately follow it with
>> a statement to the contrary. That's an odd strategy.
>>
>> You are flat-out wrong about that second line: ⟨Ĥ⟩ ⟨Ĥ⟩ is a string that
>> encodes a halting computation, and until you accept that you are just
>> spouting nonsense.

How can you expect anyone to take you seriously when you make statements
like this? You are wrong about the string ⟨Ĥ⟩ ⟨Ĥ⟩ because of what you
said one line previously. It's insane that you think you can get away
with this and no one will pick you up on it.

--
Ben.

On 8/12/2021 6:00 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/12/2021 4:10 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/12/2021 3:00 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>>>> if M applied to wM halts, and
>>>>>>
>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>> if M applied to wM does not halt
>>>>>>
>>>>>> // M refers to the TM of the first wM parameter to Ĥ.qx
>>>>>>
>>>>>> Now that you accept that the above is true...
>>>>>
>>>>> I don't. It's a garbled formula arising from a silly error on your
>>>>> part. I'd like to know where (you thinkq) I said I accept this nonsense
>>>>> so I can correct any such impression.
>>>
>>> I'd like to know, please.
>>
>> The above is a cut-and-paste of the same corrected and clarified
>> version of Linz that I have been referring to for over a year. I
>> didn't change it.
>
> I can't find any example (in an exchange with me) older than 8 weeks.
> Anyway, I can't correct the impression if you can't point to the post
> that made you think I accepted this bizarre set of symbols.
>

This is how Linz does it as shown on his page 319 and my page 21
(He has two start states).
q0 wM ⊢* Ĥq0 wM wM ⊢* Ĥ∞
q0 wM ⊢* Ĥq0 wM wM ⊢* Ĥqn

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

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Can you see that the above never halts if Ĥ.qx us a UTM?

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Can you see that the above never halts if Ĥ.qx us a UTM?

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Can you see that the above never halts if Ĥ.qx us a UTM?

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Can you see that the above never halts if Ĥ.qx us a UTM?

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Can you see that the above never halts if Ĥ.qx us a UTM?

--
Copyright 2021 Pete Olcott

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

On 8/12/2021 6:28 PM, olcott wrote:

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Can you see that the above never halts if Ĥ.qx is a UTM?

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Can you see that the above never halts if Ĥ.qx is a UTM?

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Can you see that the above never halts if Ĥ.qx is a UTM?

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Can you see that the above never halts if Ĥ.qx is a UTM?

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Can you see that the above never halts if Ĥ.qx is a UTM?

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 8/12/2021 6:28 PM, olcott wrote:
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> Can you see that the above never halts if Ĥ.qx is a UTM?
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> Can you see that the above never halts if Ĥ.qx is a UTM?
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> Can you see that the above never halts if Ĥ.qx is a UTM?
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> Can you see that the above never halts if Ĥ.qx is a UTM?
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> Can you see that the above never halts if Ĥ.qx is a UTM?

I can see you don't want to talk about why you are wrong. That's
perfectly natural.

--
Ben.

On 8/12/2021 7:26 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/12/2021 6:28 PM, olcott wrote:
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> Can you see that the above never halts if Ĥ.qx is a UTM?
>
> I can see you don't want to talk about why you are wrong. That's
> perfectly natural.
>

I can see why you don't want to point out my mistake
(because there is no mistake).

It is true that when the halt decider that is an identical copy of H
is replaced by a UTM that:

Ĥ.q0 would copy its input then
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ would simulate its input on this copy
repeating this cycle forever...

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 8/12/2021 6:00 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:

>>> The above is a cut-and-paste of the same corrected and clarified
>>> version of Linz that I have been referring to for over a year. I
>>> didn't change it.
>>
>> I can't find any example (in an exchange with me) older than 8 weeks.
>> Anyway, I can't correct the impression if you can't point to the post
>> that made you think I accepted this bizarre set of symbols.
>
> This is how Linz does it as shown on his page 319 and my page 21
> (He has two start states).
> q0 wM ⊢* Ĥq0 wM wM ⊢* Ĥ∞
> q0 wM ⊢* Ĥq0 wM wM ⊢* Ĥqn

You are right -- it's a re-working of what Linz has. My apologies.

But I don't "accept it as true" because it's a universally quantified
statement about how a TM behaves for all inputs, and I know some inputs
fail. What's more, you don't (yet) claim that it's true either. The
only case you claim if true is the one where wM = ⟨Ĥ⟩.

So while I accept is states how Ĥ should behave, I don't accept that it
true (for all M) and I specifically don't accept that it's true for the
one M (and wM) you care about.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 8/12/2021 7:26 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/12/2021 6:28 PM, olcott wrote:
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>
>> I can see you don't want to talk about why you are wrong. That's
>> perfectly natural.
>
> I can see why you don't want to point out my mistake
> (because there is no mistake).

I keep pointing them out, and you keep wanting to talk about something
else. The mistakes are very simple:

(1) Ĥ applied to ⟨Ĥ⟩ halts when Linz says it should not.

(2) You incorrectly claim that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string representing a
computation that does not halt.

> It is true that when the halt decider that is an identical copy of H
> is replaced by a UTM that:
>
> Ĥ.q0 would copy its input then
> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ would simulate its input on this copy
> repeating this cycle forever...

Nothing here alters the two facts (1) and (2) that show you are wrong.
Your only hope is to get me to talk about anything other than (1) and
(2) because, it seems, you have nothing to say about them.

--
Ben.

On 8/12/2021 7:53 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/12/2021 6:00 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>
>>>> The above is a cut-and-paste of the same corrected and clarified
>>>> version of Linz that I have been referring to for over a year. I
>>>> didn't change it.
>>>
>>> I can't find any example (in an exchange with me) older than 8 weeks.
>>> Anyway, I can't correct the impression if you can't point to the post
>>> that made you think I accepted this bizarre set of symbols.
>>
>> This is how Linz does it as shown on his page 319 and my page 21
>> (He has two start states).
>> q0 wM ⊢* Ĥq0 wM wM ⊢* Ĥ∞
>> q0 wM ⊢* Ĥq0 wM wM ⊢* Ĥqn
>
> You are right -- it's a re-working of what Linz has. My apologies.
>
> But I don't "accept it as true" because it's a universally quantified

This is a universal quantifier: ∀

> statement about how a TM behaves for all inputs, and I know some inputs
> fail. What's more, you don't (yet) claim that it's true either. The
> only case you claim if true is the one where wM = ⟨Ĥ⟩.
>

It is a template that stipulates the behavior at certain points in the
state transitions. Since H only refers to deciders it must always reach
past the last ⊢* state.

> So while I accept is states how Ĥ should behave, I don't accept that it
> true (for all M) and I specifically don't accept that it's true for the
> one M (and wM) you care about.
>

Expressions of language that are stipulated to be true are impossibly
false.

In the following BASIC statement:
100 let X = 5
you are not free to disagree that X equals 5.

--
Copyright 2021 Pete Olcott

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

On 8/12/2021 8:05 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 8/12/2021 7:26 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 8/12/2021 6:28 PM, olcott wrote:
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>
>>> I can see you don't want to talk about why you are wrong. That's
>>> perfectly natural.
>>
>> I can see why you don't want to point out my mistake
>> (because there is no mistake).
>
> I keep pointing them out, and you keep wanting to talk about something
> else. The mistakes are very simple:
>
> (1) Ĥ applied to ⟨Ĥ⟩ halts when Linz says it should not.
>

You keep looking at the wrong part of the computation.
You keep looking at the wrong part of the computation.
You keep looking at the wrong part of the computation.
You keep looking at the wrong part of the computation.

Yes the first Ĥ halts.
No the first ⟨Ĥ⟩ never halts.

I keep saying that I have a white cat and you prove that I am wrong by
showing that I do not have a black dog.

> (2) You incorrectly claim that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string representing a
> computation that does not halt.
>

Ĥ.q0 ⟨Ĥ⟩ copies its input then
Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ simulates this input with this copy

which copies its input
which is simulated with this copy

which copies its input
which is simulated with this copy

which copies its input
which is simulated with this copy...

>> It is true that when the halt decider that is an identical copy of H
>> is replaced by a UTM that:
>>
>> Ĥ.q0 would copy its input then
>> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ would simulate its input on this copy
>> repeating this cycle forever...
>
> Nothing here alters the two facts (1) and (2) that show you are wrong.
> Your only hope is to get me to talk about anything other than (1) and
> (2) because, it seems, you have nothing to say about them.
>

--
Copyright 2021 Pete Olcott

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

On 8/12/21 7:28 PM, olcott wrote:
> On 8/12/2021 6:00 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/12/2021 4:10 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/12/2021 3:00 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>>>>>> if M applied to wM halts, and
>>>>>>>
>>>>>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>>>>> if M applied to wM does not halt
>>>>>>>
>>>>>>> // M refers to the TM of the first wM parameter to Ĥ.qx
>>>>>>>
>>>>>>> Now that you accept that the above is true...
>>>>>>
>>>>>> I don't.  It's a garbled formula arising from a silly error on your
>>>>>> part.  I'd like to know where (you thinkq) I said I accept this
>>>>>> nonsense
>>>>>> so I can correct any such impression.
>>>>
>>>> I'd like to know, please.
>>>
>>> The above is a cut-and-paste of the same corrected and clarified
>>> version of Linz that I have been referring to for over a year. I
>>> didn't change it.
>>
>> I can't find any example (in an exchange with me) older than 8 weeks.
>> Anyway, I can't correct the impression if you can't point to the post
>> that made you think I accepted this bizarre set of symbols.
>>
>
> This is how Linz does it as shown on his page 319 and my page 21
> (He has two start states).
> q0 wM ⊢* Ĥq0 wM wM ⊢* Ĥ∞
> q0 wM ⊢* Ĥq0 wM wM ⊢* Ĥqn
>
> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>
>
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> Can you see that the above never halts if Ĥ.qx us a UTM?
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> Can you see that the above never halts if Ĥ.qx us a UTM?
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> Can you see that the above never halts if Ĥ.qx us a UTM?
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> Can you see that the above never halts if Ĥ.qx us a UTM?
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> Can you see that the above never halts if Ĥ.qx us a UTM?
>
>

Yes, IF H is a UTM (no such thing as a state being a UTM) then H^(<H^>)
will never halt, but also H(<H^>) never halts either to give an answer,
so that H is still wrong.

If H isn't a UTM, but does halt and return the answer of non-halting,
then treating it as if it was is an ERROR, and shows UNSOUND logic. As
has been shown, for this case, H^(<H^>) is a Halting Computation, thus
showing that this H is also WRONG.

You keep on forgetting that H^ is dependent on H, so you have to take
that into account with your logic, and a UTM until ... is not a UTM.

On 8/12/21 9:19 PM, olcott wrote:
> On 8/12/2021 8:05 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/12/2021 7:26 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/12/2021 6:28 PM, olcott wrote:
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>>
>>>> I can see you don't want to talk about why you are wrong.  That's
>>>> perfectly natural.
>>>
>>> I can see why you don't want to point out my mistake
>>> (because there is no mistake).
>>
>> I keep pointing them out, and you keep wanting to talk about something
>> else.  The mistakes are very simple:
>>
>> (1) Ĥ applied to ⟨Ĥ⟩ halts when Linz says it should not.
>>
>
> You keep looking at the wrong part of the computation.
> You keep looking at the wrong part of the computation.
> You keep looking at the wrong part of the computation.
> You keep looking at the wrong part of the computation.
>
> Yes the first Ĥ halts.
> No the first ⟨Ĥ⟩ never halts.

Representations are NOT computataion, and thus do not 'Halt'

Aborted simulation do NOT indicate that the the machine that they are
simulating is non-halting.

ALL copies of a given machine, will ultimately behave exactly the same.
If one copy is only partially simulated, that simulation may not
complete, but that only shows that you only looked at part of the behavior.

>
> I keep saying that I have a white cat and you prove that I am wrong by
> showing that I do not have a black dog.
>
>> (2) You incorrectly claim that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string representing a
>> computation that does not halt.
>>
>
> Ĥ.q0 ⟨Ĥ⟩ copies its input then
> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ simulates this input with this copy
>
> which copies its input
> which is simulated with this copy
>
> which copies its input
> which is simulated with this copy
>
> which copies its input
> which is simulated with this copy...

Yes, if H doesn't abort this is what happens, but then that H never
answers when directly asked, so is wrong.

If H does abort, then at some point it will pull the rug out from this
level of simulation loop, return its answer to its caller, and that copy
of H^ will Halt, showing that H was wrong in its analysis that the loop
would have been unending.

Remember, H needs to take into account what the copy of H it is
simulating will do, based on what it will do itself.

It ERRS in assuming H will not abort when H does abort.

olcott <NoOne@NoWhere.com> writes:

> On 8/12/2021 8:05 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 8/12/2021 7:26 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 8/12/2021 6:28 PM, olcott wrote:
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>>>
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>> Can you see that the above never halts if Ĥ.qx is a UTM?
>>>>
>>>> I can see you don't want to talk about why you are wrong. That's
>>>> perfectly natural.
>>>
>>> I can see why you don't want to point out my mistake
>>> (because there is no mistake).
>> I keep pointing them out, and you keep wanting to talk about something
>> else. The mistakes are very simple:
>> (1) Ĥ applied to ⟨Ĥ⟩ halts when Linz says it should not.
>
> You keep looking at the wrong part of the computation.
> You keep looking at the wrong part of the computation.
> You keep looking at the wrong part of the computation.
> You keep looking at the wrong part of the computation.

I keep looking at the part that shows you are wrong. I'm not interested
in the other parts.

> Yes the first Ĥ halts.

.... when applied to ⟨Ĥ⟩. And Linz says that's wrong.

> No the first ⟨Ĥ⟩ never halts.

⟨Ĥ⟩ is a string. It does not halt nor does it not halt -- it's just a
string. Try saying what you mean.

> I keep saying that I have a white cat and you prove that I am wrong by
> showing that I do not have a black dog.

No. You keep showing the lines that say that your Ĥ does not meet
Linz's specification (for the one case you care about). You keep
showing us the black dog while saying that you have a white cat. I just
keep pointing to the back dog you keep posting about.

>> (2) You incorrectly claim that ⟨Ĥ⟩ ⟨Ĥ⟩ is a string representing a
>> computation that does not halt.
>
> Ĥ.q0 ⟨Ĥ⟩ copies its input then
> Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ simulates this input with this copy
>
> which copies its input
> which is simulated with this copy
>
> which copies its input
> which is simulated with this copy
>
> which copies its input
> which is simulated with this copy...

⟨Ĥ⟩ ⟨Ĥ⟩ is a string representing the computation that you keep telling us
halts.

Both are just about as simple a mistake as it's possible to make. In
both cases you provide all the information required to see that you are
wrong. You are simply too invested to be able to walk away now.

--
Ben.