On Thu, Apr 20, 2017 at 4:44 PM, Francesco Bonazzi
wrote:
>
>
> On Thursday, 20 April 2017 21:23:54 UTC+2, Aaron Meurer wrote:
>>
>>
>>
>> On Thu, Apr 20, 2017 at 6:12 AM, Francesco Bonazzi
>> wrote:
>> >
>> >
>> > On Wednesday, 19 April 2017
On Thursday, 20 April 2017 21:23:54 UTC+2, Aaron Meurer wrote:
>
>
>
> On Thu, Apr 20, 2017 at 6:12 AM, Francesco Bonazzi > wrote:
> >
> >
> > On Wednesday, 19 April 2017 21:51:08 UTC+2, Aaron Meurer wrote:
> >>
> >> Performance is a valid concern. We should definitely
On Thu, Apr 20, 2017 at 6:12 AM, Francesco Bonazzi
wrote:
>
>
> On Wednesday, 19 April 2017 21:51:08 UTC+2, Aaron Meurer wrote:
>>
>> Performance is a valid concern. We should definitely check that.
>>
>> The __slots__ part I don't know. That could probably be done
On Wednesday, 19 April 2017 21:51:08 UTC+2, Aaron Meurer wrote:
>
> Performance is a valid concern. We should definitely check that.
>
> The __slots__ part I don't know. That could probably be done differently.
>
>
I didn't like that part too. Has anyone a better idea?
Regarding the
Performance is a valid concern. We should definitely check that.
The __slots__ part I don't know. That could probably be done differently.
Regarding the implementation itself, how would you do it? The ability
to make Mul or Add do custom stuff for custom objects is a very
commonly requested
Le 19/04/17 à 19:00, Francesco Bonazzi a écrit :
On Wednesday, 19 April 2017 17:05:08 UTC+2, Ronan Lamy wrote:
Le 18/04/17 à 21:28, Francesco Bonazzi a écrit :
> I'm gonna merge this PR soon:
>
> https://github.com/sympy/sympy/pull/12508
On Wednesday, 19 April 2017 17:05:08 UTC+2, Ronan Lamy wrote:
>
> Le 18/04/17 à 21:28, Francesco Bonazzi a écrit :
> > I'm gonna merge this PR soon:
> >
> > https://github.com/sympy/sympy/pull/12508
>
> Wow, that's horrifying! Good luck maintaining it!
>
>
Why is it horrifying?
--
You
Le 18/04/17 à 21:28, Francesco Bonazzi a écrit :
I'm gonna merge this PR soon:
https://github.com/sympy/sympy/pull/12508
Wow, that's horrifying! Good luck maintaining it!
If anyone oppose merging the PR in its current state, please write it
before it's too late.
--
You received this
I'm gonna merge this PR soon:
https://github.com/sympy/sympy/pull/12508
If anyone oppose merging the PR in its current state, please write it
before it's too late.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and
https://github.com/sympy/sympy/pull/12508
Initial proposal.
--
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 sympy+unsubscr...@googlegroups.com.
To post to this group,
I haven't thought about the details, but just happened to click on Matthew
Rocklins 2014 SciPy talk where he introduces the multiple dispatch ideas
for SymPy and it seemed relevant to this issue.
Jason
moorepants.info
+01 530-601-9791 <(530)%20601-9791>
On Sun, Mar 26, 2017 at 6:21 AM,
On Sunday, 26 March 2017 00:48:13 UTC+1, Jason Moore wrote:
>
> Would multiple dispatch be best for implementing Add/Mul/Etc for these
> different types?
>
I think this alternative would work better than multiple dispatching. It's
also much simpler to implement.
--
You received this
Would multiple dispatch be best for implementing Add/Mul/Etc for these
different types?
Jason
moorepants.info
+01 530-601-9791
On Thu, Mar 23, 2017 at 10:45 AM, Aaron Meurer wrote:
> An expression like x*A + B would be problematic, but 2*A + B should
> actually be fine,
An expression like x*A + B would be problematic, but 2*A + B should
actually be fine, because the flatten algorithm splits off numeric
coefficients (so that they can be combined).
Aaron Meurer
On Thu, Mar 23, 2017 at 11:59 AM, Francesco Bonazzi
wrote:
> There's another
There's another complication. Consider the expression:
3*A + 2*B
Suppose *A* and *B* require a flatten-postprocessor at the *Add* level. The
*Add* object will not detect them, because its parameters are just two *Mul*
objects.
--
You received this message because you are subscribed to the
Ah, that would take care of subclass checks too. If someone wanted to
add their own postprocessor to an existing class they'd need to
subclass it, but that's fine (it is adding behavior to a class, so
subclassing makes sense).
We should think about ordering. set() ordering is (effectively)
On Wednesday, 22 March 2017 18:48:15 UTC+1, Aaron Meurer wrote:
>
>
> How would it work as a set? How do you know which function to call?
>
>
I was thinking about something like this:
class Add:
_check_postprocess = False
@classmethod
def flatten(cls, seq):
postprocess =
On Wed, Mar 22, 2017 at 9:36 AM, Francesco Bonazzi
wrote:
>
>
> On Tuesday, 21 March 2017 18:30:46 UTC+1, Aaron Meurer wrote:
>>
>> I like the idea, although we've have to make sure to keep things fast,
>> especially for common objects.
>
>
> Yes, that's the main problem.
On Tuesday, 21 March 2017 18:30:46 UTC+1, Aaron Meurer wrote:
>
> I like the idea, although we've have to make sure to keep things fast,
> especially for common objects.
>
Yes, that's the main problem. A simple idea is to load these preprocessors
only if the submodules requiring them are
I like the idea, although we've have to make sure to keep things fast,
especially for common objects.
Maybe each class could have a registry, and at the top of each class,
it could have a function that checks each argument against the
registry. So for instance, for Add:
class Add:
I am trying to fix the unit system module in SymPy, and I got into a
problem:
>>> meter + second
meter + second
>>> length + time
length + time
Such expressions create an *Add* object. Technically, they such raise an
exception, given that the summation involves incompatible dimensions.
21 matches
Mail list logo