Re: HHH(DD) --- COMPUTE ACTUAL MAPPING FROM INPUT TO OUTPUT --- Ignoramus !!!

On 4/30/2025 11:28 AM, olcott wrote:

On 4/29/2025 4:49 AM, Mikko wrote:

On 2025-04-28 15:52:13 +0000, olcott said:
>

On 4/28/2025 4:01 AM, Mikko wrote:

On 2025-04-16 17:36:31 +0000, olcott said:
>

On 4/16/2025 7:29 AM, Richard Heathfield wrote:

On 16/04/2025 12:40, olcott wrote:

sum(3,2) IS NOT THE SAME AS sum(5,2).
IT IS EITHER STUPID OR DISHONEST FOR YOU TO TRY TO
GET AWAY FOR CLAIMING THIS USING THE STRAW DECEPTION
INTENTIONALLY INCORRECT PARAPHRASE OF MY WORDS.

>
Whether sum(3,2) is or is not the same as sum(5,2) is not the question. The question is whether a universal termination analyser can be constructed, and the answer is that it can't.
>
This has been rigorously proved. If you want to overturn the proof you've got your work cut out to persuade anyone to listen, not least because anyone who tries to enter into a dialogue with you is met with contempt and scorn.
>
The proof stands.
>

>
*corresponding output to the input*
*corresponding output to the input*
*corresponding output to the input*
*corresponding output to the input*
*corresponding output to the input*
>
Not freaking allowed to look at any damn thing
else besides the freaking input. Must compute whatever
mapping ACTUALLY EXISTS FROM THIS INPUT.

>
A halt decider is is not allowed to compute "whatever" mapping. It is
required to compute one specific mapping: to "no" if the computation
described by the input can be continesd forever without halting, to
"no" otherwise.

>
It must do this by applying the finite string transformation
rules specified by the x86 language to the input to HHH(DD).

>
No, it needn't. A halt decider cannot do other than certain finite string
operations. No relation to x86 language is required.
>

This DOES NOT DERIVE THE BEHAVIOR OF THE DIRECTLY EXECUTED DD.

>
Whether the execution is "direct" or otherwise is irrelevant. A computation
either halts or not. A halt decider must just tell whether the somputation
halts. It is true that no Turing machine can determine this about every
computation, i.e., no Turing machine is a halt decider.
>

It DOES DERIVE DD EMULATED BY HHH AND ALSO DERIVES THE RECURSIVE
EMULATION OF HHH EMULATING ITSELF EMULATING DD.

>
Which are not mentioned in the halting problem.
>

 When understand rather than simply ignore the HHH/DD
example it can be seen that every conventional halting
problem proof

Which starts with the assumption that these requirements can be met:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly

suffers the same fate. The contradictory
part of the "impossible" input IS NEVER REACHABLE.

And because there is a contradiction, the assumption that the above requriements can be met is is proven false, as show by Linz and you have *explictly* agreed is correct.

 int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
 It took several C programmers only a few minutes to see this.
The same thing applies to the Peter Linz proof.
 Unlike the HHH/DD example the Linz proof lacks a fully
specified termination analyzer written in a language that
has a complete definition.

Irrelavant, because *no* assumptions are made about how HHH is implemented.

 Replacing the code of HHH with an unconditional simulator and subsequently running HHH(DD) according to the finite string
transformation rules of the x86 language DOES NOT HALT!
 

Obviously, but that changes the input.
Changing the input is not allowed.