On 3/4/2022 11:36 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/4/2022 9:29 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> I know that all deciders compute the mapping from their input finite
>>>> strings to an accept or reject state. You and Ben prove that you do
>>>> not understand that halt deciders are deciders.
>>> Lying about technical matters is one thing[1], but lying about people is
>>> not on. It's despicable and you should stop doing it.
>>
>> When you would actually directly address the point at hand you have no
>> rebuttal because it is correct.
>
> What are you waffling about now? Of course a halt decider (were such a
> thing to exist) would be a decider. Your lie is that neither I nor
> Richard have ever said what claim. Continuing to lie about what people
> claim is despicable. You've done it before. You will probably keep
> doing it.
>
>> THIS IS THE POINT AT HAND
>
> By which you mean this the current distraction from 17 years of
> uncorrected mistakes.
>
>> It is the case that all deciders ONLY compute the mapping from their
>> input finite strings to an accept or reject state thus everything that
>> is not an input finite sting is out-of-scope for the decider.
>
> Apart form the bad wording, no one has ever objected to that.
>
>> This shows that embedded_H must compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to an
>> accept or reject state and is not allowed to report on the behavior of
>> the computation that contains itself Ĥ ⟨Ĥ⟩.
>
> Nonsense. First off, this is a silly use of language -- a TM is not
> "allowed" or "not allowed" to do anything. A TM+input entails a
> sequence of configurations determined solely by the state transition
> function and the input. They have do not need permission for anything,
> and permission can not be withdrawn about anything.
>
> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ entail the same sequence of
> configurations up to qn or qy. If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qy ⊦ oo then
> H accepts ⟨Ĥ⟩ ⟨Ĥ⟩. If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qn then H rejects ⟨Ĥ⟩ ⟨Ĥ⟩.
It seems that all you have is one dishonest dodge or another. I have not
been speaking about H for many months so when you bring it up now it is
a direct dodge of the point at hand.

When embedded_H computes the mapping from its input finite string pair
⟨Ĥ⟩ ⟨Ĥ⟩ inputs to an accept or reject state it does this on the basis of
the behavior specified by this finite string pair: ⟨Ĥ⟩ ⟨Ĥ⟩ and not on
the basis of the behavior of the computation that contains itself: Ĥ ⟨Ĥ⟩.

Your failure to understand this proves that you do not sufficiently
understand how deciders work.

--
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 2022-03-04 12:46:22 +0000, Ben Bacarisse said:

> Mikko <mikko.levanto@iki.fi> writes:
>
>> On 2022-03-03 14:58:15 +0000, olcott said:
>>
>>> On 3/3/2022 4:34 AM, Mikko wrote:
>>>> On 2022-03-03 03:13:35 +0000, olcott said:
>>>>
>>>>> We make it even simpler a decider is required to compute the mapping
>>>>> from its finite string input to an accept or reject state.
>>>> Irrelevant, as Linz' Definition 12.1 does not use the word "decider" and
>>>> does not require that the solution to the halting problem be a decider.
>>>> Mikko
>>>>
>>> All halt deciders are deciders.
>>
>> The definition 12.1 does not say so.
>
> So what? Linz does not use the word decider at all,

therefore a statement about deciders does not affect whether
some H is a soulution to the halting problem as defined in the
definition 12.1 of Linz.

Mikko

On 3/4/2022 12:43 PM, Mikko wrote:
> On 2022-03-04 12:46:22 +0000, Ben Bacarisse said:
>
>> Mikko <mikko.levanto@iki.fi> writes:
>>
>>> On 2022-03-03 14:58:15 +0000, olcott said:
>>>
>>>> On 3/3/2022 4:34 AM, Mikko wrote:
>>>>> On 2022-03-03 03:13:35 +0000, olcott said:
>>>>>
>>>>>> We make it even simpler a decider is required to compute the
>>>>>> mapping from its finite string input to an accept or reject state.
>>>>> Irrelevant, as Linz' Definition 12.1 does not use the word
>>>>> "decider" and
>>>>> does not require that the solution to the halting problem be a
>>>>> decider.
>>>>> Mikko
>>>>>
>>>> All halt deciders are deciders.
>>>
>>> The definition 12.1 does not say so.
>>
>> So what?  Linz does not use the word decider at all,
>
> therefore a statement about deciders does not affect whether
> some H is a soulution to the halting problem as defined in the
> definition 12.1 of Linz.
>
> Mikko
>

Linz does not mention the term "decider" separately because it is common
knowledge that all halt deciders are deciders.

--
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/4/22 1:51 PM, olcott wrote:
> On 3/4/2022 12:43 PM, Mikko wrote:
>> On 2022-03-04 12:46:22 +0000, Ben Bacarisse said:
>>
>>> Mikko <mikko.levanto@iki.fi> writes:
>>>
>>>> On 2022-03-03 14:58:15 +0000, olcott said:
>>>>
>>>>> On 3/3/2022 4:34 AM, Mikko wrote:
>>>>>> On 2022-03-03 03:13:35 +0000, olcott said:
>>>>>>
>>>>>>> We make it even simpler a decider is required to compute the
>>>>>>> mapping from its finite string input to an accept or reject state.
>>>>>> Irrelevant, as Linz' Definition 12.1 does not use the word
>>>>>> "decider" and
>>>>>> does not require that the solution to the halting problem be a
>>>>>> decider.
>>>>>> Mikko
>>>>>>
>>>>> All halt deciders are deciders.
>>>>
>>>> The definition 12.1 does not say so.
>>>
>>> So what?  Linz does not use the word decider at all,
>>
>> therefore a statement about deciders does not affect whether
>> some H is a soulution to the halting problem as defined in the
>> definition 12.1 of Linz.
>>
>> Mikko
>>
>
> Linz does not mention the term "decider" separately because it is common
> knowledge that all halt deciders are deciders.
>

And since YOUR 'decider' doesn't match the requirements of the Halting
Problem, it isn't a Halt Decider.

Halt Deciders, by Definition, report the Halting/Non-Halting of the
Computation there input is a representation of, which means that H
applied to <H^> <H^> reports on the behavior of H^ applied to <H^>,
which you have claimed your H isn't allowed to by your logic, so it
can't be the required Halt Decider.

FAIL.

On 3/4/22 1:12 PM, olcott wrote:
> On 3/4/2022 11:36 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/4/2022 9:29 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> I know that all deciders compute the mapping from their input finite
>>>>> strings to an accept or reject state. You and Ben prove that you do
>>>>> not understand that halt deciders are deciders.
>>>> Lying about technical matters is one thing[1], but lying about
>>>> people is
>>>> not on.  It's despicable and you should stop doing it.
>>>
>>> When you would actually directly address the point at hand you have no
>>> rebuttal because it is correct.
>>
>> What are you waffling about now?  Of course a halt decider (were such a
>> thing to exist) would be a decider.  Your lie is that neither I nor
>> Richard have ever said what claim.  Continuing to lie about what people
>> claim is despicable.  You've done it before.  You will probably keep
>> doing it.
>>
>>> THIS IS THE POINT AT HAND
>>
>> By which you mean this the current distraction from 17 years of
>> uncorrected mistakes.
>>
>>> It is the case that all deciders ONLY compute the mapping from their
>>> input finite strings to an accept or reject state thus everything that
>>> is not an input finite sting is out-of-scope for the decider.
>>
>> Apart form the bad wording, no one has ever objected to that.
>>
>>> This shows that embedded_H must compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to an
>>> accept or reject state and is not allowed to report on the behavior of
>>> the computation that contains itself Ĥ ⟨Ĥ⟩.
>>
>> Nonsense.  First off, this is a silly use of language -- a TM is not
>> "allowed" or "not allowed" to do anything.  A TM+input entails a
>> sequence of configurations determined solely by the state transition
>> function and the input.  They have do not need permission for anything,
>> and permission can not be withdrawn about anything.
>>
>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ entail the same sequence of
>> configurations up to qn or qy.  If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qy ⊦ oo then
>> H accepts ⟨Ĥ⟩ ⟨Ĥ⟩.  If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qn then H rejects ⟨Ĥ⟩ ⟨Ĥ⟩.
> It seems that all you have is one dishonest dodge or another. I have not
> been speaking about H for many months so when you bring it up now it is
> a direct dodge of the point at hand.
>
> When embedded_H computes the mapping from its input finite string pair
> ⟨Ĥ⟩ ⟨Ĥ⟩ inputs to an accept or reject state it does this on the basis of
> the behavior specified by this finite string pair: ⟨Ĥ⟩ ⟨Ĥ⟩ and not on
> the basis of the behavior of the computation that contains itself: Ĥ ⟨Ĥ⟩.
>
> Your failure to understand this proves that you do not sufficiently
> understand how deciders work.
>

But embedded_H is just a copy of H, so you HAVE been talking about H,
that or you are talking about something very foreign to the concept of a
Turing Machine, and thus not applicable to the problem at all.

You also don't seem to understand that 'strings' don't have any behavior
at all, they just represent something with behavior, and <H^> <H^> is
DEFINED to represent the behavior of H^ applied to <H^>.

If not, then you are just not working on the problem you claim.

There is NO 'self reference' exception in the definition, if you can
find one, please provide a reference to it. (Not just one of your
rantings that it can't mean that)

The fact that H^ refers to H and thus makes it impossible for your
design of H to answer the question isn't a problem with the question, it
just shows you answer is insufficient, and the fact that NO H can
correctly answer the question for the H^ built on it is the basis for
saying that no H can answer correctly for all required inputs.

FAIL.

Mikko <mikko.levanto@iki.fi> writes:

> On 2022-03-04 12:46:22 +0000, Ben Bacarisse said:
>
>> Mikko <mikko.levanto@iki.fi> writes:
>>
>>> On 2022-03-03 14:58:15 +0000, olcott said:
>>>
>>>> On 3/3/2022 4:34 AM, Mikko wrote:
>>>>> On 2022-03-03 03:13:35 +0000, olcott said:
>>>>>
>>>>>> We make it even simpler a decider is required to compute the mapping from its finite string input to an accept or reject state.
>>>>> Irrelevant, as Linz' Definition 12.1 does not use the word "decider" and
>>>>> does not require that the solution to the halting problem be a decider.
>>>>> Mikko
>>>>>
>>>> All halt deciders are deciders.
>>> The definition 12.1 does not say so.
>
>> So what? Linz does not use the word decider at all,
>
> therefore a statement about deciders does not affect whether
> some H is a soulution to the halting problem as defined in the
> definition 12.1 of Linz.

No. You have a very odd way of thinking about mathematics. The words
used don't alter the facts -- that there is no TM satisfying Linz's 12.1
can be, loosely, stated as "there is no decider for the strings that
represent halting computations". It might make someone ask "what do you
mean by a decide?" but it's only inaccurate if the words are being used
in some outlandish way. That's not the case here.

--
Ben.

On 3/4/2022 12:43 PM, Mikko wrote:
> On 2022-03-04 12:46:22 +0000, Ben Bacarisse said:
>
>> Mikko <mikko.levanto@iki.fi> writes:
>>
>>> On 2022-03-03 14:58:15 +0000, olcott said:
>>>
>>>> On 3/3/2022 4:34 AM, Mikko wrote:
>>>>> On 2022-03-03 03:13:35 +0000, olcott said:
>>>>>
>>>>>> We make it even simpler a decider is required to compute the
>>>>>> mapping from its finite string input to an accept or reject state.
>>>>> Irrelevant, as Linz' Definition 12.1 does not use the word
>>>>> "decider" and
>>>>> does not require that the solution to the halting problem be a
>>>>> decider.
>>>>> Mikko
>>>>>
>>>> All halt deciders are deciders.
>>>
>>> The definition 12.1 does not say so.
>>
>> So what?  Linz does not use the word decider at all,
>
> therefore a statement about deciders does not affect whether
> some H is a soulution to the halting problem as defined in the
> definition 12.1 of Linz.
>
> Mikko
>

It is like you don't understand that a calico cat is a cat.

--
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/4/22 4:08 PM, olcott wrote:
> On 3/4/2022 12:43 PM, Mikko wrote:
>> On 2022-03-04 12:46:22 +0000, Ben Bacarisse said:
>>
>>> Mikko <mikko.levanto@iki.fi> writes:
>>>
>>>> On 2022-03-03 14:58:15 +0000, olcott said:
>>>>
>>>>> On 3/3/2022 4:34 AM, Mikko wrote:
>>>>>> On 2022-03-03 03:13:35 +0000, olcott said:
>>>>>>
>>>>>>> We make it even simpler a decider is required to compute the
>>>>>>> mapping from its finite string input to an accept or reject state.
>>>>>> Irrelevant, as Linz' Definition 12.1 does not use the word
>>>>>> "decider" and
>>>>>> does not require that the solution to the halting problem be a
>>>>>> decider.
>>>>>> Mikko
>>>>>>
>>>>> All halt deciders are deciders.
>>>>
>>>> The definition 12.1 does not say so.
>>>
>>> So what?  Linz does not use the word decider at all,
>>
>> therefore a statement about deciders does not affect whether
>> some H is a soulution to the halting problem as defined in the
>> definition 12.1 of Linz.
>>
>> Mikko
>>
>
> It is like you don't understand that a calico cat is a cat.
>

No, it seems more like you don't realize that your skunk, even though
isome call it a 'Pole Cat' isn't actually a Cat.

olcott <NoOne@NoWhere.com> writes:

> On 3/4/2022 11:36 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/4/2022 9:29 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> I know that all deciders compute the mapping from their input finite
>>>>> strings to an accept or reject state. You and Ben prove that you do
>>>>> not understand that halt deciders are deciders.
>>>> Lying about technical matters is one thing[1], but lying about people is
>>>> not on. It's despicable and you should stop doing it.
>>>
>>> When you would actually directly address the point at hand you have no
>>> rebuttal because it is correct.
>> What are you waffling about now? Of course a halt decider (were such a
>> thing to exist) would be a decider. Your lie is that neither I nor
>> Richard have ever said what claim. Continuing to lie about what people
>> claim is despicable. You've done it before. You will probably keep
>> doing it.
>>
>>> THIS IS THE POINT AT HAND
>> By which you mean this the current distraction from 17 years of
>> uncorrected mistakes.
>>
>>> It is the case that all deciders ONLY compute the mapping from their
>>> input finite strings to an accept or reject state thus everything that
>>> is not an input finite sting is out-of-scope for the decider.
>> Apart form the bad wording, no one has ever objected to that.
>>
>>> This shows that embedded_H must compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to an
>>> accept or reject state and is not allowed to report on the behavior of
>>> the computation that contains itself Ĥ ⟨Ĥ⟩.
>>
>> Nonsense. First off, this is a silly use of language -- a TM is not
>> "allowed" or "not allowed" to do anything. A TM+input entails a
>> sequence of configurations determined solely by the state transition
>> function and the input. They have do not need permission for anything,
>> and permission can not be withdrawn about anything.
>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ entail the same sequence of
>> configurations up to qn or qy. If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qy ⊦ oo then
>> H accepts ⟨Ĥ⟩ ⟨Ĥ⟩. If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qn then H rejects ⟨Ĥ⟩ ⟨Ĥ⟩.
>
> It seems that all you have is one dishonest dodge or another. I have
> not been speaking about H for many months so when you bring it up now
> it is a direct dodge of the point at hand.

Of course you are not speaking about H. You are wrong about H so you
must try to not talk about it anymore. Ironically it's you that want me
to dodge this issue: if I can't talk about H, you condemn me to do
nothing but dodge the key point -- that H is wrong.

> When embedded_H computes the mapping from its input finite string pair
> ⟨Ĥ⟩ ⟨Ĥ⟩ inputs to an accept or reject state it does this on the basis
> of the behavior specified by this finite string pair: ⟨Ĥ⟩ ⟨Ĥ⟩

Sign. I wish you could get the details right. It would allow a
discussion of the big mistakes. embedded_H has no accepting state.

Anyway, I can't tell you why you are wrong because I must not talk about
H. Great -- that simplifies my replies a lot.

> and not on the basis of the behavior of the computation that contains
> itself: Ĥ ⟨Ĥ⟩.

Fortunately for you, you have banned me from telling you why this is
wrong!

> Your failure to understand this proves that you do not sufficiently
> understand how deciders work.

I know why you are wrong, but if I told you I would, apparently, be
dodging something! Enjoy your ignorance. If it gets tedious, the offer
to explain remains open...

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> When a sequence of configurations would never reach their final state
> in any finite number of steps of pure simulation then this sequence of
> configurations specify non-halting behavior.

This is the halting problem. It is better expressed in the simpler
terms given in texts like Linz. I don't like the wording, just gives
the gist.

> The criterion measure shown below defines the set of configurations
> that never reach their final state.
>
> Simple English version of Olcott's Halt status criterion measure:
> Every simulating halt decider that must abort the simulation of its
> input to prevent its infinite simulation correctly transitions to its
> reject state.

This is not the halting problem. Its even more badly written than the
first (for example, it's circular, and uses undefined metaphors like
"abort") but it conveys enough for readers to know that it's not the
correct criterion for the halting problem. It's this "Halt status
criterion measure" (pompous or what?) that permits your decider to
reject a string that represents a halting computation.

You need to pick what H is defined to do -- decide halting (as in Linz),
or to decide PO-almost-but-not-really halting (which no one but you
cares about). But it's clear from the above that are trying to
equivocate -- its the same as halting, honest! -- just re-worded so it
isn't.

--
Ben.

On 3/4/2022 5:30 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/4/2022 11:36 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/4/2022 9:29 AM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> I know that all deciders compute the mapping from their input finite
>>>>>> strings to an accept or reject state. You and Ben prove that you do
>>>>>> not understand that halt deciders are deciders.
>>>>> Lying about technical matters is one thing[1], but lying about people is
>>>>> not on. It's despicable and you should stop doing it.
>>>>
>>>> When you would actually directly address the point at hand you have no
>>>> rebuttal because it is correct.
>>> What are you waffling about now? Of course a halt decider (were such a
>>> thing to exist) would be a decider. Your lie is that neither I nor
>>> Richard have ever said what claim. Continuing to lie about what people
>>> claim is despicable. You've done it before. You will probably keep
>>> doing it.
>>>
>>>> THIS IS THE POINT AT HAND
>>> By which you mean this the current distraction from 17 years of
>>> uncorrected mistakes.
>>>
>>>> It is the case that all deciders ONLY compute the mapping from their
>>>> input finite strings to an accept or reject state thus everything that
>>>> is not an input finite sting is out-of-scope for the decider.
>>> Apart form the bad wording, no one has ever objected to that.
>>>
>>>> This shows that embedded_H must compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to an
>>>> accept or reject state and is not allowed to report on the behavior of
>>>> the computation that contains itself Ĥ ⟨Ĥ⟩.
>>>
>>> Nonsense. First off, this is a silly use of language -- a TM is not
>>> "allowed" or "not allowed" to do anything. A TM+input entails a
>>> sequence of configurations determined solely by the state transition
>>> function and the input. They have do not need permission for anything,
>>> and permission can not be withdrawn about anything.
>>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ entail the same sequence of
>>> configurations up to qn or qy. If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qy ⊦ oo then
>>> H accepts ⟨Ĥ⟩ ⟨Ĥ⟩. If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qn then H rejects ⟨Ĥ⟩ ⟨Ĥ⟩.
>>
>> It seems that all you have is one dishonest dodge or another. I have
>> not been speaking about H for many months so when you bring it up now
>> it is a direct dodge of the point at hand.
>
> Of course you are not speaking about H. You are wrong about H so you
> must try to not talk about it anymore. Ironically it's you that want me
> to dodge this issue: if I can't talk about H, you condemn me to do
> nothing but dodge the key point -- that H is wrong.
>
>> When embedded_H computes the mapping from its input finite string pair
>> ⟨Ĥ⟩ ⟨Ĥ⟩ inputs to an accept or reject state it does this on the basis
>> of the behavior specified by this finite string pair: ⟨Ĥ⟩ ⟨Ĥ⟩
>
> Sign. I wish you could get the details right. It would allow a
> discussion of the big mistakes. embedded_H has no accepting state.
>

embedded_H does indeed have an accept state, Ĥ.qy still exists even
though it has been broken by the appended infinite loop.

> Anyway, I can't tell you why you are wrong because I must not talk about
> H. Great -- that simplifies my replies a lot.
>
>> and not on the basis of the behavior of the computation that contains
>> itself: Ĥ ⟨Ĥ⟩.
>
> Fortunately for you, you have banned me from telling you why this is
> wrong!
>

WHICH FACTS DO YOU DISAGREE WITH?
(a) It is the case that deciders compute the mapping ONLY from their
inputs to an accept or reject state.

(b) It is the case that deciders DO NOT compute the mapping from
non-inputs to anything.

(c) It is the case that the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H
would never reach the final state of ⟨Ĥ⟩.qn in any finite number of steps.

>> Your failure to understand this proves that you do not sufficiently
>> understand how deciders work.
>
> I know why you are wrong, but if I told you I would, apparently, be
> dodging something! Enjoy your ignorance. If it gets tedious, the offer
> to explain remains open...
>

If my reasoning is incorrect then a flaw could be pointed out. If it is
impossible to point out any error in my reasoning then this proves that
it is correct.

To avoid this challenge you simply change the subject to fool the
gullible into believing that you provided a rebuttal. Gullible fools
never notice that a rebuttal has no supporting reasoning as long as it
does have seemingly convincing rhetoric.

--
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/4/22 6:56 PM, olcott wrote:
> On 3/4/2022 5:30 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/4/2022 11:36 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 3/4/2022 9:29 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> I know that all deciders compute the mapping from their input finite
>>>>>>> strings to an accept or reject state. You and Ben prove that you do
>>>>>>> not understand that halt deciders are deciders.
>>>>>> Lying about technical matters is one thing[1], but lying about
>>>>>> people is
>>>>>> not on.  It's despicable and you should stop doing it.
>>>>>
>>>>> When you would actually directly address the point at hand you have no
>>>>> rebuttal because it is correct.
>>>> What are you waffling about now?  Of course a halt decider (were such a
>>>> thing to exist) would be a decider.  Your lie is that neither I nor
>>>> Richard have ever said what claim.  Continuing to lie about what people
>>>> claim is despicable.  You've done it before.  You will probably keep
>>>> doing it.
>>>>
>>>>> THIS IS THE POINT AT HAND
>>>> By which you mean this the current distraction from 17 years of
>>>> uncorrected mistakes.
>>>>
>>>>> It is the case that all deciders ONLY compute the mapping from their
>>>>> input finite strings to an accept or reject state thus everything that
>>>>> is not an input finite sting is out-of-scope for the decider.
>>>> Apart form the bad wording, no one has ever objected to that.
>>>>
>>>>> This shows that embedded_H must compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to an
>>>>> accept or reject state and is not allowed to report on the behavior of
>>>>> the computation that contains itself Ĥ ⟨Ĥ⟩.
>>>>
>>>> Nonsense.  First off, this is a silly use of language -- a TM is not
>>>> "allowed" or "not allowed" to do anything.  A TM+input entails a
>>>> sequence of configurations determined solely by the state transition
>>>> function and the input.  They have do not need permission for anything,
>>>> and permission can not be withdrawn about anything.
>>>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ entail the same sequence of
>>>> configurations up to qn or qy.  If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qy ⊦ oo then
>>>> H accepts ⟨Ĥ⟩ ⟨Ĥ⟩.  If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qn then H rejects ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>
>>> It seems that all you have is one dishonest dodge or another. I have
>>> not been speaking about H for many months so when you bring it up now
>>> it is a direct dodge of the point at hand.
>>
>> Of course you are not speaking about H.  You are wrong about H so you
>> must try to not talk about it anymore.  Ironically it's you that want me
>> to dodge this issue: if I can't talk about H, you condemn me to do
>> nothing but dodge the key point -- that H is wrong.
>>
>>> When embedded_H computes the mapping from its input finite string pair
>>> ⟨Ĥ⟩ ⟨Ĥ⟩ inputs to an accept or reject state it does this on the basis
>>> of the behavior specified by this finite string pair: ⟨Ĥ⟩ ⟨Ĥ⟩
>>
>> Sign.  I wish you could get the details right.  It would allow a
>> discussion of the big mistakes.  embedded_H has no accepting state.
>>
>
> embedded_H does indeed have an accept state, Ĥ.qy still exists even
> though it has been broken by the appended infinite loop.
>
>> Anyway, I can't tell you why you are wrong because I must not talk about
>> H.  Great -- that simplifies my replies a lot.
>>
>>> and not on the basis of the behavior of the computation that contains
>>> itself: Ĥ ⟨Ĥ⟩.
>>
>> Fortunately for you, you have banned me from telling you why this is
>> wrong!
>>
>
> WHICH FACTS DO YOU DISAGREE WITH?
> (a) It is the case that deciders compute the mapping ONLY from their
> inputs to an accept or reject state.
>
> (b) It is the case that deciders DO NOT compute the mapping from
> non-inputs to anything.
>
> (c) It is the case that the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H
> would never reach the final state of ⟨Ĥ⟩.qn in any finite number of steps.

embedded_H either DOES or DOES NOT perform a pure simulation forever.

If it does not, then the fact that it aborts its simulation means it is
not a valid source of truth about the behavior of its input.

If it does perform the pure simulation, then it is true that the
computation its input represents would not halt, but this embedded_H
never gives an answer.

For the first class of embedded_H to 'look' at the behavior of the
second class of embedded_H is invalid, because each class looks at a
different input, since the input was built based on the embedded_H that
has been decided to be THE embedded_H that claims to be correct.

Thus, if your first embedded_H is doing that, it isn't looking at ITS
input, but a different input given to a different machine, and you have
made the error of equivocation.

FAIL.

>
>>> Your failure to understand this proves that you do not sufficiently
>>> understand how deciders work.
>>
>> I know why you are wrong, but if I told you I would, apparently, be
>> dodging something!  Enjoy your ignorance.  If it gets tedious, the offer
>> to explain remains open...
>>
>
> If my reasoning is incorrect then a flaw could be pointed out. If it is
> impossible to point out any error in my reasoning then this proves that
> it is correct.

And it has been, many times, but you seem to be to ignorant to understand.

I will point out, you have refuese to actually point out an actual
significant error in anything anyone who 'disagrees' with you has said.

PROVING that you are just a pathological Lying Hypocrite.

>
> To avoid this challenge you simply change the subject to fool the
> gullible into believing that you provided a rebuttal. Gullible fools
> never notice that a rebuttal has no supporting reasoning as long as it
> does have seemingly convincing rhetoric.
>

And only a fool like PO is so dumb as to not understand how utterly
wrong he is.

Your whole 'proof' is a string of poorly strung together mis-deffinition
and fallicies that don't provide any real support for your statements.

You have even in so many words ADMITTED that you don't understand the
basics of the field, but still claim that you are so ahead in it that
others just don't understand your 'Genius'.

It isn't Genius, it is utter foolishness and stupidity. You aren't smart
enough to understand you don't know anything useful.

On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> When a sequence of configurations would never reach their final state
>> in any finite number of steps of pure simulation then this sequence of
>> configurations specify non-halting behavior.
>
> This is the halting problem. It is better expressed in the simpler
> terms given in texts like Linz. I don't like the wording, just gives
> the gist.
>

OK good so far.

>> The criterion measure shown below defines the set of configurations
>> that never reach their final state.
>>
>> Simple English version of Olcott's Halt status criterion measure:
>> Every simulating halt decider that must abort the simulation of its
>> input to prevent its infinite simulation correctly transitions to its
>> reject state.
>
> This is not the halting problem. Its even more badly written than the
> first (for example, it's circular, and uses undefined metaphors like
> "abort") but it conveys enough for readers to know that it's not the
> correct criterion for the halting problem. It's this "Halt status
> criterion measure" (pompous or what?) that permits your decider to
> reject a string that represents a halting computation.
>

When a simulating halt decider correctly determines its correctly
simulated input would never reach its final state in any finite number
of steps of pure simulation then this simulating halt decider has
correctly determined that this input specifies non-halting behavior.

> You need to pick what H is defined to do -- decide halting (as in Linz),
> or to decide PO-almost-but-not-really halting (which no one but you
> cares about). But it's clear from the above that are trying to
> equivocate -- its the same as halting, honest! -- just re-worded so it
> isn't.
>

--
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/4/22 7:34 PM, olcott wrote:
> On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> When a sequence of configurations would never reach their final state
>>> in any finite number of steps of pure simulation then this sequence of
>>> configurations specify non-halting behavior.
>>
>> This is the halting problem.  It is better expressed in the simpler
>> terms given in texts like Linz.  I don't like the wording, just gives
>> the gist.
>>
>
> OK good so far.
>
>>> The criterion measure shown below defines the set of configurations
>>> that never reach their final state.
>>>
>>> Simple English version of Olcott's Halt status criterion measure:
>>> Every simulating halt decider that must abort the simulation of its
>>> input to prevent its infinite simulation correctly transitions to its
>>> reject state.
>>
>> This is not the halting problem.  Its even more badly written than the
>> first (for example, it's circular, and uses undefined metaphors like
>> "abort") but it conveys enough for readers to know that it's not the
>> correct criterion for the halting problem.  It's this "Halt status
>> criterion measure" (pompous or what?) that permits your decider to
>> reject a string that represents a halting computation.
>>
>
> When a simulating halt decider correctly determines its correctly
> simulated input would never reach its final state in any finite number
> of steps of pure simulation then this simulating halt decider has
> correctly determined that this input specifies non-halting behavior.

Right, PREREQUISITE: CORRECTLY determined. Not just 'some logic says',
but it needs to prove correct.

Since you have rejected the DEFINITION of correct, nothing you say can
actually be meaningful.

Remember the ONLY TRUE definition of the CORRECT answer is:

H applied to <M> w must -> H.Qy IFF M applied to w will Halt and -> H.Qn
IFF M applied to w will never Halt.

You then need to couple that with the requirement that the Halt Decider
needs to have an actual in place detailed algorithm with definite steps
(and 'prove x' is NOT a definite step, you need to detail HOW to prove),
so your decider does an actual computation.

>
>> You need to pick what H is defined to do -- decide halting (as in Linz),
>> or to decide PO-almost-but-not-really halting (which no one but you
>> cares about).  But it's clear from the above that are trying to
>> equivocate -- its the same as halting, honest! -- just re-worded so it
>> isn't.
>>
>
>

On 2022-03-04 21:07:30 +0000, Ben Bacarisse said:

> The words used don't alter the facts -- that there is no TM satisfying
> Linz's 12.1 can be, loosely, stated as "there is no decider for the
> strings that represent halting computations".

Words can be (and often are) used to hide facts.

Mikko

Mikko <mikko.levanto@iki.fi> writes:

> On 2022-03-04 21:07:30 +0000, Ben Bacarisse said:
>
>> The words used don't alter the facts -- that there is no TM
>> satisfying Linz's 12.1 can be, loosely, stated as "there is no
>> decider for the strings that represent halting computations".
>
> Words can be (and often are) used to hide facts.

But not, as far as I can see, in this case. The meaning of "decider" --
a TM whose language is decidable -- is not causing any confusion. OK,
PO lies about what other people say and/or know about "deciders", but
the fault there is in the lying, not in the words used.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> When a sequence of configurations would never reach their final state
>>> in any finite number of steps of pure simulation then this sequence of
>>> configurations specify non-halting behavior.
>>
>> This is the halting problem. It is better expressed in the simpler
>> terms given in texts like Linz. I don't like the wording, just gives
>> the gist.
>
> OK good so far.
>
>>> The criterion measure shown below defines the set of configurations
>>> that never reach their final state.
>>>
>>> Simple English version of Olcott's Halt status criterion measure:
>>> Every simulating halt decider that must abort the simulation of its
>>> input to prevent its infinite simulation correctly transitions to its
>>> reject state.
>>
>> This is not the halting problem. Its even more badly written than the
>> first (for example, it's circular, and uses undefined metaphors like
>> "abort") but it conveys enough for readers to know that it's not the
>> correct criterion for the halting problem. It's this "Halt status
>> criterion measure" (pompous or what?) that permits your decider to
>> reject a string that represents a halting computation.
>
> When a simulating halt decider correctly determines its correctly
> simulated input would never reach its final state in any finite number
> of steps of pure simulation then this simulating halt decider has
> correctly determined that this input specifies non-halting behavior.

There is no such thing as a simulating halt decider because there are no
halt deciders at all. But we can find out what you are saying about
these things asking if a TM, any TM, can do what you say:

When a TM (any TM) correctly determines its correctly simulated input
would never reach its final state in any finite number of steps of pure
simulation then this TM has correctly determined that this input
specifies non-halting behavior.

And re-worded again using tighter language and without all the filler
words:

When a TM determines that a simulation of its input would not halt it
can correctly report that the input represents a non-halting
computation.

And even more simply (and obviously):

When a TM determines that its input represents a non-halting computation
it can correct report that the input represents a non-halting
computation.

Kind of pointless thing to say, isn't it? Such TMs are ten-a-penny.

The irony is that you limited your claim (a safe and reasonable claim as
I hope you can see) to the very class of TMs that /can't/ do what you
say because there are none!

>> You need to pick what H is defined to do -- decide halting (as in Linz),
>> or to decide PO-almost-but-not-really halting (which no one but you
>> cares about). But it's clear from the above that are trying to
>> equivocate -- its the same as halting, honest! -- just re-worded so it
>> isn't.

This still stands. Every form of weasel words you try to come up with
is either (a) trivial (as here), (b) the halting problem with its
unassailable proofs or (c) your silly not-the-halting-problem that no
one cares about.

In symbols: what you have described here:

M x y ⊦* qn if x represents a TM that does not halt on y

There are many such M. What you are avoiding (the halting problem) is
this:

N x y ⊦* qn if, and only if, x represents a TM that does not halt on y
N x y ⊦* qy otherwise.

There are no such N. See any of the proofs you have not yet read. What
you sometimes describe:

P x y ⊦* qn if, and only if some waffle that's not like N above
P x y ⊦* qy otherwise.

--
Ben.

olcott <NoOne@NoWhere.com> writes:

> On 3/4/2022 5:30 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/4/2022 11:36 AM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 3/4/2022 9:29 AM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> I know that all deciders compute the mapping from their input finite
>>>>>>> strings to an accept or reject state. You and Ben prove that you do
>>>>>>> not understand that halt deciders are deciders.
>>>>>> Lying about technical matters is one thing[1], but lying about people is
>>>>>> not on. It's despicable and you should stop doing it.
>>>>>
>>>>> When you would actually directly address the point at hand you have no
>>>>> rebuttal because it is correct.
>>>> What are you waffling about now? Of course a halt decider (were such a
>>>> thing to exist) would be a decider. Your lie is that neither I nor
>>>> Richard have ever said what claim. Continuing to lie about what people
>>>> claim is despicable. You've done it before. You will probably keep
>>>> doing it.
>>>>
>>>>> THIS IS THE POINT AT HAND
>>>> By which you mean this the current distraction from 17 years of
>>>> uncorrected mistakes.
>>>>
>>>>> It is the case that all deciders ONLY compute the mapping from their
>>>>> input finite strings to an accept or reject state thus everything that
>>>>> is not an input finite sting is out-of-scope for the decider.
>>>> Apart form the bad wording, no one has ever objected to that.
>>>>
>>>>> This shows that embedded_H must compute the mapping from ⟨Ĥ⟩ ⟨Ĥ⟩ to an
>>>>> accept or reject state and is not allowed to report on the behavior of
>>>>> the computation that contains itself Ĥ ⟨Ĥ⟩.
>>>>
>>>> Nonsense. First off, this is a silly use of language -- a TM is not
>>>> "allowed" or "not allowed" to do anything. A TM+input entails a
>>>> sequence of configurations determined solely by the state transition
>>>> function and the input. They have do not need permission for anything,
>>>> and permission can not be withdrawn about anything.
>>>> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ and H ⟨Ĥ⟩ ⟨Ĥ⟩ entail the same sequence of
>>>> configurations up to qn or qy. If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qy ⊦ oo then
>>>> H accepts ⟨Ĥ⟩ ⟨Ĥ⟩. If embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊦* qn then H rejects ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>
>>> It seems that all you have is one dishonest dodge or another. I have
>>> not been speaking about H for many months so when you bring it up now
>>> it is a direct dodge of the point at hand.
>> Of course you are not speaking about H. You are wrong about H so you
>> must try to not talk about it anymore. Ironically it's you that want me
>> to dodge this issue: if I can't talk about H, you condemn me to do
>> nothing but dodge the key point -- that H is wrong.
>>
>>> When embedded_H computes the mapping from its input finite string pair
>>> ⟨Ĥ⟩ ⟨Ĥ⟩ inputs to an accept or reject state it does this on the basis
>>> of the behavior specified by this finite string pair: ⟨Ĥ⟩ ⟨Ĥ⟩
>> Sign. I wish you could get the details right. It would allow a
>> discussion of the big mistakes. embedded_H has no accepting state.
>
> embedded_H does indeed have an accept state, Ĥ.qy still exists even
> though it has been broken by the appended infinite loop.

So we can add accepting state as another phase you use without knowing
what it means. You are passing up so many opportunities to learn.
Wouldn't you like to know what are saying when you words?

>> Anyway, I can't tell you why you are wrong because I must not talk about
>> H. Great -- that simplifies my replies a lot.
>>
>>> and not on the basis of the behavior of the computation that contains
>>> itself: Ĥ ⟨Ĥ⟩.
>>
>> Fortunately for you, you have banned me from telling you why this is
>> wrong!
>
> WHICH FACTS DO YOU DISAGREE WITH?
> (a) It is the case that deciders compute the mapping ONLY from their
> inputs to an accept or reject state.
>
> (b) It is the case that deciders DO NOT compute the mapping from
> non-inputs to anything.
>
> (c) It is the case that the pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H
> would never reach the final state of ⟨Ĥ⟩.qn in any finite number of
> steps.

I disagree with (a), (b) and (c) but with (a) and (b) only because you
can't write technical English. (a) is almost right correct; (b) depends
on how you (and I) choose to define "compute the mapping" so it might be
right, but (c) is just garbage -- literal nonsense.

Am I still banned from talking about your H and Linz's H? If so, I
can't say more.

> If my reasoning is incorrect then a flaw could be pointed out. If it
> is impossible to point out any error in my reasoning then this proves
> that it is correct.

There's difference between pointing out a flaw, and seeing a flaw. You
see a flaw in the proof but you can't point it out. Lots of people have
pointed out flaws in what you are saying, but you can't see them. Until
you get off your high horse and try to understand what people are
telling you, you will remain stuck talking garbage like your (c) above.

> To avoid this challenge you simply change the subject to fool the
> gullible into believing that you provided a rebuttal.

It's hard for me to be more clear: your silly "criterion" (I can't
remember the actual pompous phrase you use) does not define the halting
problem. No one cares about it except you. How much more clear can I
possibly be?

--
Ben.

On 3/5/2022 2:38 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> When a sequence of configurations would never reach their final state
>>>> in any finite number of steps of pure simulation then this sequence of
>>>> configurations specify non-halting behavior.
>>>
>>> This is the halting problem. It is better expressed in the simpler
>>> terms given in texts like Linz. I don't like the wording, just gives
>>> the gist.
>>
>> OK good so far.
>>
>>>> The criterion measure shown below defines the set of configurations
>>>> that never reach their final state.
>>>>
>>>> Simple English version of Olcott's Halt status criterion measure:
>>>> Every simulating halt decider that must abort the simulation of its
>>>> input to prevent its infinite simulation correctly transitions to its
>>>> reject state.
>>>
>>> This is not the halting problem. Its even more badly written than the
>>> first (for example, it's circular, and uses undefined metaphors like
>>> "abort") but it conveys enough for readers to know that it's not the
>>> correct criterion for the halting problem. It's this "Halt status
>>> criterion measure" (pompous or what?) that permits your decider to
>>> reject a string that represents a halting computation.
>>
>> When a simulating halt decider correctly determines its correctly
>> simulated input would never reach its final state in any finite number
>> of steps of pure simulation then this simulating halt decider has
>> correctly determined that this input specifies non-halting behavior.
>
> There is no such thing as a simulating halt decider because there are no
> halt deciders at all.

Then call it a halt determiner.

> But we can find out what you are saying about
> these things asking if a TM, any TM, can do what you say:
>
> When a TM (any TM) correctly determines its correctly simulated input
> would never reach its final state in any finite number of steps of pure
> simulation then this TM has correctly determined that this input
> specifies non-halting behavior.
>
> And re-worded again using tighter language and without all the filler
> words:
>
> When a TM determines that a simulation of its input would not halt it
> can correctly report that the input represents a non-halting
> computation.
>

Not precise enough. It must be a simulation performed by the simulating
halt determiner.

When a TM determines that [its correct pure] simulation of its input
would not halt it can correctly report that the input represents a
non-halting computation.

Your definition will be to confusing for people that are not computer
scientists because they will believe that when the simulating halt
determiner aborts its simulation that this causes the input to halt,
thus the halt determiner is contradicting itself.

> And even more simply (and obviously):
>
> When a TM determines that its input represents a non-halting computation
> it can correct report that the input represents a non-halting
> computation.
>
> Kind of pointless thing to say, isn't it? Such TMs are ten-a-penny.
>
> The irony is that you limited your claim (a safe and reasonable claim as
> I hope you can see) to the very class of TMs that /can't/ do what you
> say because there are none!
>

A halt determiner is the same thing as a halt decider with the only
difference being that the halt determiner needs to only correctly
determine the halt status of a single input pair or a limited set of
input pairs, thus has a restricted domain.

When a simulating halt determiner correctly determines its correctly
simulated input would never reach its final state in any finite number
of steps of pure simulation then this simulating halt determiner has
correctly determined that this input specifies non-halting behavior.

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

Could a correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H transition to
⟨Ĥ⟩.qn ?

When Ĥ is applied to ⟨Ĥ⟩
Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩

Then these steps would keep repeating:
Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

--
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/5/22 4:26 PM, olcott wrote:
> On 3/5/2022 2:38 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> When a sequence of configurations would never reach their final state
>>>>> in any finite number of steps of pure simulation then this sequence of
>>>>> configurations specify non-halting behavior.
>>>>
>>>> This is the halting problem.  It is better expressed in the simpler
>>>> terms given in texts like Linz.  I don't like the wording, just gives
>>>> the gist.
>>>
>>> OK good so far.
>>>
>>>>> The criterion measure shown below defines the set of configurations
>>>>> that never reach their final state.
>>>>>
>>>>> Simple English version of Olcott's Halt status criterion measure:
>>>>> Every simulating halt decider that must abort the simulation of its
>>>>> input to prevent its infinite simulation correctly transitions to its
>>>>> reject state.
>>>>
>>>> This is not the halting problem.  Its even more badly written than the
>>>> first (for example, it's circular, and uses undefined metaphors like
>>>> "abort") but it conveys enough for readers to know that it's not the
>>>> correct criterion for the halting problem.  It's this "Halt status
>>>> criterion measure" (pompous or what?) that permits your decider to
>>>> reject a string that represents a halting computation.
>>>
>>> When a simulating halt decider correctly determines its correctly
>>> simulated input would never reach its final state in any finite number
>>> of steps of pure simulation then this simulating halt decider has
>>> correctly determined that this input specifies non-halting behavior.
>>
>> There is no such thing as a simulating halt decider because there are no
>> halt deciders at all.
>
> Then call it a halt determiner.
>
>>  But we can find out what you are saying about
>> these things asking if a TM, any TM, can do what you say:
>>
>> When a TM (any TM) correctly determines its correctly simulated input
>> would never reach its final state in any finite number of steps of pure
>> simulation then this TM has correctly determined that this input
>> specifies non-halting behavior.
>>
>> And re-worded again using tighter language and without all the filler
>> words:
>>
>> When a TM determines that a simulation of its input would not halt it
>> can correctly report that the input represents a non-halting
>> computation.
>>
>
> Not precise enough. It must be a simulation performed by the simulating
> halt determiner.
>

The problem with that is that you then don't match the definition of
Halting, so are no longer being a Halt Decider.

> When a TM determines that [its correct pure] simulation of its input
> would not halt it can correctly report that the input represents a
> non-halting computation.

Since NO Halt Decider can correct simulate a non-halting computation and
be a decider (as the correct simulation of a non-halting computaiton
takes infinite time), you need to change the wording to be that if the
TM can determine that the correct pure simulation by a UTM of its input
would not halt, it can correctly report that the input represents a
non-halting computation.

The problem for you is that your H fails to meet this correct
definition, sunce we can show that if H <H^> <H^> goes to H.Qn that <H^>
<H^> when simulated by a UTM goes to H^.Qn and Halts, so H was incorrect.

>
> Your definition will be to confusing for people that are not computer
> scientists because they will believe that when the simulating halt
> determiner aborts its simulation that this causes the input to halt,
> thus the halt determiner is contradicting itself.
>

And your definition is just WRONG.

>> And even more simply (and obviously):
>>
>> When a TM determines that its input represents a non-halting computation
>> it can correct report that the input represents a non-halting
>> computation.
>>
>> Kind of pointless thing to say, isn't it?  Such TMs are ten-a-penny.
>>
>> The irony is that you limited your claim (a safe and reasonable claim as
>> I hope you can see) to the very class of TMs that /can't/ do what you
>> say because there are none!
>>
>
> A halt determiner is the same thing as a halt decider with the only
> difference being that the halt determiner needs to only correctly
> determine the halt status of a single input pair or a limited set of
> input pairs, thus has a restricted domain.

But your machine still gets the key one wrong.

>
> When a simulating halt determiner correctly determines its correctly
> simulated input would never reach its final state in any finite number
> of steps of pure simulation then this simulating halt determiner has
> correctly determined that this input specifies non-halting behavior.

Which is the wrong definition, so it isn't even a Halt whatever, it is
just a POOP determiner.

>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> Could a correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H transition to
> ⟨Ĥ⟩.qn ?

embedded_H is only a correct pure simulation if it can never abort, so
the question becomes meaningless, as it onlly applies to a decider that
fails to decide.

>
> When Ĥ is applied to ⟨Ĥ⟩
>   Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>
> Then these steps would keep repeating:
>   Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>   Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>   Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>
>
>
>

And the above trace only happens if H/embedded_H never aborts, and thus
fails by not giving an answer.

olcott <NoOne@NoWhere.com> writes:

> On 3/5/2022 2:38 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> When a sequence of configurations would never reach their final state
>>>>> in any finite number of steps of pure simulation then this sequence of
>>>>> configurations specify non-halting behavior.
>>>>
>>>> This is the halting problem. It is better expressed in the simpler
>>>> terms given in texts like Linz. I don't like the wording, just gives
>>>> the gist.
>>>
>>> OK good so far.
>>>
>>>>> The criterion measure shown below defines the set of configurations
>>>>> that never reach their final state.
>>>>>
>>>>> Simple English version of Olcott's Halt status criterion measure:
>>>>> Every simulating halt decider that must abort the simulation of its
>>>>> input to prevent its infinite simulation correctly transitions to its
>>>>> reject state.
>>>>
>>>> This is not the halting problem. Its even more badly written than the
>>>> first (for example, it's circular, and uses undefined metaphors like
>>>> "abort") but it conveys enough for readers to know that it's not the
>>>> correct criterion for the halting problem. It's this "Halt status
>>>> criterion measure" (pompous or what?) that permits your decider to
>>>> reject a string that represents a halting computation.
>>>
>>> When a simulating halt decider correctly determines its correctly
>>> simulated input would never reach its final state in any finite number
>>> of steps of pure simulation then this simulating halt decider has
>>> correctly determined that this input specifies non-halting behavior.
>> There is no such thing as a simulating halt decider because there are no
>> halt deciders at all.
>
> Then call it a halt determiner.

What they are called is not really very important. What they do is
crucial.

>> But we can find out what you are saying about
>> these things asking if a TM, any TM, can do what you say:
>>
>> When a TM (any TM) correctly determines its correctly simulated input
>> would never reach its final state in any finite number of steps of pure
>> simulation then this TM has correctly determined that this input
>> specifies non-halting behavior.
>>
>> And re-worded again using tighter language and without all the filler
>> words:
>>
>> When a TM determines that a simulation of its input would not halt it
>> can correctly report that the input represents a non-halting
>> computation.
>
> Not precise enough. It must be a simulation performed by the
> simulating halt determiner.

Ah, then you need to define what that is. If it's different to a
simulator in any significant way then your statements is not about the
halting problem and can be ignored.

> When a TM determines that [its correct pure] simulation of its input
> would not halt it can correctly report that the input represents a
> non-halting computation.

This is either the same as my re-write (if you remove the [...] part or
replace "its" with "a") or it is an attempt to obscure the that fact
that the "determiner" can ignore some halting computations because "it"
halted them. I am sure it the latter this as been you ruse for ages.

Anyway, you should either write the correct condition as found in every
textbook you've never read, or just come clean that you are not talking
about the halting problem.

> Your definition will be to confusing for people that are not computer
> scientists because they will believe that when the simulating halt
> determiner aborts its simulation that this causes the input to halt,
> thus the halt determiner is contradicting itself.

My definition did not use undefined terms like "simulating halt
determiner" or "abort". And mine had no absurd vague "its" in it.

>> And even more simply (and obviously):
>> When a TM determines that its input represents a non-halting computation
>> it can correct report that the input represents a non-halting
>> computation.

> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Of course you miss of the key conditions because you have not yet found
a way to write the that fools anyone:

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ halts on input ⟨Ĥ⟩, and
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ does not halts on input ⟨Ĥ⟩.

> Could a correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H transition to
> ⟨Ĥ⟩.qn ?

Who knows? You have not defined what ⟨Ĥ⟩.qn means. In Linz, embedded_H
is the same as H (with a few tweaks) and can't correctly transition to
either Ĥ.qn or Ĥ.qy.

Your embedded_H is a mystery because it's not as in Linz.

> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>
> Then these steps would keep repeating:
> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
> Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...

OK. You are permitted to say that that is what you Ĥ does. Why should
anyone care?

--
Ben.

On 3/6/2022 11:36 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/5/2022 2:38 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> When a sequence of configurations would never reach their final state
>>>>>> in any finite number of steps of pure simulation then this sequence of
>>>>>> configurations specify non-halting behavior.
>>>>>
>>>>> This is the halting problem. It is better expressed in the simpler
>>>>> terms given in texts like Linz. I don't like the wording, just gives
>>>>> the gist.
>>>>
>>>> OK good so far.
>>>>
>>>>>> The criterion measure shown below defines the set of configurations
>>>>>> that never reach their final state.
>>>>>>
>>>>>> Simple English version of Olcott's Halt status criterion measure:
>>>>>> Every simulating halt decider that must abort the simulation of its
>>>>>> input to prevent its infinite simulation correctly transitions to its
>>>>>> reject state.
>>>>>
>>>>> This is not the halting problem. Its even more badly written than the
>>>>> first (for example, it's circular, and uses undefined metaphors like
>>>>> "abort") but it conveys enough for readers to know that it's not the
>>>>> correct criterion for the halting problem. It's this "Halt status
>>>>> criterion measure" (pompous or what?) that permits your decider to
>>>>> reject a string that represents a halting computation.
>>>>
>>>> When a simulating halt decider correctly determines its correctly
>>>> simulated input would never reach its final state in any finite number
>>>> of steps of pure simulation then this simulating halt decider has
>>>> correctly determined that this input specifies non-halting behavior.
>>> There is no such thing as a simulating halt decider because there are no
>>> halt deciders at all.
>>
>> Then call it a halt determiner.
>
> What they are called is not really very important. What they do is
> crucial.
>
>>> But we can find out what you are saying about
>>> these things asking if a TM, any TM, can do what you say:
>>>
>>> When a TM (any TM) correctly determines its correctly simulated input
>>> would never reach its final state in any finite number of steps of pure
>>> simulation then this TM has correctly determined that this input
>>> specifies non-halting behavior.
>>>
>>> And re-worded again using tighter language and without all the filler
>>> words:
>>>
>>> When a TM determines that a simulation of its input would not halt it
>>> can correctly report that the input represents a non-halting
>>> computation.
>>
>> Not precise enough. It must be a simulation performed by the
>> simulating halt determiner.
>
> Ah, then you need to define what that is. If it's different to a
> simulator in any significant way then your statements is not about the
> halting problem and can be ignored.
>
>> When a TM determines that [its correct pure] simulation of its input
>> would not halt it can correctly report that the input represents a
>> non-halting computation.
>
> This is either the same as my re-write (if you remove the [...] part or
> replace "its" with "a") or it is an attempt to obscure the that fact
> that the "determiner" can ignore some halting computations because "it"
> halted them. I am sure it the latter this as been you ruse for ages.
>
> Anyway, you should either write the correct condition as found in every
> textbook you've never read, or just come clean that you are not talking
> about the halting problem.
>
>> Your definition will be to confusing for people that are not computer
>> scientists because they will believe that when the simulating halt
>> determiner aborts its simulation that this causes the input to halt,
>> thus the halt determiner is contradicting itself.
>
> My definition did not use undefined terms like "simulating halt
> determiner" or "abort". And mine had no absurd vague "its" in it.
>
>>> And even more simply (and obviously):
>>> When a TM determines that its input represents a non-halting computation
>>> it can correct report that the input represents a non-halting
>>> computation.
>
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> Of course you miss of the key conditions because you have not yet found
> a way to write the that fools anyone:
>
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ halts on input ⟨Ĥ⟩, and
> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ does not halts on input ⟨Ĥ⟩.
>
>> Could a correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H transition to
>> ⟨Ĥ⟩.qn ?
>
> Who knows? You have not defined what ⟨Ĥ⟩.qn means. In Linz, embedded_H
> is the same as H (with a few tweaks) and can't correctly transition to
> either Ĥ.qn or Ĥ.qy.
>
> Your embedded_H is a mystery because it's not as in Linz.
>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>
>> Then these steps would keep repeating:
>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>> Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>
> OK. You are permitted to say that that is what you Ĥ does. Why should
> anyone care?
>

A halt determiner is the same thing as a halt decider with the only
difference being that the halt determiner needs to only correctly
determine the halt status of a single input pair or a limited set of
input pairs thus has a restricted domain.

A simulating halt determiner determines whether or not its input
specifies a non-halting sequence of configurations on the basis of
recognizing infinite patterns in the behavior of its simulated input
(such as the above pattern) that indicate that it would never reach its
final state in any finite number of steps of pure simulation.

> Why should anyone care?
>

Thus the copy of Linz H embedded at Ĥ.qx correctly determines that its
input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thereby refuting the Linz proof that this is
impossible.

--
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/6/22 2:17 PM, olcott wrote:
> On 3/6/2022 11:36 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/5/2022 2:38 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> When a sequence of configurations would never reach their final
>>>>>>> state
>>>>>>> in any finite number of steps of pure simulation then this
>>>>>>> sequence of
>>>>>>> configurations specify non-halting behavior.
>>>>>>
>>>>>> This is the halting problem.  It is better expressed in the simpler
>>>>>> terms given in texts like Linz.  I don't like the wording, just gives
>>>>>> the gist.
>>>>>
>>>>> OK good so far.
>>>>>
>>>>>>> The criterion measure shown below defines the set of configurations
>>>>>>> that never reach their final state.
>>>>>>>
>>>>>>> Simple English version of Olcott's Halt status criterion measure:
>>>>>>> Every simulating halt decider that must abort the simulation of its
>>>>>>> input to prevent its infinite simulation correctly transitions to
>>>>>>> its
>>>>>>> reject state.
>>>>>>
>>>>>> This is not the halting problem.  Its even more badly written than
>>>>>> the
>>>>>> first (for example, it's circular, and uses undefined metaphors like
>>>>>> "abort") but it conveys enough for readers to know that it's not the
>>>>>> correct criterion for the halting problem.  It's this "Halt status
>>>>>> criterion measure" (pompous or what?) that permits your decider to
>>>>>> reject a string that represents a halting computation.
>>>>>
>>>>> When a simulating halt decider correctly determines its correctly
>>>>> simulated input would never reach its final state in any finite number
>>>>> of steps of pure simulation then this simulating halt decider has
>>>>> correctly determined that this input specifies non-halting behavior.
>>>> There is no such thing as a simulating halt decider because there
>>>> are no
>>>> halt deciders at all.
>>>
>>> Then call it a halt determiner.
>>
>> What they are called is not really very important.  What they do is
>> crucial.
>>
>>>>   But we can find out what you are saying about
>>>> these things asking if a TM, any TM, can do what you say:
>>>>
>>>> When a TM (any TM) correctly determines its correctly simulated input
>>>> would never reach its final state in any finite number of steps of pure
>>>> simulation then this TM has correctly determined that this input
>>>> specifies non-halting behavior.
>>>>
>>>> And re-worded again using tighter language and without all the filler
>>>> words:
>>>>
>>>> When a TM determines that a simulation of its input would not halt it
>>>> can correctly report that the input represents a non-halting
>>>> computation.
>>>
>>> Not precise enough. It must be a simulation performed by the
>>> simulating halt determiner.
>>
>> Ah, then you need to define what that is.  If it's different to a
>> simulator in any significant way then your statements is not about the
>> halting problem and can be ignored.
>>
>>> When a TM determines that [its correct pure] simulation of its input
>>> would not halt it can correctly report that the input represents a
>>> non-halting computation.
>>
>> This is either the same as my re-write (if you remove the [...] part or
>> replace "its" with "a") or it is an attempt to obscure the that fact
>> that the "determiner" can ignore some halting computations because "it"
>> halted them.  I am sure it the latter this as been you ruse for ages.
>>
>> Anyway, you should either write the correct condition as found in every
>> textbook you've never read, or just come clean that you are not talking
>> about the halting problem.
>>
>>> Your definition will be to confusing for people that are not computer
>>> scientists because they will believe that when the simulating halt
>>> determiner aborts its simulation that this causes the input to halt,
>>> thus the halt determiner is contradicting itself.
>>
>> My definition did not use undefined terms like "simulating halt
>> determiner" or "abort".  And mine had no absurd vague "its" in it.
>>
>>>> And even more simply (and obviously):
>>>> When a TM determines that its input represents a non-halting
>>>> computation
>>>> it can correct report that the input represents a non-halting
>>>> computation.
>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> Of course you miss of the key conditions because you have not yet found
>> a way to write the that fools anyone:
>>
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞  if Ĥ halts on input ⟨Ĥ⟩, and
>>    Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn    if Ĥ does not halts on input ⟨Ĥ⟩.
>>
>>> Could a correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H transition to
>>> ⟨Ĥ⟩.qn ?
>>
>> Who knows?  You have not defined what ⟨Ĥ⟩.qn means.  In Linz, embedded_H
>> is the same as H (with a few tweaks) and can't correctly transition to
>> either Ĥ.qn or Ĥ.qy.
>>
>> Your embedded_H is a mystery because it's not as in Linz.
>>
>>> When Ĥ is applied to ⟨Ĥ⟩
>>>    Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>
>>> Then these steps would keep repeating:
>>>    Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>    Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>    Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩
>>> ⟨Ĥ5⟩...
>>
>> OK.  You are permitted to say that that is what you Ĥ does.  Why should
>> anyone care?
>>
>
>
> A halt determiner is the same thing as a halt decider with the only
> difference being that the halt determiner needs to only correctly
> determine the halt status of a single input pair or a limited set of
> input pairs thus has a restricted domain.

Except you use a DIFFERENT defintion of 'Halting' that does not match
what Halting actually means in the field.

TRUE definition of Halting as a decider/determier needs to determine:

H applied to <M> w need to decider Halting (and go to H.Qy) If and only
if M applied to w will Halt, and to decide Non-Halting (and go to H.Qn)
If and only if M applied to w will NEVER Halt.

We can replace the running of M applied to w with a REAL UTM and look at
UTM applied to <M> w instead. Note, BY DEFINITION, these are the same
conditon, or it isn't a UTM.

>
> A simulating halt determiner determines whether or not its input
> specifies a non-halting sequence of configurations on the basis of
> recognizing infinite patterns in the behavior of its simulated input
> (such as the above pattern) that indicate that it would never reach its
> final state in any finite number of steps of pure simulation.
>
> > Why should anyone care?
> >
>
> Thus the copy of Linz H embedded at Ĥ.qx correctly determines that its
> input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thereby refuting the Linz proof that this is
> impossible.
>

Except it doesn't. Unless some how you want to convince the world that
wrong answer are sometimes right.

Since H applied to <H^> <H^> goes to H.Qn, we KNOW by the construction
of H^ that when its copy of H goes to H.Qn that H^ also ends up in H^.Qn
and Halt.

Thus if H applied <H^> <H^> goes to H.Qn, we KNOW that H^ applied to
<H^> will apply the input <H^> <H^> to its copy of H, which will do
exactly the same thing and thus H^ goes to H^.Qn and Halts.

olcott <NoOne@NoWhere.com> writes:

> On 3/6/2022 11:36 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 3/5/2022 2:38 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>
>>>>>>> When a sequence of configurations would never reach their final state
>>>>>>> in any finite number of steps of pure simulation then this sequence of
>>>>>>> configurations specify non-halting behavior.
>>>>>>
>>>>>> This is the halting problem. It is better expressed in the simpler
>>>>>> terms given in texts like Linz. I don't like the wording, just gives
>>>>>> the gist.
>>>>>
>>>>> OK good so far.
>>>>>
>>>>>>> The criterion measure shown below defines the set of configurations
>>>>>>> that never reach their final state.
>>>>>>>
>>>>>>> Simple English version of Olcott's Halt status criterion measure:
>>>>>>> Every simulating halt decider that must abort the simulation of its
>>>>>>> input to prevent its infinite simulation correctly transitions to its
>>>>>>> reject state.
>>>>>>
>>>>>> This is not the halting problem. Its even more badly written than the
>>>>>> first (for example, it's circular, and uses undefined metaphors like
>>>>>> "abort") but it conveys enough for readers to know that it's not the
>>>>>> correct criterion for the halting problem. It's this "Halt status
>>>>>> criterion measure" (pompous or what?) that permits your decider to
>>>>>> reject a string that represents a halting computation.
>>>>>
>>>>> When a simulating halt decider correctly determines its correctly
>>>>> simulated input would never reach its final state in any finite number
>>>>> of steps of pure simulation then this simulating halt decider has
>>>>> correctly determined that this input specifies non-halting behavior.
>>>> There is no such thing as a simulating halt decider because there are no
>>>> halt deciders at all.
>>>
>>> Then call it a halt determiner.
>> What they are called is not really very important. What they do is
>> crucial.
>>
>>>> But we can find out what you are saying about
>>>> these things asking if a TM, any TM, can do what you say:
>>>>
>>>> When a TM (any TM) correctly determines its correctly simulated input
>>>> would never reach its final state in any finite number of steps of pure
>>>> simulation then this TM has correctly determined that this input
>>>> specifies non-halting behavior.
>>>>
>>>> And re-worded again using tighter language and without all the filler
>>>> words:
>>>>
>>>> When a TM determines that a simulation of its input would not halt it
>>>> can correctly report that the input represents a non-halting
>>>> computation.
>>>
>>> Not precise enough. It must be a simulation performed by the
>>> simulating halt determiner.
>>
>> Ah, then you need to define what that is. If it's different to a
>> simulator in any significant way then your statements is not about the
>> halting problem and can be ignored.

This is me pointing out a mistake which you are, as usual, ignoring.
Soon you will say, again, that no one can point out any errors in what
you say.

>>> When a TM determines that [its correct pure] simulation of its input
>>> would not halt it can correctly report that the input represents a
>>> non-halting computation.
>>
>> This is either the same as my re-write (if you remove the [...] part or
>> replace "its" with "a") or it is an attempt to obscure the that fact
>> that the "determiner" can ignore some halting computations because "it"
>> halted them. I am sure it the latter this as been you ruse for ages.
>> Anyway, you should either write the correct condition as found in every
>> textbook you've never read, or just come clean that you are not talking
>> about the halting problem.

This is me pointing out another two mistakes which you are, as usual,
ignoring. Soon you will say, again, that no one can point out any
errors in what you say.

>>> Your definition will be to confusing for people that are not computer
>>> scientists because they will believe that when the simulating halt
>>> determiner aborts its simulation that this causes the input to halt,
>>> thus the halt determiner is contradicting itself.
>> My definition did not use undefined terms like "simulating halt
>> determiner" or "abort". And mine had no absurd vague "its" in it.

And this is me pointing out yet another mistake which you are, as usual,
ignoring. Soon you will say, again, that no one can point out any
errors in what you say.

>>>> And even more simply (and obviously):
>>>> When a TM determines that its input represents a non-halting computation
>>>> it can correct report that the input represents a non-halting
>>>> computation.
>>
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>> Of course you miss of the key conditions because you have not yet found
>> a way to write the that fools anyone:
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ halts on input ⟨Ĥ⟩, and
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ does not halts on input ⟨Ĥ⟩.
>>
>>> Could a correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H transition to
>>> ⟨Ĥ⟩.qn ?
>> Who knows? You have not defined what ⟨Ĥ⟩.qn means.

And this is me pointing out yet another mistake which you are, as usual,
ignoring. Soon you will say, again, that no one can point out any
errors in your reasoning.

>> In Linz, embedded_H
>> is the same as H (with a few tweaks) and can't correctly transition to
>> either Ĥ.qn or Ĥ.qy.
>> Your embedded_H is a mystery because it's not as in Linz.

And this is me pointing out yet another mistake which you are, as usual,
ignoring.
>>> When Ĥ is applied to ⟨Ĥ⟩
>>> Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>
>>> Then these steps would keep repeating:
>>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>> Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>> OK. You are permitted to say that that is what you Ĥ does. Why should
>> anyone care?
>
> A halt determiner is the same thing as a halt decider with the only
> difference being that the halt determiner needs to only correctly
> determine the halt status of a single input pair or a limited set of
> input pairs thus has a restricted domain.

Then, for every single "input pair", there are an infinity of correct
"halt determiners". No one is interested in such trivial things.

You will probably be baffled by how I can say this, but I bet that, if
your are, you won't try to find out by trying to learn something.

> A simulating halt determiner determines whether or not its input
> specifies a non-halting sequence of configurations on the basis of
> recognizing infinite patterns in the behavior of its simulated input
> (such as the above pattern) that indicate that it would never reach
> its final state in any finite number of steps of pure simulation.

That's one way to write some of these trivial Turing machines. I still
don't care about them.

>> Why should anyone care?
>
> Thus the copy of Linz H embedded at Ĥ.qx correctly determines that its
> input: ⟨Ĥ⟩ ⟨Ĥ⟩ never halts thereby refuting the Linz proof that this
> is impossible.

Linz's H does not exist. There is no input string ⟨Ĥ⟩ ⟨Ĥ⟩. There is a
proof about that. There are lots of proofs about that.

Your H may exist, but it's not Linz's.

--
Ben.

On 3/6/2022 6:21 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 3/6/2022 11:36 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 3/5/2022 2:38 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> On 3/4/2022 5:37 PM, Ben Bacarisse wrote:
>>>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>>>
>>>>>>>> When a sequence of configurations would never reach their final state
>>>>>>>> in any finite number of steps of pure simulation then this sequence of
>>>>>>>> configurations specify non-halting behavior.
>>>>>>>
>>>>>>> This is the halting problem. It is better expressed in the simpler
>>>>>>> terms given in texts like Linz. I don't like the wording, just gives
>>>>>>> the gist.
>>>>>>
>>>>>> OK good so far.
>>>>>>
>>>>>>>> The criterion measure shown below defines the set of configurations
>>>>>>>> that never reach their final state.
>>>>>>>>
>>>>>>>> Simple English version of Olcott's Halt status criterion measure:
>>>>>>>> Every simulating halt decider that must abort the simulation of its
>>>>>>>> input to prevent its infinite simulation correctly transitions to its
>>>>>>>> reject state.
>>>>>>>
>>>>>>> This is not the halting problem. Its even more badly written than the
>>>>>>> first (for example, it's circular, and uses undefined metaphors like
>>>>>>> "abort") but it conveys enough for readers to know that it's not the
>>>>>>> correct criterion for the halting problem. It's this "Halt status
>>>>>>> criterion measure" (pompous or what?) that permits your decider to
>>>>>>> reject a string that represents a halting computation.
>>>>>>
>>>>>> When a simulating halt decider correctly determines its correctly
>>>>>> simulated input would never reach its final state in any finite number
>>>>>> of steps of pure simulation then this simulating halt decider has
>>>>>> correctly determined that this input specifies non-halting behavior.
>>>>> There is no such thing as a simulating halt decider because there are no
>>>>> halt deciders at all.
>>>>
>>>> Then call it a halt determiner.
>>> What they are called is not really very important. What they do is
>>> crucial.
>>>
>>>>> But we can find out what you are saying about
>>>>> these things asking if a TM, any TM, can do what you say:
>>>>>
>>>>> When a TM (any TM) correctly determines its correctly simulated input
>>>>> would never reach its final state in any finite number of steps of pure
>>>>> simulation then this TM has correctly determined that this input
>>>>> specifies non-halting behavior.
>>>>>
>>>>> And re-worded again using tighter language and without all the filler
>>>>> words:
>>>>>
>>>>> When a TM determines that a simulation of its input would not halt it
>>>>> can correctly report that the input represents a non-halting
>>>>> computation.
>>>>
>>>> Not precise enough. It must be a simulation performed by the
>>>> simulating halt determiner.
>>>
>>> Ah, then you need to define what that is. If it's different to a
>>> simulator in any significant way then your statements is not about the
>>> halting problem and can be ignored.
>
> This is me pointing out a mistake which you are, as usual, ignoring.
> Soon you will say, again, that no one can point out any errors in what
> you say.
>

Since I have defined it 10,000 times it seems a little nuts that you ask
me to define it again. I have defined it again below.

>>>> When a TM determines that [its correct pure] simulation of its input
>>>> would not halt it can correctly report that the input represents a
>>>> non-halting computation.
>>>
>>> This is either the same as my re-write (if you remove the [...] part or
>>> replace "its" with "a") or it is an attempt to obscure the that fact
>>> that the "determiner" can ignore some halting computations because "it"
>>> halted them. I am sure it the latter this as been you ruse for ages.
>>> Anyway, you should either write the correct condition as found in every
>>> textbook you've never read, or just come clean that you are not talking
>>> about the halting problem.
>
> This is me pointing out another two mistakes which you are, as usual,
> ignoring. Soon you will say, again, that no one can point out any
> errors in what you say.
>

When-so-ever a simulating halt determiner detects an infinite behavior
pattern in the simulation of its input such that this simulated input
would never reach its final state in any finite number of steps it
rejects this input.

>>>> Your definition will be to confusing for people that are not computer
>>>> scientists because they will believe that when the simulating halt
>>>> determiner aborts its simulation that this causes the input to halt,
>>>> thus the halt determiner is contradicting itself.
>>> My definition did not use undefined terms like "simulating halt
>>> determiner" or "abort". And mine had no absurd vague "its" in it.
>
> And this is me pointing out yet another mistake which you are, as usual,
> ignoring. Soon you will say, again, that no one can point out any
> errors in what you say.

It is freaking nuts to require "simulation has been aborted" to be defined.

>
>>>>> And even more simply (and obviously):
>>>>> When a TM determines that its input represents a non-halting computation
>>>>> it can correct report that the input represents a non-halting
>>>>> computation.
>>>
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>> Of course you miss of the key conditions because you have not yet found
>>> a way to write the that fools anyone:
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ if Ĥ halts on input ⟨Ĥ⟩, and
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.qx ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn if Ĥ does not halts on input ⟨Ĥ⟩.
>>>
>>>> Could a correct pure simulation of ⟨Ĥ⟩ ⟨Ĥ⟩ by embedded_H transition to
>>>> ⟨Ĥ⟩.qn ?
>>> Who knows? You have not defined what ⟨Ĥ⟩.qn means.
>
> And this is me pointing out yet another mistake which you are, as usual,
> ignoring. Soon you will say, again, that no one can point out any
> errors in your reasoning.

When this simulated input ⟨Ĥ⟩ ⟨Ĥ⟩ has reached its own final state this
final state is referred to as ⟨Ĥ⟩.qn.

>>> In Linz, embedded_H
>>> is the same as H (with a few tweaks) and can't correctly transition to
>>> either Ĥ.qn or Ĥ.qy.
>>> Your embedded_H is a mystery because it's not as in Linz.
>
> And this is me pointing out yet another mistake which you are, as usual,
> ignoring.

embedded_H is the copy of H that Linz specifies is embedded in the
middle of Ĥ (as I have repeated dozens of times).

Do you always expect me to repeat every single detail on every single post?

>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>> Ĥ copies its input ⟨Ĥ1⟩ to ⟨Ĥ2⟩ then embedded_H simulates ⟨Ĥ1⟩ ⟨Ĥ2⟩
>>>>
>>>> Then these steps would keep repeating:
>>>> Ĥ1 copies its input ⟨Ĥ2⟩ to ⟨Ĥ3⟩ then embedded_H simulates ⟨Ĥ2⟩ ⟨Ĥ3⟩
>>>> Ĥ2 copies its input ⟨Ĥ3⟩ to ⟨Ĥ4⟩ then embedded_H simulates ⟨Ĥ3⟩ ⟨Ĥ4⟩
>>>> Ĥ3 copies its input ⟨Ĥ4⟩ to ⟨Ĥ5⟩ then embedded_H simulates ⟨Ĥ4⟩ ⟨Ĥ5⟩...
>>> OK. You are permitted to say that that is what you Ĥ does. Why should
>>> anyone care?
>>
>> A halt determiner is the same thing as a halt decider with the only
>> difference being that the halt determiner needs to only correctly
>> determine the halt status of a single input pair or a limited set of
>> input pairs thus has a restricted domain.
>
> Then, for every single "input pair", there are an infinity of correct
> "halt determiners". No one is interested in such trivial things.
>
> You will probably be baffled by how I can say this, but I bet that, if
> your are, you won't try to find out by trying to learn something.
>
>> A simulating halt determiner determines whether or not its input
>> specifies a non-halting sequence of configurations on the basis of
>> recognizing infinite patterns in the behavior of its simulated input
>> (such as the above pattern) that indicate that it would never reach
>> its final state in any finite number of steps of pure simulation.
>
> That's one way to write some of these trivial Turing machines. I still
> don't care about them.
>