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

On 12/05/2025 02:25, Richard Heathfield wrote:

On 12/05/2025 01:38, 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.

 And you still had code left?
 

It still stops.

 Okay.
 

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

>
The decider says it doesn't stop..

 I said "cannot >>>correctly<<< decide".

There are infinitely many deciders that could be given the input.  Some of them decide that particular input correctly, and some incorrectly.
PO's HHH is one of the ones that decide incorrectly.
Saying ".. /cannot/ correctly decide.." suggests you may be thinking about something the wrong way. HHH and DD are fixed machines with fixed implementations.  They both do only one thing, which is what their code dictates:  DD halts, and HHH(DD) returns non-halting, which is incorrect.  If HHH's algorithm is somehow cloned and amended to make a different decider HHH2, then perhaps HHH2(DD) can return "halts" for DD, but HHH2 is not HHH.

 

>

we have an undecidable computation,

>
No no, that doesn't make sense.

 Agreed. Therefore, even *after* taking out all the dodgy code, the decider must be broken.

PO's HHH is broken as a halt decider, because it decides the (<DD>) input incorrectly.

 

 DD stops, and there are lots of partial halt deciders that will decide that particular input correctly.  PO's DD isn't "undecidable".

 I hear what you're saying (or at least I see what you typed), but if DD's result is so decidable, how come his decider can't correctly decide?

/can't/ ?   Remember HHH is one specific program, and it only does one thing.  So it would be more reasonable to say it /doesn't/ correctly decide DD.  If it simulated more steps (*processing the same input*) it /would/ see the normal end of the simulation, but that is just not the way his HHH is coded.
We can imagine taking a new decider HHH2 which correctly decides DD [which calls HHH, remember, not HHH2].  The problem is that the HP proof tells us how to generate from /that/ HHH2 a /new/ input DD2 which HHH2 will decide incorrectly!
So to answer your question /why/ does PO's HHH decide DD incorrectly, there's no great mystery:  DD was constructed based on PO's HHH deliberately so that HHH will get it wrong.  See the order: PO wrote his decider, /then/ the input DD was constructed which it gets wrong.  That is how the HP proof works, so you need to be perfectly clear how that proof works...
PO tries to suggest there is only one DD, which /all/ possible HHH decide incorrectly.  That's all wrong.  Each candidate HHH has its own DD that it can't decide.  PO likes to call them all "DD" which encourages his misconception.

 

No single computation can be undecidable, considered on its own! There are only two possibilities: it halts or it doesn't.

 Or both, it seems. You say it halts (and I would not hesitate to take you at your word if the alternative is to dredge up a Windows system from somewhere). Olcott says it is non-halting.
 And we both know it /can't/ be both...

Of course.  PO knows that DD() will halt when run directly from main().  More concisely, DD "halts" (as the term is defined in the halting problem).
When his HHH simulates DD, it spots a pattern in the simulation which PO calls his "infinite recursive simulation" pattern.  PO believes that this pattern "specifies non halting behaviour" but it does not, as it can match for both halting and non-halting computations.  Anyhow, PO has coded HHH to abort and return non-halting if it sees that pattern.  He really really really believes that pattern "specifies non halting", despite observing with his own eyes DD halting when called directly!  The rest of his arguments are just attempts to justify why HHH is "correct" to decide non-halting, despite DD halting.  They generally amount to something like "during simulation my HHH detected non-halting behaviour, so it is correct to decide non-halting".
Of course, the simple answer here is that his program /did not/ see non-halting behaviour; what it /did/ spot was his (unsound) "infinite recursive simulation" pattern, but to PO that is as good as saying DD will never halt.
Mike.