Re: Categorically exhaustive reasoning applied to the decision to abort

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