Am 06.05.2012 05:45, schrieb Aaron Meurer:
I agree, except "in a comment" should be replaced with "in the
docstring".
That depends somewhat.
My impression is that the docstring should contain the information
that's relevant to users of the class - i.e. for SymPy users and for
callers, and that in-class comments should be used for implementation
notes and warnings to subclassers and later maintainers.
Personally, I think it all boils down to the discussion from
https://github.com/sympy/sympy/wiki/canonicalization.
I'd avoid leveraging double dispatch (in any of its incarnations), it
creates nonlocal behaviour. Which means that changes in class A can
modify behaviour in class B somewhere entirely else.
That said, it's possible that behaviour can't be made local (some
situations are like that). In that case, the set of potentially affected
classes needs to be documented and referenced from every involved class,
so maintainers know what's up.
Other than that, the Theano approach looks nice.
I'm not sure that we need to change much to use it. Pow, Add etc. could
already be considered graph node classes. All that's needed is an
expression walker that takes an expression and rewrites it (if I'm not
totally off the mark, we already have that in the form of "simplify").
If we want to
say two Exprs can be put together in an Add, for example, then it
matters if we let Add let its args define their own behavior on it or
not.
That's essentially the question of whether the decisionmaking can be
decentralized and live in the subclasses, or needs to be centralized.
Centralized decisionmaking is nice for making sure that the whole
picture is consistent, but it sucks because any maintainer needs to
understand the whole mess to work on a part.
Decentralized decisionmaking probably won't work - you probably can
break it all down into elementary steps, but you need to create emergent
behaviour from that, and that's fragile (any local change can
inadvertently destroy intended emergent behaviour).
Maybe the best approach is a combined one: Have a centralized routine
that checks if we have a nonlocal case, and if not, delegates to the
local definitions.
Just make sure that each class that participates in a nonlocal
transformation is documented as such. (Maybe such a class should be
required to register with the transformer class, so that people who work
on a local transformation rule are automatically aware of nonlocal
transforms that might be in play.)
--
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.
