Introduction

In theory and mathematical research any set of assumptions can be considered, as long as they are interesting or lead to new consequence. In the design of complex systems however some reason should be supplied for assumptions. So some explanation should be given when a set of assertions are made about real situations. For example some of the following might be used:

---

1. Experiments designed to falsify this assumption have failed to give reason to doubt it (for instance see....)
2. I have observed that .... , on ... at..., when.....
3. The documentation/data/code found in ...in the current system assumes...
4. On ...date, Mr/Ms J Doe stated that...
5. A sample of N items were taken at random and...

---

Further the value of a statement is not just its true/false value as a proposition, or as a predicate. A false idea can be useful, exciting, interesting, a pointer to the truth, ...

Within a particular project these can be further qualified by specifying the requirement involved:

---

1. The user needs help with....
2. The system has to be very ....
3. It is usfulk to keep track of what happens to....
4. The current system holds this data:.......
5. We are expected use ..... to make the new system.

---

Evidence

A body of evidence is a structured network of statements and reasons for the statements. The relationship between the evidence for a document and the document is subtle and not like normal logic.

The statements in a body of evidence fit into a framework: AEIOU.

AEIOU Framework

• (A): Absolute and Axiomatic.

  ---

  1. Mathematics, logic, ...
  2. All based explicitly stated assumptions (Axioms...) and reasoning
  3. By definition.

  ---

• (E): Emotional, Ego, Experienced

  ---

  1. Statements about personal experiences - that are internal
  2. Feelings, hunches, dreams, revelations, beliefs, desires, ...

  ---

• (I): Improvable Truths

  ---

  1. Temporary plausible statements that may be modified later.
  2. Statements that explain (using A) all relevant O's and I's
  3. I truths often oppose E and U truths.

  ---

• (O): Observed

  ---

  1. Simple propositions, simple quantifications, statistics,....
  2. Must indicate circumstances when observations were made
  3. Experimental results.
  4. Only finite quantification is valid:
  5. O: for all my experiments E, results R.
  6. I: for all E, R.

  ---

• (U): Unique Truth

  ---

  1. "I can't think of any other explanation" plus dogma.
  2. cUrrent doctrine and world views that are accepted by many.
  3. aUthority and credentials.

  ---

Examples from Astronmy

---

1. A(Euclid) ellipses==>conic_sections.
2. A(Euclid) circles==>ellipses.
3. A(Descartes) `ellipses={{(x,y): Plane || x^2/a^2 + y^2/b^2 = 1} || a,b:Real}`.
4. E(Druid)"moon is immortal, mysterious, ....".
5. I(Aristotle)" The moon circles the earth"
6. I(Ptolemy)"The moon circles the earth with a small circular pertubation."
7. O(Newton)"Everytime I drop an apple it falls to the ground."
8. O(Apple_farmer)"Dropped apples bruise".
9. O(Apple_farmer)"bruised apples don't get a good price".
10. O(Tycho)"On the following nights and times the moon was at these positions in the sky".
11. U(Western Europe, 500.AD..1600.AD)"The world is the center of a hierarchical universe..."
12. U(Apple_farmer)"Don't drop apples".
13. I(Kepler)"The moon follows an elliptical orbit with the earth at one focus,......."
14. I(Newton)"The moon follows the laws of Motion and Gravity, and has a mass of...."

---

Example from Hamlet

---

1. E(Hamlet, time=>1)"I will kill the spy behind the curtain"
2. E(Hamlet, time=>1)"I will not kill Polonius"
3. O(Hamlet, time=>2)Polonius=the spy behind the curtain.
4. E(Hamlet, time=>3)"Oops"

---

Syntax

Only A and I truths can be safely expressed with out quotation marks. perhaps -
1. body_of_evidence::="Evidence{" #(label(truth | derived) | comment) "}".
2. label::=identifier":".
3. truth::=("A" | "I")"(" context ")"expression(@) |("E"|"I"|"O"|"U") "(" context ")" char_string.
4. derived::=(basis|)"|-"expression(@) (proof|). This is similar to ISO Standard Z.
5. basis::=L(identifier).

   Perhaps extend the label in the syntax of documentation:

6. documentation.syntax.label::=...|("A"|"I"|"E"|"O"|"U")basis.

   Example of college 1

7. Example1::=
   Net{

   Students, Classes::Finite_Sets. Enrollments:: @(S,C).
   O(Interveiw with Dean Whozis, 11 Nov 99) |- Enrollments in S(0..10)-(1..40)C.

   
   }=::Example.

   Properties

   A and I truths have to be "logical" in the sense that if the standard rules lead to contradictions then they must be denied.

   Only A_truths are guaranteed. Only mature I_truths can be expected to be correct.

   Two equivalent statements must have the same degree of belief.

   Typical life history of a document would be

8. documents_life_history::= (unsupported | observed) #(supporting_evidence | used_in_derivation | used_as_support | quoted) (refutation | entry_into_doctrine).

   Abduction vs Deduction

   Suppose a document S implies a document R then

   ---

   1. if R is refuted then so is S
   2. if S is supported then so is R

      However

   3. added support for R weakens S
   4. evidence against S may or may not effect R.

   ---

   Suppose a document S is used to derive a result R then

   ---

   1. if R is refuted then no more than one part of S has to be refuted
   2. if any S is supported then so is R

      However

   3. added support for R weakens all the statements in S
   4. evidence against some of the S's may or may not effect R.

   ---

   Half Baked Ideas

   There is a tradition that an idea takes time to mature. In other words the more that is known about how an idea fits with other ideas the mo better it is understood.

   Perhaps documents should be rated on a scale of "Bakedness" varying upwards from 0 when originally thought of and increasing by some ammount when ever it is used to support another idea, increasing with each positive review, increasing when support is found else where, and so on.

   Perhaps when documentation is modified then the new version inherits only a fraction of the "Bakedness" of the original depending on the extent of the change.

   A MATHS system should automatically track the cooking of ideas - via a reference count.

   Notice that ideas never go away! In reality, a refuted system is placed in a more restricted context...Ptolemy, Newton,...

   PQRST Requirements framework

   
   Net
   1. Purposes::Statements.
   2. Qualities::Statements.
   3. Reality::Statements.
   4. System_Situation::Statements.
   5. Technique_Tool_Technology::Statements.

   
   (End of Net)
   
   

   Developing Documents

   Theory

   In the design process a set of ideas may be changed to improve the design. In any thinking, ideas develop and so change. This can be in the following ways:

   ---

   1. Specialization

      ---

      1. Adding an assumption

      ---

   2. Generating an equivalent formulation

      ---

      1. Adding a definition
      2. adding a theorem
      3. Changing notation
      4. Changing assumptions so that the same system results.

      ---

   3. Generalisation

      ---

      1. Adding a variable = embedding in a larger set of possibilities.
      2. Removing an asumption.

      ---

   ---

   ?? Need road signs for these processes and the reasons for doing them.

   Example of college 2

   For example we may have need to track the enrollments of students in classes with:
   1. Example2::=
      Net{

      1. (Reality) |- S::=Students:Finite_sets,C::=Classes:Finite_Sets,
      2. E::=Enrollments.
         
      3. (Observation) |- (E0): |S|=1000 and |C|=160.
         
      4. (Interview with Dean Whozis, 11 Nov 99) |- E:S(0..10)-(1..40)C.
         
      5. |- (E1): E in @(S,C).
      6. E1::S->@C=fun [s] { c || s E c}.
      7. E2::C->@S=fun [c] { s || s E c}.

         
         

      8. |- (E3): E1 = S..E..C and E2 = C..E..S. [ math_13_Data_Bases.html ]

         Now if our concern is to rapidly tell students what their classes were then we might well implement E2 rather then E1 or E. If we wish to rapidly tell each lecturer who they are teaching then we might use E1 as our model. If we need both then we might consider E.

      
      }=::Example.

   . . . . . . . . . ( end of section Developing Documentation) <<Contents | End>>

. . . . . . . . . ( end of section Evidence and reasons for making statements.) <<Contents | End>>

Notes on MATHS Notation

Proofs follow a natural deduction style that start with assumptions ("Let") and continue to a consequence ("Close Let") and then discard the assumptions and deduce a conclusion. Look here [ Block%20Structure in logic_2_Proofs ] for more on the structure and rules.

The notation also allows you to create a new network of variables and constraints, and give them a name. The schema, formal system, or an elementary piece of documentation starts with "Net" and finishes "End of Net". For more, see [ notn_13_Docn_Syntax.html ] for these ways of defining and reusing pieces of logic and algebra in your documents.