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

Re: Content markups, piecewise functions, conditions

From: Andreas Strotmann <strotman@cs.fsu.edu>
Date: Wed, 12 Jul 2000 19:47:20 -0400 (EDT)
To: Stan Devitt <jsdevitt@radicalflow.com>
cc: Gérald QUINTANA <quintana@lyon.objectif.fr>, www-math@w3.org
Message-ID: <Pine.GSO.4.10.10007121913430.1848-100000@xi.cs.fsu.edu>
> 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.

Yes, I agree with you here, Stan.  With respect to the actual
representation of the "cases" or "pieces", my quick-and-dirty solution
would require some multi-level pattern matching for discovering the proper
rendering, and I would certainly welcome the introduction of
special-purpose MathML content markup for something close to the "cond" or
"if-then-else" or something a little closer to the mathematical notation

        /  -1  for x<0
        |
sign(x)=<   0  for x=0
        |
        \  +1  for x>0

Special notation for "otherwise" (and, come to think of it, the concept of
"undefined" that is necessary once you're talking piece-wise defs) could
be added as well.

My main point was that I do not think that a conditional expression like
that should involve a <bvar>, as the notions of "piece-wise" and
"function" are clearly separable and orthogonal, and I'm not aware of a
mathematical notation that mixes them together in a way that is comparable
to the way that, say, notations for integration and differentiation mix
them. 

I also wanted to point out that there is available in MathML a way of
expressing quite cleanly the concepts behind piece-wise functions, as a
vindication of MathML as it stands.

Taken together, these two points simply argue that it is a matter of
choice (taste) whether to add the "pieces"/"cases"/"cond" concept to
MathML directly or via an extension mechanism like OpenMath. 

Personally, and based on the historical precedence from its ubiquity as
primitive construct in the programming world, I would prefer adding
something like Lisp's "cond" or like "if-then-else" as a MathML primitive.
In this, I very much agree with you, Stan.

  -- Andreas


PS: a piece-wise function in this sense would therefore be represented as

lambda(x, choice( case(x<0,-1),  case(x=0,0),  case(x>0,+1) ))

where the lambda construct says "function" and the choice one says
"pieces".  In addition, a declare construct (like lambda already available
for this purpose in MathML) would say "definition".  I do not think that
anything would be gained by adding to MathML a construct that mixes
together all three.  A lot would be gained by adding one that deals
exclusively with the missing concept.

(Note that it is indeed missing, despite providing a way to emulate it.)
Received on Wednesday, 12 July 2000 19:47:22 GMT

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