[kepler-users] Recommended approach for new matrix operators

[Christopher Brooks]

Hi Thomas,

If you are concerned about performance, then the thing to do would be to add
methods to the ptolemy.data.MatrixToken class and then implement those methods
in the *MatrixToken subclasses as necessary.

Note that ScalarToken has isGreaterThan(), isLessThan(), isEqualTo() and isCloseTo().
MatrixToken has isCloseTo() and isEqualThan(), so you would need to implement
isGreaterThan() and isLessThan().

You would also need to modify ptolemy.data.expr.ParseTreeEvaluator so that
it would accept matrices for relationships other than equals and not equals.
Try searching ParseTreeEvaluator for PtParserConstants.GTE.

If you make these changes in your tree, then I could fold them into the
Ptolemy II development tree.  If you write code to be folded in, please follow the
Ptolemy II coding style at
http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIlatest/ptII/doc/coding/style.htm

See below for a few comments.

_Christopher


On 2/12/10 5:50 AM, Thomas M. Parris wrote:
> Dear Keplerites,
>
> We find ourselves in need of some new operators for matrices.  Examples
> include:
>
> 	o relational "by element" operators (e.g.,<,<=, ==,>=,>), and a
>
> 	o a "con" operator in which the output element is chosen from one of
> two correspinding input elements using a third corresponding boolean input
> element.
>
> I see three possible implementation approaches:
>
> 	Option 1. user defined functions in the expression evaluator (using
> the map function)
> 		I'm worried about performance.  Our matrices tend to be
> large (720 x 360) and we have lots (1000s) of them.  Will this an issue?  It
> looks like the map operator expects arrays instead of matrices so there will
> be overhead for conversions back and forth in addition to any overhead for
> the map operator itslef (including interpration of the function).

Option 1 would probably be slower than Option 2 or 3.

> 	Option 2. simple transformer actors
> 		This is by far the easiest option to implement and is likely
> what we will do first to get us going.

Option 2 would be faster to implement.
> 	Option 3. extensions to the expression evaluator
> 		This option does not look to difficult and has the advantage
> of improved readability in workflows with lots of computations.

Option 3 would have the fastest performance, but require updating Ptolemy.

> I welcome advice/comment.  Are my performance worries for Option 1
> overstated?  Would there be general interest in make additional matrix
> operations available through the expression evaluator?
>
> With regards,
> Tom
> p.s. Once we climb the svn/ant learning curve a bit more, we'll contribute
> any new actors (or mods to the expression evaulator) to the code base.
>
> ----------------------------------------------------
> Thomas M. Parris
> Vice President
> ISciences, LLC
> 61 Main Street, Suite 200
> Burlington, VT 05401
> Voice: +802-864-2999
> Fax:   +617-344-2580
> Email: parris at isciences.com
>
> http://www.isciences.com/  http://www.terraviva.net/
> ----------------------------------------------------
>
> _______________________________________________
> Kepler-users mailing list
> Kepler-users at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-users

-- 
Christopher Brooks, PMP                       University of California
CHESS Executive Director                      US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841 fax:510.642.2718	      (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 cell: 707.332.0670