On Sat, Oct 6, 2012 at 6:57 PM, Matthew Rocklin <[email protected]> wrote:
>
>> The rules for MatMul and MatAdd are already rather comprehensible as
>> they are, but yes, xxinv is better structured.
>
>
> They're certainly no more complicated than the code that was there before.
Absolutely.
> The idea X Inverse(X) => Identity(X.rows) is substantially simpler than the
> code that was necessary to encode this rule though. This is going to be a
> common sort of rule so this is the sort of thing we should generalize
> somehow.
How about a predicate cancellable()? Thus, x (op) y will be
transformed into identity if cancellable(x, y). The generalised
function may then work as follows:
def mat_cancellable(X, Y):
return Y == Inverse(X)
cancel(composite_expression, mat_cancellable, I)
where composite_expression is an instance of Mul, Add, MatMul, MatAdd,
etc. If it is possible to extract the identity from this operations,
then the third argument will be unnecessary.
>> > I think that there should be some rules that are pure python functions
>> > (i.e.
>> > unpack, flatten).
>>
>> If we do abide by the overall immutability of the core, we may
>> probably be able to minimise the number of rules which are _not_ pure
>> functions. (When I say "pure" I mean with no side-effects; I hope we
>> are using the same terminology :-) )
>
>
> Ah, sorry, I was using pure in the sense of "lets just use this function,
> not a class that represents this function". I wasn't using "pure" in the
> side-effect-free sense. I do however think that this system should be
> (mostly) side-effect free (mostly for caching, profiling, debug, etc....)
> That's somewhat standard in SymPy though.
Yes, and that's an advantage. Although functions with side-effects
should also be handled nicely, because, from what I know, there
actually are some mutable objects in SymPy.
>> Further, when you say "pattern matching triples", do you mean
>> representing rules as triples and having the application function
>> which checks whether its argument matches from-expr and satisfies the
>> condition, and then returns to-expr?
>
> Yes. I would like to write xxinv as
> X = Wild()
> xxinv = rule(X*Inverse(X), Identity(X.rows), True)
> or
> sym_transpose = rule(Transpose(X), X, X.is_symmetric)
Looks very nice. Shouldn't be that hard to implement either, I think.
>> > Using these rules I was able to completely separate the dependence of
>> > MatrixExprs from Expr; a task that has been bothering me for a long
>> > time.
>>
>> I don't really know the reason why this dependency was bad, but the
>> way you used strategies to split the two is impressively clean.
>
>
> A few reasons:
> 1. People would do X.expand() and this would fail (expand is a method on
> Expr that was not implemented for MatrixExprs
> 2. MatAdd would use Add.flatten which would inject 1s and 0s into the args
> which had to be cleaned up.
> 3. Lots of other things like (2)
Oh. I'm slightly upset to find out that matrix expressions don't fit
nicely within Expr; I thought Expr should represent a general
expression. I believe I just have to read more code; sorry for
off-topic :-)
Sergiu
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
