On Thu, Nov 7, 2013 at 5:40 PM, Aaron Meurer <[email protected]> wrote: > On Thu, Nov 7, 2013 at 1:22 AM, Joachim Durchholz <[email protected]> wrote: >> Am 07.11.2013 05:42, schrieb Aaron Meurer: >> >>> Yes, we still need multiple dispatch, >> >> >> I'm wondering - what do we need that for? What problem does it solve? > > See the above discussion. > >> >> >>> but it's a really hard problem, >> >> Actually, a wrapper-based solution shouldn't be too hard to do, so the >> implementation side of things is just the amount of work. > > The implementation isn't what's hard. Python is dynamic enough that > anything you come up with can be implemented well enough. > > The issue is how to actually do it, logically. How should the API > look? How should the logic of it work, especially regarding conflicts > and subclasses. How do we avoid having to define all n*n*k > possibilities (for n classes and k arguments). > >> >> At the conceptual level, it's indeed hard, it involves trade-offs with >> nonobvious consequences. >> I once tried to work it out for Eiffel, or for statically-typed languages, >> and found (to my dismay) that it involves trading off language properties >> that I all considered essential. (I do not think that having a >> dynamically-typed language like Python helps here; in my experience, dynamic >> typing just shifts the problem from the language designer's shoulders to the >> library designer's shoulders, with the library designers having less >> experience to deal successfully with the issues.) >> >> However, with a concrete goal in mind and when applying it to a restricted >> problem domain, maybe a trade-off can be found that might work. >> That's why I'm asking about the problem. Knowing the problem would help me >> finding the path of least pain. > > Well, F.B. may have his own view, but as far as I'm concerned, I only > care about one thing: I want custom classes to be able to define their > own behavior without having to modify the core. This is important for > two reasons: first, we want our users to be able to do things without > having to monkey-patch or subclass* or literally modify the core > classes, and second, we want to be able to do this within SymPy > itself, so that the core isn't such a huge mess, referencing other > parts of SymPy that it really shouldn't need to know directly about. > > (*) - I'm actually not sure if subclassing the core classes is > completely wrong. It seems it actually can be useful in some cases. > >> >> >>> no one has been working on it >> >> Yeah, and I'm not volunteering either since my time is too limited. >> What I can do is describe the issues and enable informed design decisions. >> >> >>> I'm not even sure what the best solution is yet >> >> What trade-offs are on your radar there? > > 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?
So this particulat case is clear to me: the point of a double dispatch (in this case) is that you register "x+y" handler for types X + Y, so your handler just gets called whenever x is a sublass od X and y is a subclass of Y. > 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? Python decides that first (x+y) handler should by called (see my previous note), which returns a result "r", and then a handler for "r+z" gets called. I think that Ronan's code pretty much already implements this. (Maybe your concern was about something else than I answered.) Ondrej -- 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.
