W3C home > Mailing lists > Public > www-math@w3.org > July 2000

Re: Content markups, piecewise functions, conditions

From: Stan Devitt <jsdevitt@radicalflow.com>
Date: Wed, 12 Jul 2000 18:49:30 -0400
Message-ID: <001c01bfec53$7131e800$6561a8c0@devitt.local>
To: "Andreas Strotmann" <strotman@cs.fsu.edu>
Cc: Gérald QUINTANA <quintana@lyon.objectif.fr>, <www-math@w3.org>
One quick point.

The advantage of a tagged data-structure over a lambda construct
is: that can be recognized as being a piecewise definition.

In particular, this means that it can be quickly recognized as such
and for display purposes, it means that you can invoke a special
transformation immmediately instead of having to do sophisticated
pattern matching on the arguments to lambda to see if you want
a special notation for display.

The key approach here is to:

1.  Figure out what information is needed to represent
piecewise defined functions.
2.  Put that information into a tagged data -structure,
possibly with explicit pairings as Andre suggests.
3.  As a completely separate issue, map the tagged
data-structure onto a display.

It can't be emphasised too much that the "tagged"
data structures are what enable you to re-use the
information in an efficient and predictable way.

Apart from that, I agree with Andre that some thought
should go into the actual structure.

Stan.

    2.
----- Original Message -----
From: "Andreas Strotmann" <strotman@cs.fsu.edu>
To: "Stan Devitt" <jsdevitt@radicalflow.com>
Cc: "Gérald QUINTANA" <quintana@lyon.objectif.fr>; <www-math@w3.org>
Sent: Wednesday, July 12, 2000 6:01 PM
Subject: Re: Content markups, piecewise functions, conditions


> Hi all,
>
> this is actually quite an interesting question, and I don't think I have a
> quick answer, either.  Personally, my analysis would deviate somewhat from
> Stan's, however.
>
> Off the bat, I would prefer getting the <bvar>s out of the picture, and to
> factor the question of representing piecewise functions into the two
> "orthogonal" concepts of "functions" and "pieces"/"cases".  There is ample
> historical precedence for this approach, of course - LISP's lambda
> and cond, plus pretty much all other programming languages do that.
>
> In this sense, sign(x) would be something like:
>
>   sign = lambda(x,  cond( (x<0,-1), (x>0,+1), (x=0,0)))
>
> Note that in this representation, "cond" does not bind variables, and
> conditionals can in principle involve arbitrary free variables.
>
> The latter is actually quite useful, I believe, since there are some
> well-known scenarios beyond that of piece-wise functions where it is
> "parameters" rather than arguments that are used to distinguish cases.
> Tables of integrals abound with entries where conditions involving one or
> more parameters of the integrand determine the actual closed-form solution
> for the integral -- consider
>
>  integral of x^a wrt x      is    x^(a+1)/(a+1)
>  unless a=0, in which case it is  ln(x).
>
> for a well-known example;-)
>
> Since parameter a in this example is not a bound variable, MathML's
> semantics do not allow the use of <condition> elements here as they
> require corresponding <bvar>s.
>
> Thus, the easiest solution with the least amount of impact on MathML
> would probably be to represent the sign example above as
>
>   sign = lambda(x, ( x<0 => -1 )  or  ( x>0 => +1 )  or  ( x=0 => 0))
>
> with appropriately extended semantics of <or/>(*) and <implies/>.
>
> Regards,
>
>    Andreas Strotmann
>
> (*) or perhaps <xor/> if at most one case is allowed to return a result.
> Multi-branch functions, e.g. the "plus or minus" in solutions to quadratic
> equations, might use <or/> to denote admissibility of results from any
> conditional branch.
>
> ____________________________________________________________
> "The act of defending any of the cardinal virtues has today
> all the exhilaration of a vice." -
> G.K.Chesterton: A Defense of Humilities, The Defendant, 1901
>                            www.chesterton.org/acs/quotes.htm
>
> On Tue, 11 Jul 2000, Stan Devitt wrote:
>
> > Note that the important thing to do is to capture
> > the information.  The essence of a piecewise object is:
> >
> >     1.  there is a bound variable
> >     2.  there is one or more conditions on that variable
> >         bound to outcomes, typically computed using that
> >         variable.
> >     3.  possibly a default outcome
> >
> > MathML does NOT evaluate or simplify its expressions.
> >
> > With this in mind, you probably want to choose between
> >
> >  piecewise( bvar , (condition, value )*, default )
> >
> > and
> >
> > piecewise( bvar , default , conditiongroup * )
> >
> > where
> >         conditiongroup :=   conditiongroup( condition , value )
> >
> > Either one will do the job.  Both are easy to encode using
> > csymbol, and bvar, at least in MathML 2.0.  (There were some
> > funny restrictions in MathML 1.0 that did not allow bvars
> > in new expressions and required function wrappers in the
> > first argument to apply.)  In 2.0 the first of these would look
> > something like:
> >
> >     <apply>
> >         <bvar>x</bvar>
> >         <csymbol
definitionURL="mydefinitionforpiecewise">piecewise</csymbol>
> >         <apply><lt/> ....</apply>
> >         <apply><times/> ...</apply>
> >         <apply></lt/> ... </apply>
> >          value 2
> >          default value
> >     </apply>
> >
> >
> > Note that reln is deprecated in MathML 2.0
> > Also, generally speaking it is a bad idea to encode essential
> > information in comments as sometimes processing strips those
> > comments away.
> >
> > There is no real need to use the lambda constructs as that information
> > would already be contained in the formal definition, and is really more
concerned
> > with evaluation than representation.
> >
> > Stan Devitt
> >
> >   ----- Original Message -----
> >   From: Gérald QUINTANA
> >   To: www-math@w3.org
> >   Sent: Tuesday, July 11, 2000 11:45 AM
> >   Subject: Content markups, piecewise functions, conditions
> >
> >
> >   Hi,
> >
> >   I am thinking about how I could code a piecewise function using
> >   content markups. I need content markups because I aim at making a small
> >   MathML "parser-compiler". I didn't understood exactly how conditions were
> >   working. So as to code the sign function (returns -1 when x<0, 0 when x=0
> >   and +1 when x>0) what do you think of this ? How can I tell that those 3
> >   definitions belongs to the same function ?
> >
> >   <?xml version="1.0" encoding="UTF-8"?>
> >   <!DOCTYPE math SYSTEM "file://localhost/S:/java/xerces/mathml/mathml.dtd"
>
> >   <math>
> >     <!--If x<0 then -1-->
> >     <lambda>
> >       <bvar>
> >         <ci>x</ci>
> >       </bvar>
> >       <apply>
> >         <bvar>
> >           <ci>x</ci>
> >         </bvar>
> >         <condition>
> >           <reln>
> >             <lt/>
> >             <ci>x</ci>
> >             <cn>0</cn>
> >           </reln>
> >         </condition>
> >         <apply>
> >           <minus/>
> >           <cn>1</cn>
> >         </apply>
> >       </apply>
> >     </lambda>
> >     <!--If x=0 then 0-->
> >     <lambda>
> >       <bvar>
> >         <ci>x</ci>
> >       </bvar>
> >       <apply>
> >         <bvar>
> >           <ci>x</ci>
> >         </bvar>
> >         <condition>
> >           <reln>
> >             <eq/>
> >             <ci>x</ci>
> >             <cn>0</cn>
> >           </reln>
> >         </condition>
> >         <cn>0</cn>
> >       </apply>
> >     </lambda>
> >     <!--If x>0 then +1-->
> >     <lambda>
> >       <bvar>
> >         <ci>x</ci>
> >       </bvar>
> >       <apply>
> >         <bvar>
> >           <ci>x</ci>
> >         </bvar>
> >         <condition>
> >           <reln>
> >             <eq/>
> >             <ci>x</ci>
> >             <cn>0</cn>
> >           </reln>
> >         </condition>
> >         <cn>1</cn>
> >       </apply>
> >     </lambda>
> >   </math>
> >
> >   Thanks for your help,
> >   Gerald.
> >
> >
> >   ________________________________
> >   Gérald QUINTANA
> >     gerald.quintana@ecl2000.ec-lyon.fr
> >     http://www.multimania.com/gquintana
> >
>
Received on Wednesday, 12 July 2000 18:44:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 20 February 2010 06:12:49 GMT