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
