Re: How Partial Simulations correctly determine non-halting ---Ben's 10/2022 analysis

On 6/9/2024 10:13 AM, Mikko wrote:

On 2024-06-09 14:03:08 +0000, olcott said:
 

On 6/9/2024 3:52 AM, Mikko wrote:

On 2024-06-08 13:46:07 +0000, joes said:
>

Am Sat, 08 Jun 2024 08:04:14 -0500 schrieb olcott:

On 6/8/2024 1:42 AM, Mikko wrote:

On 2024-06-07 22:26:05 +0000, olcott said:

On 6/7/2024 4:00 PM, joes wrote:

Am Fri, 07 Jun 2024 09:47:35 -0500 schrieb olcott:

On 6/7/2024 1:30 AM, Mikko wrote:

On 2024-06-06 15:31:36 +0000, olcott said:

On 6/6/2024 10:14 AM, Mikko wrote:

On 2024-06-06 13:53:58 +0000, olcott said:

On 6/6/2024 5:15 AM, Mikko wrote:

On 2024-06-05 13:29:28 +0000, olcott said:

On 6/5/2024 2:37 AM, Mikko wrote:

On 2024-06-04 18:02:03 +0000, olcott said:

>

Any finite string can be an input to some Turing machine.
Can you prove that a Turing machine is not a finite string?

By definition Turing Machines are not finite strings in the conventional
model. In my x86utm model of computation x86 machine language <is> the
input to another function written in the x86 language.

In your model, the machine code is also finite.
>

Your own attempts of a conter-proof are not about Turing machines but C
programs. C programs are finite strings, so a C program is a valid
input to a C program (and a Turing machine, too).

They are about Turing Machines yet cannot be sufficiently understood
with less than the 100% compete precision of the x86 language. They
x86utm model is required to prove that false assumptions about the
nature of correct simulation are false assumptions.

You can't hide behind an x86 implementation. The same arguments hold.
Which assumptions are false?
>

I have all of the details of the machine code and C code for HH and DDD.
I can't to the same thing for embedded_H and ⟨Ĥ⟩ ⟨Ĥ⟩ so we have to learn
by analogy.

Why can't you do that? The simulator can simulate itself.
>

This means that H is not allowed to report on the behavior of the
directly executed P(P).

So on which program does it report then?

DD(DD) is just like infinite recursion that gets terminated at its
second recursive call. DD(DD) halts only because HH(DD,DD)
correctly determines that its input DOES NOT HALT.
If HH(DD,DD) did not correctly determine that its input DOES NOT HALT
then DD(DD) would never halt.

That doesn't make sense. The function halts because a simulator says it
doesn't?

>
You missed an important point: The function halts because a simulator
CORRECTLY says it doesn't.
>

>
The first recursive call halts because the second recursive
call has been aborted. That the second recursive call had to
be aborted proves that the entire computation is non-halting.
>
DD(DD) is just like infinite recursion that gets terminated at
its second recursive call. DD(DD) halts only because HH(DD,DD)
correctly determines that its input DOES NOT HALT.
>
If HH(DD,DD) did not correctly determine that its input
DOES NOT HALT then DD(DD) would never halt.

 Nice to see that you don't disagree with my silly remark.
 

Directly executed DD(DD) and DD correctly simulated by HH are
two different sequences of configurations and HH is only held
accountable for the latter.
The everyone disagrees with this verified fact that
HH correctly simulated by DD DOES NOT HALT is less
than no rebuttal at all.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer