Am 08.11.2013 01:40, schrieb Aaron Meurer:
At this point, I don't even know how to do it *at all*, so I'm not
even that far. Some things are not clear to me. For example, if you
want to say x defines x + y as one thing and y defines x + y as
another thing, who wins? Does it matter if y is a subclass of x?
Another question, if we have x + y + z and x, y, and z all define
addition behavior, how do we avoid performing O(n**2) computations
just to construct the Add object? Even for fixed argument dispatch,
this is still a concern.
I forgot to mention that commutativity and (in some sense) associativity
further complicate issues, making the effects of any ruleset even more
difficult to grasp.
I.e. I didn't ignore that, my previous message was just too long already.
Let me state my stance: MD is hard to do well, and therefore a bad idea
if there are alternatives.
BUT the logic issues are the same if it's inside a rule engine that does
structural pattern matching. So I'm taking back my knee-jerk reaction of
"extending a programming language with MD is always a bad idea" - it
still is, but in this particular case, the emphasis on "programming
language" doesn't solve any problem.
MD is still a bad idea, it's just that there seems to be no good
alternative.
Approaches that I see:
- Cut down on MD as far as possible. Usually by defining conversion
chains (e.g. Integer->Rational->Real->Complex, BUT ON A PER-FUNCTION
BASIS - a Real->Complex conversion would not preserve semantics for
computing whether a function has a derivative, for example), and
possibly by leveraging commutativity and associativity.
- Excel at diagnostics. Have a utility that spits out the full dispatch
table for any function. For functions with more than two parameters,
spit out slices, slicing the hyperrectangle at the dimensions that give
the fewest number of slices.
- Have each function define what parameters are subject to MD and what
aren't, cutting down on the number of dimensions.
More generally, keep the MD information (which functions have MD, and
the actual dispatch tables) in data structures that aren't intimately
tied to Python wrappers. We need that information for three cases:
- Pythonic multiple dispatch
- Diagnostics
- Rule-based tree transformations (once this actually happens)
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.
