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

Ben Bacarisse <ben@bsb.me.uk> writes:

Richard Heathfield <rjh@cpax.org.uk> writes:
>

On 12/05/2025 01:38, Mike Terry wrote:

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

...

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.
>

 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?

>
This is just a misunderstand about terms.  The fact that some program
gets the answer wrong does not mean that this case is not (correctly)
decidable.  Every halting problem instance is decidable.  One of these
two programs correctly decides every instance:
>
int main(int argc, char **argv) { return 0; }
int main(int argc, char **argv) { return 1; }

Sorry.  I did not read far enough.  Mike makes the same point:

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.

This is very odd.  You know it either halts or it does not halt so what
do you mean by "Or both, it seems."?

And we both know it /can't/ be both...

--
Ben.