Re: HHH(DD) --- COMPUTE ACTUAL MAPPING FROM INPUT TO OUTPUT --- Using Finite String Transformations

On 4/23/25 11:34 PM, olcott wrote:

On 4/23/2025 7:31 PM, Mike Terry wrote:

On 23/04/2025 16:38, olcott wrote:

On 4/23/2025 10:28 AM, Mike Terry wrote:

On 23/04/2025 10:02, Fred. Zwarts wrote:

Op 22.apr.2025 om 21:50 schreef olcott:

On 4/22/2025 2:30 PM, Fred. Zwarts wrote:

Op 22.apr.2025 om 21:14 schreef olcott:

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

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

>
a function is computable if there exists an algorithm
that can do the job of the function, i.e. given an input
of the function domain it can return the corresponding output.
https://en.wikipedia.org/wiki/Computable_function
>
On Turing Machines inputs <are> finite strings, and
finite string transformation rules <are> applied to
these finite strings to derive corresponding outputs.
>

And it has been proven that no finite string transformations are possible that report the halting behaviour for all inputs that specify a correct program.

>
int sum(int x, int y) { return x + y; }
Only when people stupid assume the same thing as
sum(3,2) should return the sum of 5 + 3.
>

Therefore HHH should report on the actual input, the finite string that describes a halting program. Not on the hypothetical input that does not halt, because it is based on a hypothetical HHH that does not abort.
>
Why do you maintain that HHH should process the hypothetical input instead of the actual input.
Do you really believe that 3+2 equals 5+3?

>
I have proven that the directly executed DD and DD
emulated by HHH according to the semantics of the
x86 language have a different set of state changes
many hundreds of times for several years.

You never showed a proof. You only repeated a dream. You are dreaming many years without any logic. You failed to show the first state change where the direct execution is different from the simulation. You only showed an erroneous HHH that fails to reach the end of the simulation of a halting program.

>
Worse than this, on more than one occasion I've actually posted traces of computation DDD(DDD) executed directly and simulated by HHH side by side.  Both traces were of course /identical/, up to the point where HHH stops simulating.

>
*Factually incorrect* (You are usually very careful about these things)
The call to HHH(DD) from the directly executed DD returns.
The call to HHH(DD) from DD emulated by HHH cannot possibly return.
>

>
...because HHH stops simulating before reaching that step in the computation.  Note that I said
>
MT:  Both traces were of course /identical/,
      *up to the point where HHH stops simulating*
>
So I was factually correct.
>
>
Mike.
>

 It *is not* up to the point where HHH stops simulating.

But is once HHH stops. It is a fact that HHH stops before getting to the end of the correct simulation, and sees nothing besides what is on the correct simulation till it stops, so has nothing to correctly claim that the results will be different than the actual correct simulation.
Note, one problem with your problem setup is you want the input to exclude having the code for HHH in it, and thus the input is actually invalid, as it is thus impossible to correct simulate the code per the x86 language, as the call HHH refers to code that is not part of the input, and thus the behavior is undefined.

 It is up to the point where the simulated versus directly
executed calls HHH(DD).

And then HHH makes an error in its presumption about that call. The programmer of HHH has presumed that calls to HHH(DD) will not return, when it is a fact that calls to HHH(DD) will return 0, since that is the result of what you code for HHH does.

 This call immediately from the directly executed DD and
cannot possibility return from DD emulated by HHH according
to the finite string transformation rules of the x86 language.

No, by the rules of the x86 language, both will do exactly the same thing, HHH Just in unable to determine what the x86 language specifies foer this call, because its code takes a wrong turn at this point, because its programmer made a wrong assumption here.

 HHH doesn't stop simulating DD until one recursive emulation
later on.
 

And still stop simulating before it gets to the end which a CORRECT simulator will reach.