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.
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).
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.
