Re: 195 page execution trace of DDD correctly simulated by HH0 ---Boilerplate Reply

Am Fri, 21 Jun 2024 12:22:04 -0500 schrieb olcott:

On 6/21/2024 12:09 PM, Richard Damon wrote:

On 6/21/24 1:04 PM, olcott wrote:

On 6/21/2024 10:25 AM, Richard Damon wrote:

On 6/21/24 10:44 AM, olcott wrote:

On 6/21/2024 9:02 AM, Richard Damon wrote:

On 6/21/24 9:01 AM, olcott wrote:

On 6/21/2024 2:44 AM, Fred. Zwarts wrote:

Op 20.jun.2024 om 16:12 schreef olcott:

On 6/20/2024 3:09 AM, Fred. Zwarts wrote:

Op 20.jun.2024 om 02:00 schreef olcott:

If the simulation of a program with a loop of 5 iterations is
aborted after 3 iterations, all instructions are correctly
simulated. Nevertheless, it is an incorrect simulation, because
it should simulate up to the final state of the program.

First, NO ONE has said that *H* (or what every you are calling your
decider today) can correct simulate the input to a final state.

When there is no mapping from the finite string x86 machine language
input to H(D,D) to the behavior of D(D) then H(D,D) IS NOT being asked
about the behavior of D(D).

It means that H can't do the mapping, i.e. it is not simulating correctly.
It does a different map that doesn't fit its specification.

Not even being asked about the behavior of D(D) is not the same
situation as:
the logical impossibility of specifying a halt decider H that correctly
reports the halt status of input D that is defined to do the opposite of
whatever value that H reports.
Of course this is impossible.

Thank you. So what are we arguing about?

Nothing says that the decider has to actually be ABLE to answer the
question, only that the answer exists. Uncomputable problems just can't
be solved with a computation.

QFT

--
Man kann mit dunklen Zahlen nicht rechnen. Für die eigentliche Mathematik
sind sie vollkommen nutzlos. --Wolfgang Mückenheim