olcott <NoOne@NoWhere.com> writes:

> On 3/19/2022 7:01 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/19/2022 8:10 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 3/18/2022 8:05 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> On 3/18/2022 11:54 AM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> No BRAIN DEAD MORON this is not true, I keep calling you a BRAIN DEAD
>>>>>>>>> MORON because after I have explain all the details you cannot remember
>>>>>>>>> what I just said.
>>>>>>>> I see the petulant six-year-old is in residence today.
>>>>>>>>
>>>>>>>>> A decider maps its inputs to its own accept reject state.
>>>>>>>>> A halt decider does not compute the halt status of itself.
>>>>>>>>
>>>>>>>> A halt decider, let's call it H, maps the input <Ĥ> <Ĥ> to its accept
>>>>>
>>>>> You have changed the subject away from the Linz proof's conclusion
>>>>> that deals with Ĥ applied to <Ĥ> and not H applied to <Ĥ> <Ĥ>.
>>>> You made an incorrect statement about a halt decider. I corrected it.
>>>>
>>>> You will ignore the correction. The conversation remains exactly as it
>>>> was years ago.
>>>
>>> You can't manage to stay on the topic at hand
>> You posted an incorrect statement. I corrected it. The topic is the
>> wrong thing you said only yesterday (modulo time zones).
>
> I want to switch threads this one has an erronous main title.

I want you to stick to one subject until it is actually resolved. This
is why you have posted literally dozens of unacknowledged mistakes in
the last few years alone.

--
Ben.

On 3/19/2022 10:31 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/19/2022 6:49 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> The behavior of H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is different than the behavior of
>>>> embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>> You:
>>> "Ĥ includes an exact copy of H embedded at its state Ĥ.qx"
>>> "Linz [...] requires that Ĥ.qx is an exact copy of H"
>>> "Ĥ.qx <is> an exact copy of H"
>>> How do "exact copies" behave differently when applied to the exact same
>>> input?
>>>
>>> I thought your only remaining (big) error was to declare false (or
>>> reject) as the current answer for some halting computations, but your
>>> machines are back yo being magic PO-machines.
>>
>> strcmp(H, embedded_H) != 0 because of the appended infinite loop.
>
> This is junk in so may ways: H and embedded_H are not strings. Turing
> machines don't have strcmp. And embedded_H is only an "exact copy"
> (your words) of H up to qy and qn -- the extra states are not part of
> embedded_H.
>
>> When strcmp is used as the key element of a halt status decision then
>> this changes the behavior H relative to embedded_H for the same input.
>
> You claim to be talking about Turing machines so you must answer the
> question of how an exact copy of a Turing machine can behave differently
> on the same input? Well, it can't. Simple as that. Your machines are
> magic PO-machines, not Turing machines.
>
> You must fix this mistake immediately. Talking about magic PO-machines
> makes everything you say irrelevant.
>

I have already addressed that and I am not coming back to this thread
because people in Google groups only see many messages with the same
title of: Comic.

If you want to ask the question again in my new thread I will provide
more details there.

--
Copyright 2021 Pete Olcott

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

On 3/19/2022 10:34 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/19/2022 7:01 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/19/2022 8:10 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 3/18/2022 8:05 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> On 3/18/2022 11:54 AM, Ben Bacarisse wrote:
>>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>>
>>>>>>>>>> No BRAIN DEAD MORON this is not true, I keep calling you a BRAIN DEAD
>>>>>>>>>> MORON because after I have explain all the details you cannot remember
>>>>>>>>>> what I just said.
>>>>>>>>> I see the petulant six-year-old is in residence today.
>>>>>>>>>
>>>>>>>>>> A decider maps its inputs to its own accept reject state.
>>>>>>>>>> A halt decider does not compute the halt status of itself.
>>>>>>>>>
>>>>>>>>> A halt decider, let's call it H, maps the input <Ĥ> <Ĥ> to its accept
>>>>>>
>>>>>> You have changed the subject away from the Linz proof's conclusion
>>>>>> that deals with Ĥ applied to <Ĥ> and not H applied to <Ĥ> <Ĥ>.
>>>>> You made an incorrect statement about a halt decider. I corrected it.
>>>>>
>>>>> You will ignore the correction. The conversation remains exactly as it
>>>>> was years ago.
>>>>
>>>> You can't manage to stay on the topic at hand
>>> You posted an incorrect statement. I corrected it. The topic is the
>>> wrong thing you said only yesterday (modulo time zones).
>>
>> I want to switch threads this one has an erronous main title.
>
> I want you to stick to one subject until it is actually resolved. This
> is why you have posted literally dozens of unacknowledged mistakes in
> the last few years alone.
>

Feel free to carry this over to the new thread.

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 3/18/2022 11:54 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> No BRAIN DEAD MORON this is not true, I keep calling you a BRAIN DEAD
>>> MORON because after I have explain all the details you cannot remember
>>> what I just said.
>> I see the petulant six-year-old is in residence today.
>>
>>> A decider maps its inputs to its own accept reject state.
>>> A halt decider does not compute the halt status of itself.
>>
>> A halt decider, let's call it H, maps the input <Ĥ> <Ĥ> to its accept
>> state if (and only if) Ĥ enter a final state on input <Ĥ>, and it maps
>> <Ĥ> <Ĥ> to its reject state if (and only if) Ĥ does not enter a final
>> state on input <Ĥ>.
>>
>> No such H exists.
>>
>> You implicitly accept this fact because you propose an H which does not
>> meet this specification but I can't see why you think anyone would care
>> about it.
>
> It is the case that if Linz Ĥ applied to <Ĥ> causes the copy of Linz H
> embedded within Linz Ĥ to transition to Ĥ.qn

But you said "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you
many times" so you are confirming (again) that these are not Turing
machines but magic PO-machines where identical state transition
functions entail transitions to different states when given identical
input.

This nonsense much be fixed immediately. Nothing you say about such
magic PO-machines matters. Linz's Ĥ is a TM, not a magic PO-machine.

--
Ben.

On 2022-03-19 20:59, olcott wrote:
> On 3/19/2022 9:50 PM, André G. Isaak wrote:
>> On 2022-03-19 20:47, olcott wrote:
>>> On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>> On 2022-03-19 17:57, olcott wrote:
>>>>> On 3/19/2022 6:49 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> The behavior of H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is different than the
>>>>>>> behavior of
>>>>>>> embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>
>>>>>> You:
>>>>>>
>>>>>>    "Ĥ includes an exact copy of H embedded at its state Ĥ.qx"
>>>>>>
>>>>>>    "Linz [...] requires that Ĥ.qx is an exact copy of H"
>>>>>>
>>>>>>    "Ĥ.qx <is> an exact copy of H"
>>>>>>
>>>>>> How do "exact copies" behave differently when applied to the exact
>>>>>> same
>>>>>> input?
>>>>>>
>>>>>> I thought your only remaining (big) error was to declare false (or
>>>>>> reject) as the current answer for some halting computations, but your
>>>>>> machines are back yo being magic PO-machines.
>>>>>>
>>>>>
>>>>> strcmp(H, embedded_H) != 0 because of the appended infinite loop.
>>>>>
>>>>> When strcmp is used as the key element of a halt status decision
>>>>> then this changes the behavior H relative to embedded_H for the
>>>>> same input.
>>>>
>>>> strcmp() is a C standard library function. Turing Machines can't
>>>> call standard library functions, or any C functions for that matter.
>>>> If you want to talk about string comparison, fine, but calling it
>>>> strcmp() is just plain silly.
>>>>
>>>
>>> Its concise.
>>
>> Concise and completely inapplicable to Turing Machines.
>>
>>> I changed to a different thread that does not have the lame main
>>> thread name of Comic.
>>>
>>>> A Turing Machine has no access to *any* information apart from what
>>>> is present on its tape. Ĥ (of which your embedded_H is a part)
>>>> starts with only a *single* string on its tape.
>>>>
>>>> With what, exactly, do you plan on comparing this string in making
>>>> your 'halt status decision'?
>>
>> You didn't actually answer the above question. What exactly do you
>> plan on comparing the input to?
>>
>> André
>>
>>
>
> I am not replying to thead thread named : Comic
> any more.
>
> People that look at my work through Google groups are not aware of the
> sub-names.

I have absolutely no idea what you are talking about. I see no thread
anywhere titled 'comic'.

André

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

On 2022-03-19 21:36, olcott wrote:

> Feel free to carry this over to the new thread.

Which 'new thread'? Unless this new thread is in an entirely different
group, I don't see it.

André

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

olcott <NoOne@NoWhere.com> writes:

> On 3/19/2022 7:24 PM, Ben Bacarisse wrote:

>> I stand by my previous explanations of why this is wrong, but even that
>> is now pointless because it seems you have re-introduced the crazy idea
>> that two TMs that are exact copies of each other can behave differently
>> when given the same input.
>>
>> That is so wrong, there is simply no point in commenting on anything you
>> say because it's not about TMs.
>
> (1) H and Ĥ aren't exact copies strcmp() proves that they differ by
> the appended states. H and Ĥ use strcmp() as part of the decision
> criteria.

No one ever said they were. You said that H and embedded_H are exact
copies:

Linz [...] requires that Ĥ.qx is an exact copy of H.
Ĥ includes an exact copy of H embedded at its state Ĥ.qx
Ĥ.qx <is> an exact copy of H

> (2) I made all of this moot months ago by only focusing on the copy of
> H that is embedded within Ĥ, so when people bring up H I must tell
> this this is off topic.

And people will continue to tell you why you are wrong even if you call
it off topic. Your ruse is plain for all to see. You have been very
clear. Here you are stating it explicitly:

"Ĥ.qx maps ⟨Ĥ⟩ ⟨Ĥ⟩ to Ĥ.qn
corresponds to
H maps ⟨Ĥ⟩ ⟨Ĥ⟩ to H.qy"

This is a magic machine where the same state transition function entails
different transitions on identical inputs.

--
Ben.

On 3/19/2022 10:55 PM, André G. Isaak wrote:
> On 2022-03-19 21:36, olcott wrote:
>
>> Feel free to carry this over to the new thread.
>
>
> Which 'new thread'? Unless this new thread is in an entirely different
> group, I don't see it.
>
> André
>
>

Refuting the Peter Linz Halting Problem Proof V4 [ erroneous religious
conviction ]

--
Copyright 2021 Pete Olcott

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

On 3/19/2022 10:48 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/18/2022 11:54 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> No BRAIN DEAD MORON this is not true, I keep calling you a BRAIN DEAD
>>>> MORON because after I have explain all the details you cannot remember
>>>> what I just said.
>>> I see the petulant six-year-old is in residence today.
>>>
>>>> A decider maps its inputs to its own accept reject state.
>>>> A halt decider does not compute the halt status of itself.
>>>
>>> A halt decider, let's call it H, maps the input <Ĥ> <Ĥ> to its accept
>>> state if (and only if) Ĥ enter a final state on input <Ĥ>, and it maps
>>> <Ĥ> <Ĥ> to its reject state if (and only if) Ĥ does not enter a final
>>> state on input <Ĥ>.
>>>
>>> No such H exists.
>>>
>>> You implicitly accept this fact because you propose an H which does not
>>> meet this specification but I can't see why you think anyone would care
>>> about it.
>>
>> It is the case that if Linz Ĥ applied to <Ĥ> causes the copy of Linz H
>> embedded within Linz Ĥ to transition to Ĥ.qn
>
> But you said "No nitwit H ⟨Ĥ⟩ ⟨Ĥ⟩ transitions to H.qy as I have told you
> many times" so you are confirming (again) that these are not Turing
> machines but magic PO-machines where identical state transition
> functions entail transitions to different states when given identical
> input.
>
> This nonsense much be fixed immediately. Nothing you say about such
> magic PO-machines matters. Linz's Ĥ is a TM, not a magic PO-machine.
>

I am only responding in this thread:
Refuting the Peter Linz Halting Problem Proof V4 [ erroneous religious
conviction ]

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 3/19/2022 7:12 PM, Ben Bacarisse wrote:

>> But the behaviour of Turing machines is determined entirely by the state
>> transition function and the input, so you are not even talking about the
>> same kind of entity as Linz's proof. Nothing you say can be taken
>> seriously until this error is corrected.
>
> I am not responding to this post with the jackass main title

Fine by me. The mistake won't go way though.

What's the "main title" anyway? The subject header of this
thread is: "Re: Simulating halt deciders correct decider halting [ Ben's
perpetual mistake ][ much agreement ]".

--
Ben.

On 3/19/2022 11:01 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/19/2022 7:12 PM, Ben Bacarisse wrote:
>
>>> But the behaviour of Turing machines is determined entirely by the state
>>> transition function and the input, so you are not even talking about the
>>> same kind of entity as Linz's proof. Nothing you say can be taken
>>> seriously until this error is corrected.
>>
>> I am not responding to this post with the jackass main title
>
> Fine by me. The mistake won't go way though.
>
> What's the "main title" anyway? The subject header of this
> thread is: "Re: Simulating halt deciders correct decider halting [ Ben's
> perpetual mistake ][ much agreement ]".
>

This is my new thread:
Re: Refuting the Peter Linz Halting Problem Proof V4 [ erroneous
religious conviction ]

Google Groups only sees a single message title for hundreds of these
posts: Comic

--
Copyright 2021 Pete Olcott

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

On 3/19/2022 10:52 PM, André G. Isaak wrote:
> On 2022-03-19 20:59, olcott wrote:
>> On 3/19/2022 9:50 PM, André G. Isaak wrote:
>>> On 2022-03-19 20:47, olcott wrote:
>>>> On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>>> On 2022-03-19 17:57, olcott wrote:
>>>>>> On 3/19/2022 6:49 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> The behavior of H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is different than the
>>>>>>>> behavior of
>>>>>>>> embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>
>>>>>>> You:
>>>>>>>
>>>>>>>    "Ĥ includes an exact copy of H embedded at its state Ĥ.qx"
>>>>>>>
>>>>>>>    "Linz [...] requires that Ĥ.qx is an exact copy of H"
>>>>>>>
>>>>>>>    "Ĥ.qx <is> an exact copy of H"
>>>>>>>
>>>>>>> How do "exact copies" behave differently when applied to the
>>>>>>> exact same
>>>>>>> input?
>>>>>>>
>>>>>>> I thought your only remaining (big) error was to declare false (or
>>>>>>> reject) as the current answer for some halting computations, but
>>>>>>> your
>>>>>>> machines are back yo being magic PO-machines.
>>>>>>>
>>>>>>
>>>>>> strcmp(H, embedded_H) != 0 because of the appended infinite loop.
>>>>>>
>>>>>> When strcmp is used as the key element of a halt status decision
>>>>>> then this changes the behavior H relative to embedded_H for the
>>>>>> same input.
>>>>>
>>>>> strcmp() is a C standard library function. Turing Machines can't
>>>>> call standard library functions, or any C functions for that
>>>>> matter. If you want to talk about string comparison, fine, but
>>>>> calling it strcmp() is just plain silly.
>>>>>
>>>>
>>>> Its concise.
>>>
>>> Concise and completely inapplicable to Turing Machines.
>>>
>>>> I changed to a different thread that does not have the lame main
>>>> thread name of Comic.
>>>>
>>>>> A Turing Machine has no access to *any* information apart from what
>>>>> is present on its tape. Ĥ (of which your embedded_H is a part)
>>>>> starts with only a *single* string on its tape.
>>>>>
>>>>> With what, exactly, do you plan on comparing this string in making
>>>>> your 'halt status decision'?
>>>
>>> You didn't actually answer the above question. What exactly do you
>>> plan on comparing the input to?
>>>
>>> André
>>>
>>>
>>
>> I am not replying to thead thread named : Comic
>> any more.
>>
>> People that look at my work through Google groups are not aware of the
>> sub-names.
>
> I have absolutely no idea what you are talking about. I see no thread
> anywhere titled 'comic'.
>
> André
>

https://groups.google.com/g/comp.theory

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 3/19/2022 11:01 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:

>>> I am not responding to this post with the jackass main title
>>
>> Fine by me. The mistake won't go way though.
>> What's the "main title" anyway? The subject header of this
>> thread is: "Re: Simulating halt deciders correct decider halting [ Ben's
>> perpetual mistake ][ much agreement ]".

> Google Groups only sees a single message title for hundreds of these
> posts: Comic

Google's AI at it's finest? Your recent posts are indeed a joke.

--
Ben.

On 2022-03-19 22:08, olcott wrote:
> On 3/19/2022 10:52 PM, André G. Isaak wrote:
>> On 2022-03-19 20:59, olcott wrote:
>>> On 3/19/2022 9:50 PM, André G. Isaak wrote:
>>>> On 2022-03-19 20:47, olcott wrote:
>>>>> On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>>>> On 2022-03-19 17:57, olcott wrote:
>>>>>>> On 3/19/2022 6:49 PM, Ben Bacarisse wrote:
>>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>>
>>>>>>>>> The behavior of H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is different than the
>>>>>>>>> behavior of
>>>>>>>>> embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>>
>>>>>>>> You:
>>>>>>>>
>>>>>>>>    "Ĥ includes an exact copy of H embedded at its state Ĥ.qx"
>>>>>>>>
>>>>>>>>    "Linz [...] requires that Ĥ.qx is an exact copy of H"
>>>>>>>>
>>>>>>>>    "Ĥ.qx <is> an exact copy of H"
>>>>>>>>
>>>>>>>> How do "exact copies" behave differently when applied to the
>>>>>>>> exact same
>>>>>>>> input?
>>>>>>>>
>>>>>>>> I thought your only remaining (big) error was to declare false (or
>>>>>>>> reject) as the current answer for some halting computations, but
>>>>>>>> your
>>>>>>>> machines are back yo being magic PO-machines.
>>>>>>>>
>>>>>>>
>>>>>>> strcmp(H, embedded_H) != 0 because of the appended infinite loop.
>>>>>>>
>>>>>>> When strcmp is used as the key element of a halt status decision
>>>>>>> then this changes the behavior H relative to embedded_H for the
>>>>>>> same input.
>>>>>>
>>>>>> strcmp() is a C standard library function. Turing Machines can't
>>>>>> call standard library functions, or any C functions for that
>>>>>> matter. If you want to talk about string comparison, fine, but
>>>>>> calling it strcmp() is just plain silly.
>>>>>>
>>>>>
>>>>> Its concise.
>>>>
>>>> Concise and completely inapplicable to Turing Machines.
>>>>
>>>>> I changed to a different thread that does not have the lame main
>>>>> thread name of Comic.
>>>>>
>>>>>> A Turing Machine has no access to *any* information apart from
>>>>>> what is present on its tape. Ĥ (of which your embedded_H is a
>>>>>> part) starts with only a *single* string on its tape.
>>>>>>
>>>>>> With what, exactly, do you plan on comparing this string in making
>>>>>> your 'halt status decision'?
>>>>
>>>> You didn't actually answer the above question. What exactly do you
>>>> plan on comparing the input to?
>>>>
>>>> André
>>>>
>>>>
>>>
>>> I am not replying to thead thread named : Comic
>>> any more.
>>>
>>> People that look at my work through Google groups are not aware of
>>> the sub-names.
>>
>> I have absolutely no idea what you are talking about. I see no thread
>> anywhere titled 'comic'.
>>
>> André
>>
>
> https://groups.google.com/g/comp.theory
>

comp.theory is a usenet group. It has nothing to do with Google. Actual
newsreaders will display the correct thread title.

The question I asked above was in response to a post which you made in
the thread "Simulating halt deciders correct decider halting [ PO's
perpetual mistake ]".

It makes absolutely no sense to pose that question in some other thread
where the line I was responding to did *not* occur. That entirely
defeats the purpose of threading.

If there is a bug with how google's crappy web-interface to usenet
displays thread titles that's just one more (of the already numerous)
reason not to use google groups.

André

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

On 20/03/2022 04:01, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/19/2022 7:12 PM, Ben Bacarisse wrote:
>
>>> But the behaviour of Turing machines is determined entirely by the state
>>> transition function and the input, so you are not even talking about the
>>> same kind of entity as Linz's proof. Nothing you say can be taken
>>> seriously until this error is corrected.
>>
>> I am not responding to this post with the jackass main title
>
> Fine by me. The mistake won't go way though.
>
> What's the "main title" anyway? The subject header of this
> thread is: "Re: Simulating halt deciders correct decider halting [ Ben's
> perpetual mistake ][ much agreement ]".
>

The first post that created the thread was titled "Comic", as Andre was referring to one of the XKCD
daily comics. PO jumped in and hijacked the thread, changing the Subject header, so he's only
himself to blame.

(Probably Usenet threads don't officially have a "main title" in the standard, as each post has its
own Subject header. However, in Google Groups apparently it's all captured under the original
(first post) Subject. PO puts much stock in titles, as we see in his common practice of changing
the subthread Subject and including derogatory remarks about posters - [Beyond xxx's comprehension]
and the likes.)

Mike.

On 3/19/2022 11:27 PM, Mike Terry wrote:
> On 20/03/2022 04:01, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/19/2022 7:12 PM, Ben Bacarisse wrote:
>>
>>>> But the behaviour of Turing machines is determined entirely by the
>>>> state
>>>> transition function and the input, so you are not even talking about
>>>> the
>>>> same kind of entity as Linz's proof.  Nothing you say can be taken
>>>> seriously until this error is corrected.
>>>
>>> I am not responding to this post with the jackass main title
>>
>> Fine by me.  The mistake won't go way though.
>>
>> What's the "main title" anyway?  The subject header of this
>> thread is: "Re: Simulating halt deciders correct decider halting [ Ben's
>> perpetual mistake ][ much agreement ]".
>>
>
> The first post that created the thread was titled "Comic", as Andre was
> referring to one of the XKCD daily comics.  PO jumped in and hijacked
> the thread,

He called me by name in his first post.

--
Copyright 2021 Pete Olcott

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

On 3/20/22 12:06 AM, olcott wrote:
> On 3/19/2022 11:01 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/19/2022 7:12 PM, Ben Bacarisse wrote:
>>
>>>> But the behaviour of Turing machines is determined entirely by the
>>>> state
>>>> transition function and the input, so you are not even talking about
>>>> the
>>>> same kind of entity as Linz's proof.  Nothing you say can be taken
>>>> seriously until this error is corrected.
>>>
>>> I am not responding to this post with the jackass main title
>>
>> Fine by me.  The mistake won't go way though.
>>
>> What's the "main title" anyway?  The subject header of this
>> thread is: "Re: Simulating halt deciders correct decider halting [ Ben's
>> perpetual mistake ][ much agreement ]".
>>
>
> This is my new thread:
> Re: Refuting the Peter Linz Halting Problem Proof V4 [ erroneous
> religious conviction ]
>
> Google Groups only sees a single message title for hundreds of these
> posts: Comic
>

I suppose your using Google Groups s apropos, It is one of the biggest
sources of spam and garbage on the internet. A lot of intelgent people
just block ALL messages from GG.

On 3/19/22 11:52 PM, André G. Isaak wrote:
> On 2022-03-19 20:59, olcott wrote:
>> On 3/19/2022 9:50 PM, André G. Isaak wrote:
>>> On 2022-03-19 20:47, olcott wrote:
>>>> On 3/19/2022 9:38 PM, André G. Isaak wrote:
>>>>> On 2022-03-19 17:57, olcott wrote:
>>>>>> On 3/19/2022 6:49 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> The behavior of H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ is different than the
>>>>>>>> behavior of
>>>>>>>> embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩
>>>>>>>
>>>>>>> You:
>>>>>>>
>>>>>>>    "Ĥ includes an exact copy of H embedded at its state Ĥ.qx"
>>>>>>>
>>>>>>>    "Linz [...] requires that Ĥ.qx is an exact copy of H"
>>>>>>>
>>>>>>>    "Ĥ.qx <is> an exact copy of H"
>>>>>>>
>>>>>>> How do "exact copies" behave differently when applied to the
>>>>>>> exact same
>>>>>>> input?
>>>>>>>
>>>>>>> I thought your only remaining (big) error was to declare false (or
>>>>>>> reject) as the current answer for some halting computations, but
>>>>>>> your
>>>>>>> machines are back yo being magic PO-machines.
>>>>>>>
>>>>>>
>>>>>> strcmp(H, embedded_H) != 0 because of the appended infinite loop.
>>>>>>
>>>>>> When strcmp is used as the key element of a halt status decision
>>>>>> then this changes the behavior H relative to embedded_H for the
>>>>>> same input.
>>>>>
>>>>> strcmp() is a C standard library function. Turing Machines can't
>>>>> call standard library functions, or any C functions for that
>>>>> matter. If you want to talk about string comparison, fine, but
>>>>> calling it strcmp() is just plain silly.
>>>>>
>>>>
>>>> Its concise.
>>>
>>> Concise and completely inapplicable to Turing Machines.
>>>
>>>> I changed to a different thread that does not have the lame main
>>>> thread name of Comic.
>>>>
>>>>> A Turing Machine has no access to *any* information apart from what
>>>>> is present on its tape. Ĥ (of which your embedded_H is a part)
>>>>> starts with only a *single* string on its tape.
>>>>>
>>>>> With what, exactly, do you plan on comparing this string in making
>>>>> your 'halt status decision'?
>>>
>>> You didn't actually answer the above question. What exactly do you
>>> plan on comparing the input to?
>>>
>>> André
>>>
>>>
>>
>> I am not replying to thead thread named : Comic
>> any more.
>>
>> People that look at my work through Google groups are not aware of the
>> sub-names.
>
> I have absolutely no idea what you are talking about. I see no thread
> anywhere titled 'comic'.
>
> André
>

The VERY first message in this thread was titled 'Comic', which you
posted refering to a XKCD comic that reminded you of PO.

PO then replied to it to start the big discussion.

PO didn't realize that the GG interface uses the initial subject of the
thread to title the whole thread. I don't use GG, but I suspect you do
see the actual subject line (not 'title') when reading the actual message.

Just more of PO being PO.