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,sci.logic
Subject: Re: A computable function that reports on the behavior of its actual
 self is not allowed
Date: Sun, 12 May 2024 20:05:45 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v1rlgp$qvg2$6@i2pn2.org>
References: <v1r566$2uo21$1@dont-email.me> <v1rbmu$305vp$1@dont-email.me>
 <v1rcvn$qvg3$9@i2pn2.org> <v1rfcn$311mk$1@dont-email.me>
 <v1rggf$qvg3$10@i2pn2.org> <v1ripg$31n8h$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 13 May 2024 00:05:45 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="884226"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <v1ripg$31n8h$1@dont-email.me>
Content-Language: en-US
Bytes: 7151
Lines: 139

On 5/12/24 7:19 PM, olcott wrote:
> On 5/12/2024 5:40 PM, Richard Damon wrote:
>> On 5/12/24 6:21 PM, olcott wrote:
>>> On 5/12/2024 4:40 PM, Richard Damon wrote:
>>>> On 5/12/24 5:18 PM, olcott wrote:
>>>>> On 5/12/2024 2:27 PM, olcott wrote:
>>>>>> Computable functions are the basic objects of study in computability
>>>>>> theory. Computable functions are the formalized analogue of the
>>>>>> intuitive notion of algorithms, in the sense that a function is
>>>>>> computable if there exists an algorithm that can do the job of the
>>>>>> function, i.e. given an input of the function domain it can return 
>>>>>> the
>>>>>> corresponding output. 
>>>>>> https://en.wikipedia.org/wiki/Computable_function
>>>>>>
>>>>>> A computable function that reports on the behavior of its actual
>>>>>> self (or reports on the behavior of its caller) is not allowed.
>>>>>>
>>>>>> A decider must halt whereas simulating a pathological input
>>>>>> that would never halt unless aborted can only halt by aborting.
>>>>>>
>>>>>> This causes the direct execution of this input after it has been 
>>>>>> aborted
>>>>>> to have different behavior than the simulated input that cannot 
>>>>>> possibly
>>>>>> stop running unless aborted.
>>>>>>
>>>>>
>>>>> *MORE PRECISE WORDING* (this may take a few more rewrites)
>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> It is a verified fact that the directly executed Ĥ ⟨Ĥ⟩ cannot possibly
>>>>> stop running unless simulating partial halt decider embedded_H aborts
>>>>> its simulation of its input.
>>>>
>>>> But since embedded_H implements a specific algorithm, either it will 
>>>> or it won't. "unless" is a meaningless word here, it implies a case 
>>>> that can't happen.
>>>>
>>>> We can look at the two possible cases.
>>>>
>>>> First, if embedded_H doesn't ever abort its simulation, then, as you 
>>>> have desceribed, THAT embedded_H creates a H^ that will never halt, 
>>>> but the H that was based on will also never abort its simulation (or 
>>>> you lied that embedded_H is the needed copy of H) and thus never 
>>>> answer and fail to be a decider.
>>>>
>>>
>>> It can answer without halting by transitioning to its own internal
>>> non-final state of embedded_H.qn without ever reaching Ĥ.qn. Every
>>> simulated instance of embedded_H would do this same thing and then
>>> continue simulating its input.
>> So, you just don't understand how algorithms work, and how compuations 
>> are DEFINED.
>>
>>
>> If you want to try to define a new system of compuation that allows 
>> giving answer without the algorithm ending, but still allows all the 
>> composition operations that are included in computation theory, go 
>> ahead and try.
>>
>> You then need to show that it is Turing Complete, which means that you 
>> can't outlaw any computation allowed in a Turing Machine, like H^.
>>
>>>
>>> In this case embedded_H <is> an actual UTM that has the extra
>>> feature of examining all of the state transitions of its input
>>> to see what we can all see that Ĥ ⟨Ĥ⟩ remains stuck in recursive
>>> simulation.
>>>
>>
>> And a UTM doesn't reveal its answer until it come to a final state, 
>> just like ALL Turing Machines or equivalent computation.
>>
>>> *Or we can get an actual partial halt decider as follows*
>>> *Or we can get an actual partial halt decider as follows*
>>> *Or we can get an actual partial halt decider as follows*
>>>
>>> No decider is ever allowed to report on its own behavior thus embedded_H
>>> as a simulating partial halt decider is NOT ALLOWED to report on the
>>> direct execution of Ĥ ⟨Ĥ⟩ because this IS REPORTING ON ITS OWN BEHAVIOR.
>>
>> WHO SAYS THIS?
> 
> A decider must compute the mapping from an input.
> Its actual self cannot possibly be an input.

Sure it can, at least when converted to the form you give the input in.

A decide is tasked with computing an input to a function, that has been 
given to it in the form (perhaps) of a description. The FUNCTION being 
computed here is "Halting", and Halting take a machine and an input, and 
maps it to a binary value of Halting or Non-Halting.

A Halt Decider takes a description of that input, and nothing says that 
input description can't be the description of the decider itself.

If you want to use your arguement, NO decider can decide on any Turing 
Machine, because we can't give any Turing Machine as a input, only a 
description.

> 
> No decider takes an actual Turing machine as input thus
> no decider can possibly take its actual self as input.

Algorithmic deciders frequent take their input in the form of a 
description, and a

> 
> (a) The behavior of the directly executed Ĥ ⟨Ĥ⟩ is after
> embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ has already aborted its simulation.

Right, and that is the behavior that H is supposed to report on.

> 
> (b) The behavior of the simulated input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> is before embedded_H has aborted its simulation.

Which just shows that embedded_H doesn't do a "Correct Simulation" per 
Computation Theory, so this simulation doesn't establish the actual 
behavior "of the input" which is the behavior of the machine described 
by it (since "inputs" don't HAVE behavior, only what they represent does).

> 
> (c) These two behaviors (a) and (b) ARE NOT THE SAME. (a) will stop
> running on its own (b) will never stop running unless aborted.

But H isn't being asked about the simulation by H, but on the behavior 
of the program descrtibed by the input.

> 
> *THIS MAKES THE BEHAVIOR OF THE DIRECT EXECUTION*
> *AN INCORRECT MEASURE FOR PATHOLOGICAL INPUTS*
> 

Nope, just shows you don't understand the simple meaning of the 
question, because you have lied to yourself so much you are believing 
your own lies and made you incapable of understanding the truth.