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

On 4/25/2025 9:06 AM, joes wrote:

Am Thu, 24 Apr 2025 12:46:14 -0500 schrieb olcott:

On 4/24/2025 3:11 AM, Fred. Zwarts wrote:

Op 24.apr.2025 om 05:34 schreef olcott:

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

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

Does HHH abort after or before the call to itself?
>

That is exactly the same point. If not, show the difference in the
traces before that point.

>
As soon as the directly executed DD calls HHH(DD) this call immediately
returns.

Why doesn't it return when simulated?

  Because this is logically impossible.
 

Why are squares not round?
Because this is logically impossible.
 

Why doesn't the direct call
simulate DD calling HHH(DD)?
>

When DD emulated by HHH calls HHH(DD) then HHH emulates DD and also
emulates itself emulating DD. This is one whole recursive emulation than
the directly executed DD can possibly get to.