[Skip Navigation] [CSUSB] / [CNS] / [Comp Sci Dept] / [R J Botting] / [ MATHS ] / notn_12_Expressions
[Contents] [Source Text] || [Notation] || [Copyright] || [Contact] [Search ]
Tue Sep 18 15:18:59 PDT 2007

Contents


    Expressions in MATHS

      Introduction

        Why expressions

        An short way of expressing calculations is needed. In general some simple yet effective way of expressing algebraic expressions is needed to document software requirements, specifications, and code. They have a 200 year history of algebraic expressions or formulae helping us to express and solve problems.

        Further, the work done abstract data types and the fact that a lot of computer ideas are already known to be abstract algebras, means that MATHS needs a way to cope with expressions from any abstract algebra.

        Large Expressions

        As MATHS developed I added the ability to create multiline expressions for certain types of object using the MATHS directive notation
         		.Tag
         		.Close.Tag
        These have proved very useful:
        TagTypeNotes
        SetSetsEach paragraph defines an element in the set
        List%XA numbered n-tple or vector. One item per paragraph. Numbered 1,2,3,...
        Table@(...)A relation defined as a set of n-tples
        Etc

        Why Infix Operators

        The immense popularity of infixed binary operators (like + and *) means MATHS can not insist on functional notation. However the elegant power of functional languages like LISP and ML imply that their ideas - lambda abstraction for exmple - need to encorporated. So
         			1 * 2
        is a valid expression, but means the same as
         			*(1, 2)

        Why Priorities for Operators

        If you think 1+2*3 equals 9 then you are using the wrong priorities and doing the addition before the multiplication.
         			1 + 2 * 3
        is a valid expression, but means the same as
         			+(1, *(2,3))
        We set priorities simply to avoid expressions that end like this:
         		)))))))))))))))))))))))))))))))
        Further rules like the British rule:
      1. BODMAS::mnemonic="Brackets, Division, Multiplication, Addition, Subtraction", have been a part of algebraic expressions since for many decades.

        Priorities are an excepted part of almost all programming languages.

        Effect of ASCII

        MATHS is committed to express ideas directly in ASCII rather than encoding the written and printed look-and-feel. So the notation in expands in some unusual directions. In particular because ASCII does not have graphic characters there is a need for
        1. Operators identified by multi-character identifiers
        2. The ability to define operators locally
        3. The need for operator overloading and polymorphism.

        Need for Serial and Parallel Operators

        When mathematicians invented matrices, quaternions, and vector analysis they created a way of handling complex objects in very simple ways. This lead to a generalized form of "bulk operation" in APL and later in FP.

        Several papers and texts in the last 10 years have been espousing notations that are an extention of the traditional Σ and Π notations of mathematics. Drawing on the traditional notations, Donald Knuth's extensions in his "Art of Computer Programming", The λ calculus, and quantifiers in logic, these writers are proposing various uniform notations for quantification, summation, products, etc.

        So there is a need for rules for expressions handle the large number associative infix operations that are also used to apply to vectors, sets, and series of elements - here the standard MATHS solution: Serial and Parallel Operators is unique and powerful.

        MATHS is not the only notational system invented with similar generalisations of the Σ and Π notation. They are quite common in Computer Science. Apl had them. Knuth tinkers with Σ and Π. Unity and Z have their forms. Gries and Scheiner have their versions.

        Inheritted Features

        Expressions in MATHS follow a more general syntax than expressions in a programming language. Expressions include ideas borrowed from both mathematics and several other unnatural languages:

         Mathematics		Inverse functions, composition,...
         ADA		overloading, meaning determined by types.
         APL		Functions that operate on sets, vectors, and lists
         POP		equivalent Prefix and postfix forms
         Church, ISWIM	functions as results of expressions - '\lambda'
         ML, FP		Higher order functions
         OOP		Inheritance and polymorphism, `multimethods`
         Z		Schematic expressions summarizing logical systems

      . . . . . . . . . ( end of section Introduction) <<Contents | End>>

      Recognizing an expression.

      Just about any string of words and symbols is a possible expression... but to be meaningful it must follow special rules.

      MATHS uses an explicit multiple pass or co-routine grammatical description.



        (E1): A string of lexemes that is not terminated by a comma or period occuring outside parentheses of some kind or other, can be expression. But an expression can not contain a comma or period outside of parentheses. MATHS therefore uses punctuation to recognised balanced expressions.


      1. (E1)|- (E1a): By default a sentence, or a comma terminated phrase is a weak kind of expression.


        (E2): A second cut needs a set of operators - those symbols that only make sense when accompanying other symbols - and defines whether an expression is functional.


        (E3): A final process checks whether the balanced applicative expression is correctly type, and also infers the types in cases of ambiguity.


    1. expression::= balanced & functional & types_ok.

    2. BALANCE::=following.
      Net
        This uses the lexemes defined in the MATHS Lexicon [ notn_10_Lexicon.html ] For example
      1. comma::=",". [ comma in notn_10_Lexicon ]
      2. period::= "." whitespace. [ period in notn_10_Lexicon ] A period is a dot followed by a whitespace. So "1.2" and "java.awt" have no period in them. This is borrowed from COBOL.
      3. left::= "{" | "(" | "[" | ..., [ left in notn_10_Lexicon ]
      4. right::= "}" | ")" | "]" | ..., [ right in notn_10_Lexicon ]

        The definition of balanced is used to define an expression and a gloss (an definition in a glossary).

      5. balanced::= #(lexeme ~ ( comma | period | left | right) | quantified | schematic ).
      6. quantified::=( for_symbol #( comma | balanced )|) schematic.
      7. schematic::= left sentence #( period sentence ) right.
      8. sentence::=clause #( comma clause).
      9. clause::=balanced.
      10. for_symbol::="for" | "For".

        Notice that MATHS permits expressions like "[0..1.23)" where a l_bracket is balanced by a r_parenthesis. This is because these expressions are in use in mathematics.


      (End of Net)

    3. FUNCTIONALLITY::=following
      Net
        If we are given the set of currently defined operators then we can further parse an expression according to these rules:
      1. lexeme::Sets,
      2. operator::@lexeme. Use LEXICAL. [ notn_10_Lexicon.html ] [ //csci.csusb.edu/dick/maths/math_11_Standard ]
      3. (SYNTAX)|-For X:@#lexeme,
      4. O(X)::= (X | ),
      5. P(X)::= "(" X #( comma X ) ")",
      6. R(X)::="(" identifier "=>" X #( comma identifier "=>" X) ")",
      7. N(X)::= (X #X).

      8. functional::= prefix | infix | postfix,
      9. prefix::=N( (slash |) operator) delimited,
         		sin(x), /sin(x), +x, -x, ...
      10. postfix::=delimited (dot| "./") operator #( O(slash) operator),
         		x.sin, 4.th, x./sin, x.+
      11. infix::= delimited #( (operator | omitted_operator ) delimited),
         		x+y, (x*y)=(4*3), ...
      12. omitted_operator::=whitespace. In MATHS one infix operator can be left out without ambiguity -- as long as a complete list of operators is available. Normally this symbolizes the concatentation of two sets of strings. The operator itself shown as "( )". In looser expressions with a natural sentence structure white space also acts as an omitted_operator.

      13. delimited::= abstraction | mapping_form | extension | definite_description | quantified | non_punctuation_lexeme | uniform_binding,
      14. uniform_binding::= operator scheme.
      15. scheme::=defined in the MATHS Lexicon, [ scheme in notn_10_Lexicon ]

      16. abstraction::=#( binder bindings ) P( functional ) right. Some uniform bindings also act as abstractions.

      17. extension::= l_brace bindings double_bar functional r_brace. Some uniform bindings also act as extensions.

      18. mapping_form::= l_parenthesis O( operation | function_name | under_score ) r_parenthesis. Some uniform bindings also act as mapping_forms.

        .Note Non-uniform abstractions, extensions, and mappings are older than the uniform bindings. In time they may become deprecated and then, perhaps removed from MATHS. This depends on which notations become used the most.

      19. operation::=operator | under_score operator delimitted | delimitted operator under_score. Symbols like (1st), (2nd), (rest), (!), (_+1), (2*_) indicate functions. (_) is short for an identity function of some type or other. So (+) is an unambiguous symbol for the map that adds values together.

      20. definite_description::= "the" l_parenthesis bindings double_bar functional ( double_bar functional |). There is a uniform version of definite descriptions.
      21. quantified::=("for"|"For") bindings l_parenthesis functional r_parenthesis. Again there is a uniform binding notation for quantified expressions.

      22. binder::= O("map") | "rel" | "the" | "set", A binder introduces a new meaning for one or more variables. It is said to bind them.

      23. bindings::= binding | l_bracket binding #(comma binding) r_bracket, The brackets are needed to enclose the commas in the list. They are helpful even when not necessary.

        Bindings tie a mathematical or algebraic variable to a localized meaning - in other words to a type. Conventional abreviation - if a variable is in a binding, without a set or type attached to it, then it gets back the type of its previous usage in the text.

      24. loose_binding::= variable O(colon functional ) | set_name variable O( "where" functional ).
      25. tight_binding::=variable ":=" functional.

        In a loose binding, if the type is omitted then the newly bound variable has the same type as it's previous use in the document.

      26. binding::= variable O(colon functional | ":=" functional) | set_name variable O( "where" functional).

        The following indicate equivalent syntactic forms:

      27. For set_name S,variable v, (S v) ::=( v:S ).
      28. For set_name S, proposition P, variable v, (S v where P) ::= (v:{v:S||P}).

        Experimental Notation June 1999

        I'd to find out the implications of allowing a set of bindings to include propositions so that
      29. For set_name S, proposition P, variable v, ( v:S, P) ::= (v:{v:S||P}). Some of the implications of this freedom are not clear. Here are some examples:
      30. +[i:Nat, 0<=i<17](i*i).

        Note. I've already extended well formed formulae in formal pieces of documentation to include something like this.

        Bound variables are arbitrary

        The meaning of an expression is not changed if a binding and its expression are changed systematically by replacing one variable by another as long as the new variable isn't free in the expression:
      31. map[x](x+1) = map[y](y+1),
      32. map[z](x*z) = map[y](x*y) <>map[x](x*x).

        Free Variables

        Associated with each functional expression is a set of variables that are used in that expression and not bound in it - the free variables. The rules are simple but hard to express:
        1. Any term used in an expression is a free variable of that expression if it is not bound in a surrounding expression.
        2. A term used in an expression is a bound variable if it is bound in that expression.

        The binding essentially hides the variable from expressions that contain the expression in which the variable is bound. In the subexpressions an expression appears free. However a binding is always local, so an original meaning can be overridden locally and then the original can reappear - in the usual way (as in C, C++, the lambda calculus, Algol 60, and the integral calculus).

        For example, if free maps and expression into a set of free variables and bound maps into the bound variables then we have:

      33. free(1) = {},
      34. free(1+2+3)={},
      35. free(x+1)={x},
      36. bound(x+1)={},
      37. bound(map[x](x+1)) = {x},
      38. free(map[x](x+1)) = { }.

        So,
        Net

        1. free(constant) ={},
        2. free(variable) ={variable},
        3. free(e1 op e2) =free(e1) | free(e2),
        4. free(fun(e)) =free(e),
        5. free(map[variable:Type](e)) = free(e)~{variable},
        6. ...
        7. bound(constant) ={},
        8. bound(variable) ={},
        9. bound(e1 op e2) =bound(e1) | bound(e2),
        10. bound(fun(e)) =bound(e),
        11. bound(map[variable:Type](e)) = bound(e)|{variable},
        12. ...

        (End of Net)

        The full treatment of binding and free variable depends on the existance and position of globally defined symbols, see [ notn_11_Names.html#name ] for more.

        Free and bound variables have to watched carefully in substitution (Substitution). So when substituting for a variable only the free occurences can be replaced. Further when the substituted expression contains a free variable that is also bound in the expression, then the bound variable must be changed to a different one.

        The simple binding scheme creates an abstraction that can be used to define functions, maps, relations, sets, ...


      (End of Net)

      Type checking

      The syntax above allows expressions to be recognised, delimited, and roughly parsed. Further parsing depends on the types of the symbols in the expression. A formal model of expressions has been developed in the theory of types which sorts out questions of precedence and the like [ types.html ] Here is a summary of that documentation:

      First the notation for applying a function to an expression:

    4. For f:(T1^ T2).expression, e2:T2.expression, f(e2) :: T1.expression.
    5. For f:(T1^ T2).expression, e2:T2.expression, (e2).f:: T1.expression.
    6. For f:(T1^ T2).expression, e2:T2.expression, f(e2)=(e2).f.

      A similar rule holds for functions that require several arguments:

    7. For e1:T1.expression, e2:T2.expression, ..., f:T1^ (T2><T3><...), f(e2,e3, ...) :: T1.expression.
    8. For e1:T1.expression, e2:T2.expression, ..., f:T1^ (T2><T3><...), (e2,e3, ...).f :: T1.expression.
    9. For e1:T1.expression, e2:T2.expression, ..., f:T1^ (T2><T3><...), f(e2,e3,...) = (e2,e3,...).f .

      Finally, for any function with two arguments,

    10. For e1:T1.expression, e2:T2.expression, f:T1^ (T2><T3>) (e2 f e3) :: T1.expression.
    11. For e1:T1.expression, e2:T2.expression, f:T1^ (T2><T3>) (e2 f e3) = f(e2, e3) = (e2,e3).f.

      Parentheses can be omitted, at risk of ambiguity. Similarly commas and periods can be replaced by whitespace - but the list must be delimited by parentheses, braces, or brackets ({[]}).

      Serial Operators

        Some associative operators of type f:T1^ (T1><T1>) are designated to be SERIAL operators. If f:T1^(T1><T1) is SERIAL then f is altomatically defined as in (#T1)->T1:
      1. f(e1,e2,...) =e1 f e2 f e3...=(e1,e2,e3,...).f, and
      2. f(e1) = e1.

        Common Serial Operators

        Examples of serial operators are (and) (or) (&) (|) (!) (+) (*). This is a simplification of the notation proposed and implemented by Iverson in APL and that of Bachus's FP operations. Notice the special cases:
        For x:#@, and(x) = all elements in x are true,
        For x:#@, or(x) = some elements in x are true,
        For T:Types, x:#@T, &(x) = the intersection of all elements in x,
      3. For T:Types, x:#@T, |(x) =` the union of all elements in x`,
        For x:#Numbers, +(x) = the sum of all elements in x,
        For x:#Numbers, *(x) = the product of all elements in x,
        For x:#%T, !(x) =the concatentation of elements in x.

        Serial operators can also be used with the uniform_binder notation:

      4. +( i:Nat || odd(i), i <= N || i ) = N^2
      5. +( i:Nat . odd(i), i <= N . i ) = N^2

        Serial Commutative Operations on Sets

        A commutative serial operator like addition, multiplication, intersection, conjunction, union, and disjunction can operate on sets without ambiguity, however this may or may not have a pre-defined value when the set is not finite. So we have:
      6. For SERIAL(f), if f in commutative(A), f :: ((@A)~{{}}) <>->T1. -- f is not always defined on all subsets of A.
      7. For f, f :: ((finite@A)~{{}}) ->T1. -- f is defined for all finite subsets of A.

      8. For all f, f{a} = a.

      9. For f, S1,S2:finite@A~{{}}, if S1 & S2 ={} then f( S1 | S2) = f( S2 | S1) = f( S2 ) | f(S1). -- On finite subsets the sum of a disjoint union is the sum of the sums of the parts.

        If f has a unit(u), then f({})=u. Note. f has a unit(u) iff for all x ( (x f u)=(u f x)=x ).

        The following theorem follows for commutative serial operators (+) with an unit 0 and inverse (-) on finite sets S1 and S2:

      10. |- (decomp): For finite_sets S1,S2, +( S1 | S2 ) = +(S1) + +(S2) - +(S1&S2).

        Note.

      . . . . . . . . . ( end of section Serial Operators) <<Contents | End>>

      Parallel Operators

      All relations - operators of type @^(T1><T1) except and, or` are PARALLEL operators:
    12. e1 R e1 R e1...= R(e1,e1,...) =(e1,e1,...).R= (e1 R e1) and (e1 R e1)...
    13. <(1,2,3,4) = (1<2<3<4) = 1<2 and 2<3 and 3<4 = (1,2,3,4).<

      Examples of PARALLEL operators are iff, =, are, <,<=,<>,!=, >=,==>,>==, ->,...

      Thus, if f:@^(T1><T1) is PARALLEL then f in (#T1)->@, but if f is SERIAL then f in (#T1)->T1.

      Notice the special cases:



        iff(x) = x is a list of equivalent logical values,
        =(x) = x is list of identical elements,
        !=(x) = x is list of elements with no adjacent equal elements,
        <=(x) = x is sorted into increasing order,
        <(x) = x is sorted into increasing order and has no equal elements,
        =>>(x) = x is an ascending chain of subsets,
        ->(x) = the elements in x are connected by mappings.

      Uniform Binders

      The following definitions are based on Gries's uniform binding notation:
      1. op( x:T || P || E)::= op[x:(set[x:T](P))](E).
      2. op( x:T || E)::= op[x:T](E).
      3. op( x:T )::= op[x:T](x).

      .Note A new experimental form uses sentences and periods rather than the double_bar.
      1. op( x:T . P . E)::= op[x:(set[x:T](P))](E).
      2. op( x:T . E)::= op[x:T](E).
      3. op( x:T )::= op[x:T](x).

      If you have a strong feeling one way or another about using "||" or " . " in these kinds of expressions please send me EMail. The ultimate form adopted will be determined by what people want. EMail by clicking "Contact" at the top_of_page. with subject: MATHS: Dots or Bars.

      Precedence and Typing

      Strong typing is used in MATHS (but not programming languages) to resolve some apparent ambiguities:
    14. x + y > z can not be interpereted as
    15. +(x,>(y,z)) because + does not accept an expression of type @ as an argument. A fundamental assumption in MATHS notation is that we have an intelligent reader - one that can resolve this kind of apparent ambiguity.

      Rules of precedence can resolve other ambiguities. Given that both f,g:T><T->T then it is not imediately clear whether

    16. x f y g z is to be read as
    17. (first): (x f y) g z = g(f(x,y),z) =((x,y).f,z).g or
    18. (second): x f (y g z) = f(x, g(y,z))=(x,(y,z).g).f.

      In the first case we write that f takes precedence over g, and in the second that g takes precedence over f.

      The following precedences are predefined in MATHS - to follow established mathematical conventions:

    19. (*) and (/) take precedence over (+) and (-)
    20. (and) and (not) take precedence over (or)
    21. (&), (;), (o), (!) and (~) take precedence over (|)

      Finally when o:X->(A->B) an expression like x.o(a) is parsed as (x.o)(a) rather than x.(o(a)). This convention is chosen so that we can have:

    22. 4.th(x) =x(4).

      Substitution

      Given a map (set of pairs: x+>y ) M that associates variable symbols and names with meanings and an expression e then `substitute(M, e) replaces each free occurrence of a variable in e that is also in M` by its associated value in M. It does not replace bound occurrences however. For example:
    23. substitute( (a+>1 | b+>2 ) , 2*a+b+map[a:real](b+1+a) ) =
    24. 2*1+2+map[a:real](2+1+a) =
    25. 5+map[a:real](a+3)=
    26. 5+map[x:real](x+3) = 8+(_).

      Roughly we have these rules to defines substitution:

    27. substitute((v+>a) , e) = a.map[v](e).
    28. substitute((v+>a)|A, e) = a.map[v](substitute(A, e))=substitute(A, a.map[v]( e)).

      Some care must be taken when M substitutes an expression that contains a free variable into an expression that binds that variable. For example:

    29. substitute((x->(y+1)), map[y](2*x+y) ) = map[z](2*(y+1)+z)
    30. substitute((x->(y+1)), map[y](2*x+y) ) <> map[y](2*(y+1)+y) Because the y in y+1 is captured by the map[y]`.

      However, the order of substitution is not defined and so only Ms can be used where the order does not matter. This means that no elementary substitution can insert a variable that is being replaced in a different elementary substitution. for example For example

    31. substitute( (x+>x+y | y+>x*y), x+y ) could mean
    32. substitute( (y+>x*y), x+y+y ) = x+2*x*y or
    33. substitute( (x+>x+y), x+x*y ) = (x+y)+(x+y)*y = x+y+x*y+y*y. Hence substitute( M, e ) is defined and can be used only when M does not include pairs x+>e1 and y+>e2 where y is free in e1 or x is free in e2.

      Combinations of Maps

      MATHS defines several shorthand forms for what are called `higher order functions` in other languages. However, the forms have been chosen to generalize mathematical usage and also express ideas that are often need in formal specifications.


    34. |-For f:T1^T2, g:T2^T3, f(g) = g o f = f;g = map x:T3( ((x).f).g ) in T1^ T3

      A map is a relation and so it is a set(of pairs) and so has different meanings depending on the types of the arguments, and the context of the resulting value. In particular, functions are extended to sets, lists and maps:

    35. For f:T1^ T2, E1:@T1.expression, E2:@T2.expression, f(E2)=(E2).f ={x:T1 || for some y:E2( f(y) ) }.

    36. For f:T1^T2, E1:#T1.expression, E2:#T2.expression, f(E2)=(E2).f = map i:1..|E2|( f(E2[i]) ) = E2.f = f o E2.

    37. For f:T1^T2, e1:expression(T1), E1:@T1.expression, /f(e1) = (e1)./f = {x:T2 || f(x)=e1}.
    38. For f:T1^T2, e1:expression(T1), E1:@T1.expression, /f(E1) = (E1)./f = {x:T2 || for some y:E1(x in y ./ f) }.

      Some expressions describe relations. They use these operators "/", "o", "do", "&", "not", "|", ";" etc. They are best written as postfix operators on elements and sets:

    39. For e1:expression(T1), E1:(@T1).expression, R:@(T1,T2), e1.R in expression(@T2).
    40. For e1:expression(T1), E1:(@T1).expression, R:@(T1,T2), E1.R in expression(@T2).

    41. For e2:expression(T2), E1:(@T2).expression, R:@(T1,T2), e2./R in expression(@T1).
    42. For e2:expression(T2), E1:(@T2).expression, R:@(T1,T2), E2./R in expression(@T1).

    43. For f, R:@(T1,T2), R mod f:@(T1, T1) ::= rel x,y(x.f R y.f).
    44. For f, R:@(T1,T2), (= mod f) = rel [x,y] (x.f=y.f).

      Equivalences

    45. For e1:expression(T1), E1:expression(@T1), f:@(T1,T2), e1/f = ((e1).f)./f.
    46. For e1:expression(T1), E1:expression(@T1), f:@(T1,T2), E1/f = {y/f:T2||for some y:E1 }.

      .Dangerous_bend

    47. e1 / f <> e1 ./ f

      Conditions for an expression to be unambiguous

        Functions connect expressions of different types. Some expressions are generic or polymorphic in the sense that the types of the parts of the epression depend on the choice of actual types to replace certain symbolic ones. This not a problem. The type is ambiguous when there are two ways to assign types to the parts of an expression so that it gives different meanings.

        Example

        	  --f---> B ---g---
        	 /                 \
        	A                   C
        	 \                 /
        	  --f---> D ---g---
        There are two paths from that fit the sequence (f,g). There is only one that fits (f, B, g). Hence f(g(a)) and g o f are ambigous but g o B o f is not.

        However if the previous diagram commutes so that g o B o f = g o D o F then the ambiguity as more apparent than real.

        Theory for assigning types

        The nodes/vertices are data types and the arcs/edges are operators/functions. Find all ways of interpreting an expression written in postfix form. Data types can be used to indicate the type of an expression.

        Given a finite digraph with nodes/vertices N and edges/arcs E which has been labelled with symbols from an alphabet A. Node n:N has an unique label f(n) in A. Edge e:E has a possibly non-unique label g(e) in A or a null/empty string. The sets of labels on the nodes and arcs do not overlap. Notice - unique node labels, but non-unique and perhaps null edge labels.

        .Road_work_ahead Given a path/sequence of arcs p=((n1,n2),(n2,n3),....)

      1. and a word w=(w1,w2,w3,...) in #A then p fits w iff
      2. either both p and w are empty
      3. or w is empty and all g(p(i)) are null
      4. or w1=f(n1) and w2=g(n1,n2) and ((n2,n3),....) fits (w3,...)
      5. or w1=g(n1,n2)<>null and ((n2,n3),....) fits (w2,...)
      6. or g(n1,n2)=null and ((n2,n3),....) fits (w1,...).

        Given w find ps that fit w and show thare are not two ps that fit w with the same number of nulls.

      . . . . . . . . . ( end of section Conditions for expression to be unambiguous) <<Contents | End>>

    . . . . . . . . . ( end of section Expressions in MATHS) <<Contents | End>>

    Notes on MATHS Notation

    Special characters are defined in [ intro_characters.html ] that also outlines the syntax of expressions and a document.

    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 Structure in logic_25_Proofs ] for more on the structure and rules.

    The notation also allows you to create a new network of variables and constraints. A "Net" has a number of variables (including none) and a number of properties (including none) that connect variables. You can give them a name and then reuse them. 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. A quick example: a circle = Net{radius:Positive Real, center:Point}.

    For a complete listing of pages in this part of my site by topic see [ home.html ]

    Notes on the Underlying Logic of MATHS

    The notation used here is a formal language with syntax and a semantics described using traditional formal logic [ logic_0_Intro.html ] plus sets, functions, relations, and other mathematical extensions.

    For a more rigorous description of the standard notations see

  1. STANDARD::= See http://www.csci.csusb.edu/dick/maths/math_11_STANDARD.html

    Glossary

  2. above::reason="I'm too lazy to work out which of the above statements I need here", often the last 3 or 4 statements. The previous and previous but one statments are shown as (-1) and (-2).
  3. given::reason="I've been told that...", used to describe a problem.
  4. given::variable="I'll be given a value or object like this...", used to describe a problem.
  5. goal::theorem="The result I'm trying to prove right now".
  6. goal::variable="The value or object I'm trying to find or construct".
  7. let::reason="For the sake of argument let...", introduces a temporary hypothesis that survives until the end of the surrounding "Let...Close.Let" block or Case.
  8. hyp::reason="I assumed this in my last Let/Case/Po/...".
  9. QED::conclusion="Quite Easily Done" or "Quod Erat Demonstrandum", indicates that you have proved what you wanted to prove.
  10. QEF::conclusion="Quite Easily Faked", -- indicate that you have proved that the object you constructed fitted the goal you were given.
  11. RAA::conclusion="Reducto Ad Absurdum". This allows you to discard the last assumption (let) that you introduced.

End