Re: HHH decides a trivial non-semantic non-property of its input

On 8/7/24 9:23 AM, olcott wrote:

On 8/7/2024 2:06 AM, Mikko wrote:

On 2024-08-05 13:46:11 +0000, olcott said:
>

On 8/5/2024 8:44 AM, Python wrote:

Le 05/08/2024 à 13:50, olcott a écrit :

On 8/5/2024 3:08 AM, Mikko wrote:

On 2024-08-04 14:46:02 +0000, olcott said:
>

When we define an input that does the opposite of whatever
value that its halt decider reports there is a way for the
halt decider to report correctly.
>
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
>
int main()
{
   HHH(DD);
}
>
HHH returns false indicating that it cannot
correctly determine that its input halts.
True would mean that its input halts.

>
That is called a "partial halt decider". The set of requirements is
a subset of the requirements for "halt decider" but still require
that the answer is not "halts" if the input does not halt and that
the answer is not "does not halt" if the input halts. The difference
is that a "halt decider" is required to give one of these answers
for every input but a "partial halt decider" is not.
>
For every computation there is a partial halt decider that answers it.
>

>
I call it a halting decidability decider.
1=input halts
0=input does not halt or has pathological relationship with its decider

>
So it is NOT an halt decider. Case closed. You've lost your time
for years, and made a lot of people lose their time too.
>
>
>

>
It refutes Rice

>
No, it does not. Nothing is refuted as long as you have not proven anything.
>

 1 = halts = good input = decidable
0 = (not halts or pathological) = bad input = not decidable as halting
HHH decides a non-trivial semantic property of its input.
 

ONe thing you don't seem to understand is that "Decidability" isn't a property of an input, but of the whole problem. Given a problem, each input HAS a correct answer, and thus we can make a machine that will give that answer.
Being non-decidable is a property of the whole problem.
For the Halting Problem, you confuse the design problem with the verification problem.
We dont even HAVE an input H^/P/D until you have chosen and completely fixed and defined the decider you want to claim to be correct, and thus you can not talk about what it "should" or "could" do, only what it DOES, and if that answer it the CORRECT one.
It doesn't matter what a different decider would do with a different input (which the pathological template generates for that other decider) as it isn't the same as THIS input, since each input contains the FULL description that defines ALL the code used, including its copy of the decider that it is confounding.
Thus, you claim fails at the level of an initial category error before you even get off the ground.