Re: [sympy] Add multiple dispatch as external dependency

> > My point is, the order comes from the input itself, not from the registry. > AKA, you should use MRO. MRO satisfied monotonicity, which I think for > multiple dispatch basically says that if you subclass a class, it won't > change which function it will dispatch to (see > https://www.python.org

Re: [sympy] Add multiple dispatch as external dependency

Ok. I am installing Julia and I play with it more. Julia argument is a good argument because Julia is a solid iterative improvement over Python. I think in the next 5 years Python will be used a lot more than Julia and it's hard to predict what will happen after that. But I think that Julia is goin

Re: [sympy] Add multiple dispatch as external dependency

If you use the warnings module, you can convert warnings into exceptions easily enough, but I would just allow to specify it in the Dispatch object. As I noted in the previous email, it would be nice to subclass Dispatch to have different tie breaking schemes. You could just have Dispatch(warn=True

Re: [sympy] Add multiple dispatch as external dependency

On Wed, Apr 2, 2014 at 5:33 PM, Matthew Rocklin wrote: > Not all of the ties result from ambiguities. For example the signatures >>> (int,) and (float,) tie. Which should come first in the toposort? >>> >> >> For what input? >> > > How MD operates now is that it forms a graph of signatures wit

Re: [sympy] Add multiple dispatch as external dependency

Ah, must have missed it, fortunately Aaron bright up the same point. My response: I can see the reasoning here but slightly disagree. Both implementations are presumably valid and you should just pick one. This is also consistent with the standard set out by the Julia Language, from which I'm st

Re: [sympy] Add multiple dispatch as external dependency

I already asked this, but didn't get a reply: I really think it should raise an exception on ambiguity by default. You can allow the user to explicitly override this behavior if you know what you are doing. Sent from my mobile phone. On Apr 2, 2014 4:42 PM, "Matthew Rocklin" wrote: > If it is po

Re: [sympy] Add multiple dispatch as external dependency

If it is possible to catch warnings then we could catch an MD warning and raise an error in SymPy if we wanted. My PRs introducing MD into SymPy include a tiny sympy.dispatch module rather than using MD directly. There is little stopping us from tailoring some of the behavior to fit SymPy's prior

Re: [sympy] Add multiple dispatch as external dependency

> > Not all of the ties result from ambiguities. For example the signatures >> (int,) and (float,) tie. Which should come first in the toposort? >> > > For what input? > How MD operates now is that it forms a graph of signatures with an edge between two signatures if one is more specific than th

Re: [sympy] Add multiple dispatch as external dependency

On Wed, Apr 2, 2014 at 4:10 PM, Matthew Rocklin wrote: > Not all of the ties result from ambiguities. For example the signatures > (int,) and (float,) tie. Which should come first in the toposort? > For what input? > > Regarding API breaks I recommend that SymPy not inject any ambiguities. >

Re: [sympy] Add multiple dispatch as external dependency

Not all of the ties result from ambiguities. For example the signatures (int,) and (float,) tie. Which should come first in the toposort? Regarding API breaks I recommend that SymPy not inject any ambiguities. These can be avoided just by adding extra function definitions. E.g. @dispatch(obje

Re: [sympy] Add multiple dispatch as external dependency

And going back to my original comments, wouldn't changing tie breaking or mro schemes down the line be API breaks? Aaron Meurer On Wed, Apr 2, 2014 at 4:02 PM, Matthew Rocklin wrote: > The first incarnation of multipledispatch used mro. It worked. The code > to detect ambiguities and select

Re: [sympy] Add multiple dispatch as external dependency

Wouldn't it be better for the default tiebreaker to just raise an exception? Aaron Meurer On Wed, Apr 2, 2014 at 3:59 PM, Matthew Rocklin wrote: > Sorry, I used pseudo-random loosely. We currently use hash by default > although this could easily be changed. See the tie_breaker keyword > argu

Re: [sympy] Re: Tensor refactory

On Wednesday, April 2, 2014 9:56:29 PM UTC+2, Matthew wrote: > > Right, but ideally A(i, -i, j) and A(j, -i, i) *wouldn't unify. *Actually > in this sort of case I suppose that they would because it could be that i > == j. > Mmm, you're right. I didn't consider this problem. I believe that so

Re: [sympy] Add multiple dispatch as external dependency

The first incarnation of multipledispatch used mro. It worked. The code to detect ambiguities and select between multiple implementations in the multiple input case was fairly involved. I'm pretty happy with the abstractions behind the current setup. As always though pull requests welcome. The

Re: [sympy] Add multiple dispatch as external dependency

Also if you use __mro__, wouldn't you not have to build up some topological graph? Just pick the dispatched class that comes last in the mro. Aaron Meurer On Wed, Apr 2, 2014 at 3:58 PM, Matthew Rocklin wrote: > The multipledispatch project does not think hard about multiple > inheritance in a

Re: [sympy] Add multiple dispatch as external dependency

Sorry, I used pseudo-random loosely. We currently use hash by default although this could easily be changed. See the tie_breaker keyword argument to the edge function in conflict.py. https://github.com/mrocklin/multipledispatch/blob/master/multipledispatch/conflict.py On Wed, Apr 2, 2014 at 1:5

Re: [sympy] Add multiple dispatch as external dependency

Yeah, any project that you intend to be community based (rather than your own project) you should put under an organization. It looks like the GitHub username multipledispatch is not taken. Maybe you should grab it up. Aaron Meurer On Wed, Apr 2, 2014 at 10:15 AM, Ondřej Čertík wrote: > On Wed,

Re: [sympy] Add multiple dispatch as external dependency

The multipledispatch project does not think hard about multiple inheritance in an intelligent way. It uses issubclass in order to support abstract classes like Iterator and Number. On Wed, Apr 2, 2014 at 1:35 PM, Aaron Meurer wrote: > Why does multipledispatch use issubclass instead of __mro__

Re: [sympy] Add multiple dispatch as external dependency

Am 02.04.2014 22:32, schrieb Matthew Rocklin: The multipledispatch project detects such ambiguous situations and raises a warning when the ambiguity is created/detected (at import time). Ah, that's good. > If the developers don't do anything about it then multipledispatch selects one of the

Re: [sympy] Add multiple dispatch as external dependency

Why does multipledispatch use issubclass instead of __mro__? What happens when you dispatch on a diamond inheritance? Aaron Meurer On Wed, Apr 2, 2014 at 3:32 PM, Matthew Rocklin wrote: > The multipledispatch project detects such ambiguous situations and raises > a warning when the ambiguity i

Re: [sympy] Add multiple dispatch as external dependency

The multipledispatch project detects such ambiguous situations and raises a warning when the ambiguity is created/detected (at import time). If the developers don't do anything about it then multipledispatch selects one of the implementations to take precedence pseudo-randomly. http://multiple-di

Re: [sympy] Add multiple dispatch as external dependency

Am 02.04.2014 20:02, schrieb Matthew Rocklin: Sorry Joachim, It sounds like you're talking about name/signature pair conflicts, Not sure. > which is also what I think I was talking about. What I'm talking about can't be solved via namespaces. > It's true that foreign code can change beha

Re: [sympy] Re: Tensor refactory

Right, but ideally A(i, -i, j) and A(j, -i, i) *wouldn't unify. *Actually in this sort of case I suppose that they would because it could be that i == j. Generally speaking though unification variables do need match consistently within a term. (a, a) does not match to (1, 2). Perhaps we could c

Re: [sympy] Re: Tensor refactory

On Wednesday, April 2, 2014 7:35:45 PM UTC+2, Matthew wrote: > > Yeah, Wild subclasses from Expr, alas. The logpy solution is to have a > dispatched isvar function. > > It seems to me that the all tensor indices are in some sense wild. > Shouldn't A[i, -i] unify to A[j, -j] ? > Actually no

Re: [sympy] Add multiple dispatch as external dependency

Sorry Joachim, It sounds like you're talking about name/signature pair conflicts, which is also what I think I was talking about. It's true that foreign code can change behavior of local code which as you correctly point out can lead to issues. It can also lead to really solid code organization

Re: [sympy] Add multiple dispatch as external dependency

Am 02.04.2014 17:05, schrieb Matthew Rocklin: 1) On multidispatch itself: You can have either modularity or freeness from surprises (this has been discussed before - essentially, if you have modularity, adding a module with new MD definitions can change dispatch decisions for related combinatio

Re: [sympy] Re: Tensor refactory

Yeah, Wild subclasses from Expr, alas. The logpy solution is to have a dispatched isvar function. It seems to me that the all tensor indices are in some sense wild. Shouldn't A[i, -i] unify to A[j, -j] ? On Wed, Apr 2, 2014 at 9:41 AM, F. B. wrote: > OK, after the last PR has been merged, I

Re: [sympy] Re: Tensor refactory

OK, after the last PR has been merged, I did some tests on the indices and there are still problems with .match( ) and .replace( ), while .subs( ), .replace(..., simultaneous=False), and .xreplace( ) seem to work. The current problem is that wilds are not allowed in the expression tree, because

Re: [sympy] Add multiple dispatch as external dependency

On Wed, Apr 2, 2014 at 10:05 AM, Matthew Rocklin wrote: > By cache of size one I mean "store the last type/function pair as a tuple in > a field directly on the dispatcher, not in a dictionary". The reasoning is > that perhaps a field lookup is faster than inspecting a dictionary. I see, so you

Re: [sympy] Add multiple dispatch as external dependency

By cache of size one I mean "store the last type/function pair as a tuple in a field directly on the dispatcher, not in a dictionary". The reasoning is that perhaps a field lookup is faster than inspecting a dictionary. On Wed, Apr 2, 2014 at 8:47 AM, Ondřej Čertík wrote: > On Wed, Apr 2, 2014

Re: [sympy] Add multiple dispatch as external dependency

On Wed, Apr 2, 2014 at 9:43 AM, Matthew Rocklin wrote: > There is a fair amount of logic in the call to ambiguities. Ordering also > does a topological sort. Those are algorithmic but are both done at import > time. > > One optimization would be to have an even faster cache of size one stored in

Re: [sympy] Add multiple dispatch as external dependency

Le 02/04/14 16:23, F. B. a écrit : On Wednesday, April 2, 2014 5:09:19 PM UTC+2, Ondřej Čertík wrote: As far as performance goes --- what are the bottlenecks? Is Julia's multipledispatch the same fast? If it is faster, can multipledispatch be made faster too? Julia uses type inf

Re: [sympy] Add multiple dispatch as external dependency

There is a fair amount of logic in the call to ambiguities. Ordering also does a topological sort. Those are algorithmic but are both done at import time. One optimization would be to have an even faster cache of size one stored in a field on the dispatcher. This would avoid a dictionary lookup

Re: [sympy] Add multiple dispatch as external dependency

On Wed, Apr 2, 2014 at 9:18 AM, Matthew Rocklin wrote: >> >> As far as performance goes --- what are the bottlenecks? Is Julia's >> multipledispatch the same fast? >> If it is faster, can multipledispatch be made faster too? > > > Julia does dispatch at compile time, we do it at runtime. As imple

Re: [sympy] Add multiple dispatch as external dependency

On Wednesday, April 2, 2014 5:09:19 PM UTC+2, Ondřej Čertík wrote: > > > As far as performance goes --- what are the bottlenecks? Is Julia's > multipledispatch the same fast? > If it is faster, can multipledispatch be made faster too? > > Julia uses type inference and LLVM. I think that whenev

Re: [sympy] Add multiple dispatch as external dependency

In general I'm happy to do so. I'd like to wait until people actually starts to gain a following/developers though. On Wed, Apr 2, 2014 at 8:15 AM, Ondřej Čertík wrote: > On Wed, Apr 2, 2014 at 9:09 AM, Matthew Rocklin > wrote: > > It is possible to do either of these things, I'm against the f

Re: [sympy] Add multiple dispatch as external dependency

> > > As far as performance goes --- what are the bottlenecks? Is Julia's > multipledispatch the same fast? > If it is faster, can multipledispatch be made faster too? > Julia does dispatch at compile time, we do it at runtime. As implemented now this requires a dictionary lookup. I can imagine

Re: [sympy] Add multiple dispatch as external dependency

On Wed, Apr 2, 2014 at 9:09 AM, Matthew Rocklin wrote: > It is possible to do either of these things, I'm against the first though. > Multiple dispatch is not a SymPy project. It's as usable by numpy or > IPython as by SymPy. > > I'm happy to grant commit rights to anyone who actively develops th

Re: [sympy] Add multiple dispatch as external dependency

It is possible to do either of these things, I'm against the first though. Multiple dispatch is not a SymPy project. It's as usable by numpy or IPython as by SymPy. I'm happy to grant commit rights to anyone who actively develops the project. Ondrej has been futzing with it recently. On Wed,

Re: [sympy] Add multiple dispatch as external dependency

On Wed, Apr 2, 2014 at 9:05 AM, Matthew Rocklin wrote: >> >> 1) On multidispatch itself: You can have either modularity or freeness >> from surprises (this has been discussed before - essentially, if you have >> modularity, adding a module with new MD definitions can change dispatch >> decisions f

Re: [sympy] Add multiple dispatch as external dependency

> > > 1) On multidispatch itself: You can have either modularity or freeness > from surprises (this has been discussed before - essentially, if you have > modularity, adding a module with new MD definitions can change dispatch > decisions for related combinations of types). > This isn't a problem i

Re: [sympy] Re: Add multiple dispatch as external dependency

> By the way, what about using the test cases to tag the types of all of SymPy's methods by the @dispatch decorator? Beware that multiply dispatched functions *do* incur a microsecond of overhead. This does not come for free. In [1]: from multipledispatch import dispatch In [2]: def f(x): ..

Re: [sympy] Add multiple dispatch as external dependency

> It would probably be a good idea to get some good review done on > multipledispatch though before SymPy starts to rely on it. I also strongly encourage this. Come on over to github.com/mrocklin/multipledispatch folks! Free beer! On Tue, Apr 1, 2014 at 9:41 PM, Brian Granger wrote: > I str

Re: [sympy] Add multiple dispatch as external dependency

> > What are your plans for multiple dispatch as a project? > In terms of development I consider it mostly complete now. Plans for the future are mostly performance tweaks and support for Python3 type annotations (Jeremiah Lowin has done some good work on this) > Why can't this just be included

Re: [sympy] Add multiple dispatch as external dependency

Is it possible to move the main repository for mutlipledispatch under the sympy github org and grant the core sympy devs commit rights? Jason moorepants.info +01 530-601-9791 On Wed, Apr 2, 2014 at 4:22 AM, Joachim Durchholz wrote: > Am 02.04.2014 04:10, schrieb Matthew Rocklin: > > As a rem

[sympy] Further refinement of IndexedBase and Idx

Hi! Since I haven't opened any particular issues but only PR's I thought maybe I should announce them here so they won't go unnoticed. https://github.com/sympy/sympy/pulls/bjodah They are: - Avoid superfluous CSEs from Idx and IndexedBase instances

Re: [sympy] Add multiple dispatch as external dependency

Am 02.04.2014 04:10, schrieb Matthew Rocklin: As a reminder, SymPy currently doesn't depend on any external libraries, so this particular move also represents a policy shift. This potential policy shift follows substantial discussion, notably at https://github.com/sympy/sympy/issues/7339 . Ther

[sympy] Re: Add multiple dispatch as external dependency

By the way, what about using the test cases to tag the types of all of SymPy's methods by the @dispatch decorator? That can be useful to try an automated translation to C++ or some other language. -- You received this message because you are subscribed to the Google Groups "sympy" group. To u