Re: HP counter-example INPUT cannot possibly exist

Op 24.jun.2025 om 16:48 schreef olcott:

On 6/24/2025 3:08 AM, Mikko wrote:

On 2025-06-23 15:26:33 +0000, olcott said:
>

On 6/23/2025 1:55 AM, Mikko wrote:

On 2025-06-22 16:28:47 +0000, olcott said:
>

On 6/22/2025 2:59 AM, Mikko wrote:

On 2025-06-21 15:49:30 +0000, olcott said:
>

On 6/21/2025 3:20 AM, Mikko wrote:

On 2025-06-20 16:54:32 +0000, olcott said:
>

On 6/19/2025 3:17 AM, Mikko wrote:

On 2025-06-18 16:05:33 +0000, olcott said:
>

On 6/18/2025 10:57 AM, joes wrote:

Am Wed, 18 Jun 2025 09:39:02 -0500 schrieb olcott:

On 6/16/2025 3:21 AM, Mikko wrote:

On 2025-06-15 14:44:47 +0000, olcott said:

On 6/15/2025 4:19 AM, Mikko wrote:

On 2025-06-13 15:33:45 +0000, olcott said:

On 6/13/2025 5:37 AM, Mikko wrote:

>

As you respond to my question without answering it it is obvious
that you don't see any proofs in your article.

>
It is a fact that there is no actual input D to any termination
analyzer H that does the opposite of whatever value that H derives.
The key element that all conventional HP proofs depend on cannot
possibly exist.

>
Nonsense is not a fact.

>
After studying these things for 22 years I found that every
conventional proof of the halting problem never provides an actual
input that would do the opposite of whatever value that its partial
halt decider (PHD) returns.

>
The core part of those proofs is a constructive specification of that
test case.
>

Yet no one ever noticed that the counter-example input cannot even be
constructed thus the proof itself never actually existed.

In what sense? The code for DDD is clearly in your repository.

>
There has never been any HP proof that has
ever defined *AN ACTUAL INPUT* to a termination
analyzer that can possibly do the opposite of
whatever value that this termination analyzer
determines.

>
Of course a proof of the halting problem does not define anything
for a termination alayzer. Termination anlyzers are not a relevant
for any proof (or other discussion) about the halting problem.
>

>
Simulating termination analyzer are equivalent to
a partial halt deciders.

>
If they are they should be called "simulating partial halt deciders".

>
That is too confusing for most of my reviewers.

>
It is long but there is no evdence that it would be confusing. Those

>
Most reviewers here don't even understand that halting
is only defined as reaching a final halt state.

>
It seems that you can't understand what others write as a response.
You never show any signs of understanding.
>
If others don't understand your writing as intended then your writing
is not clear enough. People who do not understand some detail often
ask for clarifications but you never clarify what is asked.

>
I stop at their first counter-factual mistake because
people here have a very hard time fully addressing one
single point.
>
They keep flitting back and forth over many different
points to permanently avoid fully addressing one single
point.

>
That is typical to USENET discussions. But you are free to stick
to whichever point you want. If you can't that's your problem.
>

Every time anyone makes a provably counter-factual
statement it is certain that they are not understanding.

>
No, it is not. A counter-factual hypothesis is a valid tool of
rational thinking.
>
You focus too much on understanding. More important is that you write
in a way that can be understood. Too often your writing style looks
like your intent is that the reader fails to notice that your words
don't make sense.
>

 void DDD()
{
   HHH(DDD);
   return;
}
 *This is the question that HHH(DDD) correctly answers*
Can DDD correctly simulated by any termination analyzer
HHH that can possibly exist reach its own "return" statement
final halt state?
 Since any first year CS student can see that DDD
simulated by HHH cannot possibly reach its own
"return" statement final halt state, then everyone
not seeing this has proven to have insufficient
technical competence to evaluate my work.
 

Why repeating the obvious? Everyone here understands that HHH fails to reach the end of the simulation, where other simulators have no problem to reach the end of exactly the same input.