Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD)

On 5/11/25 8:48 PM, olcott wrote:

On 5/11/2025 7:38 PM, Mike Terry wrote:

On 11/05/2025 18:11, Richard Heathfield wrote:

On 11/05/2025 17:44, olcott wrote:

Any yes/no question where both yes and no are the
wrong answer is an incorrect polar question.

>
Either DD stops or it doesn't (once it's been hacked around to get it to compile and after we've leeched out all the dodgy programming).

>
Done that.  It still stops.
>

>
If the computer cannot correctly decide whether or not DD halts,

>
The decider says it doesn't stop..
>

we have an undecidable computation,

>
No no, that doesn't make sense.  DD stops, and there are lots of partial halt deciders that will decide that particular input correctly.  PO's DD isn't "undecidable".
>
No single computation can be undecidable, considered on its own!  There are only two possibilities: it halts or it doesn't.  In either case there is a decider which decides that /one specific input/ correctly. By extension, any finite number of computations is decidable - we just have a giant switch statement followed by returning halts/neverhalts as appropriate.  If the input domain has just n inputs, there are 2^n trivial deciders that together cater for every combination of each input halting or never halting.  One of those deciders is a correct decider for that (finite domain) problem.
>
The HP is asking for a TM (or equiv.) that correctly decides EVERY (P,I) in its one finite algorithm.  That is what is proven impossible.  The trick of having a big switch statement no longer works because there are infinitely many possible inputs.
>
Decidability for just one single input is trivial and not intersting.
>

and therefore some computations are undecidable, so Turing's conclusion was right. Who knew? (Apart from practically everybody else, I mean.)

>
>
Mike.

 DDD emulated by HHH according to the rules of
the computational language that DD is encoded
within already proves that the HP "impossible"
input specifies a non-halting sequence of
configurations.

No it doesn't.
First, we need to add the specified HHH to the code of DDD, or you just can do anything you talk about (and this make every HHH get a different DDD since it will be paired with that HHH and thus different then the DDD given to some other HHH). You have admitted that you whole system is just a category error, but we will fix it an move on.
Then, since HHH(DDD) returns 0, as you have stipuled it does to be correct, then it doesn't, by simple inspection and definition. do the required correct simulation by the rules of the system, since it aborts its simulation. The computational language does not allow a correct emulation to stop prematurely.
In addition, the actual correct emulation of this input *WILL* halt, as will the direcr execution of the program it represents, and since that *IS* the definition of the behavior that the decider is supposed to be answering on, it is just wrong, and you are shown to be just a stupid liar that is just showing he doesn't knwo what his words mean.

 The same goes for the Linz proof.

Right, H <H^> <H^> is wrong to say non-halting as H^ <H^> will use its copy of H applied to <H^> <H^> see that it went to qn and then it will halt.
The fact that H's emulation of H^ didn't get to that point is irrelevent, just the final results.

 The mistake is continuing to assume that a
termination analyzer must report on behavior
other than the behavior that its input specifies.

But the behavor of its input *IS* the behavior of running the program the input specifies, which is exactly what you are trying to deny.
The behavior you are talking about, the behavior of only a partial emulation of the input, confused with the behavior of diffferent inputs that have some relationship to this one is just not the behavior specified, execpt by your lies.

 When an input is simulated according to
the behavior specified by the computation
language that it is encoded within
THEN THIS SIMULATION IS CORRECT.
It seems nuts (or dishonest) to claim otherwise.
 

Right, and that is NOT the results of the partial simulation done by HHH, but the actual correct simulation done by giving that exact input (which still calls the HHH that does the aborting that the HHH you claim is correct does) and thus we see DDD calll HHH(DDD) which will emulate DDD for some number of steps, then abort its emulation because it (erroneously) thinks that the input represent a non-halting program due to a incorrect pattern programmed into it, and it then returns to DDD which then halts.
Thus the input must be Halting, and the decider wrong as it said non-halting.
It seems you don't understand the rules fo the x86 processor (or any computer).