[kepler-users] Recommended approach for new matrix operators

[Edward A. Lee]

Stopping short of modifying the expression parser, you can already
do much of what you need for the first part.
In the Expression Evaluator:

 >> a = [1, 2; 3, 4]
[1, 2; 3, 4]

 >> b = [2, 3; 4, 5]
[2, 3; 4, 5]

 >> a.isGreaterThan(b)
[false, false; false, false]


For the cons example, I think it would work reasonably
well to extend the map() function. This would be better than
converting matrices back and forth to arrays.
Currently, in our expression language, you can define:

 >> f = function(c:boolean, a:int, b:int) c ? a : b
(function(c:boolean, a:int, b:int) (c?a:b))

This is a function that depending on the first arg
returns either the second or third. I.e., it's just
a function form of the if-then-else operator c ? a : b

The map() function is too limited to do what we want,
currently, but would be rather easy to extend.
What we want is:

 >> map(f, a.isGreaterThan(b), a, b)

which would return a matrix that contains (pointwise)
the largest elements. I'm not sure how hard extending
map() to support this would be, but I'm guessing not hard.
I'm also not sure how efficient this would be...

Edward


On 2/12/10 8:55 AM, Christopher Brooks wrote:
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eal.vcf
Type: text/x-vcard
Size: 351 bytes
Desc: not available
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/attachments/20100212/3c68bf07/attachment.vcf>