Hi,
We are running into some issues with Mul in the quantum stuff. There
are two main things:
1. How Mul combines adjacent args.
2. How Mul decides if two adjacent args can be multiplied.
For now, let's focus on the second of these. The difficulty right now
is that Mul allow any two Exprs to
First off, pragmatically speaking, is there a reason why you need to use the
core Mul instead of writing your own custom Mul for the quantum stuff? I am
just saying this because even though I agree that we need this change, changing
anything in the core is very difficult and time consuming, bec
Hi,
On Wed, Jul 21, 2010 at 1:15 PM, Aaron S. Meurer wrote:
> First off, pragmatically speaking, is there a reason why you need to use the
> core Mul instead of writing your own custom Mul for the quantum stuff? I am
> just saying this because even though I agree that we need this change,
> c
On Wed, Jul 21, 2010 at 1:15 PM, Aaron S. Meurer wrote:
> First off, pragmatically speaking, is there a reason why you need to use the
> core Mul instead of writing your own custom Mul for the quantum stuff? I am
> just saying this because even though I agree that we need this change,
> changi
On Wed, Jul 21, 2010 at 2:11 PM, Ondrej Certik wrote:
> Hi,
>
> On Wed, Jul 21, 2010 at 1:15 PM, Aaron S. Meurer wrote:
>> First off, pragmatically speaking, is there a reason why you need to use the
>> core Mul instead of writing your own custom Mul for the quantum stuff? I am
>> just saying
On Jul 23, 2010, at 6:41 PM, Brian Granger wrote:
> On Wed, Jul 21, 2010 at 1:15 PM, Aaron S. Meurer wrote:
>> First off, pragmatically speaking, is there a reason why you need to use the
>> core Mul instead of writing your own custom Mul for the quantum stuff? I am
>> just saying this becaus
On Fri, Jul 23, 2010 at 5:44 PM, Brian Granger wrote:
> On Wed, Jul 21, 2010 at 2:11 PM, Ondrej Certik wrote:
>> Hi,
>>
>> On Wed, Jul 21, 2010 at 1:15 PM, Aaron S. Meurer wrote:
>>> First off, pragmatically speaking, is there a reason why you need to use
>>> the core Mul instead of writing you
Le vendredi 23 juillet 2010 à 17:41 -0700, Brian Granger a écrit :
> On Wed, Jul 21, 2010 at 1:15 PM, Aaron S. Meurer wrote:
> > First off, pragmatically speaking, is there a reason why you need to use
> > the core Mul instead of writing your own custom Mul for the quantum stuff?
> > I am just
On Fri, Jul 23, 2010 at 8:30 PM, Ronan Lamy wrote:
> Le vendredi 23 juillet 2010 à 17:41 -0700, Brian Granger a écrit :
>> On Wed, Jul 21, 2010 at 1:15 PM, Aaron S. Meurer wrote:
>> > First off, pragmatically speaking, is there a reason why you need to use
>> > the core Mul instead of writing yo
Brian Granger wrote:
On Fri, Jul 23, 2010 at 8:30 PM, Ronan Lamy wrote:
Le vendredi 23 juillet 2010 à 17:41 -0700, Brian Granger a écrit :
On Wed, Jul 21, 2010 at 1:15 PM, Aaron S. Meurer wrote:
First off, pragmatically speaking, is there a reason why you need to use the
core
Alan,
This only works because you have custom scalars as well. Because of
this, you have overridden the __mul__ and __rmul__ methods of *every*
object that is used in GA. But in quantum mechanics, I still need to
use all the regular sympy scalars that use the default Expr.__mul__
and Expr,__rmul
Here is a simple implementation that does a priority based check for __mul__
and __rmul__:
http://github.com/ellisonbg/sympy/commit/bb449fbdf78f5ef19351640d987d96204c6c3f34
On my machine the test suite does not slow down a significant amount (within
1%). Of course, if we use this approach on all
Here is an addition patch that adds this capability to all binary special
methods in Expr:
http://github.com/ellisonbg/sympy/commit/116acd6ef2bde6d0d0aa8c2f2ec1f380abbabab1
The performance penalty is still around 1%. If there is support for this
approach, I would like to merge it to trunk soon a
I written tests for this now.
Brian
On Sat, Jul 24, 2010 at 10:07 AM, Brian Granger wrote:
> Here is an addition patch that adds this capability to all binary special
> methods in Expr:
>
>
> http://github.com/ellisonbg/sympy/commit/116acd6ef2bde6d0d0aa8c2f2ec1f380abbabab1
>
> The performance p
Le samedi 24 juillet 2010 à 13:10 -0700, Brian Granger a écrit :
> I written tests for this now.
>
>
> Brian
>
> On Sat, Jul 24, 2010 at 10:07 AM, Brian Granger
> wrote:
> Here is an addition patch that adds this capability to all
> binary special methods in Expr:
>
>
On Sat, Jul 24, 2010 at 5:14 PM, Ronan Lamy wrote:
> Le samedi 24 juillet 2010 à 13:10 -0700, Brian Granger a écrit :
> > I written tests for this now.
> >
> >
> > Brian
> >
> > On Sat, Jul 24, 2010 at 10:07 AM, Brian Granger
> > wrote:
> > Here is an addition patch that adds this capabi
My experience with developing languages in Ignition, is largely the
same as what Brian outlined. Another solution though is to instead of
doing much of the Mul(args) in the core, to do reduce(operator.mul,
args). Since things get expanded into Mul objects they don't hit my
own mul objects. Right
Is it possible to implement x*y*z as reduce(operator.mul, [x, y, z])?
Aaron Meurer
On May 21, 2011, at 9:11 PM, Andy Ray Terrel
wrote:
My experience with developing languages in Ignition, is largely the
same as what Brian outlined. Another solution though is to instead of
doing much of t
Hi,
On 22 May 2011 18:17, Aaron S. Meurer wrote:
> Is it possible to implement x*y*z as reduce(operator.mul, [x, y, z])?
>
It works:
In [2]: import operator
In [3]: reduce(operator.mul, [x, y, z])
Out[3]: x⋅y⋅z
In [4]: type(_)
Out[4]:
but I wouldn't use it on large examples because it take
On Sun, May 22, 2011 at 1:12 PM, Mateusz Paprocki wrote:
> Hi,
>
> On 22 May 2011 18:17, Aaron S. Meurer wrote:
>>
>> Is it possible to implement x*y*z as reduce(operator.mul, [x, y, z])?
>
> It works:
> In [2]: import operator
> In [3]: reduce(operator.mul, [x, y, z])
> Out[3]: x⋅y⋅z
> In [4]: t
On Sun, May 22, 2011 at 1:49 PM, Andy Ray Terrel wrote:
> On Sun, May 22, 2011 at 1:12 PM, Mateusz Paprocki wrote:
>> Hi,
>>
>> On 22 May 2011 18:17, Aaron S. Meurer wrote:
>>>
>>> Is it possible to implement x*y*z as reduce(operator.mul, [x, y, z])?
>>
>> It works:
>> In [2]: import operator
>>
On May 22, 2011, at 12:12 PM, Mateusz Paprocki wrote:
> Hi,
>
> On 22 May 2011 18:17, Aaron S. Meurer wrote:
> Is it possible to implement x*y*z as reduce(operator.mul, [x, y, z])?
>
> It works:
>
> In [2]: import operator
>
> In [3]: reduce(operator.mul, [x, y, z])
> Out[3]: x⋅y⋅z
>
> In [
On May 22, 2011, at 5:16 PM, Andy Ray Terrel wrote:
> On Sun, May 22, 2011 at 1:49 PM, Andy Ray Terrel
> wrote:
>> On Sun, May 22, 2011 at 1:12 PM, Mateusz Paprocki wrote:
>>> Hi,
>>>
>>> On 22 May 2011 18:17, Aaron S. Meurer wrote:
Is it possible to implement x*y*z as reduce(oper
On Sun, May 22, 2011 at 7:27 PM, Aaron S. Meurer wrote:
>
> On May 22, 2011, at 12:12 PM, Mateusz Paprocki wrote:
>
> Hi,
>
> On 22 May 2011 18:17, Aaron S. Meurer wrote:
>>
>> Is it possible to implement x*y*z as reduce(operator.mul, [x, y, z])?
>
> It works:
> In [2]: import operator
> In [3]:
On Sun, May 22, 2011 at 7:32 PM, Aaron S. Meurer wrote:
>
> On May 22, 2011, at 5:16 PM, Andy Ray Terrel wrote:
>
>> On Sun, May 22, 2011 at 1:49 PM, Andy Ray Terrel
>> wrote:
>>> On Sun, May 22, 2011 at 1:12 PM, Mateusz Paprocki wrote:
Hi,
On 22 May 2011 18:17, Aaron S. Meurer
After attempting various ways of handling custom Mul/Add/etc logic
last summer my conclusions were:
1) Implementing my own versions of Mul/Add/etc and using _op_priority
was not a good way to proceed. There are two reasons for this: i)
the dispatch of _op_priority is easily subverted by the many
On May 22, 2011, at 7:43 PM, Andy Ray Terrel wrote:
> On Sun, May 22, 2011 at 7:27 PM, Aaron S. Meurer wrote:
>>
>> On May 22, 2011, at 12:12 PM, Mateusz Paprocki wrote:
>>
>> Hi,
>>
>> On 22 May 2011 18:17, Aaron S. Meurer wrote:
>>>
>>> Is it possible to implement x*y*z as reduce(operator
27 matches
Mail list logo
