Re: Categorically exhaustive reasoning applied to the decision to abort

Liste des GroupesRevenir à c theory 
Sujet : Re: Categorically exhaustive reasoning applied to the decision to abort
De : polcott333 (at) *nospam* gmail.com (olcott)
Groupes : comp.theory
Date : 30. Mar 2024, 15:42:55
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <uu94sv$114hv$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
User-Agent : Mozilla Thunderbird
On 3/30/2024 2:01 AM, Mikko wrote:
On 2024-03-29 14:40:14 +0000, olcott said:
 
On 3/29/2024 6:16 AM, Mikko wrote:
On 2024-03-29 03:16:05 +0000, olcott said:
>
On 3/28/2024 9:41 PM, Richard Damon wrote:
On 3/28/24 9:53 PM, olcott wrote:
On 3/28/2024 7:07 PM, Richard Damon wrote:
On 3/28/24 11:38 AM, olcott wrote:
On 3/28/2024 9:44 AM, Mikko wrote:
On 2024-03-27 14:04:17 +0000, olcott said:
>
On 3/27/2024 4:32 AM, Mikko wrote:
On 2024-03-26 14:41:08 +0000, olcott said:
>
On 3/26/2024 3:50 AM, Mikko wrote:
On 2024-03-25 22:52:18 +0000, olcott said:
>
On 3/24/2024 9:27 AM, Mikko wrote:
On 2024-03-24 02:11:34 +0000, olcott said:
>
On 3/23/2024 7:31 PM, Richard Damon wrote:
On 3/23/24 7:29 PM, olcott wrote:
On 3/23/2024 5:58 PM, immibis wrote:
On 23/03/24 16:02, olcott wrote:
(b) H(D,D) that DOES abort its simulation is correct
     (ABOUT THIS ABORT DECISION)
     because it would halt and all deciders must always halt.
>
To be a decider it has to give an answer.
>
To be a halt decider it has to give an answer that is the same as whether the direct execution of its input would halt.
>
>
That would entail that H must report on different behavior
than the behavior that H actually sees thus violate the
definition of a decider that must compute the mapping from
its inputs...
>
Nope.
You are just showing yourself to be a stupid liar.
>
Where in the DEFINITION of Compute the Mapping of the Input to the Mapped Output does it say that the decider has to be able to "see" that property of the input?
>
>
In order to compute the mapping from an input there must be
some basis that is directly provided by this input.
>
If no such basis is in the input the problem has no soution.
>
>
int sum(int x, int y){ return x + y; }
sum(3,4) is not allowed to report on the sum of 5 + 6
even if you really really believe that it should.
>
Your and my beliefs don't matter. Testers call the function with
various pairs of inputs and compare the result to the specification.
If the result is not what the specification requires then the function
is wrong and needs be fixed or rejected.
>
>
There is enough information for sum(3,4) to compute the sum of 3+4.
There is NOT enough information for sum(3,4) to compute the sum of 5+6.
>
There is enough information for H1(D,D) to compute Halts(D,D).
There is NOT enough information for H(D,D) to compute Halts(D,D).
>
There is enough information to determine whether the result is as
required by the specification.
>
>
This specification only requires a mapping from H(D,D)
to Halts(Simulated_by_H(D,D)) and it gets that one correctly.
D(D) does not halt from the POV of H.
>
What "this pecification"? This means the one you refer or point to
but you didn't.
>
>
Every implementation of H(D,D) that simulates its input must abort
this simulation or never itself halt.
>
int main() { D(D); }   is not a D simulated by H.
>
But does define what a "Correct Simulation" would be.
>
>
*NOT FOR THE PURPOSE OF AN ABORT DECIDER*
>
Why Not?
>
Correct IS Correct, and NEEDING to abort has a clear definition.
>
>
01 void D(ptr x) // ptr is pointer to void function
02 {
03   H(x, x);
04   return;
05 }
06
07 void main()
08 {
09   H(D,D);
10 }
>
Not at all.
It is commonly understood that a halt decider must
divide its inputs into those that halt when executed
and those that do not halt when executed.
>
An abort decider has a different criteria. It must
abort simulations that would cause itself to never halt.
>
It is not commonly understood what an "abort decider" is expected
to do. Therefore you need to specify everything about the expected
behaviour of an abort decider. Before you specify that there is
no point to say anything about any "abort decider" as in could not
be understood.
>
>
A simulating abort decider simulates its input until it recognizes
a behavior pattern such as
(a) Infinite loop
(b) Infinite recursion
(c) Recursive simulation
that required it to abort its simulation for itself to halt.
>
01 void D(ptr x) // ptr is pointer to void function
02 {
03   H(x, x);
04   return;
05 }
06
07 void main()
08 {
09   H(D,D);
10 }
>
*Execution Trace*
Line 09: main() invokes H(D,D);
>
*keeps repeating* (unless aborted)
Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>
*Simulation invariant*
D correctly simulated by H cannot possibly reach past its own line 03.
>
As soon as line 03 would be simulated H sees that D would call
itself with its same input, then H aborts D.
 Can you prove that two abort deciders, when given the same input,
always give the same reusult?
 
The kind of abort decider that I have been referring to can also
be construed as a pathological self-reference detector.
H(D,D) detects that its input has pathological self reference.
H1(D,D) detects that its input DOES NOT HAVE pathological self reference.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

Date Sujet#  Auteur
10 Nov 24 o 

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal