[kepler-users] Recommended approach for new matrix operators

[Thomas M. Parris]

Apologies for hammering on this a bit more.  I hope I'm not missing
something obvious.

I've played around with a.isLessThan(b) and a.isGreaterThan(b).  They work
exactly as I desire.  That accounts for two out of 5 of the element wise
relational operators (<, <=, ==, >=, >).  

If a.isEqualsTo(b) worked analogously to the above, I would be done (since I
could OR the results with the .or method).  But, consistent with the
documentation, the isEqualTo method compares the two matrices as a whole
(not element by element).

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

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

>> a == b
false

>> a.isEqualTo(b)
false

So to get the full suite of element-wise relational operators, it would
appear that we need an isEqualToElement(ScalarToken) method in the
ScalarToken class.

This looks like a straight forward adaptation of the isLessThan method in
the ScalarToken class.  Would it be consistent with the overall type
architecture?  

-- Tom

-----Original Message-----
From: Edward A. Lee [mailto:eal at eecs.berkeley.edu] 
Sent: Friday, February 12, 2010 4:56 PM
To: Thomas M. Parris
Cc: Christopher Brooks; 'kepler-users'
Subject: Re: [kepler-users] Recommended approach for new matrix operators


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
>