Re: Computable Functions --- finite string transformation rules

On 4/23/25 11:22 PM, polcott333 wrote:

On 4/23/2025 9:41 PM, Richard Damon wrote:

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 input to HHH(DD) does specify the recursive emulation
of DD including HHH emulating itself emulating DD when
one applies the finite string transformation rules of the
x86 language to THE INPUT to HHH(DD).

Yes, the input specifies FINITE recusive PARTIAL emulation, as the HHH that DD calls will emulate only a few instructions of DD and then return,
Of course, part of the problem is that in your input you exclude the code for HHH, and try to make it only implicit, which isn't allowed. HHH can not assume behavior for the HHH it sees except by what is defined in the input, or by the rules of the environment.

 You can't pop any other execution trace from the input
to HHH(DD) than that.
 

You can get *ANY* trace of the input beyond the call to HHH, as HHH isn't defined in the input.
If you include HHH in the input, then the actual execution trace of the input, as exactly shown by an actual correct emulation of it, will see that DD calls HHH(DD), which will emulated its input for a while then stop and return 0, and then DD will halt.
Now, HHH's problem is it stops before it get there, as that is what its code says to do, as seen in what is now part of the input you have defined, and thus it needs to "guess" as to the answer, and DD is programmed so what ever HHH guesses will be wrong.
Your problem is you just don't undetstand the fundamental of the problem, logic, or truth,