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 ever accountable for the behavior of the
 computation that itself is contained within (Unless that is its input)
Date: Fri, 26 Jul 2024 22:16:43 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <0025d4a8d29ba10c5f3b46b9899e3f747d1172c7@i2pn2.org>
References: <v80irs$2tlb5$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 27 Jul 2024 02:16:43 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="485228"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <v80irs$2tlb5$1@dont-email.me>
Bytes: 4557
Lines: 100

On 7/26/24 12:28 PM, olcott wrote:
> No decider is ever accountable for the behavior of the
> computation that itself is contained within.

Of course it is, if that is the machine that its input describes.

Got a reference for you claim, or is th9is just anothoer of your 
"Diagonalization proof" lies. It will be presumed to be such a lie until 
you can provide proof.

You do this enough, you have earned that presumption.

> 
> It is only accountable for computing the mapping from the
> input finite string to the actual behavior that this finite
> string specifies.
> 

Right, it is accountable for the behavior defined by the problem it is 
supposed to be answering. For Halting, one expression of that is what an 
ACTUAL UTM will do when given this input, which means

> typedef void (*ptr)();
> int HHH(ptr P);
> 
> void DDD()
> {
>    HHH(DDD);
> }
> 
> int main()
> {
>    DDD();
> }
> 

And, without the actual code of H, this isn't a valid halting problem 
input, as it isn't a full program.

When we include that code for HHH, we of course get a DIFFERENT input 
for each different HHH that DDD has been paired to (which doesn't change 
if we look at the behavor of THIS input to other deciders, or the UTM 
that determines the actual behavior).

> HHH(DDD) is only accountable for the actual behavior that
> its input specifies and is not accountable for the behavior
> of the computation that itself is contained within:
> the directly executed DDD();

WRONG. The actual behavior that its input specifies *IS* the behavior of 
the computation that is the directly executed DDD().

YOu are just proving yourself a ignorant stupid liar.

Sourcd for you claim, or you are a liar, and you are presumed (and 
proven to be) one until you actually provide that proof.

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

Which only happens like that if H (and thus embedded_H) *NEVER* abort 
its simulation of its input and thus fails to be a decider.

IF it ever does, then after that number of steps, the outer embedded_H 
will abort its simulation and return to H^.qn and thus H^ will halt.

> 
> Two complete simulations show a pair of identical TMD's are
> simulating a pair of identical inputs.  We can see this thus
> proving recursive simulation.

Nope, not if they are conditional simulation, and if they are not, then 
they can't abort the simulation.

> 
> When we understand that embedded_H is accountable for the
> behavior of its input and not accountable for the behavior
> of the computation that itself is contained within then
> we understand that embedded_H is necessarily correct to
> transition to its own Ĥ.qn state.
> 
> https://www.liarparadox.org/Linz_Proof.pdf
> 
> 

But it is responsible for ALL the bebavior of its input, even the 
behavior that it doesn't get to because it has decided to stop its 
simulation.

Of course, if it never decides to stop its simulation, it never does and 
never answers, so the programmer has a problem on their hands.