Re: Computable Functions --- OUTPUTS MUST CORRESPOND TO INPUTS

On 4/23/25 11:32 AM, olcott wrote:

On 4/23/2025 6:25 AM, joes wrote:

Am Tue, 22 Apr 2025 13:51:48 -0500 schrieb olcott:

On 4/22/2025 1:07 PM, Fred. Zwarts wrote:

Op 22.apr.2025 om 18:28 schreef olcott:

On 4/22/2025 7:57 AM, joes wrote:

Am Tue, 15 Apr 2025 15:44:06 -0500 schrieb olcott:

>

You continue to stupidly insist that int sum(int x, int y) {return x
+ y; }
returns 7 for sum(3,2) because you incorrectly understand how these
things fundamentally work.
>
It is stupidly wrong to expect HHH(DD) report on the direct
execution of DD when you are not telling it one damn thing about
this direct execution.

What else is it missing that the processor uses to execute it?
>

libx86emu <is> a correct x86 processor and does emulate its inputs
correctly.

>
The key thing here is that Olcott consistently does not understand that
HHH is given a finite string input that according to the semantics of
the x86 language specifies a halting program,

>
That is stupidly incorrect.

No, DD halts (when executed directly). HHH is not a halt decider, not even
for DD only.
>

People here stupidly assume that the outputs are not required to
correspond to the inputs.

But the direct execution of DD is computable from its description.
>

 Not as an input to HHH.

But neither the "direct execution" or the "simulation by HHH" are "inputs" to HHH. What is the input is the representation of the program to be decided on.

When HHH computes halting for DD is is only allowed
to apply the finite string transformations specified
by the x86 language to the machine code of DD.

It is only ABLE to apply them.
The REQUIREMENT to be correct are not limited to computable transformation.
The Halting Function will map the finite string representation of DD to Halting, since you have indicated that HHH will transform the representation of DD to a string indicating non-halting, and DD will then map that non-halting indication to a halting behavior.
That HHH transformed the input to the wrong string for what the Halting Mapping defined, just says it isn't a correct Halting Decider, but maybe is a correct POOP decider it that is houw you are defining your other problems mapping.

 Because DD DOES CALL ITS OWN EMULATOR this does require
the behavior measured is DD emulating by HHH including
HHH emulating itself emulating DDD.

No. because that isn't what HHH does. HHH needs to see DD calling HHH(DD) as asking HHH what it will answer about that input.
One problem is that you keep on saying you are going by the x86 instruction set, and that says NOTHING like what you are claiming. HHH sees a call HHH instruction inside DD, and thus the only correct simulation would be to go into HHH (assuming it is part of the input, if not then it just can't do a correct x86 simulation). And after each instruction, the only correct simulation is to simulate the next instruction.
If HHH is defined to be a correct simulator, then it is not allowed to stop and return, as that isn't the behavior of a correct simulator (which means it can't have that definition and also be a decider)
If HHH is defined to be a decider, and thus must stop, then is have admitted that it isn't a correct simulation, and thus it doesn't determine the behavior of its input, which is DEFINED based on the direct exectution or COMPLETE and correct simulation of that input.
If its criteria is to answer based on it own correct simulation, then the criteria is just proven to be incorrect and self-contradictory. That is why in the ACTUAL problem, the behavior the answer is based on is NOT what the decider gets from its simulation, but what the actual direct exectuion would be, which is an objective standard.

 Anyone that disagrees merely proves their own lack
of understanding that computable functions are only
allowed to apply finite string transformations to inputs.
 

So? HHH *WILL* do some finite string transformation, and when it sees DD use its copy of HHH, that same finite string transformation is all can correctly see happen.
Since HHH(DD) return non-halting, that is the only CORRECT interpreation of that call, if HHH can't figure that out, then it is just working off incorrect assumptions.
The problem you have is that you are just FALSELY ASSUMING that the function that HHH is being asked to compute is computable. In fact, the meta-question of the problem is the question of IF it IS computable, and it turns out that the answer is no, and no such decider can exist that is correct for all inputs.
The fact that HHH needs to be actually correct seems to be beyond your understanding, in part because you don't understand what truth actually is.