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: Deciders are ONLY accountable for their actual inputs ---
Date: Sun, 2 Jun 2024 13:23:00 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v3i9pk$2qu72$5@i2pn2.org>
References: <v3asj2$2ihjj$2@i2pn2.org> <v3asv1$1s60g$1@dont-email.me>
 <v3bvg7$24rgd$1@dont-email.me> <v3cml5$28tmt$1@dont-email.me>
 <v3ek78$2mbgo$1@dont-email.me> <v3fc52$2qsgd$2@dont-email.me>
 <v3h8iq$3938f$1@dont-email.me> <v3ht3m$3bkv5$5@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 2 Jun 2024 17:23:00 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2980066"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <v3ht3m$3bkv5$5@dont-email.me>
Bytes: 6364
Lines: 121

On 6/2/24 9:46 AM, olcott wrote:
> On 6/2/2024 2:56 AM, Mikko wrote:
>> On 2024-06-01 14:44:50 +0000, olcott said:
>>
>>> On 6/1/2024 2:56 AM, Mikko wrote:
>>>> On 2024-05-31 14:25:40 +0000, olcott said:
>>>>
>>>>> On 5/31/2024 2:50 AM, Fred. Zwarts wrote:
>>>>>> Op 31.mei.2024 om 00:01 schreef olcott:
>>>>>>> On 5/30/2024 4:54 PM, joes wrote:
>>>>>>>> Am Thu, 30 May 2024 09:55:24 -0500 schrieb olcott:
>>>>>>>>
>>>>>>>>> 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       }
>>>>>>>>>
>>>>>>>>> The left hand-side are line numbers of correct C code.
>>>>>>>>> This code does compile and does conform to c17.
>>>>>>>>>
>>>>>>>>> Everyone with sufficient knowledge of C can easily determine 
>>>>>>>>> that D
>>>>>>>>> correctly emulated by any *pure function* H (using an x86 
>>>>>>>>> emulator)
>>>>>>>>> cannot possibly reach its own simulated final state at line 06 
>>>>>>>>> and halt.
>>>>>>>> Yeah, of course not, if H doesn’t halt.
>>>>>>>>
>>>>>>>
>>>>>>> To actually understand my words (as in an actual honest dialogue)
>>>>>>> you must pay careful attention to every single word. Maybe you
>>>>>>> had no idea that *pure functions* must always halt.
>>>>>>>
>>>>>>> Or maybe you did not know that every computation that never reaches
>>>>>>> its own final state *DOES NOT HALT* even if it stops running because
>>>>>>> it is no longer simulated.
>>>>>>
>>>>>> Since the claim is that H is also a computation, it holds for H, 
>>>>>> as well. That means that H *DOES NOT HALT* even if it stops 
>>>>>> running because it is no longer simulated.
>>>>>>
>>>>>
>>>>> *pure function H definitely halts you are confused*
>>>>
>>>> A pure function does not halt (in C that means that a pure function
>>>> does not call exit). A pure function returns.
>>>>
>>>
>>> When a pure function returns this is the equivalent of the theory
>>> of computation halting.
>>
>> In ceratin sense, yes. But the term "pure function" is mainly used
>> in a different context where the word "halting" has a more specific
>> meaning.
>>
> 
> I need to maintain a constant mapping between theory of computation
> terminology and software engineering terminology.
> 
> Computable Function(comp sci) <is equivalent to> Pure function(SE)
> I want it to be easy for software engineers to understand my proof.

Nope. In Computation Theory, a "Computable Function" is just a 
mathematical concept of a Mapping (a, normally infinite, set of tuples 
of unique input values and output values) which happens to have a 
realizable algroith (aka Turing Machine) that can compute it.

The closest equivalent to a SE "Pure Function" is a Turing Machine or 
Equivalent, or an "Algorithm"

SE, to my knowledge, doesn't really have the equvalent of the 
Computation Theory "Computable Function", but something like it might be 
expressed in the requirements for the function. It is the specification 
of what outputs a given input SHOULD generate for the SE function to be 
correct.

> 
> Only software engineers will understand that DD correctly simulated
> by HH had different behavior than DD(DD). Comp Sci people allow Comp Sci
> dogma to overrule verified facts.

No, REAL Software Engineers would understand that a "Correct Simulation" 
of something must create a reasonable approximation of the behavior of 
the actual thing.

> 
> When I pinned Richard down on this he simply said that he does not care 
> that DD correctly simulated by HH has different behavior than DD(DD).
> 

Right. because NO ONE (except you it seems) really cares about PARTIAL 
simulations that don't answer the actual question being looked at.

> It turns out that DD correctly simulated by HH <is> the behavior that
> the input to HH(DD,DD) specifies. Deciders are ONLY accountable for
> their actual inputs. Deciders compute the mapping FROM THEIR INPUTS...

CAN'T BE. Not without ignoring the specifications. Something you seem to 
like to do, which is why you end up wrong so often.

Deciders are accountable for making their output match the Function they 
are supposed to be computing, which in this case is HALTING, which is 
DEFINED as the Turing Machine (or equivalent Program) reaching a Final 
State when it is RUN (not partially simulated) or if it will NEVER reach 
such a state after an unbounded number of steps (which an aborted 
simulation can not show).

Your concept of a "decider" just seems to omit the part of the 
definition about what make the decider "correct", which seems par for 
you, as being correct was never actually something you are concerned 
with, just SEEMING correct enough to deceive someone.