Re: I call it a halting decidability decider, and thus isn't actually a computability decider.

On 8/5/24 10:29 PM, olcott wrote:

On 8/5/2024 8:32 PM, Richard Damon wrote:

On 8/5/24 8:55 PM, olcott wrote:

On 8/5/2024 5:59 PM, Richard Damon wrote:

On 8/5/24 9:46 AM, olcott wrote:

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
>

>
Nope, since the criteria is not a avalid criteria, as it is a subjective criteria, and NOT a property of JUST the input.

>
A freaking actual execution trace is not freaking subjective.
>

>
If the trace depends on who does it, it is.
>

 There is no freaking subjectively to a sequence of x86 instructions.
DDD correctly emulated by every HHH never reaches its own "return".
This as as much a tautology as 2 + 3 = 5.
 

Then how does the exact same trace tell one decider that it can't get an answer, while it tells another that it can?
Or, if the traces are different, what instruction was actually correctly emualated per the definition of the x86 instruction set to get a different results?
Note, replacing the call HHH with something other than the actual x86 instruction level emulation of HHH, is not a correct x86 emulation.
Your problem is you are trying to redefine the meaning of correctly emulate to be something that is itself subjective, thus breaking your own definitions.
You are just proving your utter stupidity, and that you are nothing but a pathological liar that reckless disregards the truth because he doesn't dare look at it because it will prove he wasted his life.