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

On 6/9/24 10:03 AM, olcott wrote:

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.

Except that the second recursive call didn't actually need to be aborted, as the actual correct simulation of the input to the first machines input would have halted when the third recursive call was simulated

 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.

Nope, Remember, you have redefined DD to be a template, and thus it CAN have multiple behaviors based oh what it is instantiated on.
DD(DD) will have infinite recursion if the HH it is built on never aborts its simulation.
DD(DD) will have finite execution if the HH it is built on will abort its simulation, but that finite execution is longer than the period that that HH simulates for, so it can not see it.

 If HH(DD,DD) did not correctly determine that its input
DOES NOT HALT then DD(DD) would never halt.
 

So?
Yes, if HH fails to be a decider, the input is non-halting, but HH fails to be a decider.
But, if HH decides to abort its simulation and return 0, then the direct exectuition of the input, which is what Halting is DEFINED to be, will reach the final state.
All you have done is proven the HH was a correct POOP decider for that input, but no one cares about your POOP.
It is just a LIE to use the wrong criteria for the problem.