Re: No decider is accountable for the computation that itself is contained within, unless that is its input

On 7/30/24 12:24 PM, olcott wrote:

On 7/30/2024 2:24 AM, joes wrote:

Am Mon, 29 Jul 2024 15:32:44 -0500 schrieb olcott:

On 7/29/2024 3:17 PM, joes wrote:

Am Mon, 29 Jul 2024 11:32:00 -0500 schrieb olcott:

On 7/28/2024 3:40 AM, Mikko wrote:

On 2024-07-27 14:21:50 +0000, olcott said:

On 7/27/2024 2:46 AM, Mikko wrote:

On 2024-07-26 16:28:43 +0000, olcott said:

>

Halt deciders are not allowed to report on the behavior of the actual
computation that they themselves are contained within. They are only
allowed to compute the mapping from input finite strings.

What if the input is the same as the containing computation?

It always is except in the case where the decider is reporting on the TM
description that itself is contained within.

 

I don't understand. "The input is not the same as the containing
computation when deciding on the description of the containing
computation"?
>

 void DDD()
{
   HHH(DDD);
}
 The behavior of the correct emulation of the x86 machine
language input DDD to a emulating halt decider HHH is not
the same as behavior of the direct execution of DDD when
the x86 machine language of DDD is correctly emulated
by emulating halt decider HHH that calls HHH(DDD) (itself).

then it is not a correct emuluation. PERIOD.
Note, to correctly emulated DDD, you need the code for the ONE HHH that this DDD is calling.

 When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 (a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
 The behavior of the correct UTM simulation of the input
⟨Ĥ⟩ ⟨Ĥ⟩ to a simulating halt decider embedded_H is not the
same as behavior of the direct execution of Ĥ ⟨Ĥ⟩ when
⟨Ĥ⟩ ⟨Ĥ⟩ is correctly simulated by simulating halt decider
embedded_H. (see above)

No, you have the same error.
If embedded_H never aborts, as the loop claims, then it doesn't abort to give an answer.
If embedded_H does abort, the teh first embedded_H which started its emulation in the first instanct of (c) will break out of its emulation and return the H^,qn and H^ (H^) will halt.

 In both cases the simulating halt decider must abort its
simulation to prevent is own infinite execution.

As will the copy of it that it is simulating, thus it gets the wrong answer.

 An executing Turing machine is not allowed to report on
its own behavior. Every decider is only allowed to report
on the behavior that its finite string input specifies.

Which, if it contains a copy of itself, it must report on the behavior of that copy.
You are just proving your ignorance, and that you are just a pathological liar.

 The only case where the correct UTM simulation of an input
to a simulating halt decider differs from the direct execution
of this same input is when a simulating halt decider simulates
an input that calls itself.

Nope, if you try to do that, you find that your UTM isn't actually a UTM, as the DEFINITION of a UTM is that its behavior ALWAYS exactly reproduces the behavior of the machine it is simulation when that machine is directly executed.
DEFINITION, as in the actual meaning of the words Universal Turing Machine.
I guess you just admitting you are sa stupid liar.

 No one ever bothered to notice this before only because they
always rejected the notion of a simulating halt decider
out-of-hand without review.
 

No, they didn't "notice" it, because it isn't true, BY THE DEFINITIONS.

Professor Hehner noticed that the conventional HP input to
its decider does specify non-halting behavior:
      From a programmer's point of view, if we apply an
     interpreter to a program text that includes a call
     to that same interpreter with that same text as
     argument, then we have an infinite loop. A halting
     program has some of the same character as an interpreter:
     it applies to texts through abstract interpretation.
     Unsurprisingly, if we apply a halting program to a program
     text that includes a call to that same halting program
     with that same text as argument, then we have an infinite
     loop. (Hehner:2011:15)
 [5] E C R Hehner. Problems with the Halting Problem,
COMPUTING2011 Symposium on 75 years of Turing Machine and
Lambda-Calculus, Karlsruhe Germany, invited, 2011 October
20-21; Advances in Computer Science and Engineering
v.10 n.1 p.31-60, 2013
https://www.cs.toronto.edu/~hehner/PHP.pdf
 

Right, if the "decider" tries to not be wrong, its only option is to not answer, and thus be wrong.