> On Nov 8, 2013, at 2:26 AM, Joachim Durchholz <[email protected]> wrote: > > Am 08.11.2013 01:40, schrieb Aaron Meurer: >> 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. > > I'm more after whether there's a consensus about what problem we're actually > trying to solve. > >>>> 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. > > Agreed. > >> 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). > > Actually it's n^k on the zeroth approximation of n potential classes for each > of the k arguments. > More precisely, it's n1*n2*...*nk for k parameters with n1, n2, ... nk > candidate classes.
Ah. For some reason I always think n*k when it should be n^k. > > That's a hyperrectangle of class combinations that needs to be filled with > associations to code to run. > If you deal with each combination on a case-by-case basis, this becomes > unmaintainable due to sheer numbers. > If you use rules to map many combinations at once, depending on the structure > of the rules you risk overlaps (creating surprising behaviour because you're > usually not aware of the conflict) and oversights (unmapped combinations). > Standard MD rulesets tend to exclude oversights; I'm somewhat sceptical that > that's a good idea, an oversight produces a clearly visible and easily > fixable error message while an overlap silently creates unexpected behaviour > (which might not be wrong but still using the wrong, too-slow algorithm or be > otherwise undesirable). Actually, for SymPy, if there's no rule, then the behavior is to just create the unevaluated object. This will actually be the common case. x + y will return Add(x, y) in almost every case. Only if x and y are similar objects (like if they differ only by a number multiple) or some special object like O(x**2) or oo will anything special happen. So the hyperrectangle will be mostly sparse, and that's fine. It's not like with numeric libraries where x + y has to return some kind of number and so you have to catch every possible combination. We have a default behavior: leave it unevaluated. Aaron Meurer > >>> 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. > > As far as I know it's an unsolved problem. > And I have read a lot of research papers on the issue. I found that all > solved either the conflict or the oversight, but you'd need to solve both, > and I suspect it's just as unsolvable as the halting problem. > > It's been a while since I last looked into the state of research (a decade or > so); maybe somebody found an entirely different angle to solve that problem. > >>> 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? >> 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. > > That's the combinatoric explosion of the hyperrectangle. > > The design space is that you can have any three of the following properties: > - Allow end users to extend the hyperrectangle however they please > - Have no conflicts > - Have no oversights > - No combinatoric explosion > > There might be a useful compromise between these goals somewhere, but I don't > know it. > Those compromises that I read about all came with more complex base rules, > which had the undesirable effect that it became difficult to figure out which > combination of parameters would result in the call to what implementation. > > -- > 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. -- 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.
