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

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

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

Op 08.jun.2024 om 15:04 schreef 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:

>

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

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)())
{
   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.
>
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 >
If HH(DD,DD) did not correctly determine that its input
DOES NOT HALT then DD(DD) would never halt.
>
>

>
Indeed, *only if*. if HH does not halt, then DD does not halt. But your claim is that HH halts, because of that DD(DD) *DOES* halt. You cannot base a conclusion on something that does not happen.

 You are twisting the meaning of my words.
*Verified facts* (some may be beyond your technical competence)
(1) The input to HH DOES NOT HALT.

But you admit it (4) that it halts, because the HH that it calls will also think it can correctly reject its input as non-halting.
Your logic is just proving it is self-contradictory.

 (2) HH correctly recognizes that its input DOES NOT HALT.

Except that since (1) was false, (2) isn't true either, HH only THINKS it correctly recognizes that its input doessn;t halt

 (3) HH is only accountable for the behavior of its input
     because halt deciders COMPUTE THE MAPPING FROM THEIR INPUTS

And, for a halt decider, that behavior is DEFINED to be the behavior of the machine described by the input, that is the direct execution of DD(DD) in this case.

 (4) DD(DD) only halts because HH correctly rejected its
     input as non-halting.

But the direct exectution DOES Halt, because the HH that it calls does that same thing and returns 0.

 (5) HH is not accountable for the behavior of DD(DD)
     that provably differs from the behavior of DD
     correctly simulated by HH
 

Wrong,
Your claim is in violation of (3) where you call HH a Halt Decider.
Halt Decider decide on the behavior of the direct execution of the machine represented by their inputs.
If HH's simulation differs from this, then it is NOT a correct simulation by the definition that allows the replacement of the direct exectution wiht a correct simulation, so you grounds are incorrect.
Sorry, you are just showing how little you understand of what you are talking about. The problem is you never learned the facts, and have gaslite yourself with your own misconceptions that you fail to understand what is actually true.