Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: No decider is accountable for the computation that itself is
 contained within, unless that is its input
Date: Tue, 30 Jul 2024 21:21:32 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <cc655644fc552c5b556ea127974f860fa52ecf8f@i2pn2.org>
References: <v80irs$2tlb5$1@dont-email.me> <v828ju$3a1gf$1@dont-email.me>
 <v82vpu$3dftr$6@dont-email.me> <v8506m$3s27b$1@dont-email.me>
 <v88g60$i7kl$5@dont-email.me>
 <8ac9fd02d6247cec58098de53c964a5feed41946@i2pn2.org>
 <v88u9c$kpv7$1@dont-email.me>
 <3c24d92260cc29c0b39004bf3448d415c567549a@i2pn2.org>
 <v8b443$13n24$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 31 Jul 2024 01:21:32 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="931475"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <v8b443$13n24$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 6468
Lines: 129

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.