On 5/27/2021 8:40 AM, Malcolm McLean wrote:
> On Thursday, 27 May 2021 at 14:04:32 UTC+1, olcott wrote:
>> On 5/27/2021 3:38 AM, Malcolm McLean wrote:
>>> On Thursday, 27 May 2021 at 07:43:08 UTC+1, olcott wrote:
>>>> On 5/26/2021 1:17 PM, Malcolm McLean wrote:
>>>>> On Wednesday, 26 May 2021 at 16:31:10 UTC+1, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>> Yes. With the interminable H_Hat(H_Hat) example, if the offered H is
>>>>> reasonably simple, it's easy to build a decider which is more than a
>>>>> simple stub, and gives the correct answer for H_Hat(H_Hat). So it's
>>>>> easy to see that H_Hat(H_Hat) is "decidable".
>>>>
>>>> You are agreeing that H_Hat(H_Hat) is decidable,
>>>>
>>>> I am taking this to mean that H_Hat(H_Hat) can be correctly determined
>>>> to be a member of the set of non halting computations.
>>>>
>>> It's in scare quotes because apparently "decidable" is not the correct terminology.
>>> As far as I am aware (others may correct me here) "decidable" refers to sets.
>>> So a set is "decidable" if there is some Turing machine which separates all
>>> members into two sub-sets. It follows that all finite sets are "decidable" by the
>>> brute force algorithm.
>>>
>>> When we are talking about a single computation, and whether or not we know
>>> that it halts, we shouldn't use the term "decidable".
>>>
>> I think that part of the problem may be that there are things that need
>> to be said that have no correct way to say them.
>>
>> When you say that H_Hat(H_Hat) is decidable, that would seem to mean
>> that the computation Halts((u32)H_Hat, (u32)H_Hat); would return a value
>> indicating whether or not its input is a halting computation.
>>
> "Decidable", in in context of computer science, is a property of a set. It doesn't
> make much sense to apply it to a singleton set, or to a computation.
>
> We can say that H_Hat(H_Hat) is "known to halt", or "known not to halt" and we
> can say that Halts() reports this correctly or incorrectly. But it's best to avoid
> the term "decides".
>

As I did in the rest of of my reply that you trimmed:

When you refer to a decidable input I refer to the determination that an
input is included or excluded from membership on the set of halting
computations.

On 5/27/2021 8:04 AM, olcott wrote:
> When you say that H_Hat(H_Hat) is decidable, that would seem
> to mean that the computation Halts((u32)H_Hat, (u32)H_Hat);
> would return a value indicating whether or not its input is
> a halting computation.
>
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>
> The same can be said for this computation Ĥ.qx(<Ĥ>,<Ĥ>) because it is
> essentially equivalent to Halts((u32)H_Hat, (u32)H_Hat);
>
> Both Halts((u32)H_Hat, (u32)H_Hat); and Ĥ.qx(<Ĥ>,<Ĥ>)
> specify infinitely nested simulation that must be aborted.
>

--
Copyright 2021 Pete Olcott

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

On Thursday, 27 May 2021 at 14:50:16 UTC+1, olcott wrote:
> On 5/27/2021 8:40 AM, Malcolm McLean wrote:
> > On Thursday, 27 May 2021 at 14:04:32 UTC+1, olcott wrote:
> >> On 5/27/2021 3:38 AM, Malcolm McLean wrote:
> >>> On Thursday, 27 May 2021 at 07:43:08 UTC+1, olcott wrote:
> >>>> On 5/26/2021 1:17 PM, Malcolm McLean wrote:
> >>>>> On Wednesday, 26 May 2021 at 16:31:10 UTC+1, Ben Bacarisse wrote:
> >>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>> Yes. With the interminable H_Hat(H_Hat) example, if the offered H is
> >>>>> reasonably simple, it's easy to build a decider which is more than a
> >>>>> simple stub, and gives the correct answer for H_Hat(H_Hat). So it's
> >>>>> easy to see that H_Hat(H_Hat) is "decidable".
> >>>>
> >>>> You are agreeing that H_Hat(H_Hat) is decidable,
> >>>>
> >>>> I am taking this to mean that H_Hat(H_Hat) can be correctly determined
> >>>> to be a member of the set of non halting computations.
> >>>>
> >>> It's in scare quotes because apparently "decidable" is not the correct terminology.
> >>> As far as I am aware (others may correct me here) "decidable" refers to sets.
> >>> So a set is "decidable" if there is some Turing machine which separates all
> >>> members into two sub-sets. It follows that all finite sets are "decidable" by the
> >>> brute force algorithm.
> >>>
> >>> When we are talking about a single computation, and whether or not we know
> >>> that it halts, we shouldn't use the term "decidable".
> >>>
> >> I think that part of the problem may be that there are things that need
> >> to be said that have no correct way to say them.
> >>
> >> When you say that H_Hat(H_Hat) is decidable, that would seem to mean
> >> that the computation Halts((u32)H_Hat, (u32)H_Hat); would return a value
> >> indicating whether or not its input is a halting computation.
> >>
> > "Decidable", in in context of computer science, is a property of a set. It doesn't
> > make much sense to apply it to a singleton set, or to a computation.
> >
> > We can say that H_Hat(H_Hat) is "known to halt", or "known not to halt" and we
> > can say that Halts() reports this correctly or incorrectly. But it's best to avoid
> > the term "decides".
> >
> As I did in the rest of of my reply that you trimmed:
>
> When you refer to a decidable input I refer to the determination that an
> input is included or excluded from membership on the set of halting
> computations.
> On 5/27/2021 8:04 AM, olcott wrote:
> > When you say that H_Hat(H_Hat) is decidable, that would seem
> > to mean that the computation Halts((u32)H_Hat, (u32)H_Hat);
> > would return a value indicating whether or not its input is
> > a halting computation.
> >
> > Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
> > Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
> >
> > The same can be said for this computation Ĥ.qx(<Ĥ>,<Ĥ>) because it is
> > essentially equivalent to Halts((u32)H_Hat, (u32)H_Hat);
> >
> > Both Halts((u32)H_Hat, (u32)H_Hat); and Ĥ.qx(<Ĥ>,<Ĥ>)
> > specify infinitely nested simulation that must be aborted.
> >
>
Apparently I was wrong to refer to "decidable input". "Decidable" is a technical
term which is a property of a set (e.g prime numbers). You don't use it of a
single member of the set you are trying to decide.

On 5/27/2021 9:17 AM, Malcolm McLean wrote:
> On Thursday, 27 May 2021 at 14:50:16 UTC+1, olcott wrote:
>> On 5/27/2021 8:40 AM, Malcolm McLean wrote:
>>> On Thursday, 27 May 2021 at 14:04:32 UTC+1, olcott wrote:
>>>> On 5/27/2021 3:38 AM, Malcolm McLean wrote:
>>>>> On Thursday, 27 May 2021 at 07:43:08 UTC+1, olcott wrote:
>>>>>> On 5/26/2021 1:17 PM, Malcolm McLean wrote:
>>>>>>> On Wednesday, 26 May 2021 at 16:31:10 UTC+1, Ben Bacarisse wrote:
>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>> Yes. With the interminable H_Hat(H_Hat) example, if the offered H is
>>>>>>> reasonably simple, it's easy to build a decider which is more than a
>>>>>>> simple stub, and gives the correct answer for H_Hat(H_Hat). So it's
>>>>>>> easy to see that H_Hat(H_Hat) is "decidable".
>>>>>>
>>>>>> You are agreeing that H_Hat(H_Hat) is decidable,
>>>>>>
>>>>>> I am taking this to mean that H_Hat(H_Hat) can be correctly determined
>>>>>> to be a member of the set of non halting computations.
>>>>>>
>>>>> It's in scare quotes because apparently "decidable" is not the correct terminology.
>>>>> As far as I am aware (others may correct me here) "decidable" refers to sets.
>>>>> So a set is "decidable" if there is some Turing machine which separates all
>>>>> members into two sub-sets. It follows that all finite sets are "decidable" by the
>>>>> brute force algorithm.
>>>>>
>>>>> When we are talking about a single computation, and whether or not we know
>>>>> that it halts, we shouldn't use the term "decidable".
>>>>>
>>>> I think that part of the problem may be that there are things that need
>>>> to be said that have no correct way to say them.
>>>>
>>>> When you say that H_Hat(H_Hat) is decidable, that would seem to mean
>>>> that the computation Halts((u32)H_Hat, (u32)H_Hat); would return a value
>>>> indicating whether or not its input is a halting computation.
>>>>
>>> "Decidable", in in context of computer science, is a property of a set. It doesn't
>>> make much sense to apply it to a singleton set, or to a computation.
>>>
>>> We can say that H_Hat(H_Hat) is "known to halt", or "known not to halt" and we
>>> can say that Halts() reports this correctly or incorrectly. But it's best to avoid
>>> the term "decides".
>>>
>> As I did in the rest of of my reply that you trimmed:
>>
>> When you refer to a decidable input I refer to the determination that an
>> input is included or excluded from membership on the set of halting
>> computations.
>> On 5/27/2021 8:04 AM, olcott wrote:
>>> When you say that H_Hat(H_Hat) is decidable, that would seem
>>> to mean that the computation Halts((u32)H_Hat, (u32)H_Hat);
>>> would return a value indicating whether or not its input is
>>> a halting computation.
>>>
>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>>>
>>> The same can be said for this computation Ĥ.qx(<Ĥ>,<Ĥ>) because it is
>>> essentially equivalent to Halts((u32)H_Hat, (u32)H_Hat);
>>>
>>> Both Halts((u32)H_Hat, (u32)H_Hat); and Ĥ.qx(<Ĥ>,<Ĥ>)
>>> specify infinitely nested simulation that must be aborted.
>>>
>>
> Apparently I was wrong to refer to "decidable input". "Decidable" is a technical
> term which is a property of a set (e.g prime numbers). You don't use it of a
> single member of the set you are trying to decide.
>

Yes, but that is a triviality. The key thing is that
Halts((u32)H_Hat, (u32)H_Hat); does get the correct answer.

Another key point that you seemed to have missed is that if
Halts((u32)H_Hat, (u32)H_Hat); gets the correct answer
then Ĥ.qx(<Ĥ>,<Ĥ>) also gets the correct answer.

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:

> On 5/26/2021 7:00 PM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> On 5/25/2021 8:58 PM, Ben Bacarisse wrote:
>>>> olcott <NoOne@NoWhere.com> writes:
>>>>
>>>>> My halt decider correctly decides halting on inputs with pathological
>>>>> self-reference on the basis of proxy input that has the pathological
>>>>> self-reference removed.
>>>>
>>>> No. Your decider is factually wrong about the halting of at least one
>>>> case. You accept the facts that
>>>>
>>>> (a) Halts(H_Hat, H_Hat) is false, and
>>>> (b) H_Hat(H_Hat) is a finite (AKA halting) computation.
>>>
>>> It turns out that (b) is a finite computation
>>
>> Yes, everyone knows this. That's why Halts is not a halt decider.
>>
>>> in the exactly same way that an infinite loop that has been aborted is
>>> a finite computation. I explain this much better now.
>>
>> We don't need a better explanation of why Halts is not a halting
>> decider. You need to give the problem that Halts /is/ deciding a proper
>> name. It is not the halting problem.
>>
>>>> What you deny is that a halt decider is a TM that answers yes/true/1 for
>>>> all inputs representing halting computations and no/false/0
>>>> otherwise.
>>
>> Another opportunity for you to accept this basic fact about the problem
>> you claim to be talking about goes un-taken.
>>
>>>> I was going to say that the honest response at this point would be for
>>>> you to rename the property you claim to be deciding, but I read on and
>>>> it seems you might not even know what the halting problem even is.
>>>>
>>>>> On 5/24/2021 6:37 PM, Ben Bacarisse wrote:
>>>>
>>>>>> Every instance of the halting problem is decidable, (but you don't know
>>>>>> what decidable means,
>>>>>
>>>>> Decidable means that a membership algorithm exists.
>>>>
>>>> That sounds like rote learning to me. Can you use this definition to
>>>> make my remark sufficiently exact that's it is obviously true?
>>>
>>> Your most recent post did teach me that I had been saying some things
>>> somewhat incorrectly.
>>>
>>> void H_Hat(u32 P)
>>> {
>>> u32 Input_Halts = Halts(P, P);
>>> if (Input_Halts)
>>> HERE: goto HERE;
>>> }
>>>
>>> The pathological self-reference error arises in the halting theorem
>>> from the fact that both return values: {0, 1} from Halts() to H_Hat()
>>> are incorrect when H_Hat() is invoked with its own machine address as
>>> input.
>>
>> Why do you say that both 0 and 1 are incorrect?
>
> I am stopping at you first big mistake indicting that you are not
> bothering to hardly pay any attention at all.

Great. So my statements above that you are not talking about the
halting problem is not a big mistake. Or were you not paying attention?

And when I stated that you deny the basics facts about the halting
problem, that too was not a big mistake. Or were you not paying
attention then either?

> Even though H_Hat(H_Hat) either halts or fails to halt neither true
> nor false are return values that Halts() can possibly correctly return
> to H_Hat() in the computation Halts((u32)H_Hat, (u32)H_Hat);

I explained why this is either incorrect reasoning or bad use or terms.
And I answered your question assuming both interpretations. I can't
make you pay attention to these problems. They remain quoted below if
you want to address them.

Also below is the really big question that you are avoiding. No doubt
that is why you've pulled out the "I'll stop at the first thing I can
legitimately object to" stunt. That big question is that you don't know
what the instances of the halting problem are!

>> This is real code is it
>> not? There really is (you tell us) a function Halts. It's a partial
>> halt decider of your own design. You get to say what the correct answer
>> is and, presumably, your code gives what you consider to be the correct
>> answer. If you were not being so secretive, you'd publish Halts and we
>> could all see what you consider to be the correct answer for every
>> input.
>>
>>> If as you say all inputs halt or fail to halt then what is the proper
>>> technical name for cases like the above case?
>>
>> If you are not talking about your actual code, and really meant to ask
>> the hypothetical question "imagine that Halts is a perfect halt decider,
>> what is the technical term for the call H_Hat(H_Hat)?" then the answer
>> is "a contradiction" or maybe more correctly "an example that leads to a
>> contradiction".
>>
>>>>> What I don't know is what an instance of the halting problem is.
>>
>>>>> It would seem to me that an instance of a decision problem would be a
>>>>> Question/Input pair where the input is a specific finite string.
>>>>
>>>> So you've spent the last fifteen years talking about the halting problem
>>>> without knowing what the problem instances are? No wonder you have
>>>> spouted so much nonsense. And when I've told you (as I have on many
>>>> occasions) the halting problem is, did you not understand me? If not,
>>>> why didn't you ask for clarification?
>>>>
>>>> Would you like to know what the instances of the halting problem are?
>>>
>>> In computability theory and computational complexity theory, a
>>> decision problem is a problem that can be posed as a yes–no question
>>> of the input values. https://en.wikipedia.org/wiki/Decision_problem
>>>
>>> If we assume that a decision problem instance is a specific
>>> Question/Input pair and the input is a specific finite string
>>>
>>> Then a halting problem instance would be does this Turing machine
>>> Description P halt on its finite string I input?
>>
>> No. Would you like to know what the instances of the halting problem
>> are? Just say no if you prefer to carry on pontificating in ignorance of
>> the topic.
>>
>> You should write [P] for the encoding (description) of machine P and
>> <x,y> for the encoding of the pair of strings x and y. P(I) is then a
>> computation that either halts or fails to halt (I prefer "is finite or
>> not") and <[P],I> is the string representing that computation.
>>
>> Can you use that notation to say what the instances of the halting
>> problem are, and which instances should be accepted and which rejected?
>>

--
Ben.

On 5/27/2021 10:20 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 5/26/2021 7:00 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 5/25/2021 8:58 PM, Ben Bacarisse wrote:
>>>>> olcott <NoOne@NoWhere.com> writes:
>>>>>
>>>>>> My halt decider correctly decides halting on inputs with pathological
>>>>>> self-reference on the basis of proxy input that has the pathological
>>>>>> self-reference removed.
>>>>>
>>>>> No. Your decider is factually wrong about the halting of at least one
>>>>> case. You accept the facts that
>>>>>
>>>>> (a) Halts(H_Hat, H_Hat) is false, and
>>>>> (b) H_Hat(H_Hat) is a finite (AKA halting) computation.
>>>>
>>>> It turns out that (b) is a finite computation
>>>
>>> Yes, everyone knows this. That's why Halts is not a halt decider.
>>>
>>>> in the exactly same way that an infinite loop that has been aborted is
>>>> a finite computation. I explain this much better now.
>>>
>>> We don't need a better explanation of why Halts is not a halting
>>> decider. You need to give the problem that Halts /is/ deciding a proper
>>> name. It is not the halting problem.
>>>
>>>>> What you deny is that a halt decider is a TM that answers yes/true/1 for
>>>>> all inputs representing halting computations and no/false/0
>>>>> otherwise.
>>>
>>> Another opportunity for you to accept this basic fact about the problem
>>> you claim to be talking about goes un-taken.
>>>
>>>>> I was going to say that the honest response at this point would be for
>>>>> you to rename the property you claim to be deciding, but I read on and
>>>>> it seems you might not even know what the halting problem even is.
>>>>>
>>>>>> On 5/24/2021 6:37 PM, Ben Bacarisse wrote:
>>>>>
>>>>>>> Every instance of the halting problem is decidable, (but you don't know
>>>>>>> what decidable means,
>>>>>>
>>>>>> Decidable means that a membership algorithm exists.
>>>>>
>>>>> That sounds like rote learning to me. Can you use this definition to
>>>>> make my remark sufficiently exact that's it is obviously true?
>>>>
>>>> Your most recent post did teach me that I had been saying some things
>>>> somewhat incorrectly.
>>>>
>>>> void H_Hat(u32 P)
>>>> {
>>>> u32 Input_Halts = Halts(P, P);
>>>> if (Input_Halts)
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> The pathological self-reference error arises in the halting theorem
>>>> from the fact that both return values: {0, 1} from Halts() to H_Hat()
>>>> are incorrect when H_Hat() is invoked with its own machine address as
>>>> input.
>>>
>>> Why do you say that both 0 and 1 are incorrect?
>>
>> I am stopping at you first big mistake indicting that you are not
>> bothering to hardly pay any attention at all.
>
> Great. So my statements above that you are not talking about the
> halting problem is not a big mistake. Or were you not paying attention?
>

People in the dialogue seem to have a very short attention span so I
only focus on one point at a time. When I do this they quickly spout off
some unsupported dogmatic assertion or change the subject or both.

> And when I stated that you deny the basics facts about the halting
> problem, that too was not a big mistake. Or were you not paying
> attention then either?
>

You made too many mistakes to respond to. If we don't stay laser
focusing on a single mistake until it is resolved it never ever gets
resolved. It took you 4.5 years to finally acknowledge the infinitely
nested simulation of:

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn

>> Even though H_Hat(H_Hat) either halts or fails to halt neither true
>> nor false are return values that Halts() can possibly correctly return
>> to H_Hat() in the computation Halts((u32)H_Hat, (u32)H_Hat);
>
> I explained why this is either incorrect reasoning or bad use or terms.

The problem for you is that it is an accurate use of terms and it lets
the hot air out of your attempt at rebuttal.

> And I answered your question assuming both interpretations. I can't
> make you pay attention to these problems. They remain quoted below if
> you want to address them.
>
> Also below is the really big question that you are avoiding. No doubt
> that is why you've pulled out the "I'll stop at the first thing I can
> legitimately object to" stunt. That big question is that you don't know
> what the instances of the halting problem are!
>

Yes you always focus on these tedious little things utterly ignoring
that the gist of what I said does correctly refute the halting theorem.

So I find an alternative correct way to say the things that I need to say.

For some simulating halt deciders H and some (Turing machine description
P / finite string I) pairs there is no Boolean value that H can return
to P that corresponds to the actual halting behavior of P(I) in the
computation H(P,I).

If anyone says is less precisely than this it is an intentionally
disingenuous misrepresentation.

>>> This is real code is it
>>> not? There really is (you tell us) a function Halts. It's a partial
>>> halt decider of your own design. You get to say what the correct answer
>>> is and, presumably, your code gives what you consider to be the correct
>>> answer. If you were not being so secretive, you'd publish Halts and we
>>> could all see what you consider to be the correct answer for every
>>> input.
>>>
>>>> If as you say all inputs halt or fail to halt then what is the proper
>>>> technical name for cases like the above case?
>>>
>>> If you are not talking about your actual code, and really meant to ask
>>> the hypothetical question "imagine that Halts is a perfect halt decider,
>>> what is the technical term for the call H_Hat(H_Hat)?" then the answer
>>> is "a contradiction" or maybe more correctly "an example that leads to a
>>> contradiction".
>>>
>>>>>> What I don't know is what an instance of the halting problem is.
>>>
>>>>>> It would seem to me that an instance of a decision problem would be a
>>>>>> Question/Input pair where the input is a specific finite string.
>>>>>
>>>>> So you've spent the last fifteen years talking about the halting problem
>>>>> without knowing what the problem instances are? No wonder you have
>>>>> spouted so much nonsense. And when I've told you (as I have on many
>>>>> occasions) the halting problem is, did you not understand me? If not,
>>>>> why didn't you ask for clarification?
>>>>>
>>>>> Would you like to know what the instances of the halting problem are?
>>>>
>>>> In computability theory and computational complexity theory, a
>>>> decision problem is a problem that can be posed as a yes–no question
>>>> of the input values. https://en.wikipedia.org/wiki/Decision_problem
>>>>
>>>> If we assume that a decision problem instance is a specific
>>>> Question/Input pair and the input is a specific finite string
>>>>
>>>> Then a halting problem instance would be does this Turing machine
>>>> Description P halt on its finite string I input?
>>>
>>> No. Would you like to know what the instances of the halting problem
>>> are? Just say no if you prefer to carry on pontificating in ignorance of
>>> the topic.
>>>
>>> You should write [P] for the encoding (description) of machine P and
>>> <x,y> for the encoding of the pair of strings x and y. P(I) is then a
>>> computation that either halts or fails to halt (I prefer "is finite or
>>> not") and <[P],I> is the string representing that computation.
>>>
>>> Can you use that notation to say what the instances of the halting
>>> problem are, and which instances should be accepted and which rejected?
>>>
>

You did not say what post you'd like me to reply to so I've picked this
one as the easiest. (I'm limiting the time I spend on this.)

olcott <NoOne@NoWhere.com> writes:

> You made too many mistakes to respond to. If we don't stay laser
> focusing on a single mistake until it is resolved it never ever gets
> resolved. It took you 4.5 years to finally acknowledge the infinitely
> nested simulation of:

You are a despicable liar.

> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn

Nothing in these lines implies any simulation whatsoever.

I've posted a correct statement of what you are trying to say a few
times. If you ask nicely, I'll post it again.

>> Also below is the really big question that you are avoiding. No
>> doubt that is why you've pulled out the "I'll stop at the first thing
>> I can legitimately object to" stunt. That big question is that you
>> don't know what the instances of the halting problem are!
>
> Yes you always focus on these tedious little things utterly ignoring
> that the gist of what I said does correctly refute the halting
> theorem.

You consider it a tedious little thing that you don't know what the
instances of the halting problem are? And what of your refusal to
accept the most basic fact about the problem itself:

A halt decider is a TM that answers yes/true/1 for all instances
representing halting computations and no/false/0 otherwise.

Of course, you'd have to know the tedious little matter of what the
instances are so I suppose you must ignore this point again and again.

> For some simulating halt deciders H and some (Turing machine
> description P / finite string I) pairs there is no Boolean value that
> H can return to P that corresponds to the actual halting behavior of
> P(I) in the computation H(P,I).

Good luck trying to get this sort of garage into a journal! The irony
is that I know exactly what you are trying to say (and it's correct!)
but what you actually say is just preposterous. I've offered to help,
you but I'm pretty sure you don't want to be clear.

--
Ben.

On 5/27/2021 7:45 PM, Ben Bacarisse wrote:
> You did not say what post you'd like me to reply to so I've picked this
> one as the easiest. (I'm limiting the time I spend on this.)
>
> olcott <NoOne@NoWhere.com> writes:
>
>> You made too many mistakes to respond to. If we don't stay laser
>> focusing on a single mistake until it is resolved it never ever gets
>> resolved. It took you 4.5 years to finally acknowledge the infinitely
>> nested simulation of:
>
> You are a despicable liar.
>
>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
>> Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn
>
> Nothing in these lines implies any simulation whatsoever.
>
> I've posted a correct statement of what you are trying to say a few
> times. If you ask nicely, I'll post it again.
>
>>> Also below is the really big question that you are avoiding. No
>>> doubt that is why you've pulled out the "I'll stop at the first thing
>>> I can legitimately object to" stunt. That big question is that you
>>> don't know what the instances of the halting problem are!
>>
>> Yes you always focus on these tedious little things utterly ignoring
>> that the gist of what I said does correctly refute the halting
>> theorem.
>
> You consider it a tedious little thing that you don't know what the
> instances of the halting problem are?

That I do not know what those terms-of-the-art refer to is a tedious
detail that I could utterly ignore until now. I create my own private
language so that I can communicate the inter-relationships of the key
ideas to myself. It was far too much of a risk to box myself into
conventional notions until now.

> And what of your refusal to
> accept the most basic fact about the problem itself:
>
> A halt decider is a TM that answers yes/true/1 for all instances
> representing halting computations and no/false/0 otherwise.
>

That definition is perfectly acceptable depending on how the term
[halting computation] is defined.

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn

Ĥ(<Ĥ>) is decided to not be a halting computation on the basis that the
embedded halt decider at state Ĥ.qx(<Ĥ>,<Ĥ>) aborts the simulation of
its input, which is an aspect of the Ĥ(<Ĥ>) computation.

> Of course, you'd have to know the tedious little matter of what the
> instances are so I suppose you must ignore this point again and again.
>

Corresponding halt decider / input pairs such that the input is defined
to the the opposite of whatever the halt decider decides is a perfectly
clear and correct way to define the instances that I need to refer to
within the context of Siper.

http://www.liarparadox.org/sipser_165.pdf

>> For some simulating halt deciders H and some (Turing machine
>> description P / finite string I) pairs there is no Boolean value that
>> H can return to P that corresponds to the actual halting behavior of
>> P(I) in the computation H(P,I).
>
> Good luck trying to get this sort of garage into a journal! The irony
> is that I know exactly what you are trying to say (and it's correct!)
> but what you actually say is just preposterous. I've offered to help,
> you but I'm pretty sure you don't want to be clear.
>

I would be very happy to give reviewer credit to anyone wishing to help
me translate my words into the conventional way of saying them.

I can't afford to give second author credit to anyone, it would be far
too easy to steal my work.

I am almost totally done grokking the diagonalization used on the
halting problem. It turns out that Sipser and this guy apparently
explaining Siper makes it quite simple.

https://www.youtube.com/watch?v=jM6osxSX9GA

The reason that I never bothered to look at it before is that I thought
is was another example of the Diagonal Lemma.

https://en.wikipedia.org/wiki/Diagonal_lemma

--
Copyright 2021 Pete Olcott

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

On 5/23/2021 9:59 AM, Kaz Kylheku wrote:
> On 2021-05-22, olcott <NoOne@NoWhere.com> wrote:
>> On 5/22/2021 9:56 AM, Kaz Kylheku wrote:

>> Because we know that the only difference in the behavior of a simulating
>> halt decider and a simulator is that the simulating halt decider stops
>> simulating some of its inputs we can examine the behavior of these
>> inputs in a simulator to determine whether or not a simulating halt
>> decider would stop simulating these inputs.
>
> Sure, but the difference in behavior means we are jumping to a different
> column of the input-decider matrix and are no longer on the diagonal.
> To return to the diagonal while staying in the same column, we must
> switch to a different row: the row for the test case which is based on
> that column's decider. Where row and column match, we have an incorrect
> or nonterminating halting decision, according to this conventional analysis.
>
> Any reasoning that leads you, through substitutions, to discovering a
> good halting decision, but which is off the diagonal trace, has led you
> to an irrelevant configuration.

The substitutions are not actually made they are a teaching tool.

> The proof says only that the
> configurations on the diagonal are incorrect or non-halting. The
> proof does not make any assertions about non-diagonal configuations,
> therefore those configurations are not counterexamples to the proof's
> claims.

Now that I actually studied the very simple Sipser diagonalization proof
https://www.youtube.com/watch?v=jM6osxSX9GA

I can address this objection on the basis of adapting my H_Hat to become
a little closer to the Sipser D:

bool D(u32 P)
{ if ( H(P, P) )
HERE: goto HERE;
return false;
}

D correctly decides not halting on itself when H is based on simulating
its input.

On 5/27/2021 7:45 PM, Ben Bacarisse wrote:
> A halt decider is a TM that answers yes/true/1 for all instances
> representing halting computations and no/false/0 otherwise.

D(<D>) is decided to be a non-halting computation on the basis that an
aspect of this computation was aborted.

Its embedded halt decider H(<D>,<D>) aborts the simulation of its input,
which is an aspect of the complete D(<D>) computation.

> The undecidability of halting is precisely the claim that the entire
> diagonal consists of incorrect answers or non-halting. Since for every
> decider there is a diagonal entry, every decider is associated with a
> test case it does not handle.
>
> If every decider has at least one test case it does not handle, then
> there does not exist a universal (= handles all cases) decider:
> there is no algorithm that decides all cases of halting.
>

--
Copyright 2021 Pete Olcott

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

On 5/22/2021 9:56 AM, Kaz Kylheku wrote:
> On 2021-05-22, olcott <NoOne@NoWhere.com> wrote:
>> void H_Hat(u32 P)
>> {
>> u32 Input_Halts = Halts(P, P);
>> if (Input_Halts)
>> HERE: goto HERE;
>> }
>>
>> Halts decides the above case by using the behavior of the above code
>> when a simulator is substituted for the simulating halt decider to
>> correctly answer this question:
>
> For the thousandth time, "substitute" means to produce an entirely
> new S_Hat function /similar/ to the above H_Hat which calls Simulate
> instead of Halts.
>
> // S_Hat is to Simulate what H_Hat is to Halts
>
> void S_Hat(u32 P)
> {
> u32 Input_Halts = Simulate(P, P);
> if (Input_Halts)
> HERE: goto HERE;
> }
>
> That creates a new test case which shows that the following decision is
> wrong or non-halting:
>
> Simulate(S_Hat, S_Hat)
>
> just like this is wrong or non-halting:
>
> Halts(H_Hat, H_Hat)
>
>> This question <is> correctly answered by the proxy: Would the input P to
>> a simulator S halt?
>
> You must stick to the diagonal of the test case / decider combination
> matrix.
>
> Halts(S_Hat, S_Hat); // correct, but off the diagonal
>
> The halting proof is a form of diagonal argument. It says that the
> diagonal entries all fail to decide.
>
> Cases F H G <---- deecciders
>
> F^ [ F(^F,^F) ] G(^F, ^F) H(^F, ^F)
> G^ F(^G,^G) [ G(^G, ^G) ] H(^G, ^G)
> H^ F(^H,^H) G(^H, ^H) [ H(^H, ^H) ]
>
> Only the diagonal [ ] entriess are relevant. When you substitute
> a decider in the test case, to obtain another test case, you
> move vertically through the table, which takes you off the diagonal.
>
> When you replacee the decider being applied to the test case,
> you move horizontally; again off the diagonal.
>
> To stick to the diagonal, you must make both substitutions
> in parallel. E.g. when yu change from the H^ case which "attacks" the H
> decider to the G^ test case which attacks the G decider,
> it is that attacked G decider which cannot decide that case.
> You must go from H(^H, ^H) to G(^G, ^G).
>
> Until you thoroughly internalize the above, you do not
> have a grasp on halting.

I was very surprised and pleased how easy this was.

Refutation of Halting Problem Diagonalization Argument
DOI: 10.13140/RG.2.2.34446.28483

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

--
Copyright 2021 Pete Olcott

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

On 5/28/2021 7:59 PM, olcott wrote:
> I was very surprised and pleased how easy this was.
>
> Refutation of Halting Problem Diagonalization Argument
> DOI: 10.13140/RG.2.2.34446.28483
>
> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument
Congratulations! I noticed a caveat "Preprints and early-stage research
may not have been peer reviewed yet." Does this apply to you? I hope you
do well in the next stages of the pub process. Have you thought of
sending a draft to Underwood Dudley for citation from his new book on
"internet" trisectors. I think it might rate a chapter, maybe more. Be
sure you include pointers to your threads in the relevant newsgroups.
--
Jeff Barnett

olcott <NoOne@NoWhere.com> writes:

> On 5/27/2021 7:45 PM, Ben Bacarisse wrote:

>>>> Also below is the really big question that you are avoiding. No
>>>> doubt that is why you've pulled out the "I'll stop at the first thing
>>>> I can legitimately object to" stunt. That big question is that you
>>>> don't know what the instances of the halting problem are!
>>>
>>> Yes you always focus on these tedious little things utterly ignoring
>>> that the gist of what I said does correctly refute the halting
>>> theorem.
>>
>> You consider it a tedious little thing that you don't know what the
>> instances of the halting problem are?
>
> That I do not know what those terms-of-the-art refer to is a tedious
> detail that I could utterly ignore until now.

Tedious details. Tedious posts. I'll let you get on get on with it for
now.

--
Ben.

On 5/29/2021 5:24 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 5/27/2021 7:45 PM, Ben Bacarisse wrote:
>
>>>>> Also below is the really big question that you are avoiding. No
>>>>> doubt that is why you've pulled out the "I'll stop at the first thing
>>>>> I can legitimately object to" stunt. That big question is that you
>>>>> don't know what the instances of the halting problem are!
>>>>
>>>> Yes you always focus on these tedious little things utterly ignoring
>>>> that the gist of what I said does correctly refute the halting
>>>> theorem.
>>>
>>> You consider it a tedious little thing that you don't know what the
>>> instances of the halting problem are?
>>
>> That I do not know what those terms-of-the-art refer to is a tedious
>> detail that I could utterly ignore until now.
>
> Tedious details. Tedious posts. I'll let you get on get on with it for
> now.
>

You have always been a style over substance kind of guy.

--
Copyright 2021 Pete Olcott

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

On 5/23/2021 9:59 AM, Kaz Kylheku wrote:
> On 2021-05-22, olcott <NoOne@NoWhere.com> wrote:
>> On 5/22/2021 9:56 AM, Kaz Kylheku wrote:
>>> The halting proof is a form of diagonal argument. It says that the
>>> diagonal entries all fail to decide.
>>>
>>> Cases F H G <---- deecciders
>>>
>>> F^ [ F(^F,^F) ] G(^F, ^F) H(^F, ^F)
>>> G^ F(^G,^G) [ G(^G, ^G) ] H(^G, ^G)
>>> H^ F(^H,^H) G(^H, ^H) [ H(^H, ^H) ]
>>>
>>> Only the diagonal [ ] entriess are relevant. When you substitute
>>> a decider in the test case, to obtain another test case, you
>>> move vertically through the table, which takes you off the diagonal.
>>>
>>> When you replacee the decider being applied to the test case,
>>> you move horizontally; again off the diagonal.
>>>
>>> To stick to the diagonal, you must make both substitutions
>>> in parallel. E.g. when yu change from the H^ case which "attacks" the H
>>> decider to the G^ test case which attacks the G decider,
>>> it is that attacked G decider which cannot decide that case.
>>> You must go from H(^H, ^H) to G(^G, ^G).
>>>
>>> Until you thoroughly internalize the above, you do not
>>> have a grasp on halting.
>>>
>>
>> I understand where you are coming from. I am coming from somewhere else.
>> If you analyze what I am saying using conventional analysis then what I
>> am saying is incorrect.
>>
>> To see that what I am saying <is> correct you must switch to
>> unconventional analysis.
>
> The Turing model of computation, and the halting question and its
> proofs are entirely contained within "conventional analysis".
>
> You're using the language of conventional analysis to refer to
> its concepts and constructs, and to dispute its results.
>
> If you want to use "unconventional analysis", you must rigorously pin
> down what that is, before you even approach the halting problem,
> and present that framework upfront.
>
> Within that framework, you must construct that framework's own model of
> computation. Then pursue that framework's version of the halting
> problem within that framework, and not make any claims with regard to
> conventional Turing halting (which will automatically make you look
> wrong).
>
> You can use similar language like "machine", "halts", and so on, if you
> make it clear up front that these words are in your own framework and do
> not have their conventional meaning.
>
> You also face this problem: what good is your alternative analysis?
> Conventional analysis is reliable and powerful. Can we apply your
> alternative analysis to a broad area of problems and get good results?
>
>> Because we know that the only difference in the behavior of a simulating
>> halt decider and a simulator is that the simulating halt decider stops
>> simulating some of its inputs we can examine the behavior of these
>> inputs in a simulator to determine whether or not a simulating halt
>> decider would stop simulating these inputs.
>
> Sure, but the difference in behavior means we are jumping to a different
> column of the input-decider matrix and are no longer on the diagonal.
> To return to the diagonal while staying in the same column, we must
> switch to a different row: the row for the test case which is based on
> that column's decider. Where row and column match, we have an incorrect
> or nonterminating halting decision, according to this conventional analysis.
>
> Any reasoning that leads you, through substitutions, to discovering a
> good halting decision, but which is off the diagonal trace, has led you
> to an irrelevant configuration. The proof says only that the
> configurations on the diagonal are incorrect or non-halting. The
> proof does not make any assertions about non-diagonal configuations,
> therefore those configurations are not counterexamples to the proof's
> claims.
>
> The undecidability of halting is precisely the claim that the entire
> diagonal consists of incorrect answers or non-halting. Since for every
> decider there is a diagonal entry, every decider is associated with a
> test case it does not handle.

void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{ H((u32)P, (u32)P);
}

https://en.wikipedia.org/wiki/Halting_problem#Sketch_of_proof

Now that I have studied the diagonalization method much more thoroughly
I can say that its error is that is assuming that H must return a value
to P.

It fails to consider this possibility:

(1) The simulating halt decider H aborts the simulation of its input P
before ever returning any value to P.

(2) It does this on the the basis that P is calling H in infinite
recursion.

>
> If every decider has at least one test case it does not handle, then
> there does not exist a universal (= handles all cases) decider:
> there is no algorithm that decides all cases of halting.
>

--
Copyright 2021 Pete Olcott

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

On 6/12/21 5:30 PM, olcott wrote:
> On 5/23/2021 9:59 AM, Kaz Kylheku wrote:
>> On 2021-05-22, olcott <NoOne@NoWhere.com> wrote:
>>> On 5/22/2021 9:56 AM, Kaz Kylheku wrote:
>>>> The halting proof is a form of diagonal argument. It says that the
>>>> diagonal entries all fail to decide.
>>>>
>>>> Cases       F           H            G   <---- deecciders
>>>>
>>>> F^    [ F(^F,^F) ]  G(^F, ^F)    H(^F, ^F)
>>>> G^      F(^G,^G)  [ G(^G, ^G) ]  H(^G, ^G)
>>>> H^      F(^H,^H)    G(^H, ^H)  [ H(^H, ^H) ]
>>>>
>>>> Only the diagonal [ ] entriess are relevant.  When you substitute
>>>> a decider in the test case, to obtain another test case, you
>>>> move vertically through the table, which takes you off the diagonal.
>>>>
>>>> When you replacee the decider being applied to the test case,
>>>> you move horizontally; again off the diagonal.
>>>>
>>>> To stick to the diagonal, you must make both substitutions
>>>> in parallel. E.g. when yu change from the H^ case which "attacks" the H
>>>> decider to the G^ test case which attacks the G decider,
>>>> it is that attacked G decider which cannot decide that case.
>>>> You must go from H(^H, ^H) to G(^G, ^G).
>>>>
>>>> Until you thoroughly internalize the above, you do not
>>>> have a grasp on halting.
>>>>
>>>
>>> I understand where you are coming from. I am coming from somewhere else.
>>> If you analyze what I am saying using conventional analysis then what I
>>> am saying is incorrect.
>>>
>>> To see that what I am saying <is> correct you must switch to
>>> unconventional analysis.
>>
>> The Turing model of computation, and the halting question and its
>> proofs are entirely contained within "conventional analysis".
>>
>> You're using the language of conventional analysis to refer to
>> its concepts and constructs, and to dispute its results.
>>
>> If you want to use "unconventional analysis", you must rigorously pin
>> down what that is, before you even approach the halting problem,
>> and present that framework upfront.
>>
>> Within that framework, you must construct that framework's own model of
>> computation.  Then pursue that framework's version of the halting
>> problem within that framework, and not make any claims with regard to
>> conventional Turing halting (which will automatically make you look
>> wrong).
>>
>> You can use similar language like "machine", "halts", and so on, if you
>> make it clear up front that these words are in your own framework and do
>> not have their conventional meaning.
>>
>> You also face this problem: what good is your alternative analysis?
>> Conventional analysis is reliable and powerful. Can we apply your
>> alternative analysis to a broad area of problems and get good results?
>>
>>> Because we know that the only difference in the behavior of a simulating
>>> halt decider and a simulator is that the simulating halt decider stops
>>> simulating some of its inputs we can examine the behavior of these
>>> inputs in a simulator to determine whether or not a simulating halt
>>> decider would stop simulating these inputs.
>>
>> Sure, but the difference in behavior means we are jumping to a different
>> column of the input-decider matrix and are no longer on the diagonal.
>> To return to the diagonal while staying in the same column, we must
>> switch to a different row: the row for the test case which is based on
>> that column's decider.  Where row and column match, we have an incorrect
>> or nonterminating halting decision, according to this conventional
>> analysis.
>>
>> Any reasoning that leads you, through substitutions, to discovering a
>> good halting decision, but which is off the diagonal trace, has led you
>> to an irrelevant configuration. The proof says only that the
>> configurations on the diagonal are incorrect or non-halting. The
>> proof does not make any assertions about non-diagonal configuations,
>> therefore those configurations are not counterexamples to the proof's
>> claims.
>>
>> The undecidability of halting is precisely the claim that the entire
>> diagonal consists of incorrect answers or non-halting.  Since for every
>> decider there is a diagonal entry, every decider is associated  with a
>> test case it does not handle.
>
> void P(u32 x)
> {
>   u32 Input_Halts = H(x, x);
>   if (Input_Halts)
>     HERE: goto HERE;
> }
>
> int main()
> {
>   H((u32)P, (u32)P);
> }
>
> https://en.wikipedia.org/wiki/Halting_problem#Sketch_of_proof
>
> Now that I have studied the diagonalization method much more thoroughly
> I can say that its error is that is assuming that H must return a value
> to P.
>
> It fails to consider this possibility:
>
> (1) The simulating halt decider H aborts the simulation of its input P
> before ever returning any value to P.
>
> (2) It does this on the the basis that P is calling H in infinite
> recursion.
>
>

Wrong.

P 'calls' H with an input that happens to represent P(P) and asks to
what it would say to this.

H then starts a simulation of this input, decides that it will be
non-Halting so it stops the simulation of the input it was given and
returns the answer of n0n-Halting to its caller P.

THIS IS WHAT WILL/MUST Happen. The simulation it aborts may be of the
same code as it is running in, but is a different execution context.

H MUST return its answer to its caller.

If you claim that it doesn't, then either H never return the answer to
this question, and thus fail to be the decider, or H acts differently
depending on its caller and fails to be a computation, so isn't a Turing
Machine equivalent so isn't even qualified to be considered for the job.

You mind can't seem to keep track of the levels of execution.