Path: ...!3.eu.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic
Subject: Re: No decider is allowed to report on the behavior of the
 computation that itself is contained within
Date: Wed, 22 May 2024 22:27:42 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v2m9iu$1qo0t$2@i2pn2.org>
References: <EOydnaeszcdfHS__nZ2dnUU7_83NnZ2d@giganews.com>
 <PtvsK.300027$5fVf.158200@fx09.iad>
 <CaWdnZEntLawFS__nZ2dnUU7_83NnZ2d@giganews.com>
 <ccb8af3c-e497-4d6e-8040-826a4e87a6e7n@googlegroups.com>
 <g9qdnRjZj9uBlS7_nZ2dnUU7_8zNnZ2d@giganews.com>
 <0f7ed34c-5aaa-4858-885e-66e16777f599n@googlegroups.com>
 <87a6a44s02.fsf@bsb.me.uk>
 <a9adde1d-ad2c-444c-9b14-88841f5e8783n@googlegroups.com>
 <87sfnv2e6e.fsf@bsb.me.uk>
 <3a337f21-4828-46c4-b5be-87c76cff9db4n@googlegroups.com>
 <v2lnh0$1c0ls$1@dont-email.me> <v2lth6$1nrfv$5@i2pn2.org>
 <v2m8e0$1ievj$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 23 May 2024 02:27:42 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="1925149"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <v2m8e0$1ievj$1@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 8194
Lines: 176

On 5/22/24 10:07 PM, olcott wrote:
> On 5/22/2024 6:01 PM, Richard Damon wrote:
>> On 5/22/24 5:19 PM, olcott wrote:
>>> On 6/24/2022 2:53 AM, Malcolm McLean wrote:
>>>> He's dry-run P(P) and established that it doesn't halt. He's invoked 
>>>> H on it
>>>> and H reports that it doesn't halt. He's run P(P) and it halts.
>>>>
>>>> So something odd is going on there that needs an explanation.
>>>
>>> *MUCH BETTER WORDS THAN ONE YEAR AGO*
>>> *MUCH BETTER WORDS THAN ONE YEAR AGO*
>>> *MUCH BETTER WORDS THAN ONE YEAR AGO*
>>>
>>> typedef int (*ptr)();  // ptr is pointer to int function in C
>>> 00       int H(ptr p, ptr i);
>>> 01       int D(ptr p)
>>> 02       {
>>> 03         int Halt_Status = H(p, p);
>>> 04         if (Halt_Status)
>>> 05           HERE: goto HERE;
>>> 06         return Halt_Status;
>>> 07       }
>>> 08
>>> 09       int main()
>>> 10       {
>>> 11         H(D,D);
>>> 12         return 0;
>>> 13       }
>>>
>>> In the above case a simulator is an x86 emulator that correctly emulates
>>> at least one of the x86 instructions of D in the order specified by the
>>> x86 instructions of D.
>>>
>>> This may include correctly emulating the x86 instructions of H in the
>>> order specified by the x86 instructions of H thus calling H(D,D) in
>>> recursive simulation.
>>>
>>> It is trivial to see that for every H/D pair of the infinite
>>> set of H/D pairs that match the above template that
>>>
>>> D correctly simulated by H cannot possibly reach its own final
>>> state at line 06 and halt because D correctly simulated by
>>> H remains stuck in recursive simulation.
>>>
>>> Deciders are only accountable for the behavior of their inputs
>>> and are thus not allowed to report on the behavior of the computation
>>> that they themselves are contained within.
>>
>> No. "Behavior of their inputss" MEANS for Turing Machines that are 
>> computing properties of Turing Machines (like Halt Deciders) have the 
>> "behavior of their input" defined as the Behavior of the machine their 
>> input represents/describes/specifies.
>>
> 
> Only specifies and no matter how many times you deny it,
> it remains a verified fact that:
> the input to H
> the input to H
> the input to H
> the input to H
> the input to H
> the input to H
> the input to H
> specifies that it never reaches its own final state and halts.

No since when the input is run, and that is the behavior the input 
SPECIFIED (per the definiton) it will HALT.

THAT is the behavior that it specifies.

It may be that H can not simulate to that point, but that is just a 
limitation in your design for H. I have shown you a design, which is 
implementable as a Turing Machine equivalent (at least if you assume you 
can handle the detection of the D(D) calling H(D,D) problem) that can 
get past that point. And for other versions of D where the is an answer 
that H could give and be correct, can actually prove that it has a 
corret answer.

This shows that you don't understand what you are talking about, and 
just p=spouting off your normal garbage.

> 
>> And, there is no rule that prohibits that machine given as a 
>> representation from including a copy of the machine that is deciding 
>> on it.
>>
> 
> The rule is the deciders operate on inputs and thus cannot possibly
> operate on their own actual selves.

Right, but they CAN operation on a description of themselves.

You forget, Deciders don't operation directly on machines, and since 
they ARE a machine, we can't give "themselves" to them, or ANY other 
machine as an input. What we can do is give a 
representation/description/specification that can just as easily be of 
what they are as any other machine.

> 
>> Yes, you litterally can't phrase the question as being about "The 
>> machine you are contained within", 
> 
> Everyone has always implicitly assumed this false assumption.

Nope. It seems only YOU think it is that question.

> 
>> but you can give the description of that machine and ask about it. 
> 
> That is one level of indirection away from the actual machine and
> provides the incorrect basis for saying that "this sentence is not true" 
> is true on the basis of:
> This sentence is not true: "This sentence is not true" is true.

Which is just red herring and shows you don't understand what the 
problems is.

This is why I have asked you to actually write out a FORMAL 
SPECIFICATION for what H is, what its input is, and what it is trying to 
decide on.

> 
>> The point is that Turing Machines don't have that sort of "reference" 
>> to allow the use of the pronoun to reference the machine, you need to 
>> actually give the machine (by an encoding of it).
>>
> 
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> 
> embedded_H is not operating on itself it is operating
> one level of indirect reference away from its actual self.
> *THIS CHANGES EVERYTHING*

It is operating on a description of itself.

It STILL Must give the same answer as H, and must pass that answer to 
H^, which will make that answer wrong.

Of course, all of this is beyound your understanding because it seems 
you STILL don't understand what it means to be a Turing Machine.

> 
>>>
>>> There is no Turing machine that can possibly take its actual
>>> self as an input because actual Turing Machines are not allowed
>>> as inputs to other Turing Machines.
>>
>> But representations of them are, so we CAN ask Turing Machine about 
>> the behavior of a Turing Machine that includes a copy of itself.
>>
>>>
>>> *thus the behavior of D(D) executed from main() has always been moot*
>>> *thus the behavior of D(D) executed from main() has always been moot*
>>> *thus the behavior of D(D) executed from main() has always been moot*
>>>
>>>
>>
>> No, because that is what DEFINES Halting.
> 
> I already proved otherwise. That you ignored or failed to
> understand this proof does not mean that I didn't already
> prove otherwise.
> 
========== REMAINDER OF ARTICLE TRUNCATED ==========