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*

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

On 10/22/23 5: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*
>

But, since that isn't actually the program specification, your claim
means nothing.

Yes, we can show that it is impossible to write a program to compute if
a given program halts. If you want to define that question as "invalid",
then how do you determine if a specification is actually valid? Or do
you thiink "Validity" can change based on Knowledge, which yields a very
weak version of "Truth".

Now, does your claim of no actual limit mean that we can definitely
write a program to determine the truth or falsity of the twin primes
conjecture? (since there are no limits on what can be computed from a
valid question).

Or, are you saying that because we found one program to no be writable,
it doesn't affect what other programs are writable, since they never were.

In other words, a worthless statement.

Yes. the proof that the halting problem is not computable does not
change which other problems are computable or not, but does help see
which category some problems are in, and becomes a clear proof that some
problems are definitely not computable.

There are many other problem that might be found to be not computable,
and we know some of them.

Just as there are statements that might not be provable, and we know
that there exist statements that are not provable (but are still true).

So, none of this gets you to the point of showing you big claim, and in
fact, by admitting that Halting is not computable, we can prove a lot of
the limits to possible knowledge.

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.

Since 1936 no one ever noticed that the inability to
do the logically impossible is merely a fake ruse of
a limit and not any actual limit what-so-ever.

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

On 10/22/23 6:26 PM, 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.
>
> Since 1936 no one ever noticed that the inability to
> do the logically impossible is merely a fake ruse of
> a limit and not any actual limit what-so-ever.
>

No, it shows that writing a program to correctly determine the halting
status of any program given as input is impossible.

IF you think that knowledge is worthless, so be it, your loss.

So, how do you determine that a given problem is "invalid"?

Do you first need to determine if it is impossible?

And, do you accept that some logically correct problems, like the twins
prime conjecture, might not be possible to determine with a program?

Or does the problem suddenly become "logically impossible" if we find
out that it is impossible to program?

It seems, your idea of logic doesn't understand what it can ask about
until you actually know the answer to the question, which make it a very
weak system.

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.

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.

** A square circle must be round and simultaneously
have four equal length sides, thus not be round.

Self-contradictory inputs <are> analogous to a
thing having mutually exclusive properties.

Kind Regards...

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

On 10/22/23 8:41 PM, 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.
>
> ** A square circle must be round and simultaneously
> have four equal length sides, thus not be round.
>
> Self-contradictory inputs <are> analogous to a
> thing having mutually exclusive properties.
>
> Kind Regards...
>

So, you are admitting you lied when you said you have a fully functional
Halt decider, because now you say such a thing is logically impossible?

And you are now AGREEING that the Halting Problem, that is the making of
a Turing Machine/Program that can correctly tell the Halting status of
ANY program represented as its input, is in fact, impossible to do.

I hope you are not going to try and say that You CAN make such a program
as long as the input isn't "Invalid", as the DEFINITION was for "ANY"
program, and this "Pathological" input is definitely "A Program", so
unless you can show how this program isn't actually a program, you are
just stuck with having to admit that you are just a iiar.

Note, ANY means ANY, not just all the ones I can handle.

On 10/22/2023 10:41 PM, 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.
>
> ** A square circle must be round and simultaneously
> have four equal length sides, thus not be round.

That the halting problem defined in (a) is unsatisfiable
thus logically impossible causes this definition of the
problem to be rejected as invalid. It does not cause all
definitions to be rejected.

Everyone insists that H must report in the behavior of
the non-input of the direct execution of D(D) is unsatisfiable
thus incorrect.

When H reports on D correctly simulated by H such that H
must take into account that D does call H in recursive
simulation then this definition is satisfiable.

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

On 10/23/23 7:31 AM, olcott wrote:
> On 10/22/2023 10:41 PM, 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.
>>
>> ** A square circle must be round and simultaneously
>> have four equal length sides, thus not be round.
>
> That the halting problem defined in (a) is unsatisfiable
> thus logically impossible causes this definition of the
> problem to be rejected as invalid. It does not cause all
> definitions to be rejected.
>

What other definition is THE definition? I guess you think all truth is
relative and nothing is absolutely trye?

> Everyone insists that H must report in the behavior of
> the non-input of the direct execution of D(D) is unsatisfiable
> thus incorrect.

Nope. What is actually wrong with asking a program that claims to be a
"Halt Decider" from giving the actually correct answer to the actual
problem it is given, namely asking if the computation described by its
inputs will halt or not?

You seem to think that wrong answers are sometimes right!

>
> When H reports on D correctly simulated by H such that H
> must take into account that D does call H in recursive
> simulation then this definition is satisfiable.
>

Except THAT is the invalid statement, as H DOESN'T correctly simulate it
input by the ACTUAL definition of "Correct Simulatioh", namely that it
competely recreates the actual behavior of the actual machine described
by the input.

Thus, it is YOUR argument that is based in INCORRECT definitions, and
thus is INVALID.

YOURS is the logic that is accepting contradictions as valid answers.

YOUR logic is the one that says that things don't need to do what they
are required to do.

YOUR logic is what promotes things like disinformation, becuase you just
try to find "excuses" for why you don't need to give the actual correct
answer, and claim that is valid logic.

Your "Correct Reasoning" is thus proved to be a method to actually LIE.

That seems to be the only thing you know how to do.

Note again, you refuse to actually answer the chalanges, which is just
your own admission that you know your logic can't answer the errors
being pointed out, so you are just going to the method of the "Big Lie"
and just repeating the same unsupported claims, hoping that by repeating
the error enough, it will be taken as true.

You are just a pitiful ignorant pathological liar, who can't handle the
truth.

On 10/23/2023 9:31 AM, olcott wrote:
> On 10/22/2023 10:41 PM, 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.
>>
>> ** A square circle must be round and simultaneously
>> have four equal length sides, thus not be round.
>
> That the halting problem defined in (a) is unsatisfiable
> thus logically impossible causes this definition of the
> problem to be rejected as invalid. It does not cause all
> definitions to be rejected.
>
> Everyone insists that H must report in the behavior of
> the non-input of the direct execution of D(D) is unsatisfiable
> thus incorrect.
>
> When H reports on D correctly simulated by H such that H
> must take into account that D does call H in recursive
> simulation then this definition is satisfiable.
>

When we base the halt status decision on the definition in
(a) we are asking H to correctly answer a self-contradictory
question. That is the reason why (a) is not satisfiable.

Dishonest rebuttals will use the strawman deception to refer
to some other definition besides (a) in a dishonest attempt
to fake "prove" that (a) is not asking a self-contradictory
question.

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

On 10/23/23 8:37 AM, olcott wrote:
> On 10/23/2023 9:31 AM, olcott wrote:
>> On 10/22/2023 10:41 PM, 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.
>>>
>>> ** A square circle must be round and simultaneously
>>> have four equal length sides, thus not be round.
>>
>> That the halting problem defined in (a) is unsatisfiable
>> thus logically impossible causes this definition of the
>> problem to be rejected as invalid. It does not cause all
>> definitions to be rejected.
>>
>> Everyone insists that H must report in the behavior of
>> the non-input of the direct execution of D(D) is unsatisfiable
>> thus incorrect.
>>
>> When H reports on D correctly simulated by H such that H
>> must take into account that D does call H in recursive
>> simulation then this definition is satisfiable.
>>
>
> When we base the halt status decision on the definition in
> (a) we are asking H to correctly answer a self-contradictory
> question. That is the reason why (a) is not satisfiable.

But the ACTUAL question is: Does the Program Described by the input to
the decider Halt When Run?

That Question has a definite answer, since the decider it was built on
was a definite decider and thus has definite code and behavior, and thus
can NOT be "self-contradictory"

The "self-contradictory" question you create is because you don't
understand that H needs to be created and fixed before you can actually
ask the question, and your question is a different one, about how to try
to design

>
> Dishonest rebuttals will use the strawman deception to refer
> to some other definition besides (a) in a dishonest attempt
> to fake "prove" that (a) is not asking a self-contradictory
> question.
>
>

Right, the strawman deception is using the wrong definiton.

The ONLY correct definition is the one that refers to the ACTUAL
problem, which is the one you sort of describe in your (a), so you are
ADMITTING that your (b) mut be a dishonest attempt to fake a proof.

So, I guess you are admitting that your "Correct simulation by H"
version is just a lie, because it isn't the actual requriement, and that
H never actually does the "correct simulation" your requirement needs,
so it is just invalid.

On 10/23/2023 10:37 AM, olcott wrote:
> On 10/23/2023 9:31 AM, olcott wrote:
>> On 10/22/2023 10:41 PM, 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.
>>>
>>> ** A square circle must be round and simultaneously
>>> have four equal length sides, thus not be round.
>>
>> That the halting problem defined in (a) is unsatisfiable
>> thus logically impossible causes this definition of the
>> problem to be rejected as invalid. It does not cause all
>> definitions to be rejected.
>>
>> Everyone insists that H must report in the behavior of
>> the non-input of the direct execution of D(D) is unsatisfiable
>> thus incorrect.
>>
>> When H reports on D correctly simulated by H such that H
>> must take into account that D does call H in recursive
>> simulation then this definition is satisfiable.
>>
>
> When we base the halt status decision on the definition in
> (a) we are asking H to correctly answer a self-contradictory
> question. That is the reason why (a) is not satisfiable.
>
> Dishonest rebuttals will use the strawman deception to refer
> to some other definition besides (a) in a dishonest attempt
> to fake "prove" that (a) is not asking a self-contradictory
> question.

An incorrect question is any question that lacks
a correct answer from some infinite set of deciders.

Every instance of the infinite set of decider/input
pairs that match (a) gets the wrong answer because
Does your input halt on its input?
is a self-contradictory question for every element
of this infinite set.

When I refer to all the elements of an infinite set
and someone says that there is some other element of
this set that I did not refer to it is dead obvious
that they are lying.

--
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 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.

Anyhow, even if you don't understand why HP is considered significant, at least it's a good thing
that you finally acknowledge the result is correct. (Even if "only because blah blah blah" - the
point is it IS in fact correct, not so my /why/.)

Mike.

On 10/23/23 9:11 AM, olcott wrote:
> On 10/23/2023 10:37 AM, olcott wrote:
>> On 10/23/2023 9:31 AM, olcott wrote:
>>> On 10/22/2023 10:41 PM, 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.
>>>>
>>>> ** A square circle must be round and simultaneously
>>>> have four equal length sides, thus not be round.
>>>
>>> That the halting problem defined in (a) is unsatisfiable
>>> thus logically impossible causes this definition of the
>>> problem to be rejected as invalid. It does not cause all
>>> definitions to be rejected.
>>>
>>> Everyone insists that H must report in the behavior of
>>> the non-input of the direct execution of D(D) is unsatisfiable
>>> thus incorrect.
>>>
>>> When H reports on D correctly simulated by H such that H
>>> must take into account that D does call H in recursive
>>> simulation then this definition is satisfiable.
>>>
>>
>> When we base the halt status decision on the definition in
>> (a) we are asking H to correctly answer a self-contradictory
>> question. That is the reason why (a) is not satisfiable.
>>
>> Dishonest rebuttals will use the strawman deception to refer
>> to some other definition besides (a) in a dishonest attempt
>> to fake "prove" that (a) is not asking a self-contradictory
>> question.
>
> An incorrect question is any question that lacks
> a correct answer from some infinite set of deciders.

Right, but the actual question has a correct answer for every input
given to all those deciders. Just that all the deciders are themselves,
incorrect.

>
> Every instance of the infinite set of decider/input
> pairs that match (a) gets the wrong answer because
> Does your input halt on its input?
> is a self-contradictory question for every element
> of this infinite set.

No, for every instance of the infinite set of deciders, its input has a
correct answer, its just the decider doesn't give it.

What is "Self-contradictory" about the input. It is a SPECIFIC program
which has a definite answer, INDEPENDENT of the decider answering it.

Only when you try to change the question to assume that the given
decider must be coreect, do you get to "self-contradictory". This just
shows that you are trying to use a "Strawman", and that shows that you
should know you are just wrong.

That a given program gives the wrong answer doesn't mean the question
doesn't have an answer.

>
> When I refer to all the elements of an infinite set
> and someone says that there is some other element of
> this set that I did not refer to it is dead obvious
> that they are lying.
>
>

No, you are lying because confuse the question.

THe question is NOT "What answer does H need to give?", but "What is the
behavior of the program described by the input?".

YOU are the converting the question to the wrong question, and thus
making the Strawman.

There is no requirement in the question that H actually must get the
answer right, it only needs to get the answer right if it is to be
considered a correct decider, and the existance of a correct decider is
not assumed, and in fact, that is the question, does such a thing exist.

Since EVERY element of your set is a decider that is given an input that
has a correct answer, but the decider didn't give it, makes your set a
set of incorrect deciders, and thus the sub-set of the set which IS a
correct decider is empty.

Thus, since you argue that your set include every possible decider, you
have actually proven to proposition, that no such decider exists.

And AGAIN, since you refuede to actually answer the errors pointed out,
you are just admitting you don't have an answer to those errors and are
tactfully admitting you are wrong, but just trying the principle of the
"Big Lie" of repeating your erroneous statements over and over with the
hope that they mgiht get accepted just by the volume of the repetition.

This just shows that you are engaging in the same type of disinformation
that you claim you want to fight, showing yourself to be a ignorant
hypocritical pathological liar that doesn't understand a thing about
which they are talking.

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.

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

On 10/23/23 11:02 AM, 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.

Except that you are using a strawman question, so, as you yourself have
said, your arguement is invalid.

The ACTUAL question is: "Does the Computation described by the input Halt?"

Since for THIS H, H(D,D) returns non-halting, the computation described
by the input, that is D(D), will halt, and thus there IS a "Correct
Answer" to the actual question, and it is not "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.
>

Nope, more of your lies. You just don't understand what he agreed to,
since you don't seem to actually understand the technical meaning of the
words you usec.

Since your H doesn't do a "Correct Simulation" per the definiton of the
field, you can't claim that it can correctly determine what its
non-existant correct simulation would have done.

The ACTUAL correct simulation of the input shows that D(D) will Halt,
and thus H could not have "correctly determined" that it doesn't.

The ultimate problem is that you logic is based on the LIE that H could
do something other than what it was programmed to do.

You CAN look at the behavior of an alternate program (which you
deceptively try to also call H) which doesn't do the abort, but the
input will still be based on the ORIGINAL program H, which does what
this program eventually does do. Since this program aborts its
simulation and returns 0, which makes D(D) halt, so this alternate
program, if it doesn't abort its simulation, will see that D(D) calls
H(D,D) and then this simulated H will simulate to the point that the
original/actual H aborts its simulation, and returns 0, and then the
simulated D will Halt.

Thus, the CORRECT determination of what a "Correct Simulation" by a
variant of H that doesn't abort its simulation, would be that it Halts,
which isn't what you H actually does, so it violated its design criteria
and gave the wrong answer.

The fact that it is impossible to make a program do the operation
doesn't make the question or specification "invalid", but make it
"non-computable". There IS an answer, it just can't be produced by any
program.

This goes back to your fundamental logical issue. You think that if
something can't be programmed/known, it can't be valid/true, but that is
NOT how logic works.

You can try to limit your system to obey such a restriction, but that
severely limits your system, so for programming it can't be "Turing
Complete", and for logic, it means it can't handle the properties of the
Natural Numbers. Such systems do exist, and apply to very restricted
sets of problems, but are generally too weak to be used for more general
applications.

Your inability to understand this, just shows how limited your ability
to reason, as apparently, you can't see that the real world needs more
than those very weak systems to think about them.

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.

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

On 10/23/23 11:49 AM, 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.
>

Why do you say that?

There IS a correct answer for any specific input (to the actual question).

Note, to make that input for the case described, the decider has to
first be defined, and thus the behavior of H(D,D) specified, and thus
the behavior of D(D) defined.

Once that happens, it just turns out that H is wrong.

In this sample case, H(D,D) is Non-Halting, and D(D) Halts.

Correct answer exists, and might be given by a different decider, but
this H is just wrong.

A program being wrong isn't an illogical thing, so we don't have a
contradiction.

The contradiction you reach is when you INCORRECTLY ASSUME that H must
be right. There is norequirement that we can actually make the decider
described, and in fact the ultimate question is CAN such a decider be
created.

Your inability to undertand that some things are just uncomputable, just
as some truths are unprovable, just shows the limitiation in your mind.

You are just showing that you are too stupid to understand how the logic
works, because you can't comprehend things that are too abstract for you.

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.

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

On 10/23/23 12: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.
>

So, you are just admitting that you can't answer the errors that I have
pointed out so many times, but just keep repeating you same erroneous
claims.

Just shows how stupid you are.

As I said, you you haven't respoded to, because you just can't:

Why do you say that?

There IS a correct answer for any specific input (to the actual question).

Note, to make that input for the case described, the decider has to
first be defined, and thus the behavior of H(D,D) specified, and thus
the behavior of D(D) defined.

Once that happens, it just turns out that H is wrong.

In this sample case, H(D,D) is Non-Halting, and D(D) Halts.

Correct answer exists, and might be given by a different decider, but
this H is just wrong.

A program being wrong isn't an illogical thing, so we don't have a
contradiction.

The contradiction you reach is when you INCORRECTLY ASSUME that H must
be right. There is norequirement that we can actually make the decider
described, and in fact the ultimate question is CAN such a decider be
created.

Your inability to undertand that some things are just uncomputable, just
as some truths are unprovable, just shows the limitiation in your mind.

You are just showing that you are too stupid to understand how the logic
works, because you can't comprehend things that are too abstract for you.

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*

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

On 10/23/23 1: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*
>
>

Your still just repeating your erroneous statements, and not answering
the errors pointed out. I guess this just shows that you have no idea
how to show what you think, but you insist it must be correct, without
actually having any actual grounds to make that claim.

You are still using UNSOUND logic, apparently because your own mind is
unsound.

The question:

"Does the Computation describe by the input Halt?" is NOT
"self-contradictiory", as, once you can actually ask that question, it
has an answer.

Remember, the input doesn't exist until it is created, and to create the
input you are talking about, you first need to choose the decider it is
to refute. Having done that, the input represents a specific machine,
which will have a specific behavior.

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.

All self-contradictory questions are incorrect questions.

*The inability to correctly answer incorrect questions*
*does not place any real limit on anyone or anything*

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

On 10/23/23 2: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.

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.