On 23/10/2023 19:02, olcott wrote:
> On 10/23/2023 11:20 AM, Mike Terry wrote:
>> On 23/10/2023 04:41, olcott wrote:
>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>> On 23/10/2023 02:26, olcott wrote:
>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>> This is the essence of an alternative proof related to
>>>>>> the halting problem
>>>>>>
>>>>>> *It seems that everyone agrees with this*
>>>>>> (a) When the halting problem is defined with a program
>>>>>> specification that requires an H to report on the behavior
>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>> whatever Boolean value that H returns then this is an
>>>>>> unsatisfiable program specification.
>>>>>>
>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>> *the inability to do the logically impossible thus places*
>>>>>> *no actual limit on anyone or anything*
>>>>>>
>>>>>
>>>>> The halting problem proofs only show that no machine
>>>>> can do the logically impossible.
>>>>
>>>> ...where "the logically impossible" = "correctly determine the halting status for EVERY
>>>> computation".
>>>>
>>>> Yes, that IS logically impossible, but we do not just take your word for that.  We demand a
>>>> mathematical proof of this fact!  Fortunately there are a number of such proofs - e.g. the Linz
>>>> proof you used to claim to have refuted.
>>>>
>>>> That proof proceeds by showing that for ANY purported halt decider, one particular computation
>>>> we can see it definitely gets wrong will be the one that internally incorporates the logic of
>>>> the decider in order to basically "do the opposite of whatever the decider returns" - just like
>>>> you say!
>>>>
>>>> You now seem to recognise that H does indeed fail for that particular computation.  (It's ok
>>>> that you say "right, but it ONLY gets it wrong because it's logically impossible for it to be
>>>> correct for that input". Of course it's logically impossible: that's what the Linz proof shows!
>>>> The key point is that it DOES get it wrong, so fails the spec for a halt decider.)
>>>>
>>>> Summary: yes, it is "logically impossible" for a program to correctly determine the halting
>>>> status of EVEY computation, since we know how to construct at least one such that we can plainly
>>>> see it gets wrong.
>>>>
>>>> Put differently, the halting problem is undecideable, just like everyone has been telling you
>>>> for 30(?) years.  It's taken you many years to get to this point, but finally you've arrived!
>>>> Well done.
>>>>
>>>> To cement your clean break with the past, you should now confirm that your previous claims to
>>>> have "refuted" the Linz (and similar) proofs were mistaken.  If you like, you can hedge your
>>>> wording, saying the Linz proof /is/ valid, but /only because/ it is logically impossible for a
>>>> Halt Decider to exist with all the properties such a decider would be required to have. [viz
>>>> correctly deciding EVERY computation including its own "nemesis" computation.]
>>>>
>>>>
>>>> Regards,
>>>> Mike.
>>>>
>>>
>>> We also know that it is logically impossible for a
>>> CAD system to correctly draw a square circle** yet no
>>> one takes this to be a fundamental limit of computation.
>>
>> We could say that being unable to correctly draw a square circle DOES illustrate a limit of
>> computation.  The reason nobody says this, is because nobody ever considered the opposite might be
>> possible, so it's redundant.
>>
>> The situation is quite different with HP:
>>
>> The square circle program spec asks for a program that produces something which everyone can see
>> is mathematically and logically impossible - mathematically, there are NO SQUARE CIRCLES.
>>
>> The "HP program spec" asks for a program that can calculate the halting status for ANY
>> computation. There IS a mathematical function that maps computations (their representations) to
>> their halting status - so the interest here is whether this (EXISTING) function CAN BE COMPUTED BY
>> A TM.  The answer is NO, as the Linz proof (and what you've acknowledged above) shows this is
>> "logically impossible" - all such TMs get at least one input wrong.
>>
>> So the square circle problem says nothing interesting about computation.  The HP says something
>> interesting: the mathematical function that maps (representations of) computations to their
>> halting status IS NOT COMPUTABLE.  That's a fundamental limit on the power of TM computation.
>>
>
> The unsatisfiability of the (a) definition of the halting
> problem spec only says that self-contradictory questions
> lack a correct answer because they are self-contradictory.

No, it says (directly) that there is NO program satisfying the spec required for a Halt Decider.
That is saying, in other words, that the HP is undecidable.

There's nothing in (a) about "self-contradictory questions" - that's just confusion in your own mind.

>
> A PhD computer science professor of many decades that
> has been published in the two most highly esteemed
> computer science journals perfectly agrees with me on
> this by direct email conversation and his own paper
> that says essentially the same thing.
>

Yet another of your appeals to (absent) authority! Perhaps your supporter might come here and
discuss the problem him/herself. Meanwhile we'll all assume this is like your other authorities
you've misquoted in the past, who clearly did not support your possition at all...

Mike.

On 10/23/2023 5:14 PM, Mike Terry wrote:
> On 23/10/2023 19:02, olcott wrote:
>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>> On 23/10/2023 04:41, olcott wrote:
>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>> This is the essence of an alternative proof related to
>>>>>>> the halting problem
>>>>>>>
>>>>>>> *It seems that everyone agrees with this*
>>>>>>> (a) When the halting problem is defined with a program
>>>>>>> specification that requires an H to report on the behavior
>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>> unsatisfiable program specification.
>>>>>>>
>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>> *no actual limit on anyone or anything*
>>>>>>>
>>>>>>
>>>>>> The halting problem proofs only show that no machine
>>>>>> can do the logically impossible.
>>>>>
>>>>> ...where "the logically impossible" = "correctly determine the
>>>>> halting status for EVERY computation".
>>>>>
>>>>> Yes, that IS logically impossible, but we do not just take your
>>>>> word for that.  We demand a mathematical proof of this fact!
>>>>> Fortunately there are a number of such proofs - e.g. the Linz proof
>>>>> you used to claim to have refuted.
>>>>>
>>>>> That proof proceeds by showing that for ANY purported halt decider,
>>>>> one particular computation we can see it definitely gets wrong will
>>>>> be the one that internally incorporates the logic of the decider in
>>>>> order to basically "do the opposite of whatever the decider
>>>>> returns" - just like you say!
>>>>>
>>>>> You now seem to recognise that H does indeed fail for that
>>>>> particular computation.  (It's ok that you say "right, but it ONLY
>>>>> gets it wrong because it's logically impossible for it to be
>>>>> correct for that input". Of course it's logically impossible:
>>>>> that's what the Linz proof shows! The key point is that it DOES get
>>>>> it wrong, so fails the spec for a halt decider.)
>>>>>
>>>>> Summary: yes, it is "logically impossible" for a program to
>>>>> correctly determine the halting status of EVEY computation, since
>>>>> we know how to construct at least one such that we can plainly see
>>>>> it gets wrong.
>>>>>
>>>>> Put differently, the halting problem is undecideable, just like
>>>>> everyone has been telling you for 30(?) years.  It's taken you many
>>>>> years to get to this point, but finally you've arrived! Well done.
>>>>>
>>>>> To cement your clean break with the past, you should now confirm
>>>>> that your previous claims to have "refuted" the Linz (and similar)
>>>>> proofs were mistaken.  If you like, you can hedge your wording,
>>>>> saying the Linz proof /is/ valid, but /only because/ it is
>>>>> logically impossible for a Halt Decider to exist with all the
>>>>> properties such a decider would be required to have. [viz correctly
>>>>> deciding EVERY computation including its own "nemesis" computation.]
>>>>>
>>>>>
>>>>> Regards,
>>>>> Mike.
>>>>>
>>>>
>>>> We also know that it is logically impossible for a
>>>> CAD system to correctly draw a square circle** yet no
>>>> one takes this to be a fundamental limit of computation.
>>>
>>> We could say that being unable to correctly draw a square circle DOES
>>> illustrate a limit of computation.  The reason nobody says this, is
>>> because nobody ever considered the opposite might be possible, so
>>> it's redundant.
>>>
>>> The situation is quite different with HP:
>>>
>>> The square circle program spec asks for a program that produces
>>> something which everyone can see is mathematically and logically
>>> impossible - mathematically, there are NO SQUARE CIRCLES.
>>>
>>> The "HP program spec" asks for a program that can calculate the
>>> halting status for ANY computation. There IS a mathematical function
>>> that maps computations (their representations) to their halting
>>> status - so the interest here is whether this (EXISTING) function CAN
>>> BE COMPUTED BY A TM.  The answer is NO, as the Linz proof (and what
>>> you've acknowledged above) shows this is "logically impossible" - all
>>> such TMs get at least one input wrong.
>>>
>>> So the square circle problem says nothing interesting about
>>> computation.  The HP says something interesting: the mathematical
>>> function that maps (representations of) computations to their halting
>>> status IS NOT COMPUTABLE.  That's a fundamental limit on the power of
>>> TM computation.
>>>
>>
>> The unsatisfiability of the (a) definition of the halting
>> problem spec only says that self-contradictory questions
>> lack a correct answer because they are self-contradictory.
>
> No, it says (directly) that there is NO program satisfying the spec
> required for a Halt Decider. That is saying, in other words, that the HP
> is undecidable.
>
> There's nothing in (a) about "self-contradictory questions" - that's
> just confusion in your own mind.
>
>>
>> A PhD computer science professor of many decades that
>> has been published in the two most highly esteemed
>> computer science journals perfectly agrees with me on
>> this by direct email conversation and his own paper
>> that says essentially the same thing.
>>
>
> Yet another of your appeals to (absent) authority!  Perhaps your
> supporter might come here and discuss the problem him/herself.
> Meanwhile we'll all assume this is like your other authorities you've
> misquoted in the past, who clearly did not support your possition at all...
>
> Mike.
>

*Here are the verbatim words that he agreed to*
Yet the gist of the issue with the halting problem seems to be
that the whole notion of decision problem undecidability is
inherently flawed in that it requires the logically impossible.

Requiring a halt decider H to report on the behavior of the
direct execution of input D when D has been defined to do
the opposite of whatever Boolean value that H returns is
simply an incorrect problem definition because it requires
the logically impossible.

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

On 23/10/2023 23:20, olcott wrote:
> On 10/23/2023 5:14 PM, Mike Terry wrote:
>> On 23/10/2023 19:02, olcott wrote:
>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>> On 23/10/2023 04:41, olcott wrote:
>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>> the halting problem
>>>>>>>>
>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>> unsatisfiable program specification.
>>>>>>>>
>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>
>>>>>>>
>>>>>>> The halting problem proofs only show that no machine
>>>>>>> can do the logically impossible.
>>>>>>
>>>>>> ...where "the logically impossible" = "correctly determine the halting status for EVERY
>>>>>> computation".
>>>>>>
>>>>>> Yes, that IS logically impossible, but we do not just take your word for that.  We demand a
>>>>>> mathematical proof of this fact! Fortunately there are a number of such proofs - e.g. the Linz
>>>>>> proof you used to claim to have refuted.
>>>>>>
>>>>>> That proof proceeds by showing that for ANY purported halt decider, one particular computation
>>>>>> we can see it definitely gets wrong will be the one that internally incorporates the logic of
>>>>>> the decider in order to basically "do the opposite of whatever the decider returns" - just
>>>>>> like you say!
>>>>>>
>>>>>> You now seem to recognise that H does indeed fail for that particular computation.  (It's ok
>>>>>> that you say "right, but it ONLY gets it wrong because it's logically impossible for it to be
>>>>>> correct for that input". Of course it's logically impossible: that's what the Linz proof
>>>>>> shows! The key point is that it DOES get it wrong, so fails the spec for a halt decider.)
>>>>>>
>>>>>> Summary: yes, it is "logically impossible" for a program to correctly determine the halting
>>>>>> status of EVEY computation, since we know how to construct at least one such that we can
>>>>>> plainly see it gets wrong.
>>>>>>
>>>>>> Put differently, the halting problem is undecideable, just like everyone has been telling you
>>>>>> for 30(?) years.  It's taken you many years to get to this point, but finally you've arrived!
>>>>>> Well done.
>>>>>>
>>>>>> To cement your clean break with the past, you should now confirm that your previous claims to
>>>>>> have "refuted" the Linz (and similar) proofs were mistaken.  If you like, you can hedge your
>>>>>> wording, saying the Linz proof /is/ valid, but /only because/ it is logically impossible for a
>>>>>> Halt Decider to exist with all the properties such a decider would be required to have. [viz
>>>>>> correctly deciding EVERY computation including its own "nemesis" computation.]
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Mike.
>>>>>>
>>>>>
>>>>> We also know that it is logically impossible for a
>>>>> CAD system to correctly draw a square circle** yet no
>>>>> one takes this to be a fundamental limit of computation.
>>>>
>>>> We could say that being unable to correctly draw a square circle DOES illustrate a limit of
>>>> computation.  The reason nobody says this, is because nobody ever considered the opposite might
>>>> be possible, so it's redundant.
>>>>
>>>> The situation is quite different with HP:
>>>>
>>>> The square circle program spec asks for a program that produces something which everyone can see
>>>> is mathematically and logically impossible - mathematically, there are NO SQUARE CIRCLES.
>>>>
>>>> The "HP program spec" asks for a program that can calculate the halting status for ANY
>>>> computation. There IS a mathematical function that maps computations (their representations) to
>>>> their halting status - so the interest here is whether this (EXISTING) function CAN BE COMPUTED
>>>> BY A TM.  The answer is NO, as the Linz proof (and what you've acknowledged above) shows this is
>>>> "logically impossible" - all such TMs get at least one input wrong.
>>>>
>>>> So the square circle problem says nothing interesting about computation.  The HP says something
>>>> interesting: the mathematical function that maps (representations of) computations to their
>>>> halting status IS NOT COMPUTABLE.  That's a fundamental limit on the power of TM computation.
>>>>
>>>
>>> The unsatisfiability of the (a) definition of the halting
>>> problem spec only says that self-contradictory questions
>>> lack a correct answer because they are self-contradictory.
>>
>> No, it says (directly) that there is NO program satisfying the spec required for a Halt Decider.
>> That is saying, in other words, that the HP is undecidable.
>>
>> There's nothing in (a) about "self-contradictory questions" - that's just confusion in your own mind.
>>
>>>
>>> A PhD computer science professor of many decades that
>>> has been published in the two most highly esteemed
>>> computer science journals perfectly agrees with me on
>>> this by direct email conversation and his own paper
>>> that says essentially the same thing.
>>>
>>
>> Yet another of your appeals to (absent) authority!  Perhaps your supporter might come here and
>> discuss the problem him/herself. Meanwhile we'll all assume this is like your other authorities
>> you've misquoted in the past, who clearly did not support your possition at all...
>>
>> Mike.
>>
>
> *Here are the verbatim words that he agreed to*
> Yet the gist of the issue with the halting problem seems to be
> that the whole notion of decision problem undecidability is
> inherently flawed in that it requires the logically impossible.
>
> Requiring a halt decider H to report on the behavior of the
> direct execution of input D when D has been defined to do
> the opposite of whatever Boolean value that H returns is
> simply an incorrect problem definition because it requires
> the logically impossible.
>

Hehe - seems he's actually agreeing WITH WHAT I said above, which is not supporting your position AT
ALL. This is exactly the same as when you conversed with Prof. Sipser and completely misunderstood
what he was saying!

That's disappointing news - if you really are misunderstanding the common phrase "logically
impossible", then there's no evidence you've changed your position at all. So I'll bow out now...

Mike.

On 10/23/23 3:06 PM, olcott wrote:
> On 10/23/2023 4:33 PM, olcott wrote:
>> On 10/23/2023 3:54 PM, olcott wrote:
>>> On 10/23/2023 2:28 PM, olcott wrote:
>>>> On 10/23/2023 1:49 PM, olcott wrote:
>>>>> On 10/23/2023 1:02 PM, olcott wrote:
>>>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>>>> the halting problem
>>>>>>>>>>>
>>>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>>>
>>>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>>>> can do the logically impossible.
>>>>>>>>>
>>>>>>>>> ...where "the logically impossible" = "correctly determine the
>>>>>>>>> halting status for EVERY computation".
>>>>>>>>>
>>>>>>>>> Yes, that IS logically impossible, but we do not just take your
>>>>>>>>> word for that.  We demand a mathematical proof of this fact!
>>>>>>>>> Fortunately there are a number of such proofs - e.g. the Linz
>>>>>>>>> proof you used to claim to have refuted.
>>>>>>>>>
>>>>>>>>> That proof proceeds by showing that for ANY purported halt
>>>>>>>>> decider, one particular computation we can see it definitely
>>>>>>>>> gets wrong will be the one that internally incorporates the
>>>>>>>>> logic of the decider in order to basically "do the opposite of
>>>>>>>>> whatever the decider returns" - just like you say!
>>>>>>>>>
>>>>>>>>> You now seem to recognise that H does indeed fail for that
>>>>>>>>> particular computation.  (It's ok that you say "right, but it
>>>>>>>>> ONLY gets it wrong because it's logically impossible for it to
>>>>>>>>> be correct for that input". Of course it's logically
>>>>>>>>> impossible: that's what the Linz proof shows! The key point is
>>>>>>>>> that it DOES get it wrong, so fails the spec for a halt decider.)
>>>>>>>>>
>>>>>>>>> Summary: yes, it is "logically impossible" for a program to
>>>>>>>>> correctly determine the halting status of EVEY computation,
>>>>>>>>> since we know how to construct at least one such that we can
>>>>>>>>> plainly see it gets wrong.
>>>>>>>>>
>>>>>>>>> Put differently, the halting problem is undecideable, just like
>>>>>>>>> everyone has been telling you for 30(?) years.  It's taken you
>>>>>>>>> many years to get to this point, but finally you've arrived!
>>>>>>>>> Well done.
>>>>>>>>>
>>>>>>>>> To cement your clean break with the past, you should now
>>>>>>>>> confirm that your previous claims to have "refuted" the Linz
>>>>>>>>> (and similar) proofs were mistaken.  If you like, you can hedge
>>>>>>>>> your wording, saying the Linz proof /is/ valid, but /only
>>>>>>>>> because/ it is logically impossible for a Halt Decider to exist
>>>>>>>>> with all the properties such a decider would be required to
>>>>>>>>> have. [viz correctly deciding EVERY computation including its
>>>>>>>>> own "nemesis" computation.]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Mike.
>>>>>>>>>
>>>>>>>>
>>>>>>>> We also know that it is logically impossible for a
>>>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>>>> one takes this to be a fundamental limit of computation.
>>>>>>>
>>>>>>> We could say that being unable to correctly draw a square circle
>>>>>>> DOES illustrate a limit of computation.  The reason nobody says
>>>>>>> this, is because nobody ever considered the opposite might be
>>>>>>> possible, so it's redundant.
>>>>>>>
>>>>>>> The situation is quite different with HP:
>>>>>>>
>>>>>>> The square circle program spec asks for a program that produces
>>>>>>> something which everyone can see is mathematically and logically
>>>>>>> impossible - mathematically, there are NO SQUARE CIRCLES.
>>>>>>>
>>>>>>> The "HP program spec" asks for a program that can calculate the
>>>>>>> halting status for ANY computation. There IS a mathematical
>>>>>>> function that maps computations (their representations) to their
>>>>>>> halting status - so the interest here is whether this (EXISTING)
>>>>>>> function CAN BE COMPUTED BY A TM.  The answer is NO, as the Linz
>>>>>>> proof (and what you've acknowledged above) shows this is
>>>>>>> "logically impossible" - all such TMs get at least one input wrong.
>>>>>>>
>>>>>>> So the square circle problem says nothing interesting about
>>>>>>> computation.  The HP says something interesting: the mathematical
>>>>>>> function that maps (representations of) computations to their
>>>>>>> halting status IS NOT COMPUTABLE.  That's a fundamental limit on
>>>>>>> the power of TM computation.
>>>>>>>
>>>>>>
>>>>>> The unsatisfiability of the (a) definition of the halting
>>>>>> problem spec only says that self-contradictory questions
>>>>>> lack a correct answer because they are self-contradictory.
>>>>>>
>>>>>> A PhD computer science professor of many decades that
>>>>>> has been published in the two most highly esteemed
>>>>>> computer science journals perfectly agrees with me on
>>>>>> this by direct email conversation and his own paper
>>>>>> that says essentially the same thing.
>>>>>>
>>>>>
>>>>> (a) proves that the question:
>>>>>
>>>>> "Does the Computation described by the input Halt?"
>>>>>
>>>>> has self-contradictory instances and these are the
>>>>> ones that make (a) unsatisfiable.
>>>>>
>>>>
>>>> The only reason that the halting problem proof shows
>>>> that the halting problem specification is unsatisfiable
>>>> is that for every halt decider H there are inputs D
>>>> that make the question:
>>>>
>>>> "Does the Computation described by the input Halt?"
>>>> a self-contradictory question.
>>>
>>> Of every H that can possibly be defined there is an
>>> input D that makes the question:
>>> "Does the Computation described by the input Halt?"
>>> a self-contradictory thus incorrect question.
>>>
>>> *The inability to correctly answer incorrect questions*
>>> *does not place any real limit on anyone or anything*
>>
>> "Does the Computation described by the input Halt?"
>> has self-contradictory instances for every H.
>
> *I say that because it is true and you know it is true*
> *I say that because it is true and you know it is true*
> *I say that because it is true and you know it is true*

On 10/23/23 3:20 PM, olcott wrote:
> On 10/23/2023 5:14 PM, Mike Terry wrote:
>> On 23/10/2023 19:02, olcott wrote:
>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>> On 23/10/2023 04:41, olcott wrote:
>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>> the halting problem
>>>>>>>>
>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>> unsatisfiable program specification.
>>>>>>>>
>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>
>>>>>>>
>>>>>>> The halting problem proofs only show that no machine
>>>>>>> can do the logically impossible.
>>>>>>
>>>>>> ...where "the logically impossible" = "correctly determine the
>>>>>> halting status for EVERY computation".
>>>>>>
>>>>>> Yes, that IS logically impossible, but we do not just take your
>>>>>> word for that.  We demand a mathematical proof of this fact!
>>>>>> Fortunately there are a number of such proofs - e.g. the Linz
>>>>>> proof you used to claim to have refuted.
>>>>>>
>>>>>> That proof proceeds by showing that for ANY purported halt
>>>>>> decider, one particular computation we can see it definitely gets
>>>>>> wrong will be the one that internally incorporates the logic of
>>>>>> the decider in order to basically "do the opposite of whatever the
>>>>>> decider returns" - just like you say!
>>>>>>
>>>>>> You now seem to recognise that H does indeed fail for that
>>>>>> particular computation.  (It's ok that you say "right, but it ONLY
>>>>>> gets it wrong because it's logically impossible for it to be
>>>>>> correct for that input". Of course it's logically impossible:
>>>>>> that's what the Linz proof shows! The key point is that it DOES
>>>>>> get it wrong, so fails the spec for a halt decider.)
>>>>>>
>>>>>> Summary: yes, it is "logically impossible" for a program to
>>>>>> correctly determine the halting status of EVEY computation, since
>>>>>> we know how to construct at least one such that we can plainly see
>>>>>> it gets wrong.
>>>>>>
>>>>>> Put differently, the halting problem is undecideable, just like
>>>>>> everyone has been telling you for 30(?) years.  It's taken you
>>>>>> many years to get to this point, but finally you've arrived! Well
>>>>>> done.
>>>>>>
>>>>>> To cement your clean break with the past, you should now confirm
>>>>>> that your previous claims to have "refuted" the Linz (and similar)
>>>>>> proofs were mistaken.  If you like, you can hedge your wording,
>>>>>> saying the Linz proof /is/ valid, but /only because/ it is
>>>>>> logically impossible for a Halt Decider to exist with all the
>>>>>> properties such a decider would be required to have. [viz
>>>>>> correctly deciding EVERY computation including its own "nemesis"
>>>>>> computation.]
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Mike.
>>>>>>
>>>>>
>>>>> We also know that it is logically impossible for a
>>>>> CAD system to correctly draw a square circle** yet no
>>>>> one takes this to be a fundamental limit of computation.
>>>>
>>>> We could say that being unable to correctly draw a square circle
>>>> DOES illustrate a limit of computation.  The reason nobody says
>>>> this, is because nobody ever considered the opposite might be
>>>> possible, so it's redundant.
>>>>
>>>> The situation is quite different with HP:
>>>>
>>>> The square circle program spec asks for a program that produces
>>>> something which everyone can see is mathematically and logically
>>>> impossible - mathematically, there are NO SQUARE CIRCLES.
>>>>
>>>> The "HP program spec" asks for a program that can calculate the
>>>> halting status for ANY computation. There IS a mathematical function
>>>> that maps computations (their representations) to their halting
>>>> status - so the interest here is whether this (EXISTING) function
>>>> CAN BE COMPUTED BY A TM.  The answer is NO, as the Linz proof (and
>>>> what you've acknowledged above) shows this is "logically impossible"
>>>> - all such TMs get at least one input wrong.
>>>>
>>>> So the square circle problem says nothing interesting about
>>>> computation.  The HP says something interesting: the mathematical
>>>> function that maps (representations of) computations to their
>>>> halting status IS NOT COMPUTABLE.  That's a fundamental limit on the
>>>> power of TM computation.
>>>>
>>>
>>> The unsatisfiability of the (a) definition of the halting
>>> problem spec only says that self-contradictory questions
>>> lack a correct answer because they are self-contradictory.
>>
>> No, it says (directly) that there is NO program satisfying the spec
>> required for a Halt Decider. That is saying, in other words, that the
>> HP is undecidable.
>>
>> There's nothing in (a) about "self-contradictory questions" - that's
>> just confusion in your own mind.
>>
>>>
>>> A PhD computer science professor of many decades that
>>> has been published in the two most highly esteemed
>>> computer science journals perfectly agrees with me on
>>> this by direct email conversation and his own paper
>>> that says essentially the same thing.
>>>
>>
>> Yet another of your appeals to (absent) authority!  Perhaps your
>> supporter might come here and discuss the problem him/herself.
>> Meanwhile we'll all assume this is like your other authorities you've
>> misquoted in the past, who clearly did not support your possition at
>> all...
>>
>> Mike.
>>
>
> *Here are the verbatim words that he agreed to*
> Yet the gist of the issue with the halting problem seems to be
> that the whole notion of decision problem undecidability is
> inherently flawed in that it requires the logically impossible.
>
> Requiring a halt decider H to report on the behavior of the
> direct execution of input D when D has been defined to do
> the opposite of whatever Boolean value that H returns is
> simply an incorrect problem definition because it requires
> the logically impossible.
>

Which doesn't say what you claim he agreed to, because you don't seem to
understand the meaning of "correct"

This shows how little you understand about logic and what Truth is.

On 10/23/2023 5:55 PM, Mike Terry wrote:
> On 23/10/2023 23:20, olcott wrote:
>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>> On 23/10/2023 19:02, olcott wrote:
>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>> the halting problem
>>>>>>>>>
>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>
>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>
>>>>>>>>
>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>> can do the logically impossible.
>>>>>>>
>>>>>>> ...where "the logically impossible" = "correctly determine the
>>>>>>> halting status for EVERY computation".
>>>>>>>
>>>>>>> Yes, that IS logically impossible, but we do not just take your
>>>>>>> word for that.  We demand a mathematical proof of this fact!
>>>>>>> Fortunately there are a number of such proofs - e.g. the Linz
>>>>>>> proof you used to claim to have refuted.
>>>>>>>
>>>>>>> That proof proceeds by showing that for ANY purported halt
>>>>>>> decider, one particular computation we can see it definitely gets
>>>>>>> wrong will be the one that internally incorporates the logic of
>>>>>>> the decider in order to basically "do the opposite of whatever
>>>>>>> the decider returns" - just like you say!
>>>>>>>
>>>>>>> You now seem to recognise that H does indeed fail for that
>>>>>>> particular computation.  (It's ok that you say "right, but it
>>>>>>> ONLY gets it wrong because it's logically impossible for it to be
>>>>>>> correct for that input". Of course it's logically impossible:
>>>>>>> that's what the Linz proof shows! The key point is that it DOES
>>>>>>> get it wrong, so fails the spec for a halt decider.)
>>>>>>>
>>>>>>> Summary: yes, it is "logically impossible" for a program to
>>>>>>> correctly determine the halting status of EVEY computation, since
>>>>>>> we know how to construct at least one such that we can plainly
>>>>>>> see it gets wrong.
>>>>>>>
>>>>>>> Put differently, the halting problem is undecideable, just like
>>>>>>> everyone has been telling you for 30(?) years.  It's taken you
>>>>>>> many years to get to this point, but finally you've arrived! Well
>>>>>>> done.
>>>>>>>
>>>>>>> To cement your clean break with the past, you should now confirm
>>>>>>> that your previous claims to have "refuted" the Linz (and
>>>>>>> similar) proofs were mistaken.  If you like, you can hedge your
>>>>>>> wording, saying the Linz proof /is/ valid, but /only because/ it
>>>>>>> is logically impossible for a Halt Decider to exist with all the
>>>>>>> properties such a decider would be required to have. [viz
>>>>>>> correctly deciding EVERY computation including its own "nemesis"
>>>>>>> computation.]
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mike.
>>>>>>>
>>>>>>
>>>>>> We also know that it is logically impossible for a
>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>> one takes this to be a fundamental limit of computation.
>>>>>
>>>>> We could say that being unable to correctly draw a square circle
>>>>> DOES illustrate a limit of computation.  The reason nobody says
>>>>> this, is because nobody ever considered the opposite might be
>>>>> possible, so it's redundant.
>>>>>
>>>>> The situation is quite different with HP:
>>>>>
>>>>> The square circle program spec asks for a program that produces
>>>>> something which everyone can see is mathematically and logically
>>>>> impossible - mathematically, there are NO SQUARE CIRCLES.
>>>>>
>>>>> The "HP program spec" asks for a program that can calculate the
>>>>> halting status for ANY computation. There IS a mathematical
>>>>> function that maps computations (their representations) to their
>>>>> halting status - so the interest here is whether this (EXISTING)
>>>>> function CAN BE COMPUTED BY A TM.  The answer is NO, as the Linz
>>>>> proof (and what you've acknowledged above) shows this is "logically
>>>>> impossible" - all such TMs get at least one input wrong.
>>>>>
>>>>> So the square circle problem says nothing interesting about
>>>>> computation.  The HP says something interesting: the mathematical
>>>>> function that maps (representations of) computations to their
>>>>> halting status IS NOT COMPUTABLE.  That's a fundamental limit on
>>>>> the power of TM computation.
>>>>>
>>>>
>>>> The unsatisfiability of the (a) definition of the halting
>>>> problem spec only says that self-contradictory questions
>>>> lack a correct answer because they are self-contradictory.
>>>
>>> No, it says (directly) that there is NO program satisfying the spec
>>> required for a Halt Decider. That is saying, in other words, that the
>>> HP is undecidable.
>>>
>>> There's nothing in (a) about "self-contradictory questions" - that's
>>> just confusion in your own mind.
>>>
>>>>
>>>> A PhD computer science professor of many decades that
>>>> has been published in the two most highly esteemed
>>>> computer science journals perfectly agrees with me on
>>>> this by direct email conversation and his own paper
>>>> that says essentially the same thing.
>>>>
>>>
>>> Yet another of your appeals to (absent) authority!  Perhaps your
>>> supporter might come here and discuss the problem him/herself.
>>> Meanwhile we'll all assume this is like your other authorities you've
>>> misquoted in the past, who clearly did not support your possition at
>>> all...
>>>
>>> Mike.
>>>
>>
>> *Here are the verbatim words that he agreed to*
>> Yet the gist of the issue with the halting problem seems to be
>> that the whole notion of decision problem undecidability is
>> inherently flawed in that it requires the logically impossible.
>>
>> Requiring a halt decider H to report on the behavior of the
>> direct execution of input D when D has been defined to do
>> the opposite of whatever Boolean value that H returns is
>> simply an incorrect problem definition because it requires
>> the logically impossible.
>>
>
> Hehe - seems he's actually agreeing WITH WHAT I said above, which is not
> supporting your position AT ALL.  This is exactly the same as when you
> conversed with Prof. Sipser and completely misunderstood what he was
> saying!
>

On 10/23/2023 5:55 PM, Mike Terry wrote:
> On 23/10/2023 23:20, olcott wrote:
>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>> On 23/10/2023 19:02, olcott wrote:
>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>> the halting problem
>>>>>>>>>
>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>
>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>
>>>>>>>>
>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>> can do the logically impossible.
>>>>>>>
>>>>>>> ...where "the logically impossible" = "correctly determine the
>>>>>>> halting status for EVERY computation".
>>>>>>>
>>>>>>> Yes, that IS logically impossible, but we do not just take your
>>>>>>> word for that.  We demand a mathematical proof of this fact!
>>>>>>> Fortunately there are a number of such proofs - e.g. the Linz
>>>>>>> proof you used to claim to have refuted.
>>>>>>>
>>>>>>> That proof proceeds by showing that for ANY purported halt
>>>>>>> decider, one particular computation we can see it definitely gets
>>>>>>> wrong will be the one that internally incorporates the logic of
>>>>>>> the decider in order to basically "do the opposite of whatever
>>>>>>> the decider returns" - just like you say!
>>>>>>>
>>>>>>> You now seem to recognise that H does indeed fail for that
>>>>>>> particular computation.  (It's ok that you say "right, but it
>>>>>>> ONLY gets it wrong because it's logically impossible for it to be
>>>>>>> correct for that input". Of course it's logically impossible:
>>>>>>> that's what the Linz proof shows! The key point is that it DOES
>>>>>>> get it wrong, so fails the spec for a halt decider.)
>>>>>>>
>>>>>>> Summary: yes, it is "logically impossible" for a program to
>>>>>>> correctly determine the halting status of EVEY computation, since
>>>>>>> we know how to construct at least one such that we can plainly
>>>>>>> see it gets wrong.
>>>>>>>
>>>>>>> Put differently, the halting problem is undecideable, just like
>>>>>>> everyone has been telling you for 30(?) years.  It's taken you
>>>>>>> many years to get to this point, but finally you've arrived! Well
>>>>>>> done.
>>>>>>>
>>>>>>> To cement your clean break with the past, you should now confirm
>>>>>>> that your previous claims to have "refuted" the Linz (and
>>>>>>> similar) proofs were mistaken.  If you like, you can hedge your
>>>>>>> wording, saying the Linz proof /is/ valid, but /only because/ it
>>>>>>> is logically impossible for a Halt Decider to exist with all the
>>>>>>> properties such a decider would be required to have. [viz
>>>>>>> correctly deciding EVERY computation including its own "nemesis"
>>>>>>> computation.]
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mike.
>>>>>>>
>>>>>>
>>>>>> We also know that it is logically impossible for a
>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>> one takes this to be a fundamental limit of computation.
>>>>>
>>>>> We could say that being unable to correctly draw a square circle
>>>>> DOES illustrate a limit of computation.  The reason nobody says
>>>>> this, is because nobody ever considered the opposite might be
>>>>> possible, so it's redundant.
>>>>>
>>>>> The situation is quite different with HP:
>>>>>
>>>>> The square circle program spec asks for a program that produces
>>>>> something which everyone can see is mathematically and logically
>>>>> impossible - mathematically, there are NO SQUARE CIRCLES.
>>>>>
>>>>> The "HP program spec" asks for a program that can calculate the
>>>>> halting status for ANY computation. There IS a mathematical
>>>>> function that maps computations (their representations) to their
>>>>> halting status - so the interest here is whether this (EXISTING)
>>>>> function CAN BE COMPUTED BY A TM.  The answer is NO, as the Linz
>>>>> proof (and what you've acknowledged above) shows this is "logically
>>>>> impossible" - all such TMs get at least one input wrong.
>>>>>
>>>>> So the square circle problem says nothing interesting about
>>>>> computation.  The HP says something interesting: the mathematical
>>>>> function that maps (representations of) computations to their
>>>>> halting status IS NOT COMPUTABLE.  That's a fundamental limit on
>>>>> the power of TM computation.
>>>>>
>>>>
>>>> The unsatisfiability of the (a) definition of the halting
>>>> problem spec only says that self-contradictory questions
>>>> lack a correct answer because they are self-contradictory.
>>>
>>> No, it says (directly) that there is NO program satisfying the spec
>>> required for a Halt Decider. That is saying, in other words, that the
>>> HP is undecidable.
>>>
>>> There's nothing in (a) about "self-contradictory questions" - that's
>>> just confusion in your own mind.
>>>
>>>>
>>>> A PhD computer science professor of many decades that
>>>> has been published in the two most highly esteemed
>>>> computer science journals perfectly agrees with me on
>>>> this by direct email conversation and his own paper
>>>> that says essentially the same thing.
>>>>
>>>
>>> Yet another of your appeals to (absent) authority!  Perhaps your
>>> supporter might come here and discuss the problem him/herself.
>>> Meanwhile we'll all assume this is like your other authorities you've
>>> misquoted in the past, who clearly did not support your possition at
>>> all...
>>>
>>> Mike.
>>>
>>
>> *Here are the verbatim words that he agreed to*
>> Yet the gist of the issue with the halting problem seems to be
>> that the whole notion of decision problem undecidability is
>> inherently flawed in that it requires the logically impossible.
>>
>> Requiring a halt decider H to report on the behavior of the
>> direct execution of input D when D has been defined to do
>> the opposite of whatever Boolean value that H returns is
>> simply an incorrect problem definition because it requires
>> the logically impossible.
>>
>
> Hehe - seems he's actually agreeing WITH WHAT I said above, which is not
> supporting your position AT ALL.  This is exactly the same as when you
> conversed with Prof. Sipser and completely misunderstood what he was
> saying!
>

On 24/10/2023 00:34, olcott wrote:
> On 10/23/2023 5:55 PM, Mike Terry wrote:
>> On 23/10/2023 23:20, olcott wrote:
>>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>>> On 23/10/2023 19:02, olcott wrote:
>>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>>> the halting problem
>>>>>>>>>>
>>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>>
>>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>>> can do the logically impossible.
>>>>>>>>
>>>>>>>> ...where "the logically impossible" = "correctly determine the halting status for EVERY
>>>>>>>> computation".
>>>>>>>>
>>>>>>>> Yes, that IS logically impossible, but we do not just take your word for that.  We demand a
>>>>>>>> mathematical proof of this fact! Fortunately there are a number of such proofs - e.g. the
>>>>>>>> Linz proof you used to claim to have refuted.
>>>>>>>>
>>>>>>>> That proof proceeds by showing that for ANY purported halt decider, one particular
>>>>>>>> computation we can see it definitely gets wrong will be the one that internally incorporates
>>>>>>>> the logic of the decider in order to basically "do the opposite of whatever the decider
>>>>>>>> returns" - just like you say!
>>>>>>>>
>>>>>>>> You now seem to recognise that H does indeed fail for that particular computation.  (It's ok
>>>>>>>> that you say "right, but it ONLY gets it wrong because it's logically impossible for it to
>>>>>>>> be correct for that input". Of course it's logically impossible: that's what the Linz proof
>>>>>>>> shows! The key point is that it DOES get it wrong, so fails the spec for a halt decider.)
>>>>>>>>
>>>>>>>> Summary: yes, it is "logically impossible" for a program to correctly determine the halting
>>>>>>>> status of EVEY computation, since we know how to construct at least one such that we can
>>>>>>>> plainly see it gets wrong.
>>>>>>>>
>>>>>>>> Put differently, the halting problem is undecideable, just like everyone has been telling
>>>>>>>> you for 30(?) years.  It's taken you many years to get to this point, but finally you've
>>>>>>>> arrived! Well done.
>>>>>>>>
>>>>>>>> To cement your clean break with the past, you should now confirm that your previous claims
>>>>>>>> to have "refuted" the Linz (and similar) proofs were mistaken.  If you like, you can hedge
>>>>>>>> your wording, saying the Linz proof /is/ valid, but /only because/ it is logically
>>>>>>>> impossible for a Halt Decider to exist with all the properties such a decider would be
>>>>>>>> required to have. [viz correctly deciding EVERY computation including its own "nemesis"
>>>>>>>> computation.]
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Mike.
>>>>>>>>
>>>>>>>
>>>>>>> We also know that it is logically impossible for a
>>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>>> one takes this to be a fundamental limit of computation.
>>>>>>
>>>>>> We could say that being unable to correctly draw a square circle DOES illustrate a limit of
>>>>>> computation.  The reason nobody says this, is because nobody ever considered the opposite
>>>>>> might be possible, so it's redundant.
>>>>>>
>>>>>> The situation is quite different with HP:
>>>>>>
>>>>>> The square circle program spec asks for a program that produces something which everyone can
>>>>>> see is mathematically and logically impossible - mathematically, there are NO SQUARE CIRCLES.
>>>>>>
>>>>>> The "HP program spec" asks for a program that can calculate the halting status for ANY
>>>>>> computation. There IS a mathematical function that maps computations (their representations)
>>>>>> to their halting status - so the interest here is whether this (EXISTING) function CAN BE
>>>>>> COMPUTED BY A TM.  The answer is NO, as the Linz proof (and what you've acknowledged above)
>>>>>> shows this is "logically impossible" - all such TMs get at least one input wrong.
>>>>>>
>>>>>> So the square circle problem says nothing interesting about computation.  The HP says
>>>>>> something interesting: the mathematical function that maps (representations of) computations
>>>>>> to their halting status IS NOT COMPUTABLE.  That's a fundamental limit on the power of TM
>>>>>> computation.
>>>>>>
>>>>>
>>>>> The unsatisfiability of the (a) definition of the halting
>>>>> problem spec only says that self-contradictory questions
>>>>> lack a correct answer because they are self-contradictory.
>>>>
>>>> No, it says (directly) that there is NO program satisfying the spec required for a Halt Decider.
>>>> That is saying, in other words, that the HP is undecidable.
>>>>
>>>> There's nothing in (a) about "self-contradictory questions" - that's just confusion in your own
>>>> mind.
>>>>
>>>>>
>>>>> A PhD computer science professor of many decades that
>>>>> has been published in the two most highly esteemed
>>>>> computer science journals perfectly agrees with me on
>>>>> this by direct email conversation and his own paper
>>>>> that says essentially the same thing.
>>>>>
>>>>
>>>> Yet another of your appeals to (absent) authority!  Perhaps your supporter might come here and
>>>> discuss the problem him/herself. Meanwhile we'll all assume this is like your other authorities
>>>> you've misquoted in the past, who clearly did not support your possition at all...
>>>>
>>>> Mike.
>>>>
>>>
>>> *Here are the verbatim words that he agreed to*
>>> Yet the gist of the issue with the halting problem seems to be
>>> that the whole notion of decision problem undecidability is
>>> inherently flawed in that it requires the logically impossible.
>>>
>>> Requiring a halt decider H to report on the behavior of the
>>> direct execution of input D when D has been defined to do
>>> the opposite of whatever Boolean value that H returns is
>>> simply an incorrect problem definition because it requires
>>> the logically impossible.
>>>
>>
>> Hehe - seems he's actually agreeing WITH WHAT I said above, which is not supporting your position
>> AT ALL.  This is exactly the same as when you conversed with Prof. Sipser and completely
>> misunderstood what he was saying!

On 10/23/2023 6:59 PM, Mike Terry wrote:
> On 24/10/2023 00:34, olcott wrote:
>> On 10/23/2023 5:55 PM, Mike Terry wrote:
>>> On 23/10/2023 23:20, olcott wrote:
>>>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>>>> On 23/10/2023 19:02, olcott wrote:
>>>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>>>> the halting problem
>>>>>>>>>>>
>>>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>>>
>>>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>>>> can do the logically impossible.
>>>>>>>>>
>>>>>>>>> ...where "the logically impossible" = "correctly determine the
>>>>>>>>> halting status for EVERY computation".
>>>>>>>>>
>>>>>>>>> Yes, that IS logically impossible, but we do not just take your
>>>>>>>>> word for that.  We demand a mathematical proof of this fact!
>>>>>>>>> Fortunately there are a number of such proofs - e.g. the Linz
>>>>>>>>> proof you used to claim to have refuted.
>>>>>>>>>
>>>>>>>>> That proof proceeds by showing that for ANY purported halt
>>>>>>>>> decider, one particular computation we can see it definitely
>>>>>>>>> gets wrong will be the one that internally incorporates the
>>>>>>>>> logic of the decider in order to basically "do the opposite of
>>>>>>>>> whatever the decider returns" - just like you say!
>>>>>>>>>
>>>>>>>>> You now seem to recognise that H does indeed fail for that
>>>>>>>>> particular computation.  (It's ok that you say "right, but it
>>>>>>>>> ONLY gets it wrong because it's logically impossible for it to
>>>>>>>>> be correct for that input". Of course it's logically
>>>>>>>>> impossible: that's what the Linz proof shows! The key point is
>>>>>>>>> that it DOES get it wrong, so fails the spec for a halt decider.)
>>>>>>>>>
>>>>>>>>> Summary: yes, it is "logically impossible" for a program to
>>>>>>>>> correctly determine the halting status of EVEY computation,
>>>>>>>>> since we know how to construct at least one such that we can
>>>>>>>>> plainly see it gets wrong.
>>>>>>>>>
>>>>>>>>> Put differently, the halting problem is undecideable, just like
>>>>>>>>> everyone has been telling you for 30(?) years.  It's taken you
>>>>>>>>> many years to get to this point, but finally you've arrived!
>>>>>>>>> Well done.
>>>>>>>>>
>>>>>>>>> To cement your clean break with the past, you should now
>>>>>>>>> confirm that your previous claims to have "refuted" the Linz
>>>>>>>>> (and similar) proofs were mistaken.  If you like, you can hedge
>>>>>>>>> your wording, saying the Linz proof /is/ valid, but /only
>>>>>>>>> because/ it is logically impossible for a Halt Decider to exist
>>>>>>>>> with all the properties such a decider would be required to
>>>>>>>>> have. [viz correctly deciding EVERY computation including its
>>>>>>>>> own "nemesis" computation.]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Mike.
>>>>>>>>>
>>>>>>>>
>>>>>>>> We also know that it is logically impossible for a
>>>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>>>> one takes this to be a fundamental limit of computation.
>>>>>>>
>>>>>>> We could say that being unable to correctly draw a square circle
>>>>>>> DOES illustrate a limit of computation.  The reason nobody says
>>>>>>> this, is because nobody ever considered the opposite might be
>>>>>>> possible, so it's redundant.
>>>>>>>
>>>>>>> The situation is quite different with HP:
>>>>>>>
>>>>>>> The square circle program spec asks for a program that produces
>>>>>>> something which everyone can see is mathematically and logically
>>>>>>> impossible - mathematically, there are NO SQUARE CIRCLES.
>>>>>>>
>>>>>>> The "HP program spec" asks for a program that can calculate the
>>>>>>> halting status for ANY computation. There IS a mathematical
>>>>>>> function that maps computations (their representations) to their
>>>>>>> halting status - so the interest here is whether this (EXISTING)
>>>>>>> function CAN BE COMPUTED BY A TM.  The answer is NO, as the Linz
>>>>>>> proof (and what you've acknowledged above) shows this is
>>>>>>> "logically impossible" - all such TMs get at least one input wrong.
>>>>>>>
>>>>>>> So the square circle problem says nothing interesting about
>>>>>>> computation.  The HP says something interesting: the mathematical
>>>>>>> function that maps (representations of) computations to their
>>>>>>> halting status IS NOT COMPUTABLE.  That's a fundamental limit on
>>>>>>> the power of TM computation.
>>>>>>>
>>>>>>
>>>>>> The unsatisfiability of the (a) definition of the halting
>>>>>> problem spec only says that self-contradictory questions
>>>>>> lack a correct answer because they are self-contradictory.
>>>>>
>>>>> No, it says (directly) that there is NO program satisfying the spec
>>>>> required for a Halt Decider. That is saying, in other words, that
>>>>> the HP is undecidable.
>>>>>
>>>>> There's nothing in (a) about "self-contradictory questions" -
>>>>> that's just confusion in your own mind.
>>>>>
>>>>>>
>>>>>> A PhD computer science professor of many decades that
>>>>>> has been published in the two most highly esteemed
>>>>>> computer science journals perfectly agrees with me on
>>>>>> this by direct email conversation and his own paper
>>>>>> that says essentially the same thing.
>>>>>>
>>>>>
>>>>> Yet another of your appeals to (absent) authority!  Perhaps your
>>>>> supporter might come here and discuss the problem him/herself.
>>>>> Meanwhile we'll all assume this is like your other authorities
>>>>> you've misquoted in the past, who clearly did not support your
>>>>> possition at all...
>>>>>
>>>>> Mike.
>>>>>
>>>>
>>>> *Here are the verbatim words that he agreed to*
>>>> Yet the gist of the issue with the halting problem seems to be
>>>> that the whole notion of decision problem undecidability is
>>>> inherently flawed in that it requires the logically impossible.
>>>>
>>>> Requiring a halt decider H to report on the behavior of the
>>>> direct execution of input D when D has been defined to do
>>>> the opposite of whatever Boolean value that H returns is
>>>> simply an incorrect problem definition because it requires
>>>> the logically impossible.
>>>>
>>>
>>> Hehe - seems he's actually agreeing WITH WHAT I said above, which is
>>> not supporting your position AT ALL.  This is exactly the same as
>>> when you conversed with Prof. Sipser and completely misunderstood
>>> what he was saying!
>
> Reading more closely... If your "supporter" said "Yet the gist of the
> issue..." then /perhaps/ he is agreeing with you.  Hard to say without
> the full context, which you never understand or present correctly.
>
> If your "supporter" said "Requiring a halt decider H ..." then he is
> probably just agreeing with me - but to me now, those sound more like
> /your/ words, misunderstanding "logically impossible".
>
> In either case it is meaningless, because your "supporter" IS NOT HERE
> participating in the thread! So just present your case as YOU see it and
> forget your absent supporters!  :)
>
> <https://en.wikipedia.org/wiki/Argument_from_authority>
>
> Mike.
>

On 24/10/2023 01:08, olcott wrote:
> On 10/23/2023 6:59 PM, Mike Terry wrote:
>> On 24/10/2023 00:34, olcott wrote:
>>> On 10/23/2023 5:55 PM, Mike Terry wrote:
>>>> On 23/10/2023 23:20, olcott wrote:
>>>>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>>>>> On 23/10/2023 19:02, olcott wrote:
>>>>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>>>>> the halting problem|
>>>>>>>>>>>>
>>>>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>>>>
>>>>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>>>>> can do the logically impossible.
>>>>>>>>>>
>>>>>>>>>> ...where "the logically impossible" = "correctly determine the halting status for EVERY
>>>>>>>>>> computation".
>>>>>>>>>>
>>>>>>>>>> Yes, that IS logically impossible, but we do not just take your word for that.  We demand
>>>>>>>>>> a mathematical proof of this fact! Fortunately there are a number of such proofs - e.g.
>>>>>>>>>> the Linz proof you used to claim to have refuted.
>>>>>>>>>>
>>>>>>>>>> That proof proceeds by showing that for ANY purported halt decider, one particular
>>>>>>>>>> computation we can see it definitely gets wrong will be the one that internally
>>>>>>>>>> incorporates the logic of the decider in order to basically "do the opposite of whatever
>>>>>>>>>> the decider returns" - just like you say!
>>>>>>>>>>
>>>>>>>>>> You now seem to recognise that H does indeed fail for that particular computation.  (It's
>>>>>>>>>> ok that you say "right, but it ONLY gets it wrong because it's logically impossible for it
>>>>>>>>>> to be correct for that input". Of course it's logically impossible: that's what the Linz
>>>>>>>>>> proof shows! The key point is that it DOES get it wrong, so fails the spec for a halt
>>>>>>>>>> decider.)
>>>>>>>>>>
>>>>>>>>>> Summary: yes, it is "logically impossible" for a program to correctly determine the
>>>>>>>>>> halting status of EVEY computation, since we know how to construct at least one such that
>>>>>>>>>> we can plainly see it gets wrong.
>>>>>>>>>>
>>>>>>>>>> Put differently, the halting problem is undecideable, just like everyone has been telling
>>>>>>>>>> you for 30(?) years.  It's taken you many years to get to this point, but finally you've
>>>>>>>>>> arrived! Well done.
>>>>>>>>>>
>>>>>>>>>> To cement your clean break with the past, you should now confirm that your previous claims
>>>>>>>>>> to have "refuted" the Linz (and similar) proofs were mistaken.  If you like, you can hedge
>>>>>>>>>> your wording, saying the Linz proof /is/ valid, but /only because/ it is logically
>>>>>>>>>> impossible for a Halt Decider to exist with all the properties such a decider would be
>>>>>>>>>> required to have. [viz correctly deciding EVERY computation including its own "nemesis"
>>>>>>>>>> computation.]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Mike.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We also know that it is logically impossible for a
>>>>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>>>>> one takes this to be a fundamental limit of computation.
>>>>>>>>
>>>>>>>> We could say that being unable to correctly draw a square circle DOES illustrate a limit of
>>>>>>>> computation.  The reason nobody says this, is because nobody ever considered the opposite
>>>>>>>> might be possible, so it's redundant.
>>>>>>>>
>>>>>>>> The situation is quite different with HP:
>>>>>>>>
>>>>>>>> The square circle program spec asks for a program that produces something which everyone can
>>>>>>>> see is mathematically and logically impossible - mathematically, there are NO SQUARE CIRCLES.
>>>>>>>>
>>>>>>>> The "HP program spec" asks for a program that can calculate the halting status for ANY
>>>>>>>> computation. There IS a mathematical function that maps computations (their representations)
>>>>>>>> to their halting status - so the interest here is whether this (EXISTING) function CAN BE
>>>>>>>> COMPUTED BY A TM.  The answer is NO, as the Linz proof (and what you've acknowledged above)
>>>>>>>> shows this is "logically impossible" - all such TMs get at least one input wrong.
>>>>>>>>
>>>>>>>> So the square circle problem says nothing interesting about computation.  The HP says
>>>>>>>> something interesting: the mathematical function that maps (representations of) computations
>>>>>>>> to their halting status IS NOT COMPUTABLE.  That's a fundamental limit on the power of TM
>>>>>>>> computation.
>>>>>>>>
>>>>>>>
>>>>>>> The unsatisfiability of the (a) definition of the halting
>>>>>>> problem spec only says that self-contradictory questions
>>>>>>> lack a correct answer because they are self-contradictory.
>>>>>>
>>>>>> No, it says (directly) that there is NO program satisfying the spec required for a Halt
>>>>>> Decider. That is saying, in other words, that the HP is undecidable.
>>>>>>
>>>>>> There's nothing in (a) about "self-contradictory questions" - that's just confusion in your
>>>>>> own mind.
>>>>>>
>>>>>>>
>>>>>>> A PhD computer science professor of many decades that
>>>>>>> has been published in the two most highly esteemed
>>>>>>> computer science journals perfectly agrees with me on
>>>>>>> this by direct email conversation and his own paper
>>>>>>> that says essentially the same thing.
>>>>>>>
>>>>>>
>>>>>> Yet another of your appeals to (absent) authority!  Perhaps your supporter might come here and
>>>>>> discuss the problem him/herself. Meanwhile we'll all assume this is like your other
>>>>>> authorities you've misquoted in the past, who clearly did not support your possition at all...
>>>>>>
>>>>>> Mike.
>>>>>>
>>>>>
>>>>> *Here are the verbatim words that he agreed to*
>>>>> Yet the gist of the issue with the halting problem seems to be
>>>>> that the whole notion of decision problem undecidability is
>>>>> inherently flawed in that it requires the logically impossible.
>>>>>
>>>>> Requiring a halt decider H to report on the behavior of the
>>>>> direct execution of input D when D has been defined to do
>>>>> the opposite of whatever Boolean value that H returns is
>>>>> simply an incorrect problem definition because it requires
>>>>> the logically impossible.
>>>>>
>>>>
>>>> Hehe - seems he's actually agreeing WITH WHAT I said above, which is not supporting your
>>>> position AT ALL.  This is exactly the same as when you conversed with Prof. Sipser and
>>>> completely misunderstood what he was saying!
>>
>> Reading more closely... If your "supporter" said "Yet the gist of the issue..." then /perhaps/ he
>> is agreeing with you.  Hard to say without the full context, which you never understand or present
>> correctly.
>>
>> If your "supporter" said "Requiring a halt decider H ..." then he is probably just agreeing with
>> me - but to me now, those sound more like /your/ words, misunderstanding "logically impossible".
>>
>> In either case it is meaningless, because your "supporter" IS NOT HERE participating in the
>> thread! So just present your case as YOU see it and forget your absent supporters!  :)
>>
>> <https://en.wikipedia.org/wiki/Argument_from_authority>
>>
>> Mike.
>>
>
> *He said that the halting problem definition <is> incorrect*
> There are no ways to misinterpret that.
>
> *He agreed with these verbatim words*
> The whole concept of decision problem undecidability is fatally flawed
> because it requires satisfying a logically impossible requirement.

On 10/23/2023 6:59 PM, Mike Terry wrote:
> On 24/10/2023 00:34, olcott wrote:
>> On 10/23/2023 5:55 PM, Mike Terry wrote:
>>> On 23/10/2023 23:20, olcott wrote:
>>>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>>>> On 23/10/2023 19:02, olcott wrote:
>>>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>>>> the halting problem
>>>>>>>>>>>
>>>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>>>
>>>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>>>> can do the logically impossible.
>>>>>>>>>
>>>>>>>>> ...where "the logically impossible" = "correctly determine the
>>>>>>>>> halting status for EVERY computation".
>>>>>>>>>
>>>>>>>>> Yes, that IS logically impossible, but we do not just take your
>>>>>>>>> word for that.  We demand a mathematical proof of this fact!
>>>>>>>>> Fortunately there are a number of such proofs - e.g. the Linz
>>>>>>>>> proof you used to claim to have refuted.
>>>>>>>>>
>>>>>>>>> That proof proceeds by showing that for ANY purported halt
>>>>>>>>> decider, one particular computation we can see it definitely
>>>>>>>>> gets wrong will be the one that internally incorporates the
>>>>>>>>> logic of the decider in order to basically "do the opposite of
>>>>>>>>> whatever the decider returns" - just like you say!
>>>>>>>>>
>>>>>>>>> You now seem to recognise that H does indeed fail for that
>>>>>>>>> particular computation.  (It's ok that you say "right, but it
>>>>>>>>> ONLY gets it wrong because it's logically impossible for it to
>>>>>>>>> be correct for that input". Of course it's logically
>>>>>>>>> impossible: that's what the Linz proof shows! The key point is
>>>>>>>>> that it DOES get it wrong, so fails the spec for a halt decider.)
>>>>>>>>>
>>>>>>>>> Summary: yes, it is "logically impossible" for a program to
>>>>>>>>> correctly determine the halting status of EVEY computation,
>>>>>>>>> since we know how to construct at least one such that we can
>>>>>>>>> plainly see it gets wrong.
>>>>>>>>>
>>>>>>>>> Put differently, the halting problem is undecideable, just like
>>>>>>>>> everyone has been telling you for 30(?) years.  It's taken you
>>>>>>>>> many years to get to this point, but finally you've arrived!
>>>>>>>>> Well done.
>>>>>>>>>
>>>>>>>>> To cement your clean break with the past, you should now
>>>>>>>>> confirm that your previous claims to have "refuted" the Linz
>>>>>>>>> (and similar) proofs were mistaken.  If you like, you can hedge
>>>>>>>>> your wording, saying the Linz proof /is/ valid, but /only
>>>>>>>>> because/ it is logically impossible for a Halt Decider to exist
>>>>>>>>> with all the properties such a decider would be required to
>>>>>>>>> have. [viz correctly deciding EVERY computation including its
>>>>>>>>> own "nemesis" computation.]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Mike.
>>>>>>>>>
>>>>>>>>
>>>>>>>> We also know that it is logically impossible for a
>>>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>>>> one takes this to be a fundamental limit of computation.
>>>>>>>
>>>>>>> We could say that being unable to correctly draw a square circle
>>>>>>> DOES illustrate a limit of computation.  The reason nobody says
>>>>>>> this, is because nobody ever considered the opposite might be
>>>>>>> possible, so it's redundant.
>>>>>>>
>>>>>>> The situation is quite different with HP:
>>>>>>>
>>>>>>> The square circle program spec asks for a program that produces
>>>>>>> something which everyone can see is mathematically and logically
>>>>>>> impossible - mathematically, there are NO SQUARE CIRCLES.
>>>>>>>
>>>>>>> The "HP program spec" asks for a program that can calculate the
>>>>>>> halting status for ANY computation. There IS a mathematical
>>>>>>> function that maps computations (their representations) to their
>>>>>>> halting status - so the interest here is whether this (EXISTING)
>>>>>>> function CAN BE COMPUTED BY A TM.  The answer is NO, as the Linz
>>>>>>> proof (and what you've acknowledged above) shows this is
>>>>>>> "logically impossible" - all such TMs get at least one input wrong.
>>>>>>>
>>>>>>> So the square circle problem says nothing interesting about
>>>>>>> computation.  The HP says something interesting: the mathematical
>>>>>>> function that maps (representations of) computations to their
>>>>>>> halting status IS NOT COMPUTABLE.  That's a fundamental limit on
>>>>>>> the power of TM computation.
>>>>>>>
>>>>>>
>>>>>> The unsatisfiability of the (a) definition of the halting
>>>>>> problem spec only says that self-contradictory questions
>>>>>> lack a correct answer because they are self-contradictory.
>>>>>
>>>>> No, it says (directly) that there is NO program satisfying the spec
>>>>> required for a Halt Decider. That is saying, in other words, that
>>>>> the HP is undecidable.
>>>>>
>>>>> There's nothing in (a) about "self-contradictory questions" -
>>>>> that's just confusion in your own mind.
>>>>>
>>>>>>
>>>>>> A PhD computer science professor of many decades that
>>>>>> has been published in the two most highly esteemed
>>>>>> computer science journals perfectly agrees with me on
>>>>>> this by direct email conversation and his own paper
>>>>>> that says essentially the same thing.
>>>>>>
>>>>>
>>>>> Yet another of your appeals to (absent) authority!  Perhaps your
>>>>> supporter might come here and discuss the problem him/herself.
>>>>> Meanwhile we'll all assume this is like your other authorities
>>>>> you've misquoted in the past, who clearly did not support your
>>>>> possition at all...
>>>>>
>>>>> Mike.
>>>>>
>>>>
>>>> *Here are the verbatim words that he agreed to*
>>>> Yet the gist of the issue with the halting problem seems to be
>>>> that the whole notion of decision problem undecidability is
>>>> inherently flawed in that it requires the logically impossible.
>>>>
>>>> Requiring a halt decider H to report on the behavior of the
>>>> direct execution of input D when D has been defined to do
>>>> the opposite of whatever Boolean value that H returns is
>>>> simply an incorrect problem definition because it requires
>>>> the logically impossible.
>>>>
>>>
>>> Hehe - seems he's actually agreeing WITH WHAT I said above, which is
>>> not supporting your position AT ALL.  This is exactly the same as
>>> when you conversed with Prof. Sipser and completely misunderstood
>>> what he was saying!
>
> Reading more closely... If your "supporter" said "Yet the gist of the
> issue..." then /perhaps/ he is agreeing with you.  Hard to say without
> the full context, which you never understand or present correctly.
>

On 10/23/2023 7:24 PM, Mike Terry wrote:
> On 24/10/2023 01:08, olcott wrote:
>> On 10/23/2023 6:59 PM, Mike Terry wrote:
>>> On 24/10/2023 00:34, olcott wrote:
>>>> On 10/23/2023 5:55 PM, Mike Terry wrote:
>>>>> On 23/10/2023 23:20, olcott wrote:
>>>>>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>>>>>> On 23/10/2023 19:02, olcott wrote:
>>>>>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>>>>>> the halting problem|
>>>>>>>>>>>>>
>>>>>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>>>>>
>>>>>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>>>>>> can do the logically impossible.
>>>>>>>>>>>
>>>>>>>>>>> ...where "the logically impossible" = "correctly determine
>>>>>>>>>>> the halting status for EVERY computation".
>>>>>>>>>>>
>>>>>>>>>>> Yes, that IS logically impossible, but we do not just take
>>>>>>>>>>> your word for that.  We demand a mathematical proof of this
>>>>>>>>>>> fact! Fortunately there are a number of such proofs - e.g.
>>>>>>>>>>> the Linz proof you used to claim to have refuted.
>>>>>>>>>>>
>>>>>>>>>>> That proof proceeds by showing that for ANY purported halt
>>>>>>>>>>> decider, one particular computation we can see it definitely
>>>>>>>>>>> gets wrong will be the one that internally incorporates the
>>>>>>>>>>> logic of the decider in order to basically "do the opposite
>>>>>>>>>>> of whatever the decider returns" - just like you say!
>>>>>>>>>>>
>>>>>>>>>>> You now seem to recognise that H does indeed fail for that
>>>>>>>>>>> particular computation.  (It's ok that you say "right, but it
>>>>>>>>>>> ONLY gets it wrong because it's logically impossible for it
>>>>>>>>>>> to be correct for that input". Of course it's logically
>>>>>>>>>>> impossible: that's what the Linz proof shows! The key point
>>>>>>>>>>> is that it DOES get it wrong, so fails the spec for a halt
>>>>>>>>>>> decider.)
>>>>>>>>>>>
>>>>>>>>>>> Summary: yes, it is "logically impossible" for a program to
>>>>>>>>>>> correctly determine the halting status of EVEY computation,
>>>>>>>>>>> since we know how to construct at least one such that we can
>>>>>>>>>>> plainly see it gets wrong.
>>>>>>>>>>>
>>>>>>>>>>> Put differently, the halting problem is undecideable, just
>>>>>>>>>>> like everyone has been telling you for 30(?) years.  It's
>>>>>>>>>>> taken you many years to get to this point, but finally you've
>>>>>>>>>>> arrived! Well done.
>>>>>>>>>>>
>>>>>>>>>>> To cement your clean break with the past, you should now
>>>>>>>>>>> confirm that your previous claims to have "refuted" the Linz
>>>>>>>>>>> (and similar) proofs were mistaken.  If you like, you can
>>>>>>>>>>> hedge your wording, saying the Linz proof /is/ valid, but
>>>>>>>>>>> /only because/ it is logically impossible for a Halt Decider
>>>>>>>>>>> to exist with all the properties such a decider would be
>>>>>>>>>>> required to have. [viz correctly deciding EVERY computation
>>>>>>>>>>> including its own "nemesis" computation.]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Mike.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> We also know that it is logically impossible for a
>>>>>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>>>>>> one takes this to be a fundamental limit of computation.
>>>>>>>>>
>>>>>>>>> We could say that being unable to correctly draw a square
>>>>>>>>> circle DOES illustrate a limit of computation.  The reason
>>>>>>>>> nobody says this, is because nobody ever considered the
>>>>>>>>> opposite might be possible, so it's redundant.
>>>>>>>>>
>>>>>>>>> The situation is quite different with HP:
>>>>>>>>>
>>>>>>>>> The square circle program spec asks for a program that produces
>>>>>>>>> something which everyone can see is mathematically and
>>>>>>>>> logically impossible - mathematically, there are NO SQUARE
>>>>>>>>> CIRCLES.
>>>>>>>>>
>>>>>>>>> The "HP program spec" asks for a program that can calculate the
>>>>>>>>> halting status for ANY computation. There IS a mathematical
>>>>>>>>> function that maps computations (their representations) to
>>>>>>>>> their halting status - so the interest here is whether this
>>>>>>>>> (EXISTING) function CAN BE COMPUTED BY A TM.  The answer is NO,
>>>>>>>>> as the Linz proof (and what you've acknowledged above) shows
>>>>>>>>> this is "logically impossible" - all such TMs get at least one
>>>>>>>>> input wrong.
>>>>>>>>>
>>>>>>>>> So the square circle problem says nothing interesting about
>>>>>>>>> computation.  The HP says something interesting: the
>>>>>>>>> mathematical function that maps (representations of)
>>>>>>>>> computations to their halting status IS NOT COMPUTABLE.  That's
>>>>>>>>> a fundamental limit on the power of TM computation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The unsatisfiability of the (a) definition of the halting
>>>>>>>> problem spec only says that self-contradictory questions
>>>>>>>> lack a correct answer because they are self-contradictory.
>>>>>>>
>>>>>>> No, it says (directly) that there is NO program satisfying the
>>>>>>> spec required for a Halt Decider. That is saying, in other words,
>>>>>>> that the HP is undecidable.
>>>>>>>
>>>>>>> There's nothing in (a) about "self-contradictory questions" -
>>>>>>> that's just confusion in your own mind.
>>>>>>>
>>>>>>>>
>>>>>>>> A PhD computer science professor of many decades that
>>>>>>>> has been published in the two most highly esteemed
>>>>>>>> computer science journals perfectly agrees with me on
>>>>>>>> this by direct email conversation and his own paper
>>>>>>>> that says essentially the same thing.
>>>>>>>>
>>>>>>>
>>>>>>> Yet another of your appeals to (absent) authority!  Perhaps your
>>>>>>> supporter might come here and discuss the problem him/herself.
>>>>>>> Meanwhile we'll all assume this is like your other authorities
>>>>>>> you've misquoted in the past, who clearly did not support your
>>>>>>> possition at all...
>>>>>>>
>>>>>>> Mike.
>>>>>>>
>>>>>>
>>>>>> *Here are the verbatim words that he agreed to*
>>>>>> Yet the gist of the issue with the halting problem seems to be
>>>>>> that the whole notion of decision problem undecidability is
>>>>>> inherently flawed in that it requires the logically impossible.
>>>>>>
>>>>>> Requiring a halt decider H to report on the behavior of the
>>>>>> direct execution of input D when D has been defined to do
>>>>>> the opposite of whatever Boolean value that H returns is
>>>>>> simply an incorrect problem definition because it requires
>>>>>> the logically impossible.
>>>>>>
>>>>>
>>>>> Hehe - seems he's actually agreeing WITH WHAT I said above, which
>>>>> is not supporting your position AT ALL.  This is exactly the same
>>>>> as when you conversed with Prof. Sipser and completely
>>>>> misunderstood what he was saying!
>>>
>>> Reading more closely... If your "supporter" said "Yet the gist of the
>>> issue..." then /perhaps/ he is agreeing with you.  Hard to say
>>> without the full context, which you never understand or present
>>> correctly.
>>>
>>> If your "supporter" said "Requiring a halt decider H ..." then he is
>>> probably just agreeing with me - but to me now, those sound more like
>>> /your/ words, misunderstanding "logically impossible".
>>>
>>> In either case it is meaningless, because your "supporter" IS NOT
>>> HERE participating in the thread! So just present your case as YOU
>>> see it and forget your absent supporters!  :)
>>>
>>> <https://en.wikipedia.org/wiki/Argument_from_authority>
>>>
>>> Mike.
>>>
>>
>> *He said that the halting problem definition <is> incorrect*
>> There are no ways to misinterpret that.
>>
>> *He agreed with these verbatim words*
>> The whole concept of decision problem undecidability is fatally flawed
>> because it requires satisfying a logically impossible requirement.
>
> So you claim, but who cares?  HE IS NOT PARTICIPATING IN THIS THREAD.
>
> And even if he agrees with you (which I doubt) IT DOES NOT MAGICALLY
> MAKE YOUR INCORRECT BELIEFS CORRECT!
>
> <https://en.wikipedia.org/wiki/Argument_from_authority>
>
> Mike.
>
>

On 24/10/2023 01:25, olcott wrote:
> On 10/23/2023 6:59 PM, Mike Terry wrote:
>> On 24/10/2023 00:34, olcott wrote:
>>> On 10/23/2023 5:55 PM, Mike Terry wrote:
>>>> On 23/10/2023 23:20, olcott wrote:
>>>>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>>>>> On 23/10/2023 19:02, olcott wrote:
>>>>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>>>>> the halting problem
>>>>>>>>>>>>
>>>>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>>>>
>>>>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>>>>> can do the logically impossible.
>>>>>>>>>>
>>>>>>>>>> ...where "the logically impossible" = "correctly determine the halting status for EVERY
>>>>>>>>>> computation".
>>>>>>>>>>
>>>>>>>>>> Yes, that IS logically impossible, but we do not just take your word for that.  We demand
>>>>>>>>>> a mathematical proof of this fact! Fortunately there are a number of such proofs - e.g.
>>>>>>>>>> the Linz proof you used to claim to have refuted.
>>>>>>>>>>
>>>>>>>>>> That proof proceeds by showing that for ANY purported halt decider, one particular
>>>>>>>>>> computation we can see it definitely gets wrong will be the one that internally
>>>>>>>>>> incorporates the logic of the decider in order to basically "do the opposite of whatever
>>>>>>>>>> the decider returns" - just like you say!
>>>>>>>>>>
>>>>>>>>>> You now seem to recognise that H does indeed fail for that particular computation.  (It's
>>>>>>>>>> ok that you say "right, but it ONLY gets it wrong because it's logically impossible for it
>>>>>>>>>> to be correct for that input". Of course it's logically impossible: that's what the Linz
>>>>>>>>>> proof shows! The key point is that it DOES get it wrong, so fails the spec for a halt
>>>>>>>>>> decider.)
>>>>>>>>>>
>>>>>>>>>> Summary: yes, it is "logically impossible" for a program to correctly determine the
>>>>>>>>>> halting status of EVEY computation, since we know how to construct at least one such that
>>>>>>>>>> we can plainly see it gets wrong.
>>>>>>>>>>
>>>>>>>>>> Put differently, the halting problem is undecideable, just like everyone has been telling
>>>>>>>>>> you for 30(?) years.  It's taken you many years to get to this point, but finally you've
>>>>>>>>>> arrived! Well done.
>>>>>>>>>>
>>>>>>>>>> To cement your clean break with the past, you should now confirm that your previous claims
>>>>>>>>>> to have "refuted" the Linz (and similar) proofs were mistaken.  If you like, you can hedge
>>>>>>>>>> your wording, saying the Linz proof /is/ valid, but /only because/ it is logically
>>>>>>>>>> impossible for a Halt Decider to exist with all the properties such a decider would be
>>>>>>>>>> required to have. [viz correctly deciding EVERY computation including its own "nemesis"
>>>>>>>>>> computation.]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Mike.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We also know that it is logically impossible for a
>>>>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>>>>> one takes this to be a fundamental limit of computation.
>>>>>>>>
>>>>>>>> We could say that being unable to correctly draw a square circle DOES illustrate a limit of
>>>>>>>> computation.  The reason nobody says this, is because nobody ever considered the opposite
>>>>>>>> might be possible, so it's redundant.
>>>>>>>>
>>>>>>>> The situation is quite different with HP:
>>>>>>>>
>>>>>>>> The square circle program spec asks for a program that produces something which everyone can
>>>>>>>> see is mathematically and logically impossible - mathematically, there are NO SQUARE CIRCLES.
>>>>>>>>
>>>>>>>> The "HP program spec" asks for a program that can calculate the halting status for ANY
>>>>>>>> computation. There IS a mathematical function that maps computations (their representations)
>>>>>>>> to their halting status - so the interest here is whether this (EXISTING) function CAN BE
>>>>>>>> COMPUTED BY A TM.  The answer is NO, as the Linz proof (and what you've acknowledged above)
>>>>>>>> shows this is "logically impossible" - all such TMs get at least one input wrong.
>>>>>>>>
>>>>>>>> So the square circle problem says nothing interesting about computation.  The HP says
>>>>>>>> something interesting: the mathematical function that maps (representations of) computations
>>>>>>>> to their halting status IS NOT COMPUTABLE.  That's a fundamental limit on the power of TM
>>>>>>>> computation.
>>>>>>>>
>>>>>>>
>>>>>>> The unsatisfiability of the (a) definition of the halting
>>>>>>> problem spec only says that self-contradictory questions
>>>>>>> lack a correct answer because they are self-contradictory.
>>>>>>
>>>>>> No, it says (directly) that there is NO program satisfying the spec required for a Halt
>>>>>> Decider. That is saying, in other words, that the HP is undecidable.
>>>>>>
>>>>>> There's nothing in (a) about "self-contradictory questions" - that's just confusion in your
>>>>>> own mind.
>>>>>>
>>>>>>>
>>>>>>> A PhD computer science professor of many decades that
>>>>>>> has been published in the two most highly esteemed
>>>>>>> computer science journals perfectly agrees with me on
>>>>>>> this by direct email conversation and his own paper
>>>>>>> that says essentially the same thing.
>>>>>>>
>>>>>>
>>>>>> Yet another of your appeals to (absent) authority!  Perhaps your supporter might come here and
>>>>>> discuss the problem him/herself. Meanwhile we'll all assume this is like your other
>>>>>> authorities you've misquoted in the past, who clearly did not support your possition at all...
>>>>>>
>>>>>> Mike.
>>>>>>
>>>>>
>>>>> *Here are the verbatim words that he agreed to*
>>>>> Yet the gist of the issue with the halting problem seems to be
>>>>> that the whole notion of decision problem undecidability is
>>>>> inherently flawed in that it requires the logically impossible.
>>>>>
>>>>> Requiring a halt decider H to report on the behavior of the
>>>>> direct execution of input D when D has been defined to do
>>>>> the opposite of whatever Boolean value that H returns is
>>>>> simply an incorrect problem definition because it requires
>>>>> the logically impossible.
>>>>>
>>>>
>>>> Hehe - seems he's actually agreeing WITH WHAT I said above, which is not supporting your
>>>> position AT ALL.  This is exactly the same as when you conversed with Prof. Sipser and
>>>> completely misunderstood what he was saying!
>>
>> Reading more closely... If your "supporter" said "Yet the gist of the issue..." then /perhaps/ he
>> is agreeing with you.  Hard to say without the full context, which you never understand or present
>> correctly.
>>
>
> *The gist of the whole issue is that we both*
> *agree that the halting problem is WRONG*

On 10/23/23 5:25 PM, olcott wrote:
> On 10/23/2023 6:59 PM, Mike Terry wrote:
>> On 24/10/2023 00:34, olcott wrote:
>>> On 10/23/2023 5:55 PM, Mike Terry wrote:
>>>> On 23/10/2023 23:20, olcott wrote:
>>>>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>>>>> On 23/10/2023 19:02, olcott wrote:
>>>>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>>>>> the halting problem
>>>>>>>>>>>>
>>>>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>>>>
>>>>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>>>>> can do the logically impossible.
>>>>>>>>>>
>>>>>>>>>> ...where "the logically impossible" = "correctly determine the
>>>>>>>>>> halting status for EVERY computation".
>>>>>>>>>>
>>>>>>>>>> Yes, that IS logically impossible, but we do not just take
>>>>>>>>>> your word for that.  We demand a mathematical proof of this
>>>>>>>>>> fact! Fortunately there are a number of such proofs - e.g. the
>>>>>>>>>> Linz proof you used to claim to have refuted.
>>>>>>>>>>
>>>>>>>>>> That proof proceeds by showing that for ANY purported halt
>>>>>>>>>> decider, one particular computation we can see it definitely
>>>>>>>>>> gets wrong will be the one that internally incorporates the
>>>>>>>>>> logic of the decider in order to basically "do the opposite of
>>>>>>>>>> whatever the decider returns" - just like you say!
>>>>>>>>>>
>>>>>>>>>> You now seem to recognise that H does indeed fail for that
>>>>>>>>>> particular computation.  (It's ok that you say "right, but it
>>>>>>>>>> ONLY gets it wrong because it's logically impossible for it to
>>>>>>>>>> be correct for that input". Of course it's logically
>>>>>>>>>> impossible: that's what the Linz proof shows! The key point is
>>>>>>>>>> that it DOES get it wrong, so fails the spec for a halt decider.)
>>>>>>>>>>
>>>>>>>>>> Summary: yes, it is "logically impossible" for a program to
>>>>>>>>>> correctly determine the halting status of EVEY computation,
>>>>>>>>>> since we know how to construct at least one such that we can
>>>>>>>>>> plainly see it gets wrong.
>>>>>>>>>>
>>>>>>>>>> Put differently, the halting problem is undecideable, just
>>>>>>>>>> like everyone has been telling you for 30(?) years.  It's
>>>>>>>>>> taken you many years to get to this point, but finally you've
>>>>>>>>>> arrived! Well done.
>>>>>>>>>>
>>>>>>>>>> To cement your clean break with the past, you should now
>>>>>>>>>> confirm that your previous claims to have "refuted" the Linz
>>>>>>>>>> (and similar) proofs were mistaken.  If you like, you can
>>>>>>>>>> hedge your wording, saying the Linz proof /is/ valid, but
>>>>>>>>>> /only because/ it is logically impossible for a Halt Decider
>>>>>>>>>> to exist with all the properties such a decider would be
>>>>>>>>>> required to have. [viz correctly deciding EVERY computation
>>>>>>>>>> including its own "nemesis" computation.]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Mike.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We also know that it is logically impossible for a
>>>>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>>>>> one takes this to be a fundamental limit of computation.
>>>>>>>>
>>>>>>>> We could say that being unable to correctly draw a square circle
>>>>>>>> DOES illustrate a limit of computation.  The reason nobody says
>>>>>>>> this, is because nobody ever considered the opposite might be
>>>>>>>> possible, so it's redundant.
>>>>>>>>
>>>>>>>> The situation is quite different with HP:
>>>>>>>>
>>>>>>>> The square circle program spec asks for a program that produces
>>>>>>>> something which everyone can see is mathematically and logically
>>>>>>>> impossible - mathematically, there are NO SQUARE CIRCLES.
>>>>>>>>
>>>>>>>> The "HP program spec" asks for a program that can calculate the
>>>>>>>> halting status for ANY computation. There IS a mathematical
>>>>>>>> function that maps computations (their representations) to their
>>>>>>>> halting status - so the interest here is whether this (EXISTING)
>>>>>>>> function CAN BE COMPUTED BY A TM.  The answer is NO, as the Linz
>>>>>>>> proof (and what you've acknowledged above) shows this is
>>>>>>>> "logically impossible" - all such TMs get at least one input wrong.
>>>>>>>>
>>>>>>>> So the square circle problem says nothing interesting about
>>>>>>>> computation.  The HP says something interesting: the
>>>>>>>> mathematical function that maps (representations of)
>>>>>>>> computations to their halting status IS NOT COMPUTABLE.  That's
>>>>>>>> a fundamental limit on the power of TM computation.
>>>>>>>>
>>>>>>>
>>>>>>> The unsatisfiability of the (a) definition of the halting
>>>>>>> problem spec only says that self-contradictory questions
>>>>>>> lack a correct answer because they are self-contradictory.
>>>>>>
>>>>>> No, it says (directly) that there is NO program satisfying the
>>>>>> spec required for a Halt Decider. That is saying, in other words,
>>>>>> that the HP is undecidable.
>>>>>>
>>>>>> There's nothing in (a) about "self-contradictory questions" -
>>>>>> that's just confusion in your own mind.
>>>>>>
>>>>>>>
>>>>>>> A PhD computer science professor of many decades that
>>>>>>> has been published in the two most highly esteemed
>>>>>>> computer science journals perfectly agrees with me on
>>>>>>> this by direct email conversation and his own paper
>>>>>>> that says essentially the same thing.
>>>>>>>
>>>>>>
>>>>>> Yet another of your appeals to (absent) authority!  Perhaps your
>>>>>> supporter might come here and discuss the problem him/herself.
>>>>>> Meanwhile we'll all assume this is like your other authorities
>>>>>> you've misquoted in the past, who clearly did not support your
>>>>>> possition at all...
>>>>>>
>>>>>> Mike.
>>>>>>
>>>>>
>>>>> *Here are the verbatim words that he agreed to*
>>>>> Yet the gist of the issue with the halting problem seems to be
>>>>> that the whole notion of decision problem undecidability is
>>>>> inherently flawed in that it requires the logically impossible.
>>>>>
>>>>> Requiring a halt decider H to report on the behavior of the
>>>>> direct execution of input D when D has been defined to do
>>>>> the opposite of whatever Boolean value that H returns is
>>>>> simply an incorrect problem definition because it requires
>>>>> the logically impossible.
>>>>>
>>>>
>>>> Hehe - seems he's actually agreeing WITH WHAT I said above, which is
>>>> not supporting your position AT ALL.  This is exactly the same as
>>>> when you conversed with Prof. Sipser and completely misunderstood
>>>> what he was saying!
>>
>> Reading more closely... If your "supporter" said "Yet the gist of the
>> issue..." then /perhaps/ he is agreeing with you.  Hard to say without
>> the full context, which you never understand or present correctly.
>>
>
> *The gist of the whole issue is that we both*
> *agree that the halting problem is WRONG*

On 10/23/23 4:52 PM, olcott wrote:
> On 10/23/2023 5:55 PM, Mike Terry wrote:
>> On 23/10/2023 23:20, olcott wrote:
>>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>>> On 23/10/2023 19:02, olcott wrote:
>>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>>> the halting problem
>>>>>>>>>>
>>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>>
>>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>>> can do the logically impossible.
>>>>>>>>
>>>>>>>> ...where "the logically impossible" = "correctly determine the
>>>>>>>> halting status for EVERY computation".
>>>>>>>>
>>>>>>>> Yes, that IS logically impossible, but we do not just take your
>>>>>>>> word for that.  We demand a mathematical proof of this fact!
>>>>>>>> Fortunately there are a number of such proofs - e.g. the Linz
>>>>>>>> proof you used to claim to have refuted.
>>>>>>>>
>>>>>>>> That proof proceeds by showing that for ANY purported halt
>>>>>>>> decider, one particular computation we can see it definitely
>>>>>>>> gets wrong will be the one that internally incorporates the
>>>>>>>> logic of the decider in order to basically "do the opposite of
>>>>>>>> whatever the decider returns" - just like you say!
>>>>>>>>
>>>>>>>> You now seem to recognise that H does indeed fail for that
>>>>>>>> particular computation.  (It's ok that you say "right, but it
>>>>>>>> ONLY gets it wrong because it's logically impossible for it to
>>>>>>>> be correct for that input". Of course it's logically impossible:
>>>>>>>> that's what the Linz proof shows! The key point is that it DOES
>>>>>>>> get it wrong, so fails the spec for a halt decider.)
>>>>>>>>
>>>>>>>> Summary: yes, it is "logically impossible" for a program to
>>>>>>>> correctly determine the halting status of EVEY computation,
>>>>>>>> since we know how to construct at least one such that we can
>>>>>>>> plainly see it gets wrong.
>>>>>>>>
>>>>>>>> Put differently, the halting problem is undecideable, just like
>>>>>>>> everyone has been telling you for 30(?) years.  It's taken you
>>>>>>>> many years to get to this point, but finally you've arrived!
>>>>>>>> Well done.
>>>>>>>>
>>>>>>>> To cement your clean break with the past, you should now confirm
>>>>>>>> that your previous claims to have "refuted" the Linz (and
>>>>>>>> similar) proofs were mistaken.  If you like, you can hedge your
>>>>>>>> wording, saying the Linz proof /is/ valid, but /only because/ it
>>>>>>>> is logically impossible for a Halt Decider to exist with all the
>>>>>>>> properties such a decider would be required to have. [viz
>>>>>>>> correctly deciding EVERY computation including its own "nemesis"
>>>>>>>> computation.]
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Mike.
>>>>>>>>
>>>>>>>
>>>>>>> We also know that it is logically impossible for a
>>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>>> one takes this to be a fundamental limit of computation.
>>>>>>
>>>>>> We could say that being unable to correctly draw a square circle
>>>>>> DOES illustrate a limit of computation.  The reason nobody says
>>>>>> this, is because nobody ever considered the opposite might be
>>>>>> possible, so it's redundant.
>>>>>>
>>>>>> The situation is quite different with HP:
>>>>>>
>>>>>> The square circle program spec asks for a program that produces
>>>>>> something which everyone can see is mathematically and logically
>>>>>> impossible - mathematically, there are NO SQUARE CIRCLES.
>>>>>>
>>>>>> The "HP program spec" asks for a program that can calculate the
>>>>>> halting status for ANY computation. There IS a mathematical
>>>>>> function that maps computations (their representations) to their
>>>>>> halting status - so the interest here is whether this (EXISTING)
>>>>>> function CAN BE COMPUTED BY A TM.  The answer is NO, as the Linz
>>>>>> proof (and what you've acknowledged above) shows this is
>>>>>> "logically impossible" - all such TMs get at least one input wrong.
>>>>>>
>>>>>> So the square circle problem says nothing interesting about
>>>>>> computation.  The HP says something interesting: the mathematical
>>>>>> function that maps (representations of) computations to their
>>>>>> halting status IS NOT COMPUTABLE.  That's a fundamental limit on
>>>>>> the power of TM computation.
>>>>>>
>>>>>
>>>>> The unsatisfiability of the (a) definition of the halting
>>>>> problem spec only says that self-contradictory questions
>>>>> lack a correct answer because they are self-contradictory.
>>>>
>>>> No, it says (directly) that there is NO program satisfying the spec
>>>> required for a Halt Decider. That is saying, in other words, that
>>>> the HP is undecidable.
>>>>
>>>> There's nothing in (a) about "self-contradictory questions" - that's
>>>> just confusion in your own mind.
>>>>
>>>>>
>>>>> A PhD computer science professor of many decades that
>>>>> has been published in the two most highly esteemed
>>>>> computer science journals perfectly agrees with me on
>>>>> this by direct email conversation and his own paper
>>>>> that says essentially the same thing.
>>>>>
>>>>
>>>> Yet another of your appeals to (absent) authority!  Perhaps your
>>>> supporter might come here and discuss the problem him/herself.
>>>> Meanwhile we'll all assume this is like your other authorities
>>>> you've misquoted in the past, who clearly did not support your
>>>> possition at all...
>>>>
>>>> Mike.
>>>>
>>>
>>> *Here are the verbatim words that he agreed to*
>>> Yet the gist of the issue with the halting problem seems to be
>>> that the whole notion of decision problem undecidability is
>>> inherently flawed in that it requires the logically impossible.
>>>
>>> Requiring a halt decider H to report on the behavior of the
>>> direct execution of input D when D has been defined to do
>>> the opposite of whatever Boolean value that H returns is
>>> simply an incorrect problem definition because it requires
>>> the logically impossible.
>>>
>>
>> Hehe - seems he's actually agreeing WITH WHAT I said above, which is
>> not supporting your position AT ALL.  This is exactly the same as when
>> you conversed with Prof. Sipser and completely misunderstood what he
>> was saying!
>>
>
> Requiring a halt decider H to report on the behavior of the
> direct execution of input D when D has been defined to do
> the opposite of whatever Boolean value that H returns is
> *SIMPLY AN INCORRECT PROBLEM DEFINITION* because it requires
> the logically impossible.

On 24/10/2023 01:31, olcott wrote:
> On 10/23/2023 7:24 PM, Mike Terry wrote:
>> On 24/10/2023 01:08, olcott wrote:
>>> On 10/23/2023 6:59 PM, Mike Terry wrote:
>>>> On 24/10/2023 00:34, olcott wrote:
>>>>> On 10/23/2023 5:55 PM, Mike Terry wrote:
>>>>>> On 23/10/2023 23:20, olcott wrote:
>>>>>>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>>>>>>> On 23/10/2023 19:02, olcott wrote:
>>>>>>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>>>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>>>>>>> the halting problem|
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>>>>>>> can do the logically impossible.
>>>>>>>>>>>>
>>>>>>>>>>>> ...where "the logically impossible" = "correctly determine the halting status for EVERY
>>>>>>>>>>>> computation".
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, that IS logically impossible, but we do not just take your word for that.  We
>>>>>>>>>>>> demand a mathematical proof of this fact! Fortunately there are a number of such proofs
>>>>>>>>>>>> - e.g. the Linz proof you used to claim to have refuted.
>>>>>>>>>>>>
>>>>>>>>>>>> That proof proceeds by showing that for ANY purported halt decider, one particular
>>>>>>>>>>>> computation we can see it definitely gets wrong will be the one that internally
>>>>>>>>>>>> incorporates the logic of the decider in order to basically "do the opposite of whatever
>>>>>>>>>>>> the decider returns" - just like you say!
>>>>>>>>>>>>
>>>>>>>>>>>> You now seem to recognise that H does indeed fail for that particular computation.
>>>>>>>>>>>> (It's ok that you say "right, but it ONLY gets it wrong because it's logically
>>>>>>>>>>>> impossible for it to be correct for that input". Of course it's logically impossible:
>>>>>>>>>>>> that's what the Linz proof shows! The key point is that it DOES get it wrong, so fails
>>>>>>>>>>>> the spec for a halt decider.)
>>>>>>>>>>>>
>>>>>>>>>>>> Summary: yes, it is "logically impossible" for a program to correctly determine the
>>>>>>>>>>>> halting status of EVEY computation, since we know how to construct at least one such
>>>>>>>>>>>> that we can plainly see it gets wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> Put differently, the halting problem is undecideable, just like everyone has been
>>>>>>>>>>>> telling you for 30(?) years.  It's taken you many years to get to this point, but
>>>>>>>>>>>> finally you've arrived! Well done.
>>>>>>>>>>>>
>>>>>>>>>>>> To cement your clean break with the past, you should now confirm that your previous
>>>>>>>>>>>> claims to have "refuted" the Linz (and similar) proofs were mistaken.  If you like, you
>>>>>>>>>>>> can hedge your wording, saying the Linz proof /is/ valid, but /only because/ it is
>>>>>>>>>>>> logically impossible for a Halt Decider to exist with all the properties such a decider
>>>>>>>>>>>> would be required to have. [viz correctly deciding EVERY computation including its own
>>>>>>>>>>>> "nemesis" computation.]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Mike.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> We also know that it is logically impossible for a
>>>>>>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>>>>>>> one takes this to be a fundamental limit of computation.
>>>>>>>>>>
>>>>>>>>>> We could say that being unable to correctly draw a square circle DOES illustrate a limit
>>>>>>>>>> of computation.  The reason nobody says this, is because nobody ever considered the
>>>>>>>>>> opposite might be possible, so it's redundant.
>>>>>>>>>>
>>>>>>>>>> The situation is quite different with HP:
>>>>>>>>>>
>>>>>>>>>> The square circle program spec asks for a program that produces something which everyone
>>>>>>>>>> can see is mathematically and logically impossible - mathematically, there are NO SQUARE
>>>>>>>>>> CIRCLES.
>>>>>>>>>>
>>>>>>>>>> The "HP program spec" asks for a program that can calculate the halting status for ANY
>>>>>>>>>> computation. There IS a mathematical function that maps computations (their
>>>>>>>>>> representations) to their halting status - so the interest here is whether this (EXISTING)
>>>>>>>>>> function CAN BE COMPUTED BY A TM.  The answer is NO, as the Linz proof (and what you've
>>>>>>>>>> acknowledged above) shows this is "logically impossible" - all such TMs get at least one
>>>>>>>>>> input wrong.
>>>>>>>>>>
>>>>>>>>>> So the square circle problem says nothing interesting about computation.  The HP says
>>>>>>>>>> something interesting: the mathematical function that maps (representations of)
>>>>>>>>>> computations to their halting status IS NOT COMPUTABLE.  That's a fundamental limit on the
>>>>>>>>>> power of TM computation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The unsatisfiability of the (a) definition of the halting
>>>>>>>>> problem spec only says that self-contradictory questions
>>>>>>>>> lack a correct answer because they are self-contradictory.
>>>>>>>>
>>>>>>>> No, it says (directly) that there is NO program satisfying the spec required for a Halt
>>>>>>>> Decider. That is saying, in other words, that the HP is undecidable.
>>>>>>>>
>>>>>>>> There's nothing in (a) about "self-contradictory questions" - that's just confusion in your
>>>>>>>> own mind.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> A PhD computer science professor of many decades that
>>>>>>>>> has been published in the two most highly esteemed
>>>>>>>>> computer science journals perfectly agrees with me on
>>>>>>>>> this by direct email conversation and his own paper
>>>>>>>>> that says essentially the same thing.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yet another of your appeals to (absent) authority!  Perhaps your supporter might come here
>>>>>>>> and discuss the problem him/herself. Meanwhile we'll all assume this is like your other
>>>>>>>> authorities you've misquoted in the past, who clearly did not support your possition at all...
>>>>>>>>
>>>>>>>> Mike.
>>>>>>>>
>>>>>>>
>>>>>>> *Here are the verbatim words that he agreed to*
>>>>>>> Yet the gist of the issue with the halting problem seems to be
>>>>>>> that the whole notion of decision problem undecidability is
>>>>>>> inherently flawed in that it requires the logically impossible.
>>>>>>>
>>>>>>> Requiring a halt decider H to report on the behavior of the
>>>>>>> direct execution of input D when D has been defined to do
>>>>>>> the opposite of whatever Boolean value that H returns is
>>>>>>> simply an incorrect problem definition because it requires
>>>>>>> the logically impossible.
>>>>>>>
>>>>>>
>>>>>> Hehe - seems he's actually agreeing WITH WHAT I said above, which is not supporting your
>>>>>> position AT ALL.  This is exactly the same as when you conversed with Prof. Sipser and
>>>>>> completely misunderstood what he was saying!
>>>>
>>>> Reading more closely... If your "supporter" said "Yet the gist of the issue..." then /perhaps/
>>>> he is agreeing with you.  Hard to say without the full context, which you never understand or
>>>> present correctly.
>>>>
>>>> If your "supporter" said "Requiring a halt decider H ..." then he is probably just agreeing with
>>>> me - but to me now, those sound more like /your/ words, misunderstanding "logically impossible".
>>>>
>>>> In either case it is meaningless, because your "supporter" IS NOT HERE participating in the
>>>> thread! So just present your case as YOU see it and forget your absent supporters!  :)
>>>>
>>>> <https://en.wikipedia.org/wiki/Argument_from_authority>
>>>>
>>>> Mike.
>>>>
>>>
>>> *He said that the halting problem definition <is> incorrect*
>>> There are no ways to misinterpret that.
>>>
>>> *He agreed with these verbatim words*
>>> The whole concept of decision problem undecidability is fatally flawed
>>> because it requires satisfying a logically impossible requirement.
>>
>> So you claim, but who cares?  HE IS NOT PARTICIPATING IN THIS THREAD.
>>
>> And even if he agrees with you (which I doubt) IT DOES NOT MAGICALLY MAKE YOUR INCORRECT BELIEFS
>> CORRECT!
>>
>> <https://en.wikipedia.org/wiki/Argument_from_authority>
>>
>> Mike.
>>
>>
>
> It provides significant evidence that I am not simply
> a crackpot that can be correctly dismissed out of hand.

On 10/23/2023 7:46 PM, Mike Terry wrote:
> On 24/10/2023 01:25, olcott wrote:
>> On 10/23/2023 6:59 PM, Mike Terry wrote:
>>> On 24/10/2023 00:34, olcott wrote:
>>>> On 10/23/2023 5:55 PM, Mike Terry wrote:
>>>>> On 23/10/2023 23:20, olcott wrote:
>>>>>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>>>>>> On 23/10/2023 19:02, olcott wrote:
>>>>>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>>>>>> the halting problem
>>>>>>>>>>>>>
>>>>>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>>>>>
>>>>>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>>>>>> can do the logically impossible.
>>>>>>>>>>>
>>>>>>>>>>> ...where "the logically impossible" = "correctly determine
>>>>>>>>>>> the halting status for EVERY computation".
>>>>>>>>>>>
>>>>>>>>>>> Yes, that IS logically impossible, but we do not just take
>>>>>>>>>>> your word for that.  We demand a mathematical proof of this
>>>>>>>>>>> fact! Fortunately there are a number of such proofs - e.g.
>>>>>>>>>>> the Linz proof you used to claim to have refuted.
>>>>>>>>>>>
>>>>>>>>>>> That proof proceeds by showing that for ANY purported halt
>>>>>>>>>>> decider, one particular computation we can see it definitely
>>>>>>>>>>> gets wrong will be the one that internally incorporates the
>>>>>>>>>>> logic of the decider in order to basically "do the opposite
>>>>>>>>>>> of whatever the decider returns" - just like you say!
>>>>>>>>>>>
>>>>>>>>>>> You now seem to recognise that H does indeed fail for that
>>>>>>>>>>> particular computation.  (It's ok that you say "right, but it
>>>>>>>>>>> ONLY gets it wrong because it's logically impossible for it
>>>>>>>>>>> to be correct for that input". Of course it's logically
>>>>>>>>>>> impossible: that's what the Linz proof shows! The key point
>>>>>>>>>>> is that it DOES get it wrong, so fails the spec for a halt
>>>>>>>>>>> decider.)
>>>>>>>>>>>
>>>>>>>>>>> Summary: yes, it is "logically impossible" for a program to
>>>>>>>>>>> correctly determine the halting status of EVEY computation,
>>>>>>>>>>> since we know how to construct at least one such that we can
>>>>>>>>>>> plainly see it gets wrong.
>>>>>>>>>>>
>>>>>>>>>>> Put differently, the halting problem is undecideable, just
>>>>>>>>>>> like everyone has been telling you for 30(?) years.  It's
>>>>>>>>>>> taken you many years to get to this point, but finally you've
>>>>>>>>>>> arrived! Well done.
>>>>>>>>>>>
>>>>>>>>>>> To cement your clean break with the past, you should now
>>>>>>>>>>> confirm that your previous claims to have "refuted" the Linz
>>>>>>>>>>> (and similar) proofs were mistaken.  If you like, you can
>>>>>>>>>>> hedge your wording, saying the Linz proof /is/ valid, but
>>>>>>>>>>> /only because/ it is logically impossible for a Halt Decider
>>>>>>>>>>> to exist with all the properties such a decider would be
>>>>>>>>>>> required to have. [viz correctly deciding EVERY computation
>>>>>>>>>>> including its own "nemesis" computation.]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Mike.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> We also know that it is logically impossible for a
>>>>>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>>>>>> one takes this to be a fundamental limit of computation.
>>>>>>>>>
>>>>>>>>> We could say that being unable to correctly draw a square
>>>>>>>>> circle DOES illustrate a limit of computation.  The reason
>>>>>>>>> nobody says this, is because nobody ever considered the
>>>>>>>>> opposite might be possible, so it's redundant.
>>>>>>>>>
>>>>>>>>> The situation is quite different with HP:
>>>>>>>>>
>>>>>>>>> The square circle program spec asks for a program that produces
>>>>>>>>> something which everyone can see is mathematically and
>>>>>>>>> logically impossible - mathematically, there are NO SQUARE
>>>>>>>>> CIRCLES.
>>>>>>>>>
>>>>>>>>> The "HP program spec" asks for a program that can calculate the
>>>>>>>>> halting status for ANY computation. There IS a mathematical
>>>>>>>>> function that maps computations (their representations) to
>>>>>>>>> their halting status - so the interest here is whether this
>>>>>>>>> (EXISTING) function CAN BE COMPUTED BY A TM.  The answer is NO,
>>>>>>>>> as the Linz proof (and what you've acknowledged above) shows
>>>>>>>>> this is "logically impossible" - all such TMs get at least one
>>>>>>>>> input wrong.
>>>>>>>>>
>>>>>>>>> So the square circle problem says nothing interesting about
>>>>>>>>> computation.  The HP says something interesting: the
>>>>>>>>> mathematical function that maps (representations of)
>>>>>>>>> computations to their halting status IS NOT COMPUTABLE.  That's
>>>>>>>>> a fundamental limit on the power of TM computation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The unsatisfiability of the (a) definition of the halting
>>>>>>>> problem spec only says that self-contradictory questions
>>>>>>>> lack a correct answer because they are self-contradictory.
>>>>>>>
>>>>>>> No, it says (directly) that there is NO program satisfying the
>>>>>>> spec required for a Halt Decider. That is saying, in other words,
>>>>>>> that the HP is undecidable.
>>>>>>>
>>>>>>> There's nothing in (a) about "self-contradictory questions" -
>>>>>>> that's just confusion in your own mind.
>>>>>>>
>>>>>>>>
>>>>>>>> A PhD computer science professor of many decades that
>>>>>>>> has been published in the two most highly esteemed
>>>>>>>> computer science journals perfectly agrees with me on
>>>>>>>> this by direct email conversation and his own paper
>>>>>>>> that says essentially the same thing.
>>>>>>>>
>>>>>>>
>>>>>>> Yet another of your appeals to (absent) authority!  Perhaps your
>>>>>>> supporter might come here and discuss the problem him/herself.
>>>>>>> Meanwhile we'll all assume this is like your other authorities
>>>>>>> you've misquoted in the past, who clearly did not support your
>>>>>>> possition at all...
>>>>>>>
>>>>>>> Mike.
>>>>>>>
>>>>>>
>>>>>> *Here are the verbatim words that he agreed to*
>>>>>> Yet the gist of the issue with the halting problem seems to be
>>>>>> that the whole notion of decision problem undecidability is
>>>>>> inherently flawed in that it requires the logically impossible.
>>>>>>
>>>>>> Requiring a halt decider H to report on the behavior of the
>>>>>> direct execution of input D when D has been defined to do
>>>>>> the opposite of whatever Boolean value that H returns is
>>>>>> simply an incorrect problem definition because it requires
>>>>>> the logically impossible.
>>>>>>
>>>>>
>>>>> Hehe - seems he's actually agreeing WITH WHAT I said above, which
>>>>> is not supporting your position AT ALL.  This is exactly the same
>>>>> as when you conversed with Prof. Sipser and completely
>>>>> misunderstood what he was saying!
>>>
>>> Reading more closely... If your "supporter" said "Yet the gist of the
>>> issue..." then /perhaps/ he is agreeing with you.  Hard to say
>>> without the full context, which you never understand or present
>>> correctly.
>>>
>>
>> *The gist of the whole issue is that we both*
>> *agree that the halting problem is WRONG*
>
> So you claim, but I'll say it again:  WHO CARES?  Your alleged supporter
> is not participating in this thread.
>
> Mike.

On 10/23/2023 7:51 PM, Mike Terry wrote:
> On 24/10/2023 01:31, olcott wrote:
>> On 10/23/2023 7:24 PM, Mike Terry wrote:
>>> On 24/10/2023 01:08, olcott wrote:
>>>> On 10/23/2023 6:59 PM, Mike Terry wrote:
>>>>> On 24/10/2023 00:34, olcott wrote:
>>>>>> On 10/23/2023 5:55 PM, Mike Terry wrote:
>>>>>>> On 23/10/2023 23:20, olcott wrote:
>>>>>>>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>>>>>>>> On 23/10/2023 19:02, olcott wrote:
>>>>>>>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>>>>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>>>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>>>>>>>> the halting problem|
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>>>>>>>> can do the logically impossible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ...where "the logically impossible" = "correctly determine
>>>>>>>>>>>>> the halting status for EVERY computation".
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, that IS logically impossible, but we do not just take
>>>>>>>>>>>>> your word for that.  We demand a mathematical proof of this
>>>>>>>>>>>>> fact! Fortunately there are a number of such proofs - e.g.
>>>>>>>>>>>>> the Linz proof you used to claim to have refuted.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That proof proceeds by showing that for ANY purported halt
>>>>>>>>>>>>> decider, one particular computation we can see it
>>>>>>>>>>>>> definitely gets wrong will be the one that internally
>>>>>>>>>>>>> incorporates the logic of the decider in order to basically
>>>>>>>>>>>>> "do the opposite of whatever the decider returns" - just
>>>>>>>>>>>>> like you say!
>>>>>>>>>>>>>
>>>>>>>>>>>>> You now seem to recognise that H does indeed fail for that
>>>>>>>>>>>>> particular computation. (It's ok that you say "right, but
>>>>>>>>>>>>> it ONLY gets it wrong because it's logically impossible for
>>>>>>>>>>>>> it to be correct for that input". Of course it's logically
>>>>>>>>>>>>> impossible: that's what the Linz proof shows! The key point
>>>>>>>>>>>>> is that it DOES get it wrong, so fails the spec for a halt
>>>>>>>>>>>>> decider.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Summary: yes, it is "logically impossible" for a program to
>>>>>>>>>>>>> correctly determine the halting status of EVEY computation,
>>>>>>>>>>>>> since we know how to construct at least one such that we
>>>>>>>>>>>>> can plainly see it gets wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Put differently, the halting problem is undecideable, just
>>>>>>>>>>>>> like everyone has been telling you for 30(?) years.  It's
>>>>>>>>>>>>> taken you many years to get to this point, but finally
>>>>>>>>>>>>> you've arrived! Well done.
>>>>>>>>>>>>>
>>>>>>>>>>>>> To cement your clean break with the past, you should now
>>>>>>>>>>>>> confirm that your previous claims to have "refuted" the
>>>>>>>>>>>>> Linz (and similar) proofs were mistaken.  If you like, you
>>>>>>>>>>>>> can hedge your wording, saying the Linz proof /is/ valid,
>>>>>>>>>>>>> but /only because/ it is logically impossible for a Halt
>>>>>>>>>>>>> Decider to exist with all the properties such a decider
>>>>>>>>>>>>> would be required to have. [viz correctly deciding EVERY
>>>>>>>>>>>>> computation including its own "nemesis" computation.]
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Mike.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> We also know that it is logically impossible for a
>>>>>>>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>>>>>>>> one takes this to be a fundamental limit of computation.
>>>>>>>>>>>
>>>>>>>>>>> We could say that being unable to correctly draw a square
>>>>>>>>>>> circle DOES illustrate a limit of computation.  The reason
>>>>>>>>>>> nobody says this, is because nobody ever considered the
>>>>>>>>>>> opposite might be possible, so it's redundant.
>>>>>>>>>>>
>>>>>>>>>>> The situation is quite different with HP:
>>>>>>>>>>>
>>>>>>>>>>> The square circle program spec asks for a program that
>>>>>>>>>>> produces something which everyone can see is mathematically
>>>>>>>>>>> and logically impossible - mathematically, there are NO
>>>>>>>>>>> SQUARE CIRCLES.
>>>>>>>>>>>
>>>>>>>>>>> The "HP program spec" asks for a program that can calculate
>>>>>>>>>>> the halting status for ANY computation. There IS a
>>>>>>>>>>> mathematical function that maps computations (their
>>>>>>>>>>> representations) to their halting status - so the interest
>>>>>>>>>>> here is whether this (EXISTING) function CAN BE COMPUTED BY A
>>>>>>>>>>> TM.  The answer is NO, as the Linz proof (and what you've
>>>>>>>>>>> acknowledged above) shows this is "logically impossible" -
>>>>>>>>>>> all such TMs get at least one input wrong.
>>>>>>>>>>>
>>>>>>>>>>> So the square circle problem says nothing interesting about
>>>>>>>>>>> computation.  The HP says something interesting: the
>>>>>>>>>>> mathematical function that maps (representations of)
>>>>>>>>>>> computations to their halting status IS NOT COMPUTABLE.
>>>>>>>>>>> That's a fundamental limit on the power of TM computation.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The unsatisfiability of the (a) definition of the halting
>>>>>>>>>> problem spec only says that self-contradictory questions
>>>>>>>>>> lack a correct answer because they are self-contradictory.
>>>>>>>>>
>>>>>>>>> No, it says (directly) that there is NO program satisfying the
>>>>>>>>> spec required for a Halt Decider. That is saying, in other
>>>>>>>>> words, that the HP is undecidable.
>>>>>>>>>
>>>>>>>>> There's nothing in (a) about "self-contradictory questions" -
>>>>>>>>> that's just confusion in your own mind.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> A PhD computer science professor of many decades that
>>>>>>>>>> has been published in the two most highly esteemed
>>>>>>>>>> computer science journals perfectly agrees with me on
>>>>>>>>>> this by direct email conversation and his own paper
>>>>>>>>>> that says essentially the same thing.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yet another of your appeals to (absent) authority!  Perhaps
>>>>>>>>> your supporter might come here and discuss the problem
>>>>>>>>> him/herself. Meanwhile we'll all assume this is like your other
>>>>>>>>> authorities you've misquoted in the past, who clearly did not
>>>>>>>>> support your possition at all...
>>>>>>>>>
>>>>>>>>> Mike.
>>>>>>>>>
>>>>>>>>
>>>>>>>> *Here are the verbatim words that he agreed to*
>>>>>>>> Yet the gist of the issue with the halting problem seems to be
>>>>>>>> that the whole notion of decision problem undecidability is
>>>>>>>> inherently flawed in that it requires the logically impossible.
>>>>>>>>
>>>>>>>> Requiring a halt decider H to report on the behavior of the
>>>>>>>> direct execution of input D when D has been defined to do
>>>>>>>> the opposite of whatever Boolean value that H returns is
>>>>>>>> simply an incorrect problem definition because it requires
>>>>>>>> the logically impossible.
>>>>>>>>
>>>>>>>
>>>>>>> Hehe - seems he's actually agreeing WITH WHAT I said above, which
>>>>>>> is not supporting your position AT ALL.  This is exactly the same
>>>>>>> as when you conversed with Prof. Sipser and completely
>>>>>>> misunderstood what he was saying!
>>>>>
>>>>> Reading more closely... If your "supporter" said "Yet the gist of
>>>>> the issue..." then /perhaps/ he is agreeing with you.  Hard to say
>>>>> without the full context, which you never understand or present
>>>>> correctly.
>>>>>
>>>>> If your "supporter" said "Requiring a halt decider H ..." then he
>>>>> is probably just agreeing with me - but to me now, those sound more
>>>>> like /your/ words, misunderstanding "logically impossible".
>>>>>
>>>>> In either case it is meaningless, because your "supporter" IS NOT
>>>>> HERE participating in the thread! So just present your case as YOU
>>>>> see it and forget your absent supporters!  :)
>>>>>
>>>>> <https://en.wikipedia.org/wiki/Argument_from_authority>
>>>>>
>>>>> Mike.
>>>>>
>>>>
>>>> *He said that the halting problem definition <is> incorrect*
>>>> There are no ways to misinterpret that.
>>>>
>>>> *He agreed with these verbatim words*
>>>> The whole concept of decision problem undecidability is fatally flawed
>>>> because it requires satisfying a logically impossible requirement.
>>>
>>> So you claim, but who cares?  HE IS NOT PARTICIPATING IN THIS THREAD.
>>>
>>> And even if he agrees with you (which I doubt) IT DOES NOT MAGICALLY
>>> MAKE YOUR INCORRECT BELIEFS CORRECT!
>>>
>>> <https://en.wikipedia.org/wiki/Argument_from_authority>
>>>
>>> Mike.
>>>
>>>
>>
>> It provides significant evidence that I am not simply
>> a crackpot that can be correctly dismissed out of hand.
>
> It provides NO such evidence, because your "supporter" is not here in
> the thread.  Also, you are not dismissed "out of hand" - you are
> dismissed because your posts show you to not understand what you're
> talking about, and have no ability to process logical arguments or
> understand abstract concepts, regardless of how they're presented to
> you.  Many people (myself included) have carefully explained to you why
> you are incorrect, but it always turns out to be a waste of time!  :)
>
> Mike.
>

On 10/23/2023 7:51 PM, Mike Terry wrote:
> On 24/10/2023 01:31, olcott wrote:
>> On 10/23/2023 7:24 PM, Mike Terry wrote:
>>> On 24/10/2023 01:08, olcott wrote:
>>>> On 10/23/2023 6:59 PM, Mike Terry wrote:
>>>>> On 24/10/2023 00:34, olcott wrote:
>>>>>> On 10/23/2023 5:55 PM, Mike Terry wrote:
>>>>>>> On 23/10/2023 23:20, olcott wrote:
>>>>>>>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>>>>>>>> On 23/10/2023 19:02, olcott wrote:
>>>>>>>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>>>>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>>>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>>>>>>>> the halting problem|
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>>>>>>>> can do the logically impossible.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ...where "the logically impossible" = "correctly determine
>>>>>>>>>>>>> the halting status for EVERY computation".
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, that IS logically impossible, but we do not just take
>>>>>>>>>>>>> your word for that.  We demand a mathematical proof of this
>>>>>>>>>>>>> fact! Fortunately there are a number of such proofs - e.g.
>>>>>>>>>>>>> the Linz proof you used to claim to have refuted.
>>>>>>>>>>>>>
>>>>>>>>>>>>> That proof proceeds by showing that for ANY purported halt
>>>>>>>>>>>>> decider, one particular computation we can see it
>>>>>>>>>>>>> definitely gets wrong will be the one that internally
>>>>>>>>>>>>> incorporates the logic of the decider in order to basically
>>>>>>>>>>>>> "do the opposite of whatever the decider returns" - just
>>>>>>>>>>>>> like you say!
>>>>>>>>>>>>>
>>>>>>>>>>>>> You now seem to recognise that H does indeed fail for that
>>>>>>>>>>>>> particular computation. (It's ok that you say "right, but
>>>>>>>>>>>>> it ONLY gets it wrong because it's logically impossible for
>>>>>>>>>>>>> it to be correct for that input". Of course it's logically
>>>>>>>>>>>>> impossible: that's what the Linz proof shows! The key point
>>>>>>>>>>>>> is that it DOES get it wrong, so fails the spec for a halt
>>>>>>>>>>>>> decider.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Summary: yes, it is "logically impossible" for a program to
>>>>>>>>>>>>> correctly determine the halting status of EVEY computation,
>>>>>>>>>>>>> since we know how to construct at least one such that we
>>>>>>>>>>>>> can plainly see it gets wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Put differently, the halting problem is undecideable, just
>>>>>>>>>>>>> like everyone has been telling you for 30(?) years.  It's
>>>>>>>>>>>>> taken you many years to get to this point, but finally
>>>>>>>>>>>>> you've arrived! Well done.
>>>>>>>>>>>>>
>>>>>>>>>>>>> To cement your clean break with the past, you should now
>>>>>>>>>>>>> confirm that your previous claims to have "refuted" the
>>>>>>>>>>>>> Linz (and similar) proofs were mistaken.  If you like, you
>>>>>>>>>>>>> can hedge your wording, saying the Linz proof /is/ valid,
>>>>>>>>>>>>> but /only because/ it is logically impossible for a Halt
>>>>>>>>>>>>> Decider to exist with all the properties such a decider
>>>>>>>>>>>>> would be required to have. [viz correctly deciding EVERY
>>>>>>>>>>>>> computation including its own "nemesis" computation.]
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Mike.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> We also know that it is logically impossible for a
>>>>>>>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>>>>>>>> one takes this to be a fundamental limit of computation.
>>>>>>>>>>>
>>>>>>>>>>> We could say that being unable to correctly draw a square
>>>>>>>>>>> circle DOES illustrate a limit of computation.  The reason
>>>>>>>>>>> nobody says this, is because nobody ever considered the
>>>>>>>>>>> opposite might be possible, so it's redundant.
>>>>>>>>>>>
>>>>>>>>>>> The situation is quite different with HP:
>>>>>>>>>>>
>>>>>>>>>>> The square circle program spec asks for a program that
>>>>>>>>>>> produces something which everyone can see is mathematically
>>>>>>>>>>> and logically impossible - mathematically, there are NO
>>>>>>>>>>> SQUARE CIRCLES.
>>>>>>>>>>>
>>>>>>>>>>> The "HP program spec" asks for a program that can calculate
>>>>>>>>>>> the halting status for ANY computation. There IS a
>>>>>>>>>>> mathematical function that maps computations (their
>>>>>>>>>>> representations) to their halting status - so the interest
>>>>>>>>>>> here is whether this (EXISTING) function CAN BE COMPUTED BY A
>>>>>>>>>>> TM.  The answer is NO, as the Linz proof (and what you've
>>>>>>>>>>> acknowledged above) shows this is "logically impossible" -
>>>>>>>>>>> all such TMs get at least one input wrong.
>>>>>>>>>>>
>>>>>>>>>>> So the square circle problem says nothing interesting about
>>>>>>>>>>> computation.  The HP says something interesting: the
>>>>>>>>>>> mathematical function that maps (representations of)
>>>>>>>>>>> computations to their halting status IS NOT COMPUTABLE.
>>>>>>>>>>> That's a fundamental limit on the power of TM computation.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The unsatisfiability of the (a) definition of the halting
>>>>>>>>>> problem spec only says that self-contradictory questions
>>>>>>>>>> lack a correct answer because they are self-contradictory.
>>>>>>>>>
>>>>>>>>> No, it says (directly) that there is NO program satisfying the
>>>>>>>>> spec required for a Halt Decider. That is saying, in other
>>>>>>>>> words, that the HP is undecidable.
>>>>>>>>>
>>>>>>>>> There's nothing in (a) about "self-contradictory questions" -
>>>>>>>>> that's just confusion in your own mind.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> A PhD computer science professor of many decades that
>>>>>>>>>> has been published in the two most highly esteemed
>>>>>>>>>> computer science journals perfectly agrees with me on
>>>>>>>>>> this by direct email conversation and his own paper
>>>>>>>>>> that says essentially the same thing.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yet another of your appeals to (absent) authority!  Perhaps
>>>>>>>>> your supporter might come here and discuss the problem
>>>>>>>>> him/herself. Meanwhile we'll all assume this is like your other
>>>>>>>>> authorities you've misquoted in the past, who clearly did not
>>>>>>>>> support your possition at all...
>>>>>>>>>
>>>>>>>>> Mike.
>>>>>>>>>
>>>>>>>>
>>>>>>>> *Here are the verbatim words that he agreed to*
>>>>>>>> Yet the gist of the issue with the halting problem seems to be
>>>>>>>> that the whole notion of decision problem undecidability is
>>>>>>>> inherently flawed in that it requires the logically impossible.
>>>>>>>>
>>>>>>>> Requiring a halt decider H to report on the behavior of the
>>>>>>>> direct execution of input D when D has been defined to do
>>>>>>>> the opposite of whatever Boolean value that H returns is
>>>>>>>> simply an incorrect problem definition because it requires
>>>>>>>> the logically impossible.
>>>>>>>>
>>>>>>>
>>>>>>> Hehe - seems he's actually agreeing WITH WHAT I said above, which
>>>>>>> is not supporting your position AT ALL.  This is exactly the same
>>>>>>> as when you conversed with Prof. Sipser and completely
>>>>>>> misunderstood what he was saying!
>>>>>
>>>>> Reading more closely... If your "supporter" said "Yet the gist of
>>>>> the issue..." then /perhaps/ he is agreeing with you.  Hard to say
>>>>> without the full context, which you never understand or present
>>>>> correctly.
>>>>>
>>>>> If your "supporter" said "Requiring a halt decider H ..." then he
>>>>> is probably just agreeing with me - but to me now, those sound more
>>>>> like /your/ words, misunderstanding "logically impossible".
>>>>>
>>>>> In either case it is meaningless, because your "supporter" IS NOT
>>>>> HERE participating in the thread! So just present your case as YOU
>>>>> see it and forget your absent supporters!  :)
>>>>>
>>>>> <https://en.wikipedia.org/wiki/Argument_from_authority>
>>>>>
>>>>> Mike.
>>>>>
>>>>
>>>> *He said that the halting problem definition <is> incorrect*
>>>> There are no ways to misinterpret that.
>>>>
>>>> *He agreed with these verbatim words*
>>>> The whole concept of decision problem undecidability is fatally flawed
>>>> because it requires satisfying a logically impossible requirement.
>>>
>>> So you claim, but who cares?  HE IS NOT PARTICIPATING IN THIS THREAD.
>>>
>>> And even if he agrees with you (which I doubt) IT DOES NOT MAGICALLY
>>> MAKE YOUR INCORRECT BELIEFS CORRECT!
>>>
>>> <https://en.wikipedia.org/wiki/Argument_from_authority>
>>>
>>> Mike.
>>>
>>>
>>
>> It provides significant evidence that I am not simply
>> a crackpot that can be correctly dismissed out of hand.
>
> It provides NO such evidence, because your "supporter" is not here in
> the thread.  Also, you are not dismissed "out of hand" - you are
> dismissed because your posts show you to not understand what you're
> talking about, and have no ability to process logical arguments or
> understand abstract concepts, regardless of how they're presented to
> you.  Many people (myself included) have carefully explained to you why
> you are incorrect, but it always turns out to be a waste of time!  :)
>
> Mike.
>

On 10/23/2023 5:55 PM, Mike Terry wrote:
> On 23/10/2023 23:20, olcott wrote:
>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>> On 23/10/2023 19:02, olcott wrote:
>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>> the halting problem
>>>>>>>>>
>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>
>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>
>>>>>>>>
>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>> can do the logically impossible.
>>>>>>>
>>>>>>> ...where "the logically impossible" = "correctly determine the
>>>>>>> halting status for EVERY computation".
>>>>>>>
>>>>>>> Yes, that IS logically impossible, but we do not just take your
>>>>>>> word for that.  We demand a mathematical proof of this fact!
>>>>>>> Fortunately there are a number of such proofs - e.g. the Linz
>>>>>>> proof you used to claim to have refuted.
>>>>>>>
>>>>>>> That proof proceeds by showing that for ANY purported halt
>>>>>>> decider, one particular computation we can see it definitely gets
>>>>>>> wrong will be the one that internally incorporates the logic of
>>>>>>> the decider in order to basically "do the opposite of whatever
>>>>>>> the decider returns" - just like you say!
>>>>>>>
>>>>>>> You now seem to recognise that H does indeed fail for that
>>>>>>> particular computation.  (It's ok that you say "right, but it
>>>>>>> ONLY gets it wrong because it's logically impossible for it to be
>>>>>>> correct for that input". Of course it's logically impossible:
>>>>>>> that's what the Linz proof shows! The key point is that it DOES
>>>>>>> get it wrong, so fails the spec for a halt decider.)
>>>>>>>
>>>>>>> Summary: yes, it is "logically impossible" for a program to
>>>>>>> correctly determine the halting status of EVEY computation, since
>>>>>>> we know how to construct at least one such that we can plainly
>>>>>>> see it gets wrong.
>>>>>>>
>>>>>>> Put differently, the halting problem is undecideable, just like
>>>>>>> everyone has been telling you for 30(?) years.  It's taken you
>>>>>>> many years to get to this point, but finally you've arrived! Well
>>>>>>> done.
>>>>>>>
>>>>>>> To cement your clean break with the past, you should now confirm
>>>>>>> that your previous claims to have "refuted" the Linz (and
>>>>>>> similar) proofs were mistaken.  If you like, you can hedge your
>>>>>>> wording, saying the Linz proof /is/ valid, but /only because/ it
>>>>>>> is logically impossible for a Halt Decider to exist with all the
>>>>>>> properties such a decider would be required to have. [viz
>>>>>>> correctly deciding EVERY computation including its own "nemesis"
>>>>>>> computation.]
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mike.
>>>>>>>
>>>>>>
>>>>>> We also know that it is logically impossible for a
>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>> one takes this to be a fundamental limit of computation.
>>>>>
>>>>> We could say that being unable to correctly draw a square circle
>>>>> DOES illustrate a limit of computation.  The reason nobody says
>>>>> this, is because nobody ever considered the opposite might be
>>>>> possible, so it's redundant.
>>>>>
>>>>> The situation is quite different with HP:
>>>>>
>>>>> The square circle program spec asks for a program that produces
>>>>> something which everyone can see is mathematically and logically
>>>>> impossible - mathematically, there are NO SQUARE CIRCLES.
>>>>>
>>>>> The "HP program spec" asks for a program that can calculate the
>>>>> halting status for ANY computation. There IS a mathematical
>>>>> function that maps computations (their representations) to their
>>>>> halting status - so the interest here is whether this (EXISTING)
>>>>> function CAN BE COMPUTED BY A TM.  The answer is NO, as the Linz
>>>>> proof (and what you've acknowledged above) shows this is "logically
>>>>> impossible" - all such TMs get at least one input wrong.
>>>>>
>>>>> So the square circle problem says nothing interesting about
>>>>> computation.  The HP says something interesting: the mathematical
>>>>> function that maps (representations of) computations to their
>>>>> halting status IS NOT COMPUTABLE.  That's a fundamental limit on
>>>>> the power of TM computation.
>>>>>
>>>>
>>>> The unsatisfiability of the (a) definition of the halting
>>>> problem spec only says that self-contradictory questions
>>>> lack a correct answer because they are self-contradictory.
>>>
>>> No, it says (directly) that there is NO program satisfying the spec
>>> required for a Halt Decider. That is saying, in other words, that the
>>> HP is undecidable.
>>>
>>> There's nothing in (a) about "self-contradictory questions" - that's
>>> just confusion in your own mind.
>>>
>>>>
>>>> A PhD computer science professor of many decades that
>>>> has been published in the two most highly esteemed
>>>> computer science journals perfectly agrees with me on
>>>> this by direct email conversation and his own paper
>>>> that says essentially the same thing.
>>>>
>>>
>>> Yet another of your appeals to (absent) authority!  Perhaps your
>>> supporter might come here and discuss the problem him/herself.
>>> Meanwhile we'll all assume this is like your other authorities you've
>>> misquoted in the past, who clearly did not support your possition at
>>> all...
>>>
>>> Mike.
>>>
>>
>> *Here are the verbatim words that he agreed to*
>> Yet the gist of the issue with the halting problem seems to be
>> that the whole notion of decision problem undecidability is
>> inherently flawed in that it requires the logically impossible.
>>
>> Requiring a halt decider H to report on the behavior of the
>> direct execution of input D when D has been defined to do
>> the opposite of whatever Boolean value that H returns is
>> *simply an incorrect problem definition* because it requires
>> the logically impossible.
>>
>
> Hehe - seems he's actually agreeing WITH WHAT I said above, which is not
> supporting your position AT ALL.

When people assume that I must be a crackpot then
they conclude from this that I must be terrible
at logic and on this basis they hardly pay any
attention to what I say when they contrive some
boilerplate reply that proves they did not even
see what I said.

On 10/23/23 6:59 PM, olcott wrote:
> On 10/23/2023 5:55 PM, Mike Terry wrote:
>> On 23/10/2023 23:20, olcott wrote:
>>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>>> On 23/10/2023 19:02, olcott wrote:
>>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>>> the halting problem
>>>>>>>>>>
>>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>>
>>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>>> can do the logically impossible.
>>>>>>>>
>>>>>>>> ...where "the logically impossible" = "correctly determine the
>>>>>>>> halting status for EVERY computation".
>>>>>>>>
>>>>>>>> Yes, that IS logically impossible, but we do not just take your
>>>>>>>> word for that.  We demand a mathematical proof of this fact!
>>>>>>>> Fortunately there are a number of such proofs - e.g. the Linz
>>>>>>>> proof you used to claim to have refuted.
>>>>>>>>
>>>>>>>> That proof proceeds by showing that for ANY purported halt
>>>>>>>> decider, one particular computation we can see it definitely
>>>>>>>> gets wrong will be the one that internally incorporates the
>>>>>>>> logic of the decider in order to basically "do the opposite of
>>>>>>>> whatever the decider returns" - just like you say!
>>>>>>>>
>>>>>>>> You now seem to recognise that H does indeed fail for that
>>>>>>>> particular computation.  (It's ok that you say "right, but it
>>>>>>>> ONLY gets it wrong because it's logically impossible for it to
>>>>>>>> be correct for that input". Of course it's logically impossible:
>>>>>>>> that's what the Linz proof shows! The key point is that it DOES
>>>>>>>> get it wrong, so fails the spec for a halt decider.)
>>>>>>>>
>>>>>>>> Summary: yes, it is "logically impossible" for a program to
>>>>>>>> correctly determine the halting status of EVEY computation,
>>>>>>>> since we know how to construct at least one such that we can
>>>>>>>> plainly see it gets wrong.
>>>>>>>>
>>>>>>>> Put differently, the halting problem is undecideable, just like
>>>>>>>> everyone has been telling you for 30(?) years.  It's taken you
>>>>>>>> many years to get to this point, but finally you've arrived!
>>>>>>>> Well done.
>>>>>>>>
>>>>>>>> To cement your clean break with the past, you should now confirm
>>>>>>>> that your previous claims to have "refuted" the Linz (and
>>>>>>>> similar) proofs were mistaken.  If you like, you can hedge your
>>>>>>>> wording, saying the Linz proof /is/ valid, but /only because/ it
>>>>>>>> is logically impossible for a Halt Decider to exist with all the
>>>>>>>> properties such a decider would be required to have. [viz
>>>>>>>> correctly deciding EVERY computation including its own "nemesis"
>>>>>>>> computation.]
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Mike.
>>>>>>>>
>>>>>>>
>>>>>>> We also know that it is logically impossible for a
>>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>>> one takes this to be a fundamental limit of computation.
>>>>>>
>>>>>> We could say that being unable to correctly draw a square circle
>>>>>> DOES illustrate a limit of computation.  The reason nobody says
>>>>>> this, is because nobody ever considered the opposite might be
>>>>>> possible, so it's redundant.
>>>>>>
>>>>>> The situation is quite different with HP:
>>>>>>
>>>>>> The square circle program spec asks for a program that produces
>>>>>> something which everyone can see is mathematically and logically
>>>>>> impossible - mathematically, there are NO SQUARE CIRCLES.
>>>>>>
>>>>>> The "HP program spec" asks for a program that can calculate the
>>>>>> halting status for ANY computation. There IS a mathematical
>>>>>> function that maps computations (their representations) to their
>>>>>> halting status - so the interest here is whether this (EXISTING)
>>>>>> function CAN BE COMPUTED BY A TM.  The answer is NO, as the Linz
>>>>>> proof (and what you've acknowledged above) shows this is
>>>>>> "logically impossible" - all such TMs get at least one input wrong.
>>>>>>
>>>>>> So the square circle problem says nothing interesting about
>>>>>> computation.  The HP says something interesting: the mathematical
>>>>>> function that maps (representations of) computations to their
>>>>>> halting status IS NOT COMPUTABLE.  That's a fundamental limit on
>>>>>> the power of TM computation.
>>>>>>
>>>>>
>>>>> The unsatisfiability of the (a) definition of the halting
>>>>> problem spec only says that self-contradictory questions
>>>>> lack a correct answer because they are self-contradictory.
>>>>
>>>> No, it says (directly) that there is NO program satisfying the spec
>>>> required for a Halt Decider. That is saying, in other words, that
>>>> the HP is undecidable.
>>>>
>>>> There's nothing in (a) about "self-contradictory questions" - that's
>>>> just confusion in your own mind.
>>>>
>>>>>
>>>>> A PhD computer science professor of many decades that
>>>>> has been published in the two most highly esteemed
>>>>> computer science journals perfectly agrees with me on
>>>>> this by direct email conversation and his own paper
>>>>> that says essentially the same thing.
>>>>>
>>>>
>>>> Yet another of your appeals to (absent) authority!  Perhaps your
>>>> supporter might come here and discuss the problem him/herself.
>>>> Meanwhile we'll all assume this is like your other authorities
>>>> you've misquoted in the past, who clearly did not support your
>>>> possition at all...
>>>>
>>>> Mike.
>>>>
>>>
>>> *Here are the verbatim words that he agreed to*
>>> Yet the gist of the issue with the halting problem seems to be
>>> that the whole notion of decision problem undecidability is
>>> inherently flawed in that it requires the logically impossible.
>>>
>>> Requiring a halt decider H to report on the behavior of the
>>> direct execution of input D when D has been defined to do
>>> the opposite of whatever Boolean value that H returns is
>>> *simply an incorrect problem definition* because it requires
>>> the logically impossible.
>>>
>>
>> Hehe - seems he's actually agreeing WITH WHAT I said above, which is
>> not supporting your position AT ALL.
>
> When people assume that I must be a crackpot then
> they conclude from this that I must be terrible
> at logic and on this basis they hardly pay any
> attention to what I say when they contrive some
> boilerplate reply that proves they did not even
> see what I said.
>
> *You missed this*
> *simply an incorrect problem definition*

On 10/23/23 6:54 PM, olcott wrote:
> On 10/23/2023 7:51 PM, Mike Terry wrote:
>> On 24/10/2023 01:31, olcott wrote:
>>> On 10/23/2023 7:24 PM, Mike Terry wrote:
>>>> On 24/10/2023 01:08, olcott wrote:
>>>>> On 10/23/2023 6:59 PM, Mike Terry wrote:
>>>>>> On 24/10/2023 00:34, olcott wrote:
>>>>>>> On 10/23/2023 5:55 PM, Mike Terry wrote:
>>>>>>>> On 23/10/2023 23:20, olcott wrote:
>>>>>>>>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>>>>>>>>> On 23/10/2023 19:02, olcott wrote:
>>>>>>>>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>>>>>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>>>>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>>>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>>>>>>>>> the halting problem|
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>>>>>>>>> can do the logically impossible.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ...where "the logically impossible" = "correctly determine
>>>>>>>>>>>>>> the halting status for EVERY computation".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, that IS logically impossible, but we do not just take
>>>>>>>>>>>>>> your word for that.  We demand a mathematical proof of
>>>>>>>>>>>>>> this fact! Fortunately there are a number of such proofs -
>>>>>>>>>>>>>> e.g. the Linz proof you used to claim to have refuted.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> That proof proceeds by showing that for ANY purported halt
>>>>>>>>>>>>>> decider, one particular computation we can see it
>>>>>>>>>>>>>> definitely gets wrong will be the one that internally
>>>>>>>>>>>>>> incorporates the logic of the decider in order to
>>>>>>>>>>>>>> basically "do the opposite of whatever the decider
>>>>>>>>>>>>>> returns" - just like you say!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You now seem to recognise that H does indeed fail for that
>>>>>>>>>>>>>> particular computation. (It's ok that you say "right, but
>>>>>>>>>>>>>> it ONLY gets it wrong because it's logically impossible
>>>>>>>>>>>>>> for it to be correct for that input". Of course it's
>>>>>>>>>>>>>> logically impossible: that's what the Linz proof shows!
>>>>>>>>>>>>>> The key point is that it DOES get it wrong, so fails the
>>>>>>>>>>>>>> spec for a halt decider.)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Summary: yes, it is "logically impossible" for a program
>>>>>>>>>>>>>> to correctly determine the halting status of EVEY
>>>>>>>>>>>>>> computation, since we know how to construct at least one
>>>>>>>>>>>>>> such that we can plainly see it gets wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Put differently, the halting problem is undecideable, just
>>>>>>>>>>>>>> like everyone has been telling you for 30(?) years.  It's
>>>>>>>>>>>>>> taken you many years to get to this point, but finally
>>>>>>>>>>>>>> you've arrived! Well done.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> To cement your clean break with the past, you should now
>>>>>>>>>>>>>> confirm that your previous claims to have "refuted" the
>>>>>>>>>>>>>> Linz (and similar) proofs were mistaken.  If you like, you
>>>>>>>>>>>>>> can hedge your wording, saying the Linz proof /is/ valid,
>>>>>>>>>>>>>> but /only because/ it is logically impossible for a Halt
>>>>>>>>>>>>>> Decider to exist with all the properties such a decider
>>>>>>>>>>>>>> would be required to have. [viz correctly deciding EVERY
>>>>>>>>>>>>>> computation including its own "nemesis" computation.]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Mike.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> We also know that it is logically impossible for a
>>>>>>>>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>>>>>>>>> one takes this to be a fundamental limit of computation.
>>>>>>>>>>>>
>>>>>>>>>>>> We could say that being unable to correctly draw a square
>>>>>>>>>>>> circle DOES illustrate a limit of computation.  The reason
>>>>>>>>>>>> nobody says this, is because nobody ever considered the
>>>>>>>>>>>> opposite might be possible, so it's redundant.
>>>>>>>>>>>>
>>>>>>>>>>>> The situation is quite different with HP:
>>>>>>>>>>>>
>>>>>>>>>>>> The square circle program spec asks for a program that
>>>>>>>>>>>> produces something which everyone can see is mathematically
>>>>>>>>>>>> and logically impossible - mathematically, there are NO
>>>>>>>>>>>> SQUARE CIRCLES.
>>>>>>>>>>>>
>>>>>>>>>>>> The "HP program spec" asks for a program that can calculate
>>>>>>>>>>>> the halting status for ANY computation. There IS a
>>>>>>>>>>>> mathematical function that maps computations (their
>>>>>>>>>>>> representations) to their halting status - so the interest
>>>>>>>>>>>> here is whether this (EXISTING) function CAN BE COMPUTED BY
>>>>>>>>>>>> A TM.  The answer is NO, as the Linz proof (and what you've
>>>>>>>>>>>> acknowledged above) shows this is "logically impossible" -
>>>>>>>>>>>> all such TMs get at least one input wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> So the square circle problem says nothing interesting about
>>>>>>>>>>>> computation.  The HP says something interesting: the
>>>>>>>>>>>> mathematical function that maps (representations of)
>>>>>>>>>>>> computations to their halting status IS NOT COMPUTABLE.
>>>>>>>>>>>> That's a fundamental limit on the power of TM computation.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The unsatisfiability of the (a) definition of the halting
>>>>>>>>>>> problem spec only says that self-contradictory questions
>>>>>>>>>>> lack a correct answer because they are self-contradictory.
>>>>>>>>>>
>>>>>>>>>> No, it says (directly) that there is NO program satisfying the
>>>>>>>>>> spec required for a Halt Decider. That is saying, in other
>>>>>>>>>> words, that the HP is undecidable.
>>>>>>>>>>
>>>>>>>>>> There's nothing in (a) about "self-contradictory questions" -
>>>>>>>>>> that's just confusion in your own mind.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> A PhD computer science professor of many decades that
>>>>>>>>>>> has been published in the two most highly esteemed
>>>>>>>>>>> computer science journals perfectly agrees with me on
>>>>>>>>>>> this by direct email conversation and his own paper
>>>>>>>>>>> that says essentially the same thing.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yet another of your appeals to (absent) authority!  Perhaps
>>>>>>>>>> your supporter might come here and discuss the problem
>>>>>>>>>> him/herself. Meanwhile we'll all assume this is like your
>>>>>>>>>> other authorities you've misquoted in the past, who clearly
>>>>>>>>>> did not support your possition at all...
>>>>>>>>>>
>>>>>>>>>> Mike.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Here are the verbatim words that he agreed to*
>>>>>>>>> Yet the gist of the issue with the halting problem seems to be
>>>>>>>>> that the whole notion of decision problem undecidability is
>>>>>>>>> inherently flawed in that it requires the logically impossible.
>>>>>>>>>
>>>>>>>>> Requiring a halt decider H to report on the behavior of the
>>>>>>>>> direct execution of input D when D has been defined to do
>>>>>>>>> the opposite of whatever Boolean value that H returns is
>>>>>>>>> simply an incorrect problem definition because it requires
>>>>>>>>> the logically impossible.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hehe - seems he's actually agreeing WITH WHAT I said above,
>>>>>>>> which is not supporting your position AT ALL.  This is exactly
>>>>>>>> the same as when you conversed with Prof. Sipser and completely
>>>>>>>> misunderstood what he was saying!
>>>>>>
>>>>>> Reading more closely... If your "supporter" said "Yet the gist of
>>>>>> the issue..." then /perhaps/ he is agreeing with you.  Hard to say
>>>>>> without the full context, which you never understand or present
>>>>>> correctly.
>>>>>>
>>>>>> If your "supporter" said "Requiring a halt decider H ..." then he
>>>>>> is probably just agreeing with me - but to me now, those sound
>>>>>> more like /your/ words, misunderstanding "logically impossible".
>>>>>>
>>>>>> In either case it is meaningless, because your "supporter" IS NOT
>>>>>> HERE participating in the thread! So just present your case as YOU
>>>>>> see it and forget your absent supporters!  :)
>>>>>>
>>>>>> <https://en.wikipedia.org/wiki/Argument_from_authority>
>>>>>>
>>>>>> Mike.
>>>>>>
>>>>>
>>>>> *He said that the halting problem definition <is> incorrect*
>>>>> There are no ways to misinterpret that.
>>>>>
>>>>> *He agreed with these verbatim words*
>>>>> The whole concept of decision problem undecidability is fatally flawed
>>>>> because it requires satisfying a logically impossible requirement.
>>>>
>>>> So you claim, but who cares?  HE IS NOT PARTICIPATING IN THIS THREAD.
>>>>
>>>> And even if he agrees with you (which I doubt) IT DOES NOT MAGICALLY
>>>> MAKE YOUR INCORRECT BELIEFS CORRECT!
>>>>
>>>> <https://en.wikipedia.org/wiki/Argument_from_authority>
>>>>
>>>> Mike.
>>>>
>>>>
>>>
>>> It provides significant evidence that I am not simply
>>> a crackpot that can be correctly dismissed out of hand.
>>
>> It provides NO such evidence, because your "supporter" is not here in
>> the thread.  Also, you are not dismissed "out of hand" - you are
>> dismissed because your posts show you to not understand what you're
>> talking about, and have no ability to process logical arguments or
>> understand abstract concepts, regardless of how they're presented to
>> you.  Many people (myself included) have carefully explained to you
>> why you are incorrect, but it always turns out to be a waste of time!  :)
>>
>> Mike.
>>
>
> When people assume that I must be a crackpot then
> they conclude from this that I must be terrible
> at logic and on this basis they hardly pay any
> attention to what I say when they contrive some
> boilerplate reply that proves they did not even
> see what I said.
>
>

On 10/23/23 5:56 PM, olcott wrote:
> On 10/23/2023 7:46 PM, Mike Terry wrote:
>> On 24/10/2023 01:25, olcott wrote:
>>> On 10/23/2023 6:59 PM, Mike Terry wrote:
>>>> On 24/10/2023 00:34, olcott wrote:
>>>>> On 10/23/2023 5:55 PM, Mike Terry wrote:
>>>>>> On 23/10/2023 23:20, olcott wrote:
>>>>>>> On 10/23/2023 5:14 PM, Mike Terry wrote:
>>>>>>>> On 23/10/2023 19:02, olcott wrote:
>>>>>>>>> On 10/23/2023 11:20 AM, Mike Terry wrote:
>>>>>>>>>> On 23/10/2023 04:41, olcott wrote:
>>>>>>>>>>> On 10/22/2023 10:12 PM, Mike Terry wrote:
>>>>>>>>>>>> On 23/10/2023 02:26, olcott wrote:
>>>>>>>>>>>>> On 10/22/2023 7:57 PM, olcott wrote:
>>>>>>>>>>>>>> This is the essence of an alternative proof related to
>>>>>>>>>>>>>> the halting problem
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *It seems that everyone agrees with this*
>>>>>>>>>>>>>> (a) When the halting problem is defined with a program
>>>>>>>>>>>>>> specification that requires an H to report on the behavior
>>>>>>>>>>>>>> of the direct execution of D(D) that does the opposite of
>>>>>>>>>>>>>> whatever Boolean value that H returns then this is an
>>>>>>>>>>>>>> unsatisfiable program specification.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (b)  *An unsatisfiable program specification is merely*
>>>>>>>>>>>>>> *the inability to do the logically impossible thus places*
>>>>>>>>>>>>>> *no actual limit on anyone or anything*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The halting problem proofs only show that no machine
>>>>>>>>>>>>> can do the logically impossible.
>>>>>>>>>>>>
>>>>>>>>>>>> ...where "the logically impossible" = "correctly determine
>>>>>>>>>>>> the halting status for EVERY computation".
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, that IS logically impossible, but we do not just take
>>>>>>>>>>>> your word for that.  We demand a mathematical proof of this
>>>>>>>>>>>> fact! Fortunately there are a number of such proofs - e.g.
>>>>>>>>>>>> the Linz proof you used to claim to have refuted.
>>>>>>>>>>>>
>>>>>>>>>>>> That proof proceeds by showing that for ANY purported halt
>>>>>>>>>>>> decider, one particular computation we can see it definitely
>>>>>>>>>>>> gets wrong will be the one that internally incorporates the
>>>>>>>>>>>> logic of the decider in order to basically "do the opposite
>>>>>>>>>>>> of whatever the decider returns" - just like you say!
>>>>>>>>>>>>
>>>>>>>>>>>> You now seem to recognise that H does indeed fail for that
>>>>>>>>>>>> particular computation.  (It's ok that you say "right, but
>>>>>>>>>>>> it ONLY gets it wrong because it's logically impossible for
>>>>>>>>>>>> it to be correct for that input". Of course it's logically
>>>>>>>>>>>> impossible: that's what the Linz proof shows! The key point
>>>>>>>>>>>> is that it DOES get it wrong, so fails the spec for a halt
>>>>>>>>>>>> decider.)
>>>>>>>>>>>>
>>>>>>>>>>>> Summary: yes, it is "logically impossible" for a program to
>>>>>>>>>>>> correctly determine the halting status of EVEY computation,
>>>>>>>>>>>> since we know how to construct at least one such that we can
>>>>>>>>>>>> plainly see it gets wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> Put differently, the halting problem is undecideable, just
>>>>>>>>>>>> like everyone has been telling you for 30(?) years.  It's
>>>>>>>>>>>> taken you many years to get to this point, but finally
>>>>>>>>>>>> you've arrived! Well done.
>>>>>>>>>>>>
>>>>>>>>>>>> To cement your clean break with the past, you should now
>>>>>>>>>>>> confirm that your previous claims to have "refuted" the Linz
>>>>>>>>>>>> (and similar) proofs were mistaken.  If you like, you can
>>>>>>>>>>>> hedge your wording, saying the Linz proof /is/ valid, but
>>>>>>>>>>>> /only because/ it is logically impossible for a Halt Decider
>>>>>>>>>>>> to exist with all the properties such a decider would be
>>>>>>>>>>>> required to have. [viz correctly deciding EVERY computation
>>>>>>>>>>>> including its own "nemesis" computation.]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Mike.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> We also know that it is logically impossible for a
>>>>>>>>>>> CAD system to correctly draw a square circle** yet no
>>>>>>>>>>> one takes this to be a fundamental limit of computation.
>>>>>>>>>>
>>>>>>>>>> We could say that being unable to correctly draw a square
>>>>>>>>>> circle DOES illustrate a limit of computation.  The reason
>>>>>>>>>> nobody says this, is because nobody ever considered the
>>>>>>>>>> opposite might be possible, so it's redundant.
>>>>>>>>>>
>>>>>>>>>> The situation is quite different with HP:
>>>>>>>>>>
>>>>>>>>>> The square circle program spec asks for a program that
>>>>>>>>>> produces something which everyone can see is mathematically
>>>>>>>>>> and logically impossible - mathematically, there are NO SQUARE
>>>>>>>>>> CIRCLES.
>>>>>>>>>>
>>>>>>>>>> The "HP program spec" asks for a program that can calculate
>>>>>>>>>> the halting status for ANY computation. There IS a
>>>>>>>>>> mathematical function that maps computations (their
>>>>>>>>>> representations) to their halting status - so the interest
>>>>>>>>>> here is whether this (EXISTING) function CAN BE COMPUTED BY A
>>>>>>>>>> TM.  The answer is NO, as the Linz proof (and what you've
>>>>>>>>>> acknowledged above) shows this is "logically impossible" - all
>>>>>>>>>> such TMs get at least one input wrong.
>>>>>>>>>>
>>>>>>>>>> So the square circle problem says nothing interesting about
>>>>>>>>>> computation.  The HP says something interesting: the
>>>>>>>>>> mathematical function that maps (representations of)
>>>>>>>>>> computations to their halting status IS NOT COMPUTABLE.
>>>>>>>>>> That's a fundamental limit on the power of TM computation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The unsatisfiability of the (a) definition of the halting
>>>>>>>>> problem spec only says that self-contradictory questions
>>>>>>>>> lack a correct answer because they are self-contradictory.
>>>>>>>>
>>>>>>>> No, it says (directly) that there is NO program satisfying the
>>>>>>>> spec required for a Halt Decider. That is saying, in other
>>>>>>>> words, that the HP is undecidable.
>>>>>>>>
>>>>>>>> There's nothing in (a) about "self-contradictory questions" -
>>>>>>>> that's just confusion in your own mind.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> A PhD computer science professor of many decades that
>>>>>>>>> has been published in the two most highly esteemed
>>>>>>>>> computer science journals perfectly agrees with me on
>>>>>>>>> this by direct email conversation and his own paper
>>>>>>>>> that says essentially the same thing.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yet another of your appeals to (absent) authority!  Perhaps your
>>>>>>>> supporter might come here and discuss the problem him/herself.
>>>>>>>> Meanwhile we'll all assume this is like your other authorities
>>>>>>>> you've misquoted in the past, who clearly did not support your
>>>>>>>> possition at all...
>>>>>>>>
>>>>>>>> Mike.
>>>>>>>>
>>>>>>>
>>>>>>> *Here are the verbatim words that he agreed to*
>>>>>>> Yet the gist of the issue with the halting problem seems to be
>>>>>>> that the whole notion of decision problem undecidability is
>>>>>>> inherently flawed in that it requires the logically impossible.
>>>>>>>
>>>>>>> Requiring a halt decider H to report on the behavior of the
>>>>>>> direct execution of input D when D has been defined to do
>>>>>>> the opposite of whatever Boolean value that H returns is
>>>>>>> simply an incorrect problem definition because it requires
>>>>>>> the logically impossible.
>>>>>>>
>>>>>>
>>>>>> Hehe - seems he's actually agreeing WITH WHAT I said above, which
>>>>>> is not supporting your position AT ALL.  This is exactly the same
>>>>>> as when you conversed with Prof. Sipser and completely
>>>>>> misunderstood what he was saying!
>>>>
>>>> Reading more closely... If your "supporter" said "Yet the gist of
>>>> the issue..." then /perhaps/ he is agreeing with you.  Hard to say
>>>> without the full context, which you never understand or present
>>>> correctly.
>>>>
>>>
>>> *The gist of the whole issue is that we both*
>>> *agree that the halting problem is WRONG*
>>
>> So you claim, but I'll say it again:  WHO CARES?  Your alleged
>> supporter is not participating in this thread.
>>
>> Mike.
>
> What I am expecting from this is an actual honest
> dialogue when I present our shared view. This means
> that people will carefully study my words and make
> sure to respond to exactly what I say.

On 10/23/2023 6:51 PM, Mike Terry wrote:
> On 24/10/2023 01:31, olcott wrote:
<major snip>
>> It provides significant evidence that I am not simply
>> a crackpot that can be correctly dismissed out of hand.
>
> It provides NO such evidence, because your "supporter" is not here in
> the thread.  Also, you are not dismissed "out of hand" - you are
> dismissed because your posts show you to not understand what you're
> talking about, and have no ability to process logical arguments or
> understand abstract concepts, regardless of how they're presented to
> you.  Many people (myself included) have carefully explained to you why
> you are incorrect, but it always turns out to be a waste of time!  :)
So why do you persist? I know it's really hard to not try to "crack" a
crackpot but virtue is in resisting. I hardly ever read a post by
Impotent Pete or Richard the Ernest since their posts are a mechanism to
avoid bleak lives - repetition upon repetition.
Consider, for example, the Schopenhauer quote "Talent hits a target no
one else can hit; Genius hits a target no one else can see." as part of
the Impotent's signature: one can comment as much as you want about the
fact that he 1) mostly strikes out and 2) is blind. What's the point?
He's too stupid and non self-aware to notice the irony involved -
repetition upon repetition.
--
Jeff Barnett

On 10/23/2023 11:03 PM, Jeff Barnett wrote:
> On 10/23/2023 6:51 PM, Mike Terry wrote:
>> On 24/10/2023 01:31, olcott wrote:
>
> <major snip>
>
>>> It provides significant evidence that I am not simply
>>> a crackpot that can be correctly dismissed out of hand.
>>
>> It provides NO such evidence, because your "supporter" is not here in
>> the thread.  Also, you are not dismissed "out of hand" - you are
>> dismissed because your posts show you to not understand what you're
>> talking about, and have no ability to process logical arguments or
>> understand abstract concepts, regardless of how they're presented to
>> you.  Many people (myself included) have carefully explained to you
>> why you are incorrect, but it always turns out to be a waste of time!  :)
> So why do you persist? I know it's really hard to not try to "crack" a
> crackpot but virtue is in resisting. I hardly ever read a post by
> Impotent Pete or Richard the Ernest since their posts are a mechanism to
> avoid bleak lives - repetition upon repetition.
>
> Consider, for example, the Schopenhauer quote "Talent hits a target no
> one else can hit; Genius hits a target no one else can see." as part of
> the Impotent's signature: one can comment as much as you want about the
> fact that he 1) mostly strikes out and 2) is blind. What's the point?
> He's too stupid and non self-aware to notice the irony involved -
> repetition upon repetition.

My latest line-of-reasoning has a full PhD professor of
computer science totally agreeing with one of my alternate
proofs that I began in 2004. He has published several
times in the two most prestigious computer science journals
and has been a full professor for decades.

Recently I have only been posting summarized versions
of our shared view.

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