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

On 6/8/24 9:04 AM, olcott wrote:

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:

>

A simulating halt decider cannot report on what the behavior of a
non-terminating input actually is because this would take forever.

Exactly. Didn't you say it is allowed to abort?
>

H is not allowed to report on any computation containing its actual self
because Turing machines can only take finite string inputs thus cannot
take Turing machines as inputs.

Bullshit. It can take other machines just fine. It doesn't know about
itself.
>

>
No actual Turing machine can be the input to any other actual
Turing machine. Turing machines only take finite string inputs.

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

So?
Turing Machines can be fully represented by a finite string.
And, your x86utm takes the input as machine code, but you talk about it deciding on the FUNCTION DD, which isn't that machine code, but the machine code is just a REPRESENTATION of that function.
Just like what was done to a Turing Machine.

 

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.
 void DDD(int (*x)())

Why did we jump to DDD now?

{
   HH(x, x);
}
 DDD correctly simulated by any HH cannot possibly stop running
without being aborted. When this is understood and accepted then
 When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by any embedded_H is understood
to not possibly stop running until aborted.

But the problem doesn't ask about H^ applied to (H^) correctly simulated by embedded_H, but about the behavior of H^ applied to (H^) when run.

 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.
 

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.

You switched back to DD, which isn't defined here, just by your previous context as just like DDD
You just admitted to using lying with double speak, by admitting that DDs execution, which first looks to be an infinite recursion WILL STOP ITSELF by the HH that DD calls deciding to abort its simulation and returning to DD, and thus your claim "infinite recursion" isn't.
You try to conveniently forget that what ever you make your outer HH do that is deciding on DD, because that DD was built on the HH that you end up claiming to be correct, its HH will also do.

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

Right, but that is a DIFFERENT HH. You don't seem to understand that a program is the program that it is, and not the program that it isn't.
Programs are not like people, with a choice of what they will do, but are deterministic entities whose behavior is fully fixed at their creation by their programming.
Perhaps your problem is that you gave up your free will for something, and have gotten stuck in your own deterministic hell.