If it's the same logic in every function, it should be put in the main
series() method that calls _eval_nseries.
Aaron Meurer
On Fri, Jun 24, 2016 at 6:05 PM, Francesco Bonazzi
wrote:
> I was mulling over the possibility of adding support for series expansion of
> indexed objects and/or multivar
I was mulling over the possibility of adding support for series expansion
of indexed objects and/or multivariate series.
The *_eval_nseries* method could be dispatched over its second argument
(second means the one after *self*).
The alternative would be the classical *if isinstance( ... )*, wh
What code specifically do you want to use it in?
In my experience, dispatching in SymPy functions happens by expression
type, which is often reflected by Python class, but not always. A
pattern matching based dispatching system would be more useful in my
opinion.
Aaron Meurer
On Fri, Jun 24, 201
Hi,
are there any actual intentions of ever introducing multiple dispatch
support to SymPy? Has the idea been completely abandoned?
I would like to have it as a dependency, some SymPy code could be made much
more readable with it.
For those who are unfamiliar with the topic, some time ago we h
On Thursday, February 20, 2014 2:17:07 AM UTC+1, Aaron Meurer wrote:
>
> On Wed, Feb 19, 2014 at 7:14 PM, Matthew Rocklin
> >
> wrote:
> > My guess is that Mul and Add will always just create Add and Mul
> objects.
> > Other functions will then be used to perform various simplifications on
On Wed, Feb 19, 2014 at 7:14 PM, Matthew Rocklin wrote:
> My guess is that Mul and Add will always just create Add and Mul objects.
> Other functions will then be used to perform various simplifications on
> these lists.
>
> This is how sets work with Union and Intersection. You call Union(a, b,
My guess is that Mul and Add will always just create Add and Mul objects.
Other functions will then be used to perform various simplifications on
these lists.
This is how sets work with Union and Intersection. You call Union(a, b, c,
d) where a, b, c, d are all sets. This makes a Union object co
SymPy already has a pretty widely used single dispatch system (the
_eval_* methods). Multiple dispatch would be useful for any operation
that has more than one argument. I hardly have to convince you of the
advantage of this approach.
The challenge is operations like Add and Mul that take an arbit
I've recently become interested in multiple dispatch. I know that this has
been a topic of conversation before. Can anyone point me to relevant
threads? I've gone through the recent PR by @Upapjojr
https://github.com/sympy/sympy/pull/2680 .
In particular:
1. What are the strong use cases for
On Monday, November 18, 2013 10:22:09 PM UTC+1, Ondřej Čertík wrote:
>
>
> By all means, please go ahead!
>
> We will discuss this once you post a PR, see how it looks, see if the
> speed is enough
> for tensors/quantum etc. And we can play with it.
>
Here we go, though it does not work yet
On Mon, Nov 18, 2013 at 2:12 PM, F. B. wrote:
>
> By the way, what about if I try to sketch a @dispatch decorator?
>
> It could be used experimentally in a subset of sympy, such as the tensor
> module and the quantum module.
>
> Things one should care of are:
>
> behavior of @dispatch with other s
By the way, what about if I try to sketch a *@dispatch* decorator?
It could be used experimentally in a subset of sympy, such as the tensor
module and the quantum module.
Things one should care of are:
- behavior of @dispatch with other sympy decorators
- how to display a @dispatch decor
On Sunday, November 17, 2013 11:29:30 AM UTC+1, Cristóvão Duarte Sousa
wrote:
>
>
> It seems to me, who knows nothing of computer science, that in fact Julia
> has in fact a powerful multiple dispatch system (though only on types not
> on values)
>
Multiple dispatch is based on the types of
Sorry guys for the OT, but let me conclude the answer to F.B.:
g(v::Point{Integer}) = "Point... parametric type is Integer abstract class"
can be used to do
g(Point{Integer}(int64(1),int32(2)))
"Point... parametric type is Integer abstract class"
It seems to me, who knows nothing of computer sc
I'm not a Julia specialist but I think that for the last case one must do:
julia> g{T<:Integer}(v::Point{T}) = "Point... parametric type is Integer
abstract class"
g (generic function with 1 method)
julia> g(p)
"Point... parametric type is Integer abstract class"
Anyway, I think that there must
On Wednesday, November 13, 2013 10:39:48 PM UTC+1, Ondřej Čertík wrote:
>
>
> I wonder how difficult would be to write just a very simple core in
> Julia, just so that we can experiment with this.
> See how extensible it is, and so on.
>
The problem is how to call it from Python. For what I w
On Wed, Nov 13, 2013 at 1:09 PM, F. B. wrote:
>
> Yet another alternative approach:
>
> Instead of defining Add and Mul as dependent on a parametric type associated
> with the properties of the expression, just do the opposite.
>
> Examples (Julia-like syntax, {T} is the parametric type, <: means
Yet another alternative approach:
Instead of defining *Add* and *Mul* as dependent on a parametric type
associated with the properties of the expression, just do the opposite.
Examples (Julia-like syntax, {T} is the parametric type, <: means
inheritance):
type Expr{T} <: Basic
type NonCommuta
That is reminiscent of how things are implemented in the polys module.
It's not clear to me that those ideas can extend to less rigorously
defined rings and fields (at least not without first rigorously
defining them).
Aaron Meurer
On Tue, Nov 12, 2013 at 3:52 PM, Ondřej Čertík wrote:
> Hi,
>
>
I had a try at this with Julia... unfortunately there is a problem there
because parametric type constructors are invariant, while they should be
covariant for this particular case:
julia> immutable Point{T}
x::T
y::T
end
julia> p = Point{Int64}(3, 5)
Point{Int64}(3,5
Hi,
So there is this whole Parent/coercion machinery in Sage:
http://www.sagemath.org/doc/tutorial/tour_coercion.html
http://www.sagemath.org/doc/reference/coercion/
Isn't this what you are trying to design?
Ondrej
On Tue, Nov 12, 2013 at 3:40 PM, Aaron Meurer wrote:
> I'm not a fan of the sy
I'm not a fan of the syntax, but otherwise I think you have the right idea.
Aaron Meurer
On Tue, Nov 12, 2013 at 1:24 AM, F. B. wrote:
> Obviously, Add could change its template according to the cases:
>
> Add(x, y) ===> Add[AssocOp](x, y)
> Add(x, y) + Add(oo,1) ===> Add(Add[AssocOp](x,y), Add[
Obviously, Add could change its template according to the cases:
Add(x, y) ===> Add[AssocOp](x, y)
Add(x, y) + Add(oo,1) ===> Add(Add[AssocOp](x,y), Add[InfinitiesT](oo))
===> Add[InfinitiesT](x,y,oo)
Add's *__new__* constructor could be dispatched to handle specific cases
for these template
On Monday, November 11, 2013 8:52:40 PM UTC+1, Joachim Durchholz wrote:
>
>
> > What about using instead of this an approach closer to C++ templates?
>
> The problem with C++ is that many people do not know C++, and those that
> believe they do sometimes misinterpret the definitions.
> For tha
Am 10.11.2013 23:21, schrieb F. B.:
But, isn't this breaking the logical correspondence of those two points in
the bullet list? The plus sign is no more mapped to a single object, while
the properties of addition are sometimes handled by Add, sometimes by other
objects.
Not 100% sure that we'r
Am 11.11.2013 00:08, schrieb F. B.:
In Wolfram Mathematica, + is a Plus M-expression, always. They don't have
any MatPlus, or whatever.
The behavior upon it is determined by pattern matching. [...]
I don't think pattern matching is the only way.
Actually, it is.
*Somewhere*, you need to matc
Yes, I agree this is the way to do it. It's essentially the idea from
https://code.google.com/p/sympy/issues/detail?id=2738. But again, I'm
really not sure exactly *how* to do it, down to the implementation
details. So I really feel (at least for myself) that I don't quite
understand the abstractio
On Sunday, November 10, 2013 11:31:38 PM UTC+1, Aaron Meurer wrote:
>
>
> Mathematically, + has a thousand meanings, and we blur the
> distinctions because they all act similarly. But at some point in a
> CAS, you have to unblur any notational convenience that you would
> otherwise make on pape
I think you've hit on the core of the issue. The problem is, if you
take just Symbol('x'), it can be interpreted as many things. x + 1
means the number x plus the number 1 (or does it mean the function
f(x) = x + 1?). x + O(x**2) means the set of functions whose series
expansion up to x is x. x + y
On Sunday, November 10, 2013 11:21:46 PM UTC+1, F. B. wrote:
> I was thinking about that. That AssocOp is interesting, it defines the
> commutative property of Add.
>
>
Sorry, the associative, not commutative property.
--
You received this message because you are subscribed to the Google Gro
On Sunday, November 10, 2013 10:42:39 PM UTC+1, Joachim Durchholz wrote:
> Hm. Not a problem if the same function isn't overridden in both Expr and
> AssocOp, so maybe... hopefully...
>
> ... but yes, that's going to have to be considered for multiple dispatch.
>
I was thinking about that. T
Am 10.11.2013 21:34, schrieb F. B.:
I just checked, *Add* inherits both *Expr* and *AssocOp*, both of which on
the other hand inherit *Basic*. So, unfortunately, SymPy does use multiple
inheritance and presents the diamond problem, which is likely to be solved
by Python's C3 algorithm.
Hm. Not
On Saturday, November 9, 2013 10:07:50 PM UTC+1, Joachim Durchholz wrote:
> I'm a bit concerned about that MRO usage.
> MRO as a concept is fundamentally broken. That brokenness doesn't matter
> as long as MRO doesn't matter, i.e. as long as no multiple inheritance
> is in play -
> *and I th
Am 09.11.2013 23:46, schrieb Aaron Meurer:
On Sat, Nov 9, 2013 at 1:39 PM, F. B. wrote:
Concerning cases where there is no ambiguity in their usage, what about
using this library?
https://bitbucket.org/coady/multimethod/src
I did not find the license, so I suppose it's public domain (correct
Actually, according to the setup.py,
https://bitbucket.org/coady/multimethod/src/3179d8ffa4c6c920d7ec6acbcd125489bb03a359/setup.py?at=default#cl-16,
it uses PSF license, which is fine (I think there may be some
bookkeeping clause, but it's completely compatible with BSD).
Aaron Meurer
On Sat, Nov
On Sat, Nov 9, 2013 at 1:39 PM, F. B. wrote:
> Concerning cases where there is no ambiguity in their usage, what about
> using this library?
>
> https://bitbucket.org/coady/multimethod/src
>
> I did not find the license, so I suppose it's public domain (correct me if
> I'm wrong).
No, the "defaul
Am 09.11.2013 21:39, schrieb F. B.:
Concerning cases where there is no ambiguity in their usage, what about
using this library?
https://bitbucket.org/coady/multimethod/src
I did not find the license, so I suppose it's public domain (correct me if
I'm wrong).
There are some cases where the prob
Concerning cases where there is no ambiguity in their usage, what about
using this library?
https://bitbucket.org/coady/multimethod/src
I did not find the license, so I suppose it's public domain (correct me if
I'm wrong).
There are some cases where the problems being discussed do not appear,
Am 09.11.2013 06:15, schrieb Aaron Meurer:
On Nov 8, 2013, at 2:26 AM, Joachim Durchholz wrote:
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
> On Nov 8, 2013, at 2:26 AM, Joachim Durchholz wrote:
>
> Am 08.11.2013 01:40, schrieb Aaron Meurer:
>> On Thu, Nov 7, 2013 at 1:22 AM, Joachim Durchholz wrote:
>>> Am 07.11.2013 05:42, schrieb Aaron Meurer:
>>>
Yes, we still need multiple dispatch,
>>>
>>>
>>> I'm wondering - what do we ne
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 subc
Am 08.11.2013 01:40, schrieb Aaron Meurer:
On Thu, Nov 7, 2013 at 1:22 AM, Joachim Durchholz 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
On Thu, Nov 7, 2013 at 5:40 PM, Aaron Meurer wrote:
> On Thu, Nov 7, 2013 at 1:22 AM, Joachim Durchholz 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 abov
On Thu, Nov 7, 2013 at 1:22 AM, Joachim Durchholz 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,
>
> Actual
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?
> 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 jus
Yes, we still need multiple dispatch, but it's a really hard problem,
and no one has been working on it (I'm not even sure what the best
solution is yet).
Anyway, I personally believe that if you want to refactor the core
with this, that you should clean up the assumptions first, so my plan
is to
On Wed, Nov 6, 2013 at 3:24 PM, F. B. wrote:
> Did this conversation die out? Multiple dispatch would be very useful...
>
> I was pondering of using multiple dispatch to make the diffgeom and tensor
> modules easily interact, instead of adding if isinstance ... everywhere.
It looks like the Ronan
Did this conversation die out? Multiple dispatch would be very useful...
I was pondering of using multiple dispatch to make the diffgeom and tensor
modules easily interact, instead of adding *if isinstance ...* everywhere.
--
You received this message because you are subscribed to the Google Gr
On Thu, Jul 4, 2013 at 12:09 PM, Ronan Lamy wrote:
> 2013/7/4 Ondřej Čertík
>>
>> On Wed, Jul 3, 2013 at 4:40 PM, Ronan Lamy wrote:
>> > 2013/7/3 Ondřej Čertík
>> >>
>> >> On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer
>> >> wrote:
>> >>
>> >> Why wouldn't simple type based dispatch work?
>> >>
2013/7/4 Ondřej Čertík
> On Wed, Jul 3, 2013 at 4:40 PM, Ronan Lamy wrote:
> > 2013/7/3 Ondřej Čertík
> >>
> >> On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer
> wrote:
> >>
> >> Why wouldn't simple type based dispatch work?
> >> You might be right, I just want to understand the problem more.
> >
Am 04.07.2013 03:12, schrieb Ronan Lamy:
We can certainly declare that, and it should already be true, but it
doesn't help. If a, b, c are symbols, Add(Add(a, b), c) needs to be
represented as something that looks like Add(a, b, c), so we're back to
square one.
It helps in that it eliminates th
Am 03.07.2013 23:55, schrieb Ondřej Čertík:
Maybe it is possible to implement pattern matching efficiently, but I
am a bit skeptical.
From what I see in the linked web pages on Mathematica's rule engine,
these patterns are similar to grammar rules for compilers, plus a layer
of tests for appl
On Wed, Jul 3, 2013 at 7:58 PM, Ronan Lamy wrote:
> 2013/7/4 Aaron Meurer
>>
>> On Wed, Jul 3, 2013 at 7:27 PM, Ronan Lamy wrote:
>> > 2013/7/4 Aaron Meurer
>> >>
>> >> On Wed, Jul 3, 2013 at 5:40 PM, Ronan Lamy
>> >> wrote:
>> >> > 2013/7/3 Ondřej Čertík
>> >> >>
>> >> >> On Wed, Jul 3, 2013
2013/7/4 Joachim Durchholz
> Am 03.07.2013 19:15, schrieb Aaron Meurer:
>
> I don't think it's so easy, because Add has *args.
>>
>
> It should be possible to define the behaviour of the *args case by
> declaring Add(a, b, c) to be equivalent to Add(Add(a, b), c).
> With the obvious generalizati
2013/7/4 Aaron Meurer
> On Wed, Jul 3, 2013 at 7:27 PM, Ronan Lamy wrote:
> > 2013/7/4 Aaron Meurer
> >>
> >> On Wed, Jul 3, 2013 at 5:40 PM, Ronan Lamy
> wrote:
> >> > 2013/7/3 Ondřej Čertík
> >> >>
> >> >> On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer
> >> >> wrote:
> >> >>
> >> >> Why woul
Am 03.07.2013 19:15, schrieb Aaron Meurer:
I don't think it's so easy, because Add has *args.
It should be possible to define the behaviour of the *args case by
declaring Add(a, b, c) to be equivalent to Add(Add(a, b), c).
With the obvious generalization for arbitrary parameter counts.
Doesn
On Wed, Jul 3, 2013 at 7:27 PM, Ronan Lamy wrote:
> 2013/7/4 Aaron Meurer
>>
>> On Wed, Jul 3, 2013 at 5:40 PM, Ronan Lamy wrote:
>> > 2013/7/3 Ondřej Čertík
>> >>
>> >> On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer
>> >> wrote:
>> >>
>> >> Why wouldn't simple type based dispatch work?
>> >> Yo
2013/7/4 Aaron Meurer
> On Wed, Jul 3, 2013 at 5:40 PM, Ronan Lamy wrote:
> > 2013/7/3 Ondřej Čertík
> >>
> >> On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer
> wrote:
> >>
> >> Why wouldn't simple type based dispatch work?
> >> You might be right, I just want to understand the problem more.
> >>
On Wed, Jul 3, 2013 at 5:11 PM, Aaron Meurer wrote:
> On Wed, Jul 3, 2013 at 5:40 PM, Ronan Lamy wrote:
>> 2013/7/3 Ondřej Čertík
>>>
>>> On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer wrote:
>>>
>>> Why wouldn't simple type based dispatch work?
>>> You might be right, I just want to understand t
On Wed, Jul 3, 2013 at 6:30 PM, Ondřej Čertík wrote:
> On Wed, Jul 3, 2013 at 4:40 PM, Ronan Lamy wrote:
>> 2013/7/3 Ondřej Čertík
>>>
>>> On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer wrote:
>>>
>>> Why wouldn't simple type based dispatch work?
>>> You might be right, I just want to understand
On Wed, Jul 3, 2013 at 4:40 PM, Ronan Lamy wrote:
> 2013/7/3 Ondřej Čertík
>>
>> On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer wrote:
>>
>> Why wouldn't simple type based dispatch work?
>> You might be right, I just want to understand the problem more.
>>
>> To answer Aaron's question:
>>
>> On W
On Wed, Jul 3, 2013 at 5:40 PM, Ronan Lamy wrote:
> 2013/7/3 Ondřej Čertík
>>
>> On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer wrote:
>>
>> Why wouldn't simple type based dispatch work?
>> You might be right, I just want to understand the problem more.
>>
>> To answer Aaron's question:
>>
>> On W
On Wed, Jul 3, 2013 at 4:19 PM, Brian Granger wrote:
> On Wed, Jul 3, 2013 at 1:42 PM, Ondřej Čertík wrote:
>> On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer wrote:
>>> Brian, I think you dropped off list. Forwarding to sympy.
>>>
>>> Aaron Meurer
>>>
>>> On Wed, Jul 3, 2013 at 2:29 PM, Brian Gran
2013/7/3 Ondřej Čertík
> On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer wrote:
>
> Why wouldn't simple type based dispatch work?
> You might be right, I just want to understand the problem more.
>
> To answer Aaron's question:
>
> On Wed, Jul 3, 2013 at 12:58 PM, Aaron Meurer wrote:
> > So, going
On Wed, Jul 3, 2013 at 3:46 PM, Brian Granger wrote:
> On Wed, Jul 3, 2013 at 2:42 PM, Ondřej Čertík wrote:
>> On Wed, Jul 3, 2013 at 3:19 PM, Brian Granger wrote:
>>> On Wed, Jul 3, 2013 at 1:42 PM, Ondřej Čertík
>>> wrote:
On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer wrote:
> Brian
On Wed, Jul 3, 2013 at 2:42 PM, Ondřej Čertík wrote:
> On Wed, Jul 3, 2013 at 3:19 PM, Brian Granger wrote:
>> On Wed, Jul 3, 2013 at 1:42 PM, Ondřej Čertík
>> wrote:
>>> On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer wrote:
Brian, I think you dropped off list. Forwarding to sympy.
>>>
Here is another idea that might help:
What if we *always* mapped the *args logic for operators like Mul/Add
to the binary ones:
if len(args)==2:
self.dispatch(*args)
else:
return Mul(Mul(args[0],args[1]),args[2]) etc
Then we could focus on the rules and patterns for binary versions.
This doe
On Wed, Jul 3, 2013 at 3:19 PM, Brian Granger wrote:
> On Wed, Jul 3, 2013 at 1:42 PM, Ondřej Čertík wrote:
>> On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer wrote:
>>> Brian, I think you dropped off list. Forwarding to sympy.
>>>
>>> Aaron Meurer
>>>
>>> On Wed, Jul 3, 2013 at 2:29 PM, Brian Gran
On Wed, Jul 3, 2013 at 1:42 PM, Ondřej Čertík wrote:
> On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer wrote:
>> Brian, I think you dropped off list. Forwarding to sympy.
>>
>> Aaron Meurer
>>
>> On Wed, Jul 3, 2013 at 2:29 PM, Brian Granger wrote:
>>> I think that having multiple dispatch is somet
I am not sure what our symbol syntax would look like but something like:
Infinity() + ZeroOrMore(Any()) -> Infinity()
Infinity() + ZeroOrMore(I*Any(x_)) -> Infinity() +ZeroOrMore(I*Any(x_))
Part of what is needed priorities in the matching rules...
On Wed, Jul 3, 2013 at 12:49 PM, Aaron Meurer
On Wed, Jul 3, 2013 at 1:48 PM, Aaron Meurer wrote:
> Brian, I think you dropped off list. Forwarding to sympy.
>
> Aaron Meurer
>
> On Wed, Jul 3, 2013 at 2:29 PM, Brian Granger wrote:
>> I think that having multiple dispatch is something that is needed within
>> SymPy. Multiple people have run
So, how would you do my example, oo + 3 => oo, with pattern matching?
Aaron Meurer
On Wed, Jul 3, 2013 at 2:48 PM, Aaron Meurer wrote:
> Brian, I think you dropped off list. Forwarding to sympy.
>
> Aaron Meurer
>
> On Wed, Jul 3, 2013 at 2:29 PM, Brian Granger wrote:
>> I think that having mul
Brian, I think you dropped off list. Forwarding to sympy.
Aaron Meurer
On Wed, Jul 3, 2013 at 2:29 PM, Brian Granger wrote:
> I think that having multiple dispatch is something that is needed within
> SymPy. Multiple people have run into the difficulties with providing custom
> Add/Mul logic fo
So, going back to what we discussed the first time we met in Los
Alamos, how would you reimplement something like the oo logic so that
it lives entirely in the Infinity class, not in Add.flatten (say for
simplicity, oo + 3 should go to oo, but oo + 3*I should remain as oo +
3*I)?
Aaron Meurer
On
On Wed, Jul 3, 2013 at 11:27 AM, Aaron Meurer wrote:
> No, Add(x, y, z, t) is not just used for fast construction. Any
> algorithm that recurses through an expression tree and rebuilds things
> will rebuild an Add in that way, using expr.func(*expr.args).
Which will work with both Add and AddHold
No, Add(x, y, z, t) is not just used for fast construction. Any
algorithm that recurses through an expression tree and rebuilds things
will rebuild an Add in that way, using expr.func(*expr.args).
Aaron Meurer
On Wed, Jul 3, 2013 at 12:22 PM, Ondřej Čertík wrote:
> On Wed, Jul 3, 2013 at 11:15 A
On Wed, Jul 3, 2013 at 11:22 AM, Ondřej Čertík wrote:
> On Wed, Jul 3, 2013 at 11:15 AM, Aaron Meurer wrote:
>> I don't think it's so easy, because Add has *args.
>
> If you are talking about things like:
>
> In [2]: Add(x, x, x, y, x, x)
> Out[2]: 5⋅x + y
>
> Then those are of course needed for
On Wed, Jul 3, 2013 at 11:15 AM, Aaron Meurer wrote:
> I don't think it's so easy, because Add has *args.
If you are talking about things like:
In [2]: Add(x, x, x, y, x, x)
Out[2]: 5⋅x + y
Then those are of course needed for fast construction many terms into
on Add, but this not really exposed
I don't think it's so easy, because Add has *args.
Aaron Meurer
On Wed, Jul 3, 2013 at 12:13 PM, Ondřej Čertík wrote:
> On Wed, Jul 3, 2013 at 11:04 AM, Aaron Meurer wrote:
>> It's related, because currently all canonicalization happens in the
>> class constructor, and it's impossible for class
On Wed, Jul 3, 2013 at 11:04 AM, Aaron Meurer wrote:
> It's related, because currently all canonicalization happens in the
> class constructor, and it's impossible for classes to define their own
> canonicalization (i.e., what happens in the constructor) due to lack
> of dispatch.
That's right. S
It's related, because currently all canonicalization happens in the
class constructor, and it's impossible for classes to define their own
canonicalization (i.e., what happens in the constructor) due to lack
of dispatch.
Aaron Meurer
On Wed, Jul 3, 2013 at 12:03 PM, Ondřej Čertík wrote:
> On Wed
On Wed, Jul 3, 2013 at 10:52 AM, Aaron Meurer wrote:
> When we've talked about this in the past, we put the ideas at
> https://github.com/sympy/sympy/wiki/Canonicalization. So take a look
> at what is there, and add things if you have any more ideas.
I've added a link to this thread. Note that th
When we've talked about this in the past, we put the ideas at
https://github.com/sympy/sympy/wiki/Canonicalization. So take a look
at what is there, and add things if you have any more ideas.
Aaron Meurer
On Wed, Jul 3, 2013 at 11:11 AM, Ondřej Čertík wrote:
> Hi,
>
> Prasoon has described here
Hi,
Prasoon has described here precisely the problems with extending sympy
with user defined types:
https://groups.google.com/d/topic/sympy/QV6m9Nfp9kw/discussion
Currently the only way to robustly do that is through _op_priority as
Julien described.
The usual Python approach (NotImplemented) d
84 matches
Mail list logo
