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

On 5/11/25 9:56 PM, olcott wrote:

On 5/11/2025 8:27 PM, Richard Damon wrote:

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

 _DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

Not a valid input,

 Show all the steps of DDD emulated by simulating
termination analyzer HHH according to the rules
of the x86 language where the emulated DDD reaches
its "ret" instruction.

Why? That isn't the criteria.

 You can't only because you know that you are
lying about this.

No, I am pointing out your stupidity, and you just repeat it to make it more obvious.

 Your static data trick was clever yet your HHH
was not a simulating termination analyzer.
 

Sure it was. At the outer layer it fully emulates its input.
That is more than yours does.
Of course, your concept of that is just a category error and a lie.