On Oct 4, 2012, at 9:02 PM, Matthew Rocklin <[email protected]> wrote:
Well, it's not clear to me how this would even be used. Is there some
> system that lets me say what rules I want (either very specifically,
> or in some more general way)? Is there some registry of all defined
> rules?
This is how the Theano project does things (I've CCed Frederic and James
from that project on this thread). How you get at the rules is an
orthogonal question to the rules and strategies themselves. In general, yes
a registry sounds good. To start in MatrixExpressions I'll probably just
create and use a few conglomerate rules. Our major functions simplify,
flatten, etc... could be swapped out with large rules.
> The speed depends on how that actual application of the rules
> is implemented. If things do end up being slow, we can possibly cache
> some stuff, or look at implementing it better.
>
Yes, there is lots one can do. Caching would be a fine strategy. What I
like is that the people who care about efficiency can work on this
separately from the people who care about the mathematics. You no longer
need to know both to contribute. The computational core is also likely to
be pure CS rather than a mix of CS+math.
> 2. It is a bit more sophisticated/clever. Requires you to think about
> higher
> > order functions
>
> I think if you use a good class structure then it won't be. To create
> a new rule, one just has to create a subclass of something (maybe a
> similar rule, maybe a base Rule class), that just defines the key
> components of the rule (i.e., those parts that make that rule
> different from other rules). All the if, else, map, etc. stuff should
> be abstracted in base classes.
This is a personal preference but I strongly prefer higher order functions
to inheritance. My prototype is unlikely to be OO. I think that objects are
overkill for this task.
I have to disagree, and believe me, I'm the last person to prefer an OO
style over an imperative one when imperative would do just fine (this is
one of the reasons that I hate Java). But in this case, I think it will
remove a lot of code duplication. You run into problems with a functional
interface in Python real fast because there are no attributes, and it's
impossible to inspect the code of the function. So you'll end up creating
functions that return dictionaries of the data you want. When that happens,
you are better off just using a class, which is a much cleaner way to have
a namespace (and you also get inheritance for free!).
How would my tan = sin/cos example look in your proposed functional model?
Aaron Meurer
> And if several rules are similar, we can also abstract that in in base
> classes as well. For example, a rule set like
>
> tan(x) -> sin(x)/cos(x)
> cos(x) -> sin(x)/tan(x)
> sin(x) -> tan(x)*cos(x)
>
> Are all based on the same concept, i.e., we have the identity t = s/c,
> and we can solve that identity for any of the three variables. So the
> rule object should be something as simple as
>
> class TanRule(IdentityRule):
> def __init__(self):
> t, c, s = symbols("t c s")
> self.identity = t - s/c
> self.mapping = {t: tan, s: sin, c: cis}
>
> Than the logic for figuring out how to convert sin in terms of tangent
> and cosine would all be in IdentityRule. And if there's some kind of
> rule registry, that could extract from this rule the information
> needed to apply a transformation in the kind higher level terms like
> that. If it's smart, we could even make it smart enough to combine
> rules, so that we only have to tell it about a minimal number of
> identities.
>
Yes, fortunately functions are also a very low common denominator. It would
be possible to build lots of things that create rules. I think that the
core should be functional but that, if people prefer objects then they
could be built on top fairly simply.
> Actually, my above example is still a little naive, because it doesn't
> work if the functions are not direct functions. For example, the
> identity sin(2*x) = 2*sin(x)*cos(x) would require one of the mappings
> to be a Lambda. So I think we will also need good pattern matching
> for this to work well.
>
Traditional rewrite rules are written with pattern matching in mind. What
I've proposed is a bit lower-level/low-tech. We could probably build a
rudimentary pattern matching/term rewriting system on top of this with
replace/match/find. Again, the base of `Rule :: Expr -> Expr`, is very low
level and general. We may want to build something on top of it. It's not
yet clear to me what that should be.
> I'm glad that someone is finally taking initiative on this. I think
> that MatrixExpressions are both expressive enough but small enough to
> make a good testing ground for these ideas.
>
I agree. I'm quite fond of that little module.
--
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.
--
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.
