[sympy] physics.quantum documentation

[krastanov.ste...@gmail.com]

Hello all,

I was looking at the stable and dev documentation and it seems to me that
there is nothing on the physics module. Am I right? Are there any tutorials
or references that are not automatically generated? If not, where is the
best place to look for a consistent overview of the functionality (the
source or some references)?

Regards
Stefan Krastanov

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] physics.quantum documentation

[krastanov.ste...@gmail.com]

Thank you. I have already started reading it (and misinterpreting it here
and there, but it's not to hard to follow).

On 30 March 2011 00:03, Brian Granger  wrote:

> We recently merged the quantum work from last summer into master and
> currently there are no docs ;(
>
> We are working on that, but not quite there yet.  So for now, the best
> place to start is the code (which you would want to do anyways...).
> But, probably the best place in the code to start is the tests, as
> they are reasonably complete and show what the code can do.
>
> Cheers,
>
> Brian
>
> On Tue, Mar 29, 2011 at 10:31 AM, krastanov.ste...@gmail.com
>  wrote:
> > Hello all,
> >
> > I was looking at the stable and dev documentation and it seems to me that
> > there is nothing on the physics module. Am I right? Are there any
> tutorials
> > or references that are not automatically generated? If not, where is the
> > best place to look for a consistent overview of the functionality (the
> > source or some references)?
> >
> > Regards
> > Stefan Krastanov
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "sympy" group.
> > To post to this group, send email to sympy@googlegroups.com.
> > To unsubscribe from this group, send email to
> > sympy+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/sympy?hl=en.
> >
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgran...@calpoly.edu and elliso...@gmail.com
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] spin 1/2 in physics.quantum and pretty printing

[krastanov.ste...@gmail.com]

Hi,

I am trying to use the spin classes from physics.quantum. For the moment I
am working with a two-state system (spin 1/2). Is there a class dedicated to
1/2 spins (as opposed to J?Ket where I must write zplus=JzKet(1/2,1/2))?

My main concern for the moment is the printing. I would like to use both
JzKet and JxKet and they are both printed as |1/2,+-1/2>.

I suppose that there is a nice solution where I can change only the label (I
have no knowledge of how the printing system works). If this is the case I
would like to find it, but still I prefer a cleaner solution where the class
I use has done the change of label for me.

Regards
Stefan Krastanov

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: spin 1/2 in physics.quantum and pretty printing

[krastanov.ste...@gmail.com]

For example:
|z+> for JzKet(1/2,+1/2) and |z-> for JzKet(1/2,-1/2) seem reasonable to me.
The same for x and y.

But there is also a more general question - what is the standard way to
chose a label for |u> = a * |z+> + b * |z->? I suppose that with some
experimentation and looking at the code I will find a working solution, but
I prefer to have some style guidelines.

Stefan

On 30 March 2011 17:00, Vinzent Steinberg
wrote:

> Hi,
>
> On Mar 30, 4:49 pm, "krastanov.ste...@gmail.com"
>  wrote:
> > My main concern for the moment is the printing. I would like to use both
> > JzKet and JxKet and they are both printed as |1/2,+-1/2>.
>
> How would you like it to be printed?
>
> Vinzent
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: spin 1/2 in physics.quantum and pretty printing

[krastanov.ste...@gmail.com]

So in a more general case if I want to have the variable(instance) foo_bar
of some RandomClass be printed in latex(or pretty print or whatever) as
\foo_{bar} (or whatever in the other printers) I should first subclass
RandomClass with overwritten printer and define foo_bar as an instance of
the subclass?

Is not there a more elegant way? Am I save from side effects if I just
change the instance method print without subclassing as opposed to changing
the class method print in a subclass?

Do my questions make any sense or am I doing all this the wrong way?

Stefan

On 30 March 2011 18:18, Vinzent Steinberg
wrote:

> On Mar 30, 5:14 pm, "krastanov.ste...@gmail.com"
>  wrote:
> > For example:
> > |z+> for JzKet(1/2,+1/2) and |z-> for JzKet(1/2,-1/2) seem reasonable to
> me.
> > The same for x and y.
> >
> > But there is also a more general question - what is the standard way to
> > chose a label for |u> = a * |z+> + b * |z->? I suppose that with some
> > experimentation and looking at the code I will find a working solution,
> but
> > I prefer to have some style guidelines.
>
> I'm neither familiar with the quantum code base, but it seems the
> printing is implemented in StateBase. If you wan JzKet to be printed
> differently, you have to look at the standard implementation and
> overload it in JzKet. In this case there are three methods to
> overload: _print_contents, _print_contents_pretty and
> _print_contents_latex.
>
> If you plan less radical changes, the brackets are defined in KetBase,
> so you could also just overload these.
>
> Please note that you can look at the implementation interactively
> using source(obj) or obj?? when using isympy.
>
> Vinzent
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] spin 1/2 in physics.quantum and pretty printing

[krastanov.ste...@gmail.com]

Thank you for the answer. I filed an issue and I will try to make an useful
patch some time in the near future.

Stefan

On 30 March 2011 22:55, Brian Granger  wrote:

> Hi,
>
> > I am trying to use the spin classes from physics.quantum. For the moment
> I
> > am working with a two-state system (spin 1/2). Is there a class dedicated
> to
> > 1/2 spins (as opposed to J?Ket where I must write zplus=JzKet(1/2,1/2))?
>
> We don't currently have any shorthands for the spin 1/2 case although
> they would probably make sense to have.
>
> > My main concern for the moment is the printing. I would like to use both
> > JzKet and JxKet and they are both printed as |1/2,+-1/2>.
>
> Yes, especially in the latex rendering it would make sense to add a
> subscript "x" or "z" to this notation.
>
> > I suppose that there is a nice solution where I can change only the label
> (I
> > have no knowledge of how the printing system works). If this is the case
> I
> > would like to find it, but still I prefer a cleaner solution where the
> class
> > I use has done the change of label for me.
>
> The print methods for these things are in the spin.py module and are
> pretty self explanatory.  You may also have to dig a bit deeper in the
> qexpr.py and state.py modules to see how the base classes print.
>
> Cheers,
>
> Brian
>
> > Regards
> > Stefan Krastanov
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "sympy" group.
> > To post to this group, send email to sympy@googlegroups.com.
> > To unsubscribe from this group, send email to
> > sympy+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/sympy?hl=en.
> >
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgran...@calpoly.edu and elliso...@gmail.com
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] physics.quantum - labels vs args - printing vs content

[krastanov.ste...@gmail.com]

Hi,

In short: *label is used by the printing functions but also it is used
instead of args in some other functions*

I'm trying to make the printing in physics.quantum.spin less ambiguous.
According to the answer I received here
http://groups.google.com/group/sympy/msg/3f8d4fe139b1884a it will be useful
to add subscript (or something else) to the printed expression. Here is the
problem: label is used by the printing functions but also it is used instead
of args in some other functions.

The printing functions for J?Ket are derived all from KetBase which uses
function derived from StateBase which uses function derived from QExpr.

My understanding is that the self.args of QExpr should be a list (tuple) of
the quantum numbers and other useful sympy symbols that define the
mathematical object and label should be a list (tuple) of things that must
be printed to screen. So we have the JzKet(1/2,1/2) with args (1/2,1/2) and
label (1/2,1/2) being printed as |1/2,1/2>. The problems are:
- Some parts of the code use label instead of args to get the quantum
numbers (j and m in J?Ket). So I can not have the label ("z",1/2,1/2). I
believe that a stricter distinction should be made.
- *less important and of topic* The separator "," for the label must be
the same for every separation (but can be different from ket to ket). So if
I want a better label like |z:1/2,1/2> I can't do it.

As it stands (at least for the spin part) QExpr defines label as property in
the function "return self.args" and then the code uses label instead of
args. I believe it is a bug to use label in this manner because I can not
override it to have nicer printing. The default for label is ok: just print
all quantum numbers. But for the spin for example I would like to have other
info printed.

*So am I wrong in proposing:*
- Fixing the code where label is used instead of args.
- Adding a prefix/title/something field to the label so I can have
|usefull_info : q_number_1, q_number_2, ...> printed to screen. That will
make the base printing functions more complicated but it will not change the
rest of the code. Maybe creating a QuantumLabel class would be useful.

also: All the code in quantum that deals with printing (inner product's
printer for example) supposes that the rightmost char in the string of Ket
will be >. So subscripts are out of the question if they are in the form
|foo,bar>_subscript. That is not a problem. I am just noting this assumption
that does not seem documented.

Regards
Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] physics.quantum - labels vs args - printing vs content

[krastanov.ste...@gmail.com]

Hi,

I checked out TimeDepState and I believe that I got it now and I will use it
for the spins over the weekend.

Stefan

On 31 March 2011 18:15, Brian Granger  wrote:

> Hi,
>
> > In short: label is used by the printing functions but also it is used
> > instead of args in some other functions
>
> Yes, that is the case.  The difference between label and args is
> deliberate and important:
>
> * label == set of things that determine which state you have ==
> quantum numbers usually.  This does not include things like time and
> other parameters.
> * args == label + time + 
>
> In many cases, label == args, but not in general (see TimeDepKet).
>
> > I'm trying to make the printing in physics.quantum.spin less ambiguous.
> > According to the answer I received here
> > http://groups.google.com/group/sympy/msg/3f8d4fe139b1884a it will be
> useful
> > to add subscript (or something else) to the printed expression. Here is
> the
> > problem: label is used by the printing functions but also it is used
> instead
> > of args in some other functions.
>
> This is as it should be.
>
> > The printing functions for J?Ket are derived all from KetBase which uses
> > function derived from StateBase which uses function derived from QExpr.
> >
> > My understanding is that the self.args of QExpr should be a list (tuple)
> of
> > the quantum numbers and other useful sympy symbols that define the
> > mathematical object and label should be a list (tuple) of things that
> must
> > be printed to screen. So we have the JzKet(1/2,1/2) with args (1/2,1/2)
> and
> > label (1/2,1/2) being printed as |1/2,1/2>. The problems are:
>
> Again, args also has the time, which is not in label.
>
> > - Some parts of the code use label instead of args to get the quantum
> > numbers (j and m in J?Ket). So I can not have the label ("z",1/2,1/2). I
> > believe that a stricter distinction should be made.
> > - less important and of topic The separator "," for the label must be
> > the same for every separation (but can be different from ket to ket). So
> if
> > I want a better label like |z:1/2,1/2> I can't do it.
> >
> > As it stands (at least for the spin part) QExpr defines label as property
> in
> > the function "return self.args" and then the code uses label instead of
> > args. I believe it is a bug to use label in this manner because I can not
> > override it to have nicer printing. The default for label is ok: just
> print
> > all quantum numbers. But for the spin for example I would like to have
> other
> > info printed.
> >
> > So am I wrong in proposing:
> > - Fixing the code where label is used instead of args.
> > - Adding a prefix/title/something field to the label so I can have
> > |usefull_info : q_number_1, q_number_2, ...> printed to screen. That will
> > make the base printing functions more complicated but it will not change
> the
> > rest of the code. Maybe creating a QuantumLabel class would be useful.
> >
> > also: All the code in quantum that deals with printing (inner product's
> > printer for example) supposes that the rightmost char in the string of
> Ket
> > will be >. So subscripts are out of the question if they are in the form
> > |foo,bar>_subscript. That is not a problem. I am just noting this
> assumption
> > that does not seem documented.
>
> You can do what you want be overriding the various _print_contents
> methods.  I would check out how TimeDepState in state.py handles this.
>  I think that will answer your questions.
>
> Cheers,
>
> Brian
>
> > Regards
> > Stefan
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "sympy" group.
> > To post to this group, send email to sympy@googlegroups.com.
> > To unsubscribe from this group, send email to
> > sympy+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/sympy?hl=en.
> >
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgran...@calpoly.edu and elliso...@gmail.com
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] physics.quantum - labels vs args - printing vs content

[krastanov.ste...@gmail.com]

I mean the style of the code, not the class, obviously :)

On 31 March 2011 21:47, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> Hi,
>
> I checked out TimeDepState and I believe that I got it now and I will use
> it for the spins over the weekend.
>
> Stefan
>
>
> On 31 March 2011 18:15, Brian Granger  wrote:
>
>> Hi,
>>
>> > In short: label is used by the printing functions but also it is used
>> > instead of args in some other functions
>>
>> Yes, that is the case.  The difference between label and args is
>> deliberate and important:
>>
>> * label == set of things that determine which state you have ==
>> quantum numbers usually.  This does not include things like time and
>> other parameters.
>> * args == label + time + 
>>
>> In many cases, label == args, but not in general (see TimeDepKet).
>>
>> > I'm trying to make the printing in physics.quantum.spin less ambiguous.
>> > According to the answer I received here
>> > http://groups.google.com/group/sympy/msg/3f8d4fe139b1884a it will be
>> useful
>> > to add subscript (or something else) to the printed expression. Here is
>> the
>> > problem: label is used by the printing functions but also it is used
>> instead
>> > of args in some other functions.
>>
>> This is as it should be.
>>
>> > The printing functions for J?Ket are derived all from KetBase which uses
>> > function derived from StateBase which uses function derived from QExpr.
>> >
>> > My understanding is that the self.args of QExpr should be a list (tuple)
>> of
>> > the quantum numbers and other useful sympy symbols that define the
>> > mathematical object and label should be a list (tuple) of things that
>> must
>> > be printed to screen. So we have the JzKet(1/2,1/2) with args (1/2,1/2)
>> and
>> > label (1/2,1/2) being printed as |1/2,1/2>. The problems are:
>>
>> Again, args also has the time, which is not in label.
>>
>> > - Some parts of the code use label instead of args to get the
>> quantum
>> > numbers (j and m in J?Ket). So I can not have the label ("z",1/2,1/2). I
>> > believe that a stricter distinction should be made.
>> > - less important and of topic The separator "," for the label must
>> be
>> > the same for every separation (but can be different from ket to ket). So
>> if
>> > I want a better label like |z:1/2,1/2> I can't do it.
>> >
>> > As it stands (at least for the spin part) QExpr defines label as
>> property in
>> > the function "return self.args" and then the code uses label instead of
>> > args. I believe it is a bug to use label in this manner because I can
>> not
>> > override it to have nicer printing. The default for label is ok: just
>> print
>> > all quantum numbers. But for the spin for example I would like to have
>> other
>> > info printed.
>> >
>> > So am I wrong in proposing:
>> > - Fixing the code where label is used instead of args.
>> > - Adding a prefix/title/something field to the label so I can have
>> > |usefull_info : q_number_1, q_number_2, ...> printed to screen. That
>> will
>> > make the base printing functions more complicated but it will not change
>> the
>> > rest of the code. Maybe creating a QuantumLabel class would be useful.
>> >
>> > also: All the code in quantum that deals with printing (inner product's
>> > printer for example) supposes that the rightmost char in the string of
>> Ket
>> > will be >. So subscripts are out of the question if they are in the form
>> > |foo,bar>_subscript. That is not a problem. I am just noting this
>> assumption
>> > that does not seem documented.
>>
>> You can do what you want be overriding the various _print_contents
>> methods.  I would check out how TimeDepState in state.py handles this.
>>  I think that will answer your questions.
>>
>> Cheers,
>>
>> Brian
>>
>> > Regards
>> > Stefan
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "sympy" group.
>> > To post to this group, send email to sympy@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > sympy+unsubscr...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/sympy?hl=en.
>> >
>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> bgran...@calpoly.edu and elliso...@gmail.com
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] patch for the printing of quantum.spin

[krastanov.ste...@gmail.com]

Following from here
http://groups.google.com/group/sympy/msg/accc99bb1030e6b2
Concerning issue http://code.google.com/p/sympy/issues/detail?id=2251

As the printing of spin states in physics.quantum is a bit ambiguous I have
tried to change it. I have override the _print_content* methods to add a
prefix.
As this is the first time I work with the printing system I would be
grateful if someone checks the consistency of the approach. Most importantly
- I do not know if my approach is what you have in mind for general spin
states.

If it is consistent I will check the unit tests (it's not done for the
moment)

Regards
Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

From 08e877d664a150daa45b1becd801eea3d2c51c25 Mon Sep 17 00:00:00 2001
From: Stefan Krastanov 
Date: Fri, 1 Apr 2011 16:14:25 +0200
Subject: [PATCH] Changing the printing methods of quantum.Spin

The JzKet(a,b), JxKet(a,b) and JyKet(a,b) are all
printed with the same string.
To fix the ambiguity I have added a string prefix
to the output of _print_contents*.
---
 sympy/physics/quantum/spin.py |   49 +
 1 files changed, 49 insertions(+), 0 deletions(-)

diff --git a/sympy/physics/quantum/spin.py b/sympy/physics/quantum/spin.py
index 770e21f..007efe7 100644
--- a/sympy/physics/quantum/spin.py
+++ b/sympy/physics/quantum/spin.py
@@ -424,10 +424,55 @@ def m(self):
 def _eval_hilbert_space(cls, label):
 return ComplexSpace(2*label[0]+1)
 
+#-
+# Printing
+#-
+
+_direction_string_label = None
+
+def _print_direction(self, printer, *args):
+return printer._print(self._direction_string_label, *args)
+
+_print_direction_repr = _print_direction
+_print_direction_latex = _print_direction
+
+def _print_direction_pretty(self, printer, *args):
+pform = printer._print(self._direction_string_label, *args)
+return pform
+
+def _print_contents(self, printer, *args):
+label = self._print_label(printer, *args)
+direction = self._print_direction(printer, *args)
+return '%s%s:%s%s' % (self.lbracket, direction, label, self.rbracket)
+
+def _print_contents_repr(self, printer, *args):
+label = self._print_label_repr(printer, *args)
+direction = self._print_direction_repr(printer, *args)
+return '%s,%s' % (direction, label)
+
+def _print_contents_pretty(self, printer, *args):
+pform = self._print_direction_pretty(printer, *args)
+pform = prettyForm(*pform.left((self.lbracket_pretty)))
+pform = prettyForm(*pform.right((':')))
+nextpform = self._print_label_pretty(printer, *args)
+pform = prettyForm(*pform.right((nextpform)))
+pform = prettyForm(*pform.right((self.rbracket_pretty)))
+return pform
+
+def _print_contents_latex(self, printer, *args):
+label = self._print_label_latex(printer, *args)
+direction = self._print_direction_latex(printer, *args)
+# The extra {} brackets are needed to get matplotlib's latex
+# rendered to render this properly.
+return '{%s%s:%s%s}' %\
+(self.lbracket_latex, direction, label, self.rbracket_latex)
+
 
 class JzKet(SpinState, Ket):
 """Eigenket of Jz."""
 
+_direction_string_label="z"
+
 def _eval_innerproduct_JzBra(self, bra, **hints):
 d1 = KroneckerDelta(self.j, bra.j)
 d2 = KroneckerDelta(self.m, bra.m)
@@ -459,6 +504,8 @@ def dual_class(self):
 class JxKet(SpinState, Ket):
 """Eigenket of Jx."""
 
+_direction_string_label="x"
+
 @property
 def dual_class(self):
 return JxBra
@@ -490,6 +537,8 @@ def dual_class(self):
 class JyKet(SpinState, Ket):
 """Eigenket of Jy."""
 
+_direction_string_label="y"
+
 @property
 def dual_class(self):
 return JyBra
-- 
1.7.1

[sympy] Re: patch for the printing of quantum.spin

[krastanov.ste...@gmail.com]

By the way there is something that is not immediately obvious to me
(concerning InnerProduct and a bug in my patch):

*This is ok:*
JzKet('1/2','1/2')   ==>  ❘z:1/2,-1/2⟩
JxKet('1/2','1/2')   ==>  ❘x:1/2,-1/2⟩
TimeDepKet('psi', 't')  ==> ❘ψ;t⟩

*This is probably ok:*
TimeDepKet('psi', 't').dual * TimeDepKet('psi', 't')  ==> ⟨ψ❘ψ;t⟩  # Only
one t

*This is NOT ok:*
JxKet('1/2','1/2').dual*JzKet('1/2','1/2')  ==> ⟨1/2,-1/2❘z:1/2,-1/2⟩ # The
x is lost, the output is not clear.

What should be done?

Regards
Stefan

On 1 April 2011 16:26, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> Following from here
> http://groups.google.com/group/sympy/msg/accc99bb1030e6b2
> Concerning issue http://code.google.com/p/sympy/issues/detail?id=2251
>
> As the printing of spin states in physics.quantum is a bit ambiguous I have
> tried to change it. I have override the _print_content* methods to add a
> prefix.
> As this is the first time I work with the printing system I would be
> grateful if someone checks the consistency of the approach. Most importantly
> - I do not know if my approach is what you have in mind for general spin
> states.
>
> If it is consistent I will check the unit tests (it's not done for the
> moment)
>
> Regards
> Stefan
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: patch for the printing of quantum.spin

[krastanov.ste...@gmail.com]

That is not the problem _but_ It is true that I should define
_direction_string_label for J?Bra for another reason.

With the patch (and no _direction_string_label for the J?Bras) I have
JxKet('1/2','1/2').dual  ==> ⟨z:1/2,-1/2❘
which is ok.

The problem is that innerproduct uses print_label and not print_content for
the bra which is the way it should be, at least for TimeDepKet.

Adding _direction_string_label to J?Bra is needed because someone may define
a Bra and get
JxBra('1/2','-1/2')  ==> ⟨None:1/2,-1/2❘. Otherwise it is not needed for the
use of Ket.dual as the field is already defined.

Stefan

On 1 April 2011 18:04, Julien Rioux  wrote:

> > *This is NOT ok:*
> > JxKet('1/2','1/2').dual*JzKet('1/2','1/2')  ==> ⟨1/2,-1/2❘z:1/2,-1/2⟩ #
> The
> > x is lost, the output is not clear.
> >
> > What should be done?
>
> .dual returns the J?Bra classes. You didn't define
> _direction_string_label for these classes.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: patch for the printing of quantum.spin

[krastanov.ste...@gmail.com]

If there is a consensus on this I will be happy to change it.

Otherwise is the patch ok? If it is to whom should I send it?
Here is the second part that adds _distance_string_label to the bras

On 1 April 2011 18:29, Brian Granger  wrote:

> On Fri, Apr 1, 2011 at 9:27 AM, Julien Rioux 
> wrote:
> > On Apr 1, 12:21 pm, "krastanov.ste...@gmail.com"
> >  wrote:
> >> The problem is that innerproduct uses print_label and not print_content
> for
> >> the bra which is the way it should be, at least for TimeDepKet.
> >>
> >
> > I see. Well I don't agree that ⟨ψ❘ψ;t⟩ is how it should be. I think it
> > should be ⟨ψ;t❘ψ;t⟩.
>
> +1
>
> > --
> > You received this message because you are subscribed to the Google Groups
> "sympy" group.
> > To post to this group, send email to sympy@googlegroups.com.
> > To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
> >
> >
>
>
>
> --
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> bgran...@calpoly.edu and elliso...@gmail.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

From 08e877d664a150daa45b1becd801eea3d2c51c25 Mon Sep 17 00:00:00 2001
From: Stefan Krastanov 
Date: Fri, 1 Apr 2011 16:14:25 +0200
Subject: [PATCH 1/2] Changing the printing methods of quantum.Spin

The JzKet(a,b), JxKet(a,b) and JyKet(a,b) are all
printed with the same string.
To fix the ambiguity I have added a string prefix
to the output of _print_contents*.
---
 sympy/physics/quantum/spin.py |   49 +
 1 files changed, 49 insertions(+), 0 deletions(-)

diff --git a/sympy/physics/quantum/spin.py b/sympy/physics/quantum/spin.py
index 770e21f..007efe7 100644
--- a/sympy/physics/quantum/spin.py
+++ b/sympy/physics/quantum/spin.py
@@ -424,10 +424,55 @@ def m(self):
 def _eval_hilbert_space(cls, label):
 return ComplexSpace(2*label[0]+1)
 
+#-
+# Printing
+#-
+
+_direction_string_label = None
+
+def _print_direction(self, printer, *args):
+return printer._print(self._direction_string_label, *args)
+
+_print_direction_repr = _print_direction
+_print_direction_latex = _print_direction
+
+def _print_direction_pretty(self, printer, *args):
+pform = printer._print(self._direction_string_label, *args)
+return pform
+
+def _print_contents(self, printer, *args):
+label = self._print_label(printer, *args)
+direction = self._print_direction(printer, *args)
+return '%s%s:%s%s' % (self.lbracket, direction, label, self.rbracket)
+
+def _print_contents_repr(self, printer, *args):
+label = self._print_label_repr(printer, *args)
+direction = self._print_direction_repr(printer, *args)
+return '%s,%s' % (direction, label)
+
+def _print_contents_pretty(self, printer, *args):
+pform = self._print_direction_pretty(printer, *args)
+pform = prettyForm(*pform.left((self.lbracket_pretty)))
+pform = prettyForm(*pform.right((':')))
+nextpform = self._print_label_pretty(printer, *args)
+pform = prettyForm(*pform.right((nextpform)))
+pform = prettyForm(*pform.right((self.rbracket_pretty)))
+return pform
+
+def _print_contents_latex(self, printer, *args):
+label = self._print_label_latex(printer, *args)
+direction = self._print_direction_latex(printer, *args)
+# The extra {} brackets are needed to get matplotlib's latex
+# rendered to render this properly.
+return '{%s%s:%s%s}' %\
+(self.lbracket_latex, direction, label, self.rbracket_latex)
+
 
 class JzKet(SpinState, Ket):
 """Eigenket of Jz."""
 
+_direction_string_label="z"
+
 def _eval_innerproduct_JzBra(self, bra, **hints):
 d1 = KroneckerDelta(self.j, bra.j)
 d2 = KroneckerDelta

Re: [sympy] Re: patch for the printing of quantum.spin

[krastanov.ste...@gmail.com]

Thanks. Brian also explained it in a private message.


On 2 April 2011 14:25, Vinzent Steinberg
wrote:

> On 1 Apr., 18:31, "krastanov.ste...@gmail.com"
>  wrote:
> > If there is a consensus on this I will be happy to change it.
> >
> > Otherwise is the patch ok? If it is to whom should I send it?
> > Here is the second part that adds _distance_string_label to the bras
>
> The preferable way is to create a pull request on github. Email
> patches are fine too with me, but I don't know about the quantum guys.
>
> Vinzent
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: patch for the printing of quantum.spin

[krastanov.ste...@gmail.com]

Hi

I have a question about the behavior of _print_contents. As it stands there
is no difference between _print_contents and _print main method. _print just
calls _print_contents. That way _print_content must take care for the
brackets. I believe this is counterintuitive. And it makes it difficult to
fix the printing of InnerProduct in a clear way.

I propose that the bracket printing is done in the main method _print and
that _print_contents is left printing only the content of those brackets.
That way the printing of InnerProduct will be much more easy to understand.

As it stands there is no easy way to print bra*ket. If I use _print_label it
will only print the quantum numbers and not the time (for TimeDepBra) or the
direction string (for J?Bra). If I use _print_contents the left bracket and
the vertical line are printed twice.

Stefan

On 2 April 2011 18:15, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> Thanks. Brian also explained it in a private message.
>
>
>
> On 2 April 2011 14:25, Vinzent Steinberg  > wrote:
>
>> On 1 Apr., 18:31, "krastanov.ste...@gmail.com"
>>  wrote:
>> > If there is a consensus on this I will be happy to change it.
>> >
>> > Otherwise is the patch ok? If it is to whom should I send it?
>> > Here is the second part that adds _distance_string_label to the bras
>>
>> The preferable way is to create a pull request on github. Email
>> patches are fine too with me, but I don't know about the quantum guys.
>>
>> Vinzent
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to sympy@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sympy?hl=en.
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: patch for the printing of quantum.spin

[krastanov.ste...@gmail.com]

My proposition may be detrimental for _sympyrepr in qexpr.py. Is it?
Should _print_contents print the brackets or not?

On 2 April 2011 20:53, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> Hi
>
> I have a question about the behavior of _print_contents. As it stands there
> is no difference between _print_contents and _print main method. _print just
> calls _print_contents. That way _print_content must take care for the
> brackets. I believe this is counterintuitive. And it makes it difficult to
> fix the printing of InnerProduct in a clear way.
>
> I propose that the bracket printing is done in the main method _print and
> that _print_contents is left printing only the content of those brackets.
> That way the printing of InnerProduct will be much more easy to understand.
>
> As it stands there is no easy way to print bra*ket. If I use _print_label
> it will only print the quantum numbers and not the time (for TimeDepBra) or
> the direction string (for J?Bra). If I use _print_contents the left bracket
> and the vertical line are printed twice.
>
> Stefan
>
>
> On 2 April 2011 18:15, krastanov.ste...@gmail.com <
> krastanov.ste...@gmail.com> wrote:
>
>> Thanks. Brian also explained it in a private message.
>>
>>
>>
>> On 2 April 2011 14:25, Vinzent Steinberg <
>> vinzent.steinb...@googlemail.com> wrote:
>>
>>> On 1 Apr., 18:31, "krastanov.ste...@gmail.com"
>>>  wrote:
>>> > If there is a consensus on this I will be happy to change it.
>>> >
>>> > Otherwise is the patch ok? If it is to whom should I send it?
>>> > Here is the second part that adds _distance_string_label to the bras
>>>
>>> The preferable way is to create a pull request on github. Email
>>> patches are fine too with me, but I don't know about the quantum guys.
>>>
>>> Vinzent
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "sympy" group.
>>> To post to this group, send email to sympy@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> sympy+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/sympy?hl=en.
>>>
>>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: patch for the printing of quantum.spin

[krastanov.ste...@gmail.com]

Ok, there is a pull request.

On 2 April 2011 21:15, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> My proposition may be detrimental for _sympyrepr in qexpr.py. Is it?
> Should _print_contents print the brackets or not?
>
>
> On 2 April 2011 20:53, krastanov.ste...@gmail.com <
> krastanov.ste...@gmail.com> wrote:
>
>> Hi
>>
>> I have a question about the behavior of _print_contents. As it stands
>> there is no difference between _print_contents and _print main method.
>> _print just calls _print_contents. That way _print_content must take care
>> for the brackets. I believe this is counterintuitive. And it makes it
>> difficult to fix the printing of InnerProduct in a clear way.
>>
>> I propose that the bracket printing is done in the main method _print and
>> that _print_contents is left printing only the content of those brackets.
>> That way the printing of InnerProduct will be much more easy to understand.
>>
>> As it stands there is no easy way to print bra*ket. If I use _print_label
>> it will only print the quantum numbers and not the time (for TimeDepBra) or
>> the direction string (for J?Bra). If I use _print_contents the left bracket
>> and the vertical line are printed twice.
>>
>> Stefan
>>
>>
>> On 2 April 2011 18:15, krastanov.ste...@gmail.com <
>> krastanov.ste...@gmail.com> wrote:
>>
>>> Thanks. Brian also explained it in a private message.
>>>
>>>
>>>
>>> On 2 April 2011 14:25, Vinzent Steinberg <
>>> vinzent.steinb...@googlemail.com> wrote:
>>>
>>>> On 1 Apr., 18:31, "krastanov.ste...@gmail.com"
>>>>  wrote:
>>>> > If there is a consensus on this I will be happy to change it.
>>>> >
>>>> > Otherwise is the patch ok? If it is to whom should I send it?
>>>> > Here is the second part that adds _distance_string_label to the bras
>>>>
>>>> The preferable way is to create a pull request on github. Email
>>>> patches are fine too with me, but I don't know about the quantum guys.
>>>>
>>>> Vinzent
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "sympy" group.
>>>> To post to this group, send email to sympy@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> sympy+unsubscr...@googlegroups.com.
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/sympy?hl=en.
>>>>
>>>>
>>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] quantum - spin 1/2

[krastanov.ste...@gmail.com]

Hi all,

I would like to know what is the agreed upon way to treat spin 1/2 systems
in physics.quantum?

I would like to write a shorthand class for those states (a subclass of
J?Ket maybe), but:
  - If it is just a subclass what stops me from writing my_spin_state.j =
"something different than 1/2" (maybe I can write a setter that sends and
error on such requests)?
  - More generally - is subclassing from J?Ket the right solution here?
  - What about any type of two state systems that are not necessarily spin
states. Should a special class be created for those?

On a similar topic - I started tinkering with that code because I needed
nice printing for those states. That led to this pull request:
https://github.com/sympy/sympy/pull/186. I think it is ready, but I am not
aware if in your project is considered impolite to poke developers for a
review, that is why I have not raised a question about it. Should I poke you
in the future ;) ?

Regards
Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] writing tests for pretty_print

[krastanov.ste...@gmail.com]

Hi,

I have a branch that is ready for review (and hopefully inclusion) but I
have left a few assert tests commented with a TODO tag. Those tests deal
with pretty printing and it would be nice to finish them, but reconstructing
unicode strings with escape characters is not very amusing.

Is there any convenience function that will give me not only the unicode
string of a pretty print representation, but it will also translate the
non-ascii characters to \u substring?

Regards
Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] writing tests for pretty_print

[krastanov.ste...@gmail.com]

The problem is that I am not able to create the u""" """ string in an
automatic manner (and if I just copy-paste from the isympy terminal I get
SyntaxError: Non-ASCII character)

for example pretty(pr) gives

J ⨂ J ⋅❘z:1,0⟩⨂ ❘y:1,1⟩
z   x

Now to write a test I must search for ⨂ in a unicode table or in the source.
Is there an automatic way to get the \uXXX representation for those
characters.

I tried some stuff from
http://stackoverflow.com/questions/1207457/convert-unicode-to-string-in-python-containing-extra-symbols
and
http://docs.python.org/howto/unicode.html
but nothing very useful.

The branch is https://github.com/sympy/sympy/pull/186

Regards
Stefan

On 20 April 2011 17:25, Alexey U. Gudchenko  wrote:

> 20.04.2011 15:08, krastanov.ste...@gmail.com пишет:
> > Hi,
> >
> > I have a branch that is ready for review (and hopefully inclusion) but I
> > have left a few assert tests commented with a TODO tag. Those tests deal
> > with pretty printing and it would be nice to finish them, but
> reconstructing
> > unicode strings with escape characters is not very amusing.
> >
> > Is there any convenience function that will give me not only the unicode
> > string of a pretty print representation, but it will also translate the
> > non-ascii characters to \u substring?
> >
> > Regards
> > Stefan
> >
>
> Hi,
>
> What is the pull request number or the branch and repository or the
> example?
>
> I suppose that you can  quite the contrary use u""" """ syntax (or
> unicode() ) applying to expected etalon to compare it with resulted
> unicode string.
>
>
> --
> Alexey U.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] writing tests for pretty_print

[krastanov.ste...@gmail.com]

The code is

from sympy import I, symbols, Matrix, pretty, latex
from sympy.physics.quantum.tensorproduct import TensorProduct as TP

import sympy.physics.quantum.spin as s
pr = TP(s.Jz,s.Jx)*TP(s.JzKet(1,0),s.JyKet(1,1))
# TODO assert pretty(pr) ==


On 20 April 2011 18:14, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> The problem is that I am not able to create the u""" """ string in an
> automatic manner (and if I just copy-paste from the isympy terminal I get
> SyntaxError: Non-ASCII character)
>
> for example pretty(pr) gives
>
> J ⨂ J ⋅❘z:1,0⟩⨂ ❘y:1,1⟩
> z   x
>
> Now to write a test I must search for ⨂ in a unicode table or in the
> source. Is there an automatic way to get the \uXXX representation for those
> characters.
>
> I tried some stuff from
>
> http://stackoverflow.com/questions/1207457/convert-unicode-to-string-in-python-containing-extra-symbols
> and
> http://docs.python.org/howto/unicode.html
> but nothing very useful.
>
> The branch is https://github.com/sympy/sympy/pull/186
>
> Regards
> Stefan
>
>
> On 20 April 2011 17:25, Alexey U. Gudchenko  wrote:
>
>> 20.04.2011 15:08, krastanov.ste...@gmail.com пишет:
>> > Hi,
>> >
>> > I have a branch that is ready for review (and hopefully inclusion) but I
>> > have left a few assert tests commented with a TODO tag. Those tests deal
>> > with pretty printing and it would be nice to finish them, but
>> reconstructing
>> > unicode strings with escape characters is not very amusing.
>> >
>> > Is there any convenience function that will give me not only the unicode
>> > string of a pretty print representation, but it will also translate the
>> > non-ascii characters to \u substring?
>> >
>> > Regards
>> > Stefan
>> >
>>
>> Hi,
>>
>> What is the pull request number or the branch and repository or the
>> example?
>>
>> I suppose that you can  quite the contrary use u""" """ syntax (or
>> unicode() ) applying to expected etalon to compare it with resulted
>> unicode string.
>>
>>
>> --
>> Alexey U.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to sympy@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sympy?hl=en.
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] writing tests for pretty_print

[krastanov.ste...@gmail.com]

Thank you. I'll try that.

On 20 April 2011 18:40, Felix Kaiser  wrote:

>  If you really need to use unicode symbols in the code, you can fix the
> non-ascii char problem by adding this to the top of the file::
>
> # -*- encoding: utf-8 -*-
>
> ...and then just copy&paste the ⨂ symbol directly into the code.
>
> Or you could use::
>
> >>> print repr("⨂")
> '\xe2\xa8\x82'
> >>> print '\xe2\xa8\x82'
> ⨂
>
> Felix
>
>
>
> On 04/20/2011 06:14 PM, krastanov.ste...@gmail.com wrote:
>
> The problem is that I am not able to create the u""" """ string in an
> automatic manner (and if I just copy-paste from the isympy terminal I get
> SyntaxError: Non-ASCII character)
>
> for example pretty(pr) gives
>
> J ⨂ J ⋅❘z:1,0⟩⨂ ❘y:1,1⟩
> z   x
>
> Now to write a test I must search for ⨂ in a unicode table or in the
> source. Is there an automatic way to get the \uXXX representation for those
> characters.
>
> I tried some stuff from
>
> http://stackoverflow.com/questions/1207457/convert-unicode-to-string-in-python-containing-extra-symbols
> and
> http://docs.python.org/howto/unicode.html
> but nothing very useful.
>
> The branch is https://github.com/sympy/sympy/pull/186
>
> Regards
> Stefan
>
> On 20 April 2011 17:25, Alexey U. Gudchenko  wrote:
>
>> 20.04.2011 15:08, krastanov.ste...@gmail.com пишет:
>>  > Hi,
>> >
>> > I have a branch that is ready for review (and hopefully inclusion) but I
>> > have left a few assert tests commented with a TODO tag. Those tests deal
>> > with pretty printing and it would be nice to finish them, but
>> reconstructing
>> > unicode strings with escape characters is not very amusing.
>> >
>> > Is there any convenience function that will give me not only the unicode
>> > string of a pretty print representation, but it will also translate the
>> > non-ascii characters to \u substring?
>> >
>> > Regards
>> > Stefan
>> >
>>
>>  Hi,
>>
>> What is the pull request number or the branch and repository or the
>> example?
>>
>> I suppose that you can  quite the contrary use u""" """ syntax (or
>> unicode() ) applying to expected etalon to compare it with resulted
>> unicode string.
>>
>>
>> --
>> Alexey U.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to sympy@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sympy?hl=en.
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] printing in quantum

[krastanov.ste...@gmail.com]

Hi,

First of all, I am sorry that I left the pull request I'll be talking about
halfway finished after taking so much of your time with questions about the
code. I had some more urgent responsibilities lately.

I'm talking about the pull request dealing with changes in the way that
quantum prints stuff. I have some questions to ask and I will also explain
why my code is the way it is. All this is somewhere in the commit messages
but those are not clear enough (sorry). Also an issue about this stuff is
open.

https://github.com/sympy/sympy/pull/186

*print_repr is not tested at all. Before committing it should be
tested,*but I would like some pointers on this one.

The main change is in the behavior of the printing methods of QExpr:
 # Printing of labels
 # This should print only the quantum numbers
 def _print_label(self, printer, *args):
 # Printing of contents
 # This prints the quantum numbers and the rest of the information
 def _print_contents(self, printer, *args):
 # Main methods
 # They would add brackets if needed in the subclasses
 def _sympystr(self, printer, *args): and others

And the brackets stuff is now only in State and TimeDepState.

The children of State and TimeDepState are not changed and from their point
of view nothing has changed.
but now printing of inner product is simpler because I don't need to search
for brackets and remove them.

Before this was necessary because there was no real separation between the
stuff done by _print_label
and _print_content. Frequently _print_label was used for stuff that should
be done by _print_content or
_print_content was adding brackets to the content.


Those changes permitted shorter and cleaner code to be written for those two
problems:

*
First problem - printing of inner products with something more complex than
the simplest Ket:
**Currently we have:*
In [3]: from sympy.physics.quantum import TimeDepKet
In [4]: k = TimeDepKet('psi', 't')
In [5]: k.dual*k
Out[5]: ⟨ψ❘ψ;t⟩
*The output from my code is:*
Out[5]: ⟨ψ;t❘ψ;t⟩

The code is cleaner as there is no more hacking on characters and now not
only the label but the whole content is printed. That's why the refactoring
of the label and content method was necessary.
*

Second problem - printing of spin states is ambiguous, there is no way to
distinguish Jz from Jx states:*
*Currently:*
In [6]: from sympy.physics.quantum.spin import JzKet
In [7]: j = JzKet('1/2','1/2')
In [8]: j
Out[8]: ❘1/2,1/2⟩*
My code:*
Out[8]: ❘z:1/2,1/2⟩*
*
The same stuff.


Proof of the fact that the higher classes were not affected is that no
problems were detected later, when I was adding tests.

In the pull request there are also some new tests for the printing and some
cleanup on the latex stuff.

Also a small question: the pull request contains to many commits. Should I
group them in bigger commits? Be aware that for some reason GitHub is not
listing them chronological (at least to me).

Are there any problems with the approach I have chosen?
Should I add more tests or change something?

Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: printing in quantum

[krastanov.ste...@gmail.com]

It's not the same order. git log and
https://github.com/sympy/sympy/pull/186#commits-pushed-e60b5d0 are most
definitely showing different orders and the one in git hub is not
chronological. I have rebased it a number of times, but I have never tried
to change the order of commits.

But this is just an issue with the order I see in github. It's not that
important for the pull request. I just find it strange.

What about the code? I'm looking at the print_repr tests. Is the rest OK?

Stefan


On 27 May 2011 17:44, Vinzent Steinberg wrote:

> On 26 Mai, 21:18, "krastanov.ste...@gmail.com"
>  wrote:
> > Also a small question: the pull request contains to many commits. Should
> I
> > group them in bigger commits? Be aware that for some reason GitHub is not
> > listing them chronological (at least to me).
>
> Using git rebase it should be possible to change the order of commits.
> This change should be reflected in github too. Do you get the same
> order there as with 'git log'?
>
> Vinzent
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] repr and srepr

[krastanov.ste...@gmail.com]

I know (or I think I know) that eval(srepr(thing)) == thing in sympy.

Should this be also true for repr (the python build-in)? Why are there two
different functions that should be doing the same thing? Is repr hard do
modify?

Regards
Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: printing in quantum

[krastanov.ste...@gmail.com]

https://github.com/sympy/sympy/pull/186

I've just finished adding the repr tests. All works well and after adding
the tests no bugs were found.

So as a recap:
-the printing methods are more straightforward (at least I hope so ;)
-the printing of InnerProduct and Spin looks better
-many test were added for the printing
-some bugs in the latex strings were found and fixed
-some typos in comments were fixed

Am I missing something?

Stefan

On 27 May 2011 18:45, krastanov.ste...@gmail.com  wrote:

> It's not the same order. git log and
> https://github.com/sympy/sympy/pull/186#commits-pushed-e60b5d0 are most
> definitely showing different orders and the one in git hub is not
> chronological. I have rebased it a number of times, but I have never tried
> to change the order of commits.
>
> But this is just an issue with the order I see in github. It's not that
> important for the pull request. I just find it strange.
>
> What about the code? I'm looking at the print_repr tests. Is the rest OK?
>
> Stefan
>
>
>
> On 27 May 2011 17:44, Vinzent Steinberg 
> wrote:
>
>> On 26 Mai, 21:18, "krastanov.ste...@gmail.com"
>>  wrote:
>> > Also a small question: the pull request contains to many commits. Should
>> I
>> > group them in bigger commits? Be aware that for some reason GitHub is
>> not
>> > listing them chronological (at least to me).
>>
>> Using git rebase it should be possible to change the order of commits.
>> This change should be reflected in github too. Do you get the same
>> order there as with 'git log'?
>>
>> Vinzent
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to sympy@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sympy?hl=en.
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] an old pull request

[krastanov.ste...@gmail.com]

Hi,

I'm writing about an old pull request regarding some bugs/enhancements in
the printing of the quantum module: 
https://github.com/sympy/sympy/pull/186

A week ago I explained it in more details here:
https://groups.google.com/d/topic/sympy/ZacngABe3Ws/discussion

Long before that Brian had expressed a concern about two things:
-Not enough tests (I have added those)
-The realization of the code is not great (I have explained why the code is
the way it is in the last link)

So I think the first point is already addressed. For the second one I need
somebody to point out the problems so I can fix them.

The problem is trivial but I would like to end this pull request before
addressing some more interesting problems in the module (some of the spin
operators/states have basic methods that are still unimplemented)

Regards
Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: Some changes to representations in sympy.physics.quantum

[krastanov.ste...@gmail.com]

Hi,

It's quite probable that I just don't understand the logic behind
represent.py but I have a question here.
Shouldn't the representation of |ket> in the continuous basis X be a
function of some variable (as opposed to an expression)? Something like

dummy_x --> 

That makes it unnecessary to define a dummy default label.
Still, in the context of the module I'm not sure if what I'm saying makes
sense.


I have also another question. Can you give an example of usage. Something
like: What should I do to create a ket for a gaussian (or other
distribution) using your code and find the mean value of x?


And a note about style. I believe that default_label should be
_default_label as it's not used by the user.


Regards
Stefan

On 3 June 2011 23:07, Tomo Lazovich  wrote:

> Hi again,
>
> One of the results of these changes is a bit of a change in convention in
> the way that XKets are represented, and I'd like to make sure everyone
> agrees with this.
>
> Currently, the tests for cartesian.py say that if  x = Symbol('x'), then
> represent(XKet(x)) == x. With the new default labeling, though, the result
> of represent(XKet(x)) is the inner product , or DiracDelta(x-x_1).
> Does this seem reasonable to those who will be using this?
>
> Thanks!
>
> Tomo
>
>
> On Thu, Jun 2, 2011 at 9:43 PM, Tomo Lazovich wrote:
>
>> Hello everyone,
>>
>> I've been working on changing represent.py and related functions in
>> sympy.physics.quantum so that we can represent operators and states in
>> position and momentum bases. As a start to this, after discussion with Brian
>> and Ondrej, I started trying to build functions to give default labels to
>> states and operators, so that if we specify an arbitrary basis to represent
>> in, we know how to label the kets in which we are evaluating the
>> representation. A good example would be to have an arbitrary state |psi>,
>> which we want to represent in the position basis. We would want to take an
>> inner product like , so we want the XKet, and other kets (as well as
>> operators), to have a default label.
>>
>> A start for this is located in my represent branch, here:
>> https://github.com/lazovich/sympy/compare/represent. It includes a
>> modification to represent which tries to form an inner product to do the
>> representation if it can't find a _represent_BasisClass function.
>>
>> Any comments on what is there so far from those who are interested is
>> greatly appreciated. I'm sure I've made some sympy style flubs, so any
>> comments on that front as well would be very helpful.
>>
>> Thanks!
>>
>> Tomo
>>
>>
>>
>
>
> --
> Tomo Lazovich
> Harvard College '11
> 278 Winthrop House Mail Center
> Cambridge, MA 02138
>
>  --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: Some changes to representations in sympy.physics.quantum

[krastanov.ste...@gmail.com]

Hi,

I'll try to explain my first question. For the rest, I believe your response
was clear.

I would like to be able to have a ket, apply represent on it and get a
wavefunction (I'll call it wave_func ). To me it seems that what you have is
the expression wave_func(dummy_x) and not the function dummy_x -->
wave_func(dummy_x). In other words, your dummy_x is in the namespace and a
substitution must be applied.

Maybe I'm using some Maple jargon here but I hope it is nonetheless clear.

Again, I stress on the fact that I have not tried to use cartesian.py yet.
So maybe I'm missing the point.

Stefan

On 4 June 2011 15:50, Tomo Lazovich  wrote:

> Hi Stefan,
>
> Thanks for your comments! Some responses below:
>
> On Sat, Jun 4, 2011 at 5:42 AM, krastanov.ste...@gmail.com <
> krastanov.ste...@gmail.com> wrote:
>
>> Hi,
>>
>> It's quite probable that I just don't understand the logic behind
>> represent.py but I have a question here.
>> Shouldn't the representation of |ket> in the continuous basis X be a
>> function of some variable (as opposed to an expression)? Something like
>>
>> dummy_x --> 
>>
>> That makes it unnecessary to define a dummy default label.
>> Still, in the context of the module I'm not sure if what I'm saying makes
>> sense.
>>
>>
> I think I may be missing the point here, because I believe that this in
> fact what I have changed represent to be able to do. If we are trying to
> call represent() on some |ket> in a basis, we want to be able to take the
> inner product , as you suggest, and the default labeling
> scheme is how we are able to specify when we write a class for a specific
> ket what that dummy_var should be (x for a position basis, p for a momentum
> basis, etc.). I guess we could have some universal dummy variable rather
> than specifying them individually for each type of basis, but I think that
> if the default_label is specified it makes all of the notation a bit
> clearer.
>
>
>>
>> I have also another question. Can you give an example of usage. Something
>> like: What should I do to create a ket for a gaussian (or other
>> distribution) using your code and find the mean value of x?
>>
>>
> This is something that I don't think is possible with the current classes
> that exist in cartesian.py or other places. I think what would have to
> happen for this (and this is something that I will do once the code is a bit
> more developed) is to write a class like GaussianKet which does what you
> suggest, or implement a way to specify an arbitrary function for a ket. I
> may be missing something in the code though, because I am just modifying
> code originally written by Brian and others. Perhaps someone else can chime
> in here as well.
>
>
>>
>> And a note about style. I believe that default_label should be
>> _default_label as it's not used by the user.
>>
>
> Thank you for the style note! I am new to this, and I was wondering what
> the convention for the _ in the beginning was.
>
>
>>
>>
>> Regards
>> Stefan
>>
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: Some changes to representations in sympy.physics.quantum

[krastanov.ste...@gmail.com]

That's what I was saying and you are probably right that it is not the
intended use case. Anyhow, I would like to have an option like this down the
road (for wavefunctions, not for any inner product).

On 4 June 2011 21:23, Tomo Lazovich  wrote:

> Ah, I think I understand now. You are saying that, rather than simply being
> an expression with the dummy variable, it should actually be a function that
> could be evaluated at any arbitrary value?
>
> I'm not sure what the intended use case was, but I think that this is
> something that is a virtue of how innerproduct.py is implemented, not
> represent. The evaluated inner product is an expression rather than a
> function. Perhaps the author of innerproduct can comment on that.
>
>
> On Sat, Jun 4, 2011 at 11:38 AM, krastanov.ste...@gmail.com <
> krastanov.ste...@gmail.com> wrote:
>
>> Hi,
>>
>> I'll try to explain my first question. For the rest, I believe your
>> response was clear.
>>
>> I would like to be able to have a ket, apply represent on it and get a
>> wavefunction (I'll call it wave_func ). To me it seems that what you have is
>> the expression wave_func(dummy_x) and not the function dummy_x -->
>> wave_func(dummy_x). In other words, your dummy_x is in the namespace and a
>> substitution must be applied.
>>
>> Maybe I'm using some Maple jargon here but I hope it is nonetheless clear.
>>
>> Again, I stress on the fact that I have not tried to use cartesian.py yet.
>> So maybe I'm missing the point.
>>
>> Stefan
>>
>> On 4 June 2011 15:50, Tomo Lazovich  wrote:
>>
>>> Hi Stefan,
>>>
>>> Thanks for your comments! Some responses below:
>>>
>>> On Sat, Jun 4, 2011 at 5:42 AM, krastanov.ste...@gmail.com <
>>> krastanov.ste...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> It's quite probable that I just don't understand the logic behind
>>>> represent.py but I have a question here.
>>>> Shouldn't the representation of |ket> in the continuous basis X be a
>>>> function of some variable (as opposed to an expression)? Something like
>>>>
>>>> dummy_x --> 
>>>>
>>>> That makes it unnecessary to define a dummy default label.
>>>> Still, in the context of the module I'm not sure if what I'm saying
>>>> makes sense.
>>>>
>>>>
>>> I think I may be missing the point here, because I believe that this in
>>> fact what I have changed represent to be able to do. If we are trying to
>>> call represent() on some |ket> in a basis, we want to be able to take the
>>> inner product , as you suggest, and the default labeling
>>> scheme is how we are able to specify when we write a class for a specific
>>> ket what that dummy_var should be (x for a position basis, p for a momentum
>>> basis, etc.). I guess we could have some universal dummy variable rather
>>> than specifying them individually for each type of basis, but I think that
>>> if the default_label is specified it makes all of the notation a bit
>>> clearer.
>>>
>>>
>>>>
>>>> I have also another question. Can you give an example of usage.
>>>> Something like: What should I do to create a ket for a gaussian (or other
>>>> distribution) using your code and find the mean value of x?
>>>>
>>>>
>>> This is something that I don't think is possible with the current classes
>>> that exist in cartesian.py or other places. I think what would have to
>>> happen for this (and this is something that I will do once the code is a bit
>>> more developed) is to write a class like GaussianKet which does what you
>>> suggest, or implement a way to specify an arbitrary function for a ket. I
>>> may be missing something in the code though, because I am just modifying
>>> code originally written by Brian and others. Perhaps someone else can chime
>>> in here as well.
>>>
>>>
>>>>
>>>> And a note about style. I believe that default_label should be
>>>> _default_label as it's not used by the user.
>>>>
>>>
>>> Thank you for the style note! I am new to this, and I was wondering what
>>> the convention for the _ in the beginning was.
>>>
>>>
>>>>
>>>>
>>>> Regards
>>>> Stefan
>>>>
>>>>
>>>>  --
>>> You received this message 

Re: [sympy] Re: Question about representing full expressions in sympy.physics.quantum

[krastanov.ste...@gmail.com]

That remark is quite important. In the same spirit I would like to know if
there are any arguments for using an expression for the representation
instead of a function (the use of x_1 or x_dummy or whatever seems awkward
(personal opinion!)).

Maybe one such argument is that using a function instead of an expression
breaks the (possible) reuse of code between the implementation for discreet
and continuous bases. (I'm really shooting in the dark here!)

Anyhow, I would like to know what the others think about that. Using
functions seems more natural to me (no x_dummies for one).

Stefan

On 7 June 2011 21:41, Øyvind Jensen  wrote:

> I haven't dived into the quantum module, so I don't know how to answer
> your question.  But I think maybe it will be easier to find a good
> solution if you look at it from the other end.  What is it that you
> ultimately want to do?  What is the intended use of the function you
> are implementing?
>
> Øyvind
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: Adding sympy.physics to documentation

[krastanov.ste...@gmail.com]

What would the classical module contain? Won't "newtonian", "galilean"  or
just "mechanics" be more suitable in this case?

For example Hamiltonian mechanics applies to boot classical and quantum
physics. Also optics/thermodynamics/stat. phys./etc don't play well with
such separation.

Anyway, this can be changed later.

If you prepare the skeleton files I would be happy to go over the code and
document the parts that I use.

Stefan

On 7 June 2011 20:34, Luke  wrote:

> >> 1)  Should any of the code in sympy.physics be bundled into it's own
> >> submodule (similar to quantum and/or classical)?
> >
> > You could have either a 'physics' submodule and a 'classical'
> > subsubmodule, or a 'classical physics' and a 'quantum physics'
> > submodule. I don't really care either way, and this should be easy to
> > change later. The first one corresponds more to the (intended)
> > structure of the physics-related code.
>
> I think having a physics submodule with 'classical' and 'quantum'
> subsubmodules make sense.  I'll leave the other physics subsubmodules
> (units, matrices, hydrogen, etc.) where they are for now and if it
> makes sense to rearrange things, we can do that down the road.
>
> >
> >> 2)  Are there reasons this part of sympy has not been added to
> >> docs.sympy.org in the past (other than lack of time)?
> >
> > No, it should be there, it is just that noone yet made sure it's
> > generated correctly when building the docs.
> >
>
> I'll get started on this.
>
> ~Luke
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] Why is Symbol subclassed from Boolean?

[krastanov.ste...@gmail.com]

Why is it necessary?

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Why is Symbol subclassed from Boolean?

[krastanov.ste...@gmail.com]

On 8 June 2011 22:47, Haz  wrote:

> Think of it as a predicate -- it can be either true or false (hence
> boolean).
>
Why it needs to be true or false? I don't expect the x in sin(x) to be
boolean. What am I missing?


>  On Jun 8, 2011 4:41 PM, "krastanov.ste...@gmail.com" <
> krastanov.ste...@gmail.com> wrote:
> > Why is it necessary?
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "sympy" group.
> > To post to this group, send email to sympy@googlegroups.com.
> > To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: Why is Symbol subclassed from Boolean?

[krastanov.ste...@gmail.com]

On 9 June 2011 16:17, Vinzent Steinberg wrote:

> On 9 Jun., 00:04, Haz  wrote:
> > > Why it needs to be true or false? I don't expect the x in sin(x) to be
> > > boolean. What am I missing?
> >
> >   Nothing -- I misunderstood. Ronan may be able to shed some light:
> > -https://github.com/sympy/sympy/commit/635d89c3c53fd84cc884e0ab62dc3f0.
> ..
>
> Apparently Ronan basically moved the implementation from Basic to a
> different class. I think it makes sense to move it to BooleanSymbol.
> We have predicates implemented for our new assumption system, if
> anyone needs this.
>
> But on the other hand, it can be very expressive to apply boolean to
> general expressions. 0 would be false, everything else true. You could
> write things like
>
> a = x | y = x if x else y
>
It does not look very pythonic to me. And it's not very readable. But that's
just an opinion.


>
> Vinzent
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] working with the real/imaginary part of a symbolic expression

[krastanov.ste...@gmail.com]

Hi,

Short version of the question: How to take the real/imaginary part of a
symbolic expression? Can real(x + I*y) give me "x" with the proper
assumptions in place?


Here is the context:
I'm implementing a small gaussian optics module that I am going to need
during an internship. Here is my problem.

There is a thing called complex beam
parameterthat is
a complex number whose real part is a certain quantity describing
the beam and the imaginary part is another such quantity. The formalism
treats them together in this complex number.

I want to have a class with the constructor:

>>>a=Constructor(quantityA, quantityB)
>>>a == quantityA + I*quantityB
True

with the assumptions that quantityA and quantityB are real.

Then I want to have the selectors (@property decorators):

>>>a.quantA
quantityA
>>>q.quantB
quantityB

My idea was just to define quantA as real(a) but as far as what the
documentation or Google say there is no function "real" for a general
symbolic expression in sympy. I suppose I have missed something. Can I take
the real part of a general expression? Can real(x + I*y) give me "x" with
the proper assumptions in place?

Regars
Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Question about functions in sympy

[krastanov.ste...@gmail.com]

On 10 June 2011 01:13, Mateusz Paprocki  wrote:

> Hi,
>
> On 9 June 2011 16:05, Tomo Lazovich  wrote:
>
>> Hi everyone,
>>
>> I'm thinking of implementing a Wavefunction class in
>> sympy.physics.quantum, and as a start I'm wondering about functions in sympy
>> in general. Disclaimer is that this is a potentially very noobish question.
>>
>> Is there already a way in sympy to define an arbitrary functional form?
>> I.e. to be able to easily say something like f(x) = x**2 and then evaluate
>> f(2) or whatever else you'd like to do.
>>
>
> The simplest way is to use Lambda:
>
> In [1]: f = Lambda(x, x**2)
>
> In [2]: f(2)
> Out[2]: 4
>
> You can also define your own (named) function (I mean subclass Function and
> provide eval() class method), but this may be unnecessary.
>
> How robust is this if I want to define a multivariable function? Is it done
anywhere in sympy?


>
>> Apologies if this is obvious!
>>
>> Tomo
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to sympy@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sympy?hl=en.
>>
>
> Mateusz
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] working with the real/imaginary part of a symbolic expression

[krastanov.ste...@gmail.com]

What about re(1/(x+I*y))? It does not evaluate. Is there a function that I
should call before re() so I have something with real denominator?

On 10 June 2011 01:39, Aaron Meurer  wrote:

> To assume that x is real, define it like
>
> x = Symbol('x', real=True)
>
> Then you can use the functions re() and im(), or the method
> .as_real_imag() to get the real and imaginary parts.
>
> In [1]: x, y = symbols('x y', real=True)
>
> In [2]: (x + I*y).as_real_imag()
> Out[2]: (x, y)
>
> In [3]: re(x + I*y)
> Out[3]: x
>
> In [4]: im(x + I*y)
> Out[4]: y
>
> Aaron Meurer
>
> On Thu, Jun 9, 2011 at 4:31 PM, krastanov.ste...@gmail.com
>  wrote:
> > Hi,
> >
> > Short version of the question: How to take the real/imaginary part of a
> > symbolic expression? Can real(x + I*y) give me "x" with the proper
> > assumptions in place?
> >
> >
> > Here is the context:
> > I'm implementing a small gaussian optics module that I am going to need
> > during an internship. Here is my problem.
> >
> > There is a thing called complex beam parameter that is a complex number
> > whose real part is a certain quantity describing the beam and the
> imaginary
> > part is another such quantity. The formalism treats them together in this
> > complex number.
> >
> > I want to have a class with the constructor:
> >
> >>>>a=Constructor(quantityA, quantityB)
> >>>>a == quantityA + I*quantityB
> > True
> >
> > with the assumptions that quantityA and quantityB are real.
> >
> > Then I want to have the selectors (@property decorators):
> >
> >>>>a.quantA
> > quantityA
> >>>>q.quantB
> > quantityB
> >
> > My idea was just to define quantA as real(a) but as far as what the
> > documentation or Google say there is no function "real" for a general
> > symbolic expression in sympy. I suppose I have missed something. Can I
> take
> > the real part of a general expression? Can real(x + I*y) give me "x" with
> > the proper assumptions in place?
> >
> > Regars
> > Stefan
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "sympy" group.
> > To post to this group, send email to sympy@googlegroups.com.
> > To unsubscribe from this group, send email to
> > sympy+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/sympy?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] working with the real/imaginary part of a symbolic expression

[krastanov.ste...@gmail.com]

I have found it. For future reference it's
complicated_expression.expand(complex=True).

On 10 June 2011 01:54, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> What about re(1/(x+I*y))? It does not evaluate. Is there a function that I
> should call before re() so I have something with real denominator?
>
>
> On 10 June 2011 01:39, Aaron Meurer  wrote:
>
>> To assume that x is real, define it like
>>
>> x = Symbol('x', real=True)
>>
>> Then you can use the functions re() and im(), or the method
>> .as_real_imag() to get the real and imaginary parts.
>>
>> In [1]: x, y = symbols('x y', real=True)
>>
>> In [2]: (x + I*y).as_real_imag()
>> Out[2]: (x, y)
>>
>> In [3]: re(x + I*y)
>> Out[3]: x
>>
>> In [4]: im(x + I*y)
>> Out[4]: y
>>
>> Aaron Meurer
>>
>> On Thu, Jun 9, 2011 at 4:31 PM, krastanov.ste...@gmail.com
>>  wrote:
>> > Hi,
>> >
>> > Short version of the question: How to take the real/imaginary part of a
>> > symbolic expression? Can real(x + I*y) give me "x" with the proper
>> > assumptions in place?
>> >
>> >
>> > Here is the context:
>> > I'm implementing a small gaussian optics module that I am going to need
>> > during an internship. Here is my problem.
>> >
>> > There is a thing called complex beam parameter that is a complex number
>> > whose real part is a certain quantity describing the beam and the
>> imaginary
>> > part is another such quantity. The formalism treats them together in
>> this
>> > complex number.
>> >
>> > I want to have a class with the constructor:
>> >
>> >>>>a=Constructor(quantityA, quantityB)
>> >>>>a == quantityA + I*quantityB
>> > True
>> >
>> > with the assumptions that quantityA and quantityB are real.
>> >
>> > Then I want to have the selectors (@property decorators):
>> >
>> >>>>a.quantA
>> > quantityA
>> >>>>q.quantB
>> > quantityB
>> >
>> > My idea was just to define quantA as real(a) but as far as what the
>> > documentation or Google say there is no function "real" for a general
>> > symbolic expression in sympy. I suppose I have missed something. Can I
>> take
>> > the real part of a general expression? Can real(x + I*y) give me "x"
>> with
>> > the proper assumptions in place?
>> >
>> > Regars
>> > Stefan
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "sympy" group.
>> > To post to this group, send email to sympy@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > sympy+unsubscr...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/sympy?hl=en.
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to sympy@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sympy?hl=en.
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] working with the real/imaginary part of a symbolic expression

[krastanov.ste...@gmail.com]

Thanks for the details!

On 10 June 2011 02:00, Aaron Meurer  wrote:

> So, the way that re() and im() are currently implemented, they do not
> do evaluation.  You should use .as_real_imag() instead.  However, I
> think this should change.  See
> http://code.google.com/p/sympy/issues/detail?id=754#c15.
>
> Aaron Meurer
>
> On Thu, Jun 9, 2011 at 5:54 PM, krastanov.ste...@gmail.com
>  wrote:
> > What about re(1/(x+I*y))? It does not evaluate. Is there a function that
> I
> > should call before re() so I have something with real denominator?
> >
> > On 10 June 2011 01:39, Aaron Meurer  wrote:
> >>
> >> To assume that x is real, define it like
> >>
> >> x = Symbol('x', real=True)
> >>
> >> Then you can use the functions re() and im(), or the method
> >> .as_real_imag() to get the real and imaginary parts.
> >>
> >> In [1]: x, y = symbols('x y', real=True)
> >>
> >> In [2]: (x + I*y).as_real_imag()
> >> Out[2]: (x, y)
> >>
> >> In [3]: re(x + I*y)
> >> Out[3]: x
> >>
> >> In [4]: im(x + I*y)
> >> Out[4]: y
> >>
> >> Aaron Meurer
> >>
> >> On Thu, Jun 9, 2011 at 4:31 PM, krastanov.ste...@gmail.com
> >>  wrote:
> >> > Hi,
> >> >
> >> > Short version of the question: How to take the real/imaginary part of
> a
> >> > symbolic expression? Can real(x + I*y) give me "x" with the proper
> >> > assumptions in place?
> >> >
> >> >
> >> > Here is the context:
> >> > I'm implementing a small gaussian optics module that I am going to
> need
> >> > during an internship. Here is my problem.
> >> >
> >> > There is a thing called complex beam parameter that is a complex
> number
> >> > whose real part is a certain quantity describing the beam and the
> >> > imaginary
> >> > part is another such quantity. The formalism treats them together in
> >> > this
> >> > complex number.
> >> >
> >> > I want to have a class with the constructor:
> >> >
> >> >>>>a=Constructor(quantityA, quantityB)
> >> >>>>a == quantityA + I*quantityB
> >> > True
> >> >
> >> > with the assumptions that quantityA and quantityB are real.
> >> >
> >> > Then I want to have the selectors (@property decorators):
> >> >
> >> >>>>a.quantA
> >> > quantityA
> >> >>>>q.quantB
> >> > quantityB
> >> >
> >> > My idea was just to define quantA as real(a) but as far as what the
> >> > documentation or Google say there is no function "real" for a general
> >> > symbolic expression in sympy. I suppose I have missed something. Can I
> >> > take
> >> > the real part of a general expression? Can real(x + I*y) give me "x"
> >> > with
> >> > the proper assumptions in place?
> >> >
> >> > Regars
> >> > Stefan
> >> >
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups
> >> > "sympy" group.
> >> > To post to this group, send email to sympy@googlegroups.com.
> >> > To unsubscribe from this group, send email to
> >> > sympy+unsubscr...@googlegroups.com.
> >> > For more options, visit this group at
> >> > http://groups.google.com/group/sympy?hl=en.
> >> >
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups
> >> "sympy" group.
> >> To post to this group, send email to sympy@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> sympy+unsubscr...@googlegroups.com.
> >> For more options, visit this group at
> >> http://groups.google.com/group/sympy?hl=en.
> >>
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "sympy" group.
> > To post to this group, send email to sympy@googlegroups.com.
> > To unsubscribe from this group, send email to
> > sympy+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/sympy?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] __slots__ don't work if subclassing from Add

[krastanov.ste...@gmail.com]

Hi,

I am trying to create a class that is basically the sum of two arguments
given in the constructor. Here is what I have done (simplified example with
omitted arguments and slots):

class BeamParameter(Add):

__slots__ = ['x', 'y']

def __new__(cls, x, y):
obj = Add.__new__(cls, x, I*y)
obj.x = x
obj.y = y
return obj


It works ok when Add returns Add:
>>>q=BeamParameter(1,1)
>>>q
1+I*1

But it fails when Add returns Mul:
>>>q=BeamParameter(0,1)
---> 54 obj.x = x
AttributeError: 'Mul' object has no attribute 'x'


The __slots__ are lost somewhere for some reason. I'm afraid that I don't
understand why. Maybe I should not use Add as a superclass. Do you have any
solutions?

Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] bug in pyglet, please update

[krastanov.ste...@gmail.com]

I have no ploting at all.

There is a bug in pyglet (under Ubuntu):
http://code.google.com/p/sympy/issues/detail?id=2474

Would just unpacking the latest tar over the current files be sufficient?
Should I do it and send a pull request or a more involved process is
required?

Also it will be best if pyglet is just an external dependency. See
http://code.google.com/p/sympy/issues/detail?id=2144. Would this be too much
work?

Regards
Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] __slots__ don't work if subclassing from Add

[krastanov.ste...@gmail.com]

BeamParameter should be just a complex number. As there is no Complex class
in sympy I have tried to base it on Add.

I need some additional fields and methods to implement the formalism, but if
BeamParameter returns complex number created from the two arguments in the
constructor the rest is easy.

The nested example you gave should return x+I*y+I*z. This is complete
nonsense from physical point of view, but the user is free to do it.

I have tried to do it without __slots__ and __new__ and use __init__ instead
but then isinstance(q, BeamParameter) returns False. I have no idea why it's
not True?


On 10 June 2011 22:34, Aaron Meurer  wrote:

> I'm not the best person to answer this, but probably you are doing
> this the wrong way.

I'm pretty sure you are right about me being wrong :)


>  I suppose to know how you should do it, I would
> need to know more about how you expect this class to work.  What do
> you expect BeamParamter(0, 1) to return?  How about
> BeamParameter(BeamParameter(x, y), z) (nested classes)?
>
> Aaron Meurer
>
> On Fri, Jun 10, 2011 at 12:10 PM, krastanov.ste...@gmail.com
>  wrote:
> > Hi,
> >
> > I am trying to create a class that is basically the sum of two arguments
> > given in the constructor. Here is what I have done (simplified example
> with
> > omitted arguments and slots):
> >
> > class BeamParameter(Add):
> >
> > __slots__ = ['x', 'y']
> >
> > def __new__(cls, x, y):
> > obj = Add.__new__(cls, x, I*y)
> > obj.x = x
> > obj.y = y
> > return obj
> >
> >
> > It works ok when Add returns Add:
> >>>>q=BeamParameter(1,1)
> >>>>q
> > 1+I*1
> >
> > But it fails when Add returns Mul:
> >>>>q=BeamParameter(0,1)
> > ---> 54 obj.x = x
> > AttributeError: 'Mul' object has no attribute 'x'
> >
> >
> > The __slots__ are lost somewhere for some reason. I'm afraid that I don't
> > understand why. Maybe I should not use Add as a superclass. Do you have
> any
> > solutions?
> >
> > Stefan
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "sympy" group.
> > To post to this group, send email to sympy@googlegroups.com.
> > To unsubscribe from this group, send email to
> > sympy+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/sympy?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] __slots__ don't work if subclassing from Add

[krastanov.ste...@gmail.com]

Here is a workaround that I dislike (but it works):

class BeamParameter(Expr):

__slots__ = ['z', 'z_r']

def __new__(cls, z, z_r):
inst = Expr.__new__(cls, z, z_r)
inst.z = z
inst.z_r = z_r
return inst

@property
def q(self):
return self.z+I*self.z_r

Now I can do:
>>>bp = BeamParameter(1,2)
>>>bp.q
1+I*2

But I would like to have:
>>>bp
1+I*2


On 10 June 2011 23:06, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> BeamParameter should be just a complex number. As there is no Complex class
> in sympy I have tried to base it on Add.
>
> I need some additional fields and methods to implement the formalism, but
> if BeamParameter returns complex number created from the two arguments in
> the constructor the rest is easy.
>
> The nested example you gave should return x+I*y+I*z. This is complete
> nonsense from physical point of view, but the user is free to do it.
>
> I have tried to do it without __slots__ and __new__ and use __init__
> instead but then isinstance(q, BeamParameter) returns False. I have no idea
> why it's not True?
>
>
> On 10 June 2011 22:34, Aaron Meurer  wrote:
>
>> I'm not the best person to answer this, but probably you are doing
>> this the wrong way.
>
> I'm pretty sure you are right about me being wrong :)
>
>
>>  I suppose to know how you should do it, I would
>> need to know more about how you expect this class to work.  What do
>> you expect BeamParamter(0, 1) to return?  How about
>> BeamParameter(BeamParameter(x, y), z) (nested classes)?
>>
>> Aaron Meurer
>>
>> On Fri, Jun 10, 2011 at 12:10 PM, krastanov.ste...@gmail.com
>>  wrote:
>> > Hi,
>> >
>> > I am trying to create a class that is basically the sum of two arguments
>> > given in the constructor. Here is what I have done (simplified example
>> with
>> > omitted arguments and slots):
>> >
>> > class BeamParameter(Add):
>> >
>> > __slots__ = ['x', 'y']
>> >
>> > def __new__(cls, x, y):
>> > obj = Add.__new__(cls, x, I*y)
>> > obj.x = x
>> > obj.y = y
>> > return obj
>> >
>> >
>> > It works ok when Add returns Add:
>> >>>>q=BeamParameter(1,1)
>> >>>>q
>> > 1+I*1
>> >
>> > But it fails when Add returns Mul:
>> >>>>q=BeamParameter(0,1)
>> > ---> 54 obj.x = x
>> > AttributeError: 'Mul' object has no attribute 'x'
>> >
>> >
>> > The __slots__ are lost somewhere for some reason. I'm afraid that I
>> don't
>> > understand why. Maybe I should not use Add as a superclass. Do you have
>> any
>> > solutions?
>> >
>> > Stefan
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "sympy" group.
>> > To post to this group, send email to sympy@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > sympy+unsubscr...@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/sympy?hl=en.
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to sympy@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sympy?hl=en.
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] bug in pyglet, please update

[krastanov.ste...@gmail.com]

I started moving pyglet to an external dependency. I have some other stuff
to do, but expect a pull request at the end of the day. I hope that there
wont be any unforeseen problems. For the moment I'm just doing

grep "import_thirdparty" -r .

and commenting it. I'll also add import error catching.

On 11 June 2011 03:39, Aaron Meurer  wrote:

> On Fri, Jun 10, 2011 at 2:58 PM, krastanov.ste...@gmail.com
>  wrote:
> > I have no ploting at all.
>
> You're not the only one :)
>
> >
> > There is a bug in pyglet (under Ubuntu):
> > http://code.google.com/p/sympy/issues/detail?id=2474
> >
> > Would just unpacking the latest tar over the current files be sufficient?
> > Should I do it and send a pull request or a more involved process is
> > required?
> >
> > Also it will be best if pyglet is just an external dependency. See
> > http://code.google.com/p/sympy/issues/detail?id=2144. Would this be too
> much
> > work?
> >
> > Regards
> > Stefan
> >
> > --
>
> I honestly don't know which of these would be easier to do.  Making
> Pyglet an external dependency would be preferred.  That might just
> require fixing some imports and updating some documentation, but I
> couldn't say for sure unless it was tried.
>
> Aaron Meurer
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] bug in pyglet, please update

[krastanov.ste...@gmail.com]

The pull request is in. It works for me and it is fairly trivial, but there
is always the possibility of side effects.

https://github.com/sympy/sympy/pull/406

Stefan

On 11 June 2011 11:50, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> I started moving pyglet to an external dependency. I have some other stuff
> to do, but expect a pull request at the end of the day. I hope that there
> wont be any unforeseen problems. For the moment I'm just doing
>
> grep "import_thirdparty" -r .
>
> and commenting it. I'll also add import error catching.
>
>
> On 11 June 2011 03:39, Aaron Meurer  wrote:
>
>> On Fri, Jun 10, 2011 at 2:58 PM, krastanov.ste...@gmail.com
>>  wrote:
>> > I have no ploting at all.
>>
>> You're not the only one :)
>>
>> >
>> > There is a bug in pyglet (under Ubuntu):
>> > http://code.google.com/p/sympy/issues/detail?id=2474
>> >
>> > Would just unpacking the latest tar over the current files be
>> sufficient?
>> > Should I do it and send a pull request or a more involved process is
>> > required?
>> >
>> > Also it will be best if pyglet is just an external dependency. See
>> > http://code.google.com/p/sympy/issues/detail?id=2144. Would this be too
>> much
>> > work?
>> >
>> > Regards
>> > Stefan
>> >
>> > --
>>
>> I honestly don't know which of these would be easier to do.  Making
>> Pyglet an external dependency would be preferred.  That might just
>> require fixing some imports and updating some documentation, but I
>> couldn't say for sure unless it was tried.
>>
>> Aaron Meurer
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to sympy@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sympy?hl=en.
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] SymPy 0.7.0 Release Candidate 1

[krastanov.ste...@gmail.com]

On 12 June 2011 16:07, Tomo Lazovich  wrote:

> I tested the Windows installer in Windows 7. You have to be sure to run the
> installer as an administrator or it complains that it can't set some
> registry keys. Besides that, it seems to have installed without any
> problems.  Is it possible to run the tests in Windows? I can't seem to find
> the setup.py file.
>
> On Sun, Jun 12, 2011 at 6:23 AM, David Joyner  wrote:
>
>> On Sun, Jun 12, 2011 at 1:48 AM, Aaron Meurer  wrote:
>>
>> ...
>>
>> > Please test these distributions.  All tests should pass with Python
>> > 2.4-2.7, both 32- and 64-bit, and with gmpy installed or not
>> > installed.  Please test that this is the case from the tarballed
>> > distributions themselves by running
>> >
>> > ./setup.py --prefix= install
>> >
>> > From the unpacked tarballs, and running the tests from that prefixed
>> > path.  You can also run sandboxes tests using tox.
>> >
>>
>> On a mac OS 10.6.7, I ran
>>
>> ./setup.py install
>> ./setup.py test
>>
>> with no problems. The --prefix option was not recognized.
>> The system Python for 10.6.7 is 2.7.
>>
> The --prefix command is not recognized and it's not present in --help.

>
>>
>> >
>> > Aaron Meurer
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups "sympy" group.
>> > To post to this group, send email to sympy@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> > For more options, visit this group at
>> http://groups.google.com/group/sympy?hl=en.
>> >
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to sympy@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sympy?hl=en.
>>
>>
>
>
> --
> Tomo Lazovich
> Harvard College '11
> 278 Winthrop House Mail Center
> Cambridge, MA 02138
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Problem with evaluating rotation operator

[krastanov.ste...@gmail.com]

Hi,

Did you noticed that in master qapply(Jx*JxKet(...)) does not evaluate to
...*hbar*JxKet. Jz*JzKet evaluates as expected but not the other two base
kets. Maybe it has nothing to do with your problem, but as you are rewriting
operators and states it may intervene.

Also concerning the printing see below.

Stefan

On 16 June 2011 09:04, Sean Vig  wrote:

> Hi all,
>
> In working on some stuff with spin states, I ran into some problems with
> the current implementation of the Wigner small-d matrix, Rotation.d in
> sympy.physics.quantum.spin. I had written methods to change bases using the
> Wigner D-function [0] and in testing decided to try
> >>>qapply(JzBra(1,1)*JzKet(1,1).rewrite('Jx'))
> which should be 1, as the spin ket is rewritten in the Jx basis and then
> back to the Jz basis to apply the innerproduct, but I have that it gives 0.
> I traced this back to a bug in the Rotation.d function, which currently has
> an open issue [1]. For the Wigner D-function and the small d-matrix, the
> conventions laid out in Varshalovich "Quantum Theory of Angular Momentum".
> It seems the d-matrix is fine for positive values of angle argument, but
> does not obey the symmetry d(j,m,mp,-beta)=(-1)**(m-mp)*d(j,m,mp,beta) and
> does not agree with the tables in Varshalovich. Those terms that fail for
> the j=1 case are in an XFAIL test in my branch. What is odd is that when I
> ran the equation used to define the d-matrix through Mathematica, I got
> results that agreed with the sympy output, so the problem may be in the
> equation and not a bug in the code. If anyone could take a look at that, I'd
> appreciate it.
>
> The function in question is the Rotation.D function, which is invoked as:
> >>>Rotation.D(j, m, mp, alpha, beta, gamma)
> where alpha, beta, gamma are the Euler angles of the rotation, expressed as
> a passive transformation, and j,m,mp satisfy: 
> for the rotation operator R. The D-function invokes the small d-function,
> which is done as:
> >>>Rotation.d(j, m, mp, beta)
>
>
> Another thing is even if the right values were given, my methods would not
> give the right results. Comparing to [2], when I rewrite a Jx ket in the Jz
> basis, it gives the wrong result, the signs on the terms that appear in
> JzKet(1,0).rewrite("Jx") are switched. This is likely me messing up the
> Euler angles or the invoking of the D-function. What is implemented is
> rewrite, which rewrites states in terms of a new basis. For example, we
> would expect:
> >>>JzKet(1, 0).rewrite("Jx")
> sqrt(2)/2*|1, 1>-sqrt(2)/2*|1, -1>
> Note that the output kets are JxKet's, the printing of this is currently
> ambiguous.
>

Concerning the printing you can see what I propose here
https://github.com/sympy/sympy/pull/186 This pull request is a mess. I
should squash many of the commits, but the diffs are clear.


> >>>from sympy.physics.quantum.innerproduct import InnerProduct
> >>>Innerproduct(JxBra(1,1), JzKet(1,0)).doit()
> sqrt(2)/2*|1, 1>
> Both of these functions, however, rely on represent, which gives the
> transformed state as a vector in terms of the basis elements of the new
> basis, so
> >>>from sympy.physics.quantum.represent import represent
> >>>represent(JzKet(1,0), basis=Jx)
> [ sqrt(2)/2]
> [ 0]
> [-sqrt(2)/2]
> Represent invokes Note that the statement from
> above, qapply(JzBra(1,1)*JzKet(1,1).rewrite('Jx')), qapply automatically
> turns the multiplication into an innerproduct and evaluates it. Tomorrow
> morning, I'll be putting in some docstrings to make the usage of this clear
> and opening a pull request for this branch, any review as to the
> implementation of the Wigner D-function would be a great help.
>
> Let me know if you have any questions or see any issues. Thanks.
>
> Sean
>
> [0] https://github.com/flacjacket/sympy/tree/xyz_bases
> [1] http://code.google.com/p/sympy/issues/detail?id=2423
> [2]
> http://www.chem.ucsb.edu/coursepages/11spring/226-Metiu/dl/115A%20Course%20Notes/Ch11_Angular_20Nov09.pdf
>  page
> 23
>
>  --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] Should unicode characters be used in the code?

[krastanov.ste...@gmail.com]

Certain tests pass if unicode characters are escaped (like in u"\") but
do not pass if the character is written in unicode (like u"Ф"). For examples
see the tests that fail in the branch quantum_printing.

Those test pass if they are run in python, fail in ipython (there is a bug
in ipython
http://stackoverflow.com/questions/5860713/ipython-unicode-in-gnome-terminal-linux)
and fail in sympy-bot (I don't know why). They pass if the characters are
escaped.

My questions is not how to write the test that I gave as an example - they
will be rewritten with escaped characters. The question is should I use
unicode characters (that should be supported by the language) even when some
tools seem to have problems with them? To me it seems a bad idea always to
escape characters - the tests become unreadable.

Regards
Stefan

P.S. # -*- encoding: utf-8 -*- was present when the tests failed

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Should unicode characters be used in the code?

[krastanov.ste...@gmail.com]

2011/6/20 Mateusz Paprocki 

> Hi,
>
> 2011/6/20 krastanov.ste...@gmail.com 
>
> Certain tests pass if unicode characters are escaped (like in u"\") but
>> do not pass if the character is written in unicode (like u"Ф"). For examples
>> see the tests that fail in the branch quantum_printing.
>>
>> Those test pass if they are run in python, fail in ipython (there is a bug
>> in ipython
>> http://stackoverflow.com/questions/5860713/ipython-unicode-in-gnome-terminal-linux)
>> and fail in sympy-bot (I don't know why). They pass if the characters are
>> escaped.
>>
>
> How did you run those tests in IPython? I tried your branch both in Python
> (2.6.6) and IPython and all run fine. I used this:
>
> In [1]: from sympy.utilities.runtests import test
>
> In [2]: test("sympy/physics")
> (...)
>
> to run tests under IPython.
>
>

I used ./bin/test - the tests passed. Then I copied the assert statements
(with all the necessary imports and definitions) in both ipython 0.10 and
python 2.7. They worked in python but not in ipython (the unicode strings
were badly parsed).

When running them by using test("sympy/physics") they both pass.


>
>> My questions is not how to write the test that I gave as an example - they
>> will be rewritten with escaped characters. The question is should I use
>> unicode characters (that should be supported by the language) even when some
>> tools seem to have problems with them? To me it seems a bad idea always to
>> escape characters - the tests become unreadable.
>>
>
> Do you experience any problems with tests in sympy.printing.pretty? If not
> then you should follow *exactly* the approach in pretty and you should be on
> the safe side. I see that you implemented printers for physics module
> outside sympy.printing. What it the rationale for this?
>

The printers (actually they are not new printers, just overridden methods)
were already implemented when I started working on them. So I can not give a
rationale for them being done outside sympy.printing (Actually I have no
idea how else those can be done. As I said, it's just overridden methods). I
only refactored them so they can be used more easily.

But there is one tangential question I would like to ask, Mateusz. Should I
move all the printing *tests* to sympy.printing. If so, I was completely
ignorant of this practice and I apologize.


>  I would create mixin classes for repr, str, pretty and latex with
> appropriate printing methods and add those classes as basses to appropriate
> printers. This way, you will have to make sure that Unicode is setup
> properly only in one or two files, not n >> 2.
>
> I would also use U() function from pretty_symbology.py, to make sure that
> Unicode character you use is actually globally available. U() will give you
> None if given character (which you will specify by Unicode name) belongs to
> the standard or not. It often happens that on a certain platform you can get
> more Unicode symbols, but they aren't available elsewhere.
>
>
>>
>> Regards
>> Stefan
>>
>> P.S. # -*- encoding: utf-8 -*- was present when the tests failed
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to sympy@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sympy?hl=en.
>>
>
> Mateusz
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Should unicode characters be used in the code?

[krastanov.ste...@gmail.com]

The tests that I have written follow this separation but only by chance. On
the other hand (with that new knowledge) it seems that they are very badly
structured.

Thankfully it seems that the code that is tested is not affected at all.
Only the structure of the tests.

I'm really grateful for those explications. Thanks.

Stefan


2011/6/21 Aaron Meurer 

> I think all the quantum printing code and test should remain in
> physics.  The reason is that physics is supposed to be an isolated
> module.  The module shouldn't be imported at all with "import sympy"
> or "from sympy import *". If you put the code in printing, then it
> will cause the physics module to be imported with the printing module.
>  There are ways around that, but to me, it makes the most sense to put
> the quantum printing code in the quantum module for this reason.  And
> the tests should go there too for the same reason.
>
> Even so, you should follow exactly the procedure in the
> test_pretty.py.  Perhaps it would be easier to put all the quantum
> printing tests in a single test_quantum_pretty.py file.  Then just
> copy things as they are in test_pretty.py (including the unicode
> coding comment at the top of the file).
>
> By the way, I don't know to what degree the current code actually
> follows what I said above.  But if physics code is in other modules,
> it should probably be moved into the physics module.
>
> Aaron Meurer
>
> 2011/6/20 krastanov.ste...@gmail.com :
> >
> >
> > 2011/6/20 Mateusz Paprocki 
> >>
> >> Hi,
> >>
> >> 2011/6/20 krastanov.ste...@gmail.com 
> >>>
> >>> Certain tests pass if unicode characters are escaped (like in u"\")
> >>> but do not pass if the character is written in unicode (like u"Ф"). For
> >>> examples see the tests that fail in the branch quantum_printing.
> >>>
> >>> Those test pass if they are run in python, fail in ipython (there is a
> >>> bug in ipython
> >>>
> http://stackoverflow.com/questions/5860713/ipython-unicode-in-gnome-terminal-linux
> )
> >>> and fail in sympy-bot (I don't know why). They pass if the characters
> are
> >>> escaped.
> >>
> >> How did you run those tests in IPython? I tried your branch both in
> Python
> >> (2.6.6) and IPython and all run fine. I used this:
> >> In [1]: from sympy.utilities.runtests import test
> >> In [2]: test("sympy/physics")
> >> (...)
> >> to run tests under IPython.
> >>
> >
> > I used ./bin/test - the tests passed. Then I copied the assert statements
> > (with all the necessary imports and definitions) in both ipython 0.10 and
> > python 2.7. They worked in python but not in ipython (the unicode strings
> > were badly parsed).
> >
> > When running them by using test("sympy/physics") they both pass.
> >
> >>>
> >>> My questions is not how to write the test that I gave as an example -
> >>> they will be rewritten with escaped characters. The question is should
> I use
> >>> unicode characters (that should be supported by the language) even when
> some
> >>> tools seem to have problems with them? To me it seems a bad idea always
> to
> >>> escape characters - the tests become unreadable.
> >>
> >> Do you experience any problems with tests in sympy.printing.pretty? If
> not
> >> then you should follow *exactly* the approach in pretty and you should
> be on
> >> the safe side. I see that you implemented printers for physics module
> >> outside sympy.printing. What it the rationale for this?
> >
> > The printers (actually they are not new printers, just overridden
> methods)
> > were already implemented when I started working on them. So I can not
> give a
> > rationale for them being done outside sympy.printing (Actually I have no
> > idea how else those can be done. As I said, it's just overridden
> methods). I
> > only refactored them so they can be used more easily.
> >
> > But there is one tangential question I would like to ask, Mateusz. Should
> I
> > move all the printing *tests* to sympy.printing. If so, I was completely
> > ignorant of this practice and I apologize.
> >
> >>
> >> I would create mixin classes for repr, str, pretty and latex with
> >> appropriate printing methods and add those classes as basses to
> appropriate
> >> printers. This way, you will have to make sure that Unicode is setup
> >> properly only in one or t

Re: [sympy] Should unicode characters be used in the code?

[krastanov.ste...@gmail.com]

So I suppose the whole printing of physics.quantum must be refactored. Maybe
I'm capable of doing that, but before thinking about it I prefer to refactor
the tests and get the current pull request in as I see it as an improvement.

Should I pursue this or you think it's better to scrap the pull request and
start working on the implementation of PhysicsPrettyPrinter?

Stefan

On 21 June 2011 10:00, Aaron Meurer  wrote:

> 2011/6/21 Mateusz Paprocki :
> > Hi,
> >
> > 2011/6/20 krastanov.ste...@gmail.com 
> >>
> >>
> >> 2011/6/20 Mateusz Paprocki 
> >>>
> >>> Hi,
> >>>
> >>> 2011/6/20 krastanov.ste...@gmail.com 
> >>>>
> >>>> Certain tests pass if unicode characters are escaped (like in
> u"\")
> >>>> but do not pass if the character is written in unicode (like u"Ф").
> For
> >>>> examples see the tests that fail in the branch quantum_printing.
> >>>>
> >>>> Those test pass if they are run in python, fail in ipython (there is a
> >>>> bug in ipython
> >>>>
> http://stackoverflow.com/questions/5860713/ipython-unicode-in-gnome-terminal-linux
> )
> >>>> and fail in sympy-bot (I don't know why). They pass if the characters
> are
> >>>> escaped.
> >>>
> >>> How did you run those tests in IPython? I tried your branch both in
> >>> Python (2.6.6) and IPython and all run fine. I used this:
> >>> In [1]: from sympy.utilities.runtests import test
> >>> In [2]: test("sympy/physics")
> >>> (...)
> >>> to run tests under IPython.
> >>>
> >>
> >> I used ./bin/test - the tests passed. Then I copied the assert
> statements
> >> (with all the necessary imports and definitions) in both ipython 0.10
> and
> >> python 2.7. They worked in python but not in ipython (the unicode
> strings
> >> were badly parsed).
> >>
> >> When running them by using test("sympy/physics") they both pass.
> >
> > If this is caused by a bug in IPython, then I wouldn't bother "fixing"
> this
> > in SymPy, which (as you already mentioned) would lead to unreadable tests
> > (imagine reading test_pretty.py with \u escape sequences instead of
> Unicode
> > characters), because most likely it will be fixed in 0.11. Can you show
> > which tests fail for you? (it will save us time reproducing your work)
> >
> >>
> >>
> >>>>
> >>>> My questions is not how to write the test that I gave as an example -
> >>>> they will be rewritten with escaped characters. The question is should
> I use
> >>>> unicode characters (that should be supported by the language) even
> when some
> >>>> tools seem to have problems with them? To me it seems a bad idea
> always to
> >>>> escape characters - the tests become unreadable.
> >>>
> >>> Do you experience any problems with tests in sympy.printing.pretty? If
> >>> not then you should follow *exactly* the approach in pretty and you
> should
> >>> be on the safe side. I see that you implemented printers for physics
> module
> >>> outside sympy.printing. What it the rationale for this?
> >>
> >> The printers (actually they are not new printers, just overridden
> methods)
> >> were already implemented when I started working on them. So I can not
> give a
> >> rationale for them being done outside sympy.printing (Actually I have no
> >> idea how else those can be done. As I said, it's just overridden
> methods). I
> >> only refactored them so they can be used more easily.
> >>
> >> But there is one tangential question I would like to ask, Mateusz.
> Should
> >> I move all the printing *tests* to sympy.printing. If so, I was
> completely
> >> ignorant of this practice and I apologize.
> >
> > Actually I was unaware that our printing subsystem allows to use printer
> > implementation from non-printer classes. It's reasonable to have physics
> > printers in sympy.physics but it would be also useful to have printing
> > detached from logic. Logic doesn't change that often but different people
> > use different notations, so those who dislike the default notation used
> in
> > SymPy may want to easily change this. Currently the only way to change
> the
> > notation is to subclass selected classes from sympy.physics. It would be
> > much easi

[sympy] issues to be closed

[krastanov.ste...@gmail.com]

Hi

Issues
2144 http://code.google.com/p/sympy/issues/detail?id=2144
2474 http://code.google.com/p/sympy/issues/detail?id=2474
and maybe (just maybe!)
1867 http://code.google.com/p/sympy/issues/detail?id=1867

were just dealt with. A comment with the commit hash is in 2144. Can someone
with admin rights close them?


Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] gaussian optics module

[krastanov.ste...@gmail.com]

In most (but not all) cases the arguments are directly passed to the
constructor of matrices. I suppose that then sympification is not necessary.
Am I right? After all I have type(Matrix( (1,) )[0]) == numbers.One.

I will sympify all arguments that are not implicitly sympified and also will
change the bare numbers.

On 23 September 2011 01:03, Chris Smith  wrote:

> I would be in favor of it. Things are well documented. I would change
> all bare numbers like 1 and 0 to Integer(1) and Integer(0) and then
> you won't have the issue of having to use real numbers. The general
> SymPy method for passed parameters that we want to be treated
> "symbolically" and not be subject to integer or floating results is to
> sympify them, so between lines 233 and 234, for example, I would write
> `args = sympyify(args)` so if someone passed d as 3 the 3 would become
> Integer(3).
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] gaussian optics module

[krastanov.ste...@gmail.com]

Hi,

I've added doctests to every function or class. As the module is very simple
there are no internal classes, so there is no need for __all__. I'm making a
pull request.

https://github.com/sympy/sympy/pull/617

Stefan

2011/9/23 Ondřej Čertík 

> Hi Stefan,
>
> On Thu, Sep 22, 2011 at 6:42 PM, Aaron Meurer  wrote:
> > I agree with Chris that you should submit it as a pull request.
>
> Absolutely, I would love to have your module in sympy as well.
>
> >
> > One thing that will need to be done before it is merged is that you
> > should add doctests (examples) to all the docstrings, and also some
> > regular tests in a test_gaussopt.py file.  But you can go ahead and
> > submit a pull request even before you do this, to start receiving more
> > feedback on the code.
> >
> > Another thing: I'm not sure how imports work in the physics module.
> > For example, the __init__.py file seems to import only a few things,
>
> I think that we just left most of the things in the python files
> themselves (not importing them in __init__.py), until things settle
> some more about what things should be imported and how. I think that
> the best way is to import the most usable things in the respective
> modules, that is for the wigner module:
>
> from sympy.physics.wigner import *
>
> or quantum module:
>
> from sympy.physics.quantum import *
>
> and that sympy.physics itself should not import anything.
>
> > and appears to not be up to date.  This probably needs to be cleaned
> > up.  One thing that you can do is to define __all__ at the top of the
> > module so that when someone does "from sympy.physics.gaussopt import
> > *" it will import all the right things, and none of the internal
> > variables or classes.
>
> I agree with the __all__ statement.
>
> Ondrej
>
> >
> > Aaron Meurer
> >
> > On Thu, Sep 22, 2011 at 7:34 PM, Chris Smith  wrote:
> >> On Fri, Sep 23, 2011 at 6:09 AM, krastanov.ste...@gmail.com
> >>  wrote:
> >>> In most (but not all) cases the arguments are directly passed to the
> >>> constructor of matrices. I suppose that then sympification is not
> necessary.
> >>> Am I right? After all I have type(Matrix( (1,) )[0]) == numbers.One.
> >>
> >> Yes, you are right. So if the numbers are getting sent to matrix they
> >> don't need to by sympified.
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> Groups "sympy" group.
> >> To post to this group, send email to sympy@googlegroups.com.
> >> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> >> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
> >>
> >>
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "sympy" group.
> > To post to this group, send email to sympy@googlegroups.com.
> > To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] Yet another plotting framework for sympy

[krastanov.ste...@gmail.com]

This time with multiple backends.

Please see the prototype in https://github.com/sympy/sympy/pull/673

What do you think about the interface proposed in test.py?

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] Re: Yet another plotting framework for sympy

[krastanov.ste...@gmail.com]

I've had few free minutes to add a VERY simple backend that uses textplot.

So now there are two simple backends that you can look at (MatplotlibBackend
and TextBackend). The rest of the code is not readable at all for the
moment, but you may be interested to see how simple the backends are.

I'll contact you after the weekend. I hope you find the code useful. There
is certainly much more work to be done on it, but it's already useful.

Warning: Expect many bugs!

Regards
Stefan

On 21 October 2011 18:12, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> This time with multiple backends.
>
> Please see the prototype in https://github.com/sympy/sympy/pull/673
>
> What do you think about the interface proposed in test.py?
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Google Code-In

[krastanov.ste...@gmail.com]

I would also like to help. Hopefully I'll find the time.

About the translations - I speak Bulgarian and I can probably find few
people willing to help with French translations.

Stefan Krastanov

On 23 October 2011 21:33, Aaron Meurer  wrote:

> Another thing: we need to have at least five translation tasks.  We
> were thinking to just create tasks for translating tutorials.  We need
> to have people who are fluent in the language to evaluate the task.
> Apparently, the task should only be considered as completed if the
> translation is perfect, i.e., from someone who is also fluent, to
> avoid people using machine translations.  What languages are people
> fluent in, who are willing to evaluate translations tasks?  Ondrej
> speaks Czech and Mateusz speaks Polish.
>
> Aaron Meurer
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] Plotting framework

[krastanov.ste...@gmail.com]

Hi,

Some time ago I announced that I was playing with some code for a new, more
general plotting framework for sympy.

The pull request for the proposal is
https://github.com/sympy/sympy/pull/673and I've cleaned it up a bit.
In the pull request I describe the idea. It
should support multiple backends (the current framework can be one of the
possible backends, but a cleanup is needed).

I'm not sure if the code is fitting your vision for a plotting framework but
on numerous occasions Certik has mentioned that he would like a backend
agnostic framework. The code I propose is good enough for me but you may
consider it too limited.

So, should I continue working on this proposal, do you like it, do you have
any comments/objections/corrections?

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Plotting framework

[krastanov.ste...@gmail.com]

The visual examples are in test.py in the root (the file will be
deleted/moved if there is ever a version for merging)- it's meant for copy
pasting or interactive shell, so you can see how it works.

About the differences: The code in newplot is just a *simplified* interface
to whichever backend you choose (eg matplotlib, textplot, google chart api,
the current plotting module, etc). Only textplot and matplotlib backends are
present (and they are fairly simple).

The *only* advantage of using this code instead directly one of the backends
it's that you have simplified interface for all of the common tasks
(including for example coloring as a function of parameters). For
complicated stuff you can directly access the backend.

So instead of typing

x_points = range(N_points)/float(step)
y_points = [(x**2).eval(subs={x : point}) for point in x_points]
do_whatever_you_need_to_do_to_use_THE_CHOSEN_BACKEND()

you write

p = Plot(x**2,x,start,end)
p.backend = THE_CHOSEN_BACKEND.

Obviously the current plotting framework also presents a simple interface,
but the quality of the plot is not great and the options it presents are
limited.

In test.py you can see (in comments) the basic options that the module
provides.

There is more stuff to be added, but as it already does all that I need, I
am waiting for your opinion before adding anything else that may turn out
nobody will use.

Stefan

On 26 October 2011 15:34, Christophe BAL  wrote:

> Hello,
> what are the main differences with the current plotting system ? Are there
> some "visual" examples ?
>
> Best regards.
> C.
>
> 2011/10/26 krastanov.ste...@gmail.com 
>
>> Hi,
>>
>> Some time ago I announced that I was playing with some code for a new,
>> more general plotting framework for sympy.
>>
>> The pull request for the proposal is
>> https://github.com/sympy/sympy/pull/673 and I've cleaned it up a bit. In
>> the pull request I describe the idea. It should support multiple backends
>> (the current framework can be one of the possible backends, but a cleanup is
>> needed).
>>
>> I'm not sure if the code is fitting your vision for a plotting framework
>> but on numerous occasions Certik has mentioned that he would like a backend
>> agnostic framework. The code I propose is good enough for me but you may
>> consider it too limited.
>>
>> So, should I continue working on this proposal, do you like it, do you
>> have any comments/objections/corrections?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to sympy@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sympy?hl=en.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Plotting framework

[krastanov.ste...@gmail.com]

2011/10/27 Ondřej Čertík 

> Hi Stefan,
>
> On Wed, Oct 26, 2011 at 12:54 PM, krastanov.ste...@gmail.com
>  wrote:
> > The visual examples are in test.py in the root (the file will be
> > deleted/moved if there is ever a version for merging)- it's meant for
> copy
> > pasting or interactive shell, so you can see how it works.
> >
> > About the differences: The code in newplot is just a *simplified*
> interface
> > to whichever backend you choose (eg matplotlib, textplot, google chart
> api,
> > the current plotting module, etc). Only textplot and matplotlib backends
> are
> > present (and they are fairly simple).
> >
> > The *only* advantage of using this code instead directly one of the
> backends
> > it's that you have simplified interface for all of the common tasks
> > (including for example coloring as a function of parameters). For
> > complicated stuff you can directly access the backend.
> >
> > So instead of typing
> >
> > x_points = range(N_points)/float(step)
> > y_points = [(x**2).eval(subs={x : point}) for point in x_points]
> > do_whatever_you_need_to_do_to_use_THE_CHOSEN_BACKEND()
> >
> > you write
> >
> > p = Plot(x**2,x,start,end)
> > p.backend = THE_CHOSEN_BACKEND.
>
> I would suggest to use:
>
> p = Plot(x**2, (x, start, end))
>
> to be compatible with integrate and other parts in SymPy.
>
>
I'll change that and I'm quite sure that many other details will change. But
before that I'll wait a week or two to gather comments on the general
structure of the proposed module.


> I mentioned this patch to Aaron at the Google Mentor Summit, but
> unfortunately we didn't have time to look into it there. It is very
> important to improve the plotting support, so many thanks for the
> initiative. I'll try to review this soon and provide suggestions.
>
> Ondrej
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Google Code-In

[krastanov.ste...@gmail.com]

Shouldn't there be a link to the sorted issues for GCI on the application
page?

On 30 October 2011 03:51, Aaron Meurer  wrote:

> 2011/10/29 Ondřej Čertík :
> > On Wed, Oct 26, 2011 at 1:01 AM, Aaron Meurer 
> wrote:
> > [...]
> >>
> >> Second, once we have at least five of each category, we need to
> >> compile them into a wiki page, so we can put a link to it in our
> >> application. The application is due November 1.  Ondrej, Mateusz, and
> >> I already wrote up the responses to the other questions at the summit,
> >> so we just need that. (p.s., Ondrej, should we put that on the wiki
> >> like we did for
> >> https://github.com/sympy/sympy/wiki/GSoC-2010-Organization-Application
> >> ?)
> >
> > Here it is:
> >
> > https://github.com/sympy/sympy/wiki/GCI-2011-Organization-Application
> >
> > Anyone, feel free to edit/improve or send us comments/suggestions.
> >
> > Ondrej
>
> Thanks Ondrej.  If anyone wants to edit this, please do so this
> weekend, as the application is due November 1.
>
> Aaron Meurer
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: Google Code-In

[krastanov.ste...@gmail.com]

I've added an issue about code formating
http://code.google.com/p/sympy/issues/detail?id=2815&thanks=2815&ts=1320077133
but I can not edit the tags so it's not marked as GCI issue.

On 31 October 2011 08:56, lira.lg  wrote:

> I want to help. The last year I was a GCI mentor for Haiku and Parrot
> and of course I am a GSoC since 2007, this year for codehaus.
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] evalf with subs is oo times slower than without

[krastanov.ste...@gmail.com]

In [21]: s = summation(k**(-2.1), (k, 1, oo))
In [23]: %timeit s.evalf()
1 loops, best of 3: 196 ms per loop

In [24]: s = summation(k**(-x), (k, 1, oo))
In [26]: %timeit s.evalf(subs={x : 2.1})
still calculating

This seems like a bug?

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] problems with lambdify

[krastanov.ste...@gmail.com]

>
> *concerning sums:
> *In [1]: s = summation(k**(-x),(k,1,oo))
>
> In [2]: s
> Out[2]:
>
>   ∞
>  ___
>  \  `
>   \-x
>   /   k
>  /__,
> k = 1
>
> In [3]: fs = lambdify([x], s) # I've added a print statement inside so I
> can see the lambda string
> lambda x: (Sum(k**(-x), (k, 1, oo)))
>
> In [4]: fs(2)
> /usr/lib/pymodules/python2.7/numpy/__init__.pyc in (x)
>
> NameError: global name 'Sum' is not defined
>
>
> *concerning integrals:*
> In [5]: expr = integrate(1/sqrt(x**2+x), (x, 1, y))
>
> In [6]: func = lambdify([y], expr)
>
> In [7]: func(2) ValueError: Symbolic value, can't compute
>
>
> Can somebody explain this to me, I'm looking at the code but I do not
> understand why lambdify with mpmath and evalf are not reusing one another?
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] Re: evalf with subs is oo times slower than without

[krastanov.ste...@gmail.com]

few minutes after sending the mail I got this

/home/stefan/Workspace/sympy/sympy/core/operations.pyc in
_eval_template_is_attr(self, is_attr)
214 r = True
--> 215 for t in self.args:
216 a = getattr(t, is_attr)
217 if a is None: return

RuntimeError: maximum recursion depth exceeded


On 9 November 2011 16:46, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> In [21]: s = summation(k**(-2.1), (k, 1, oo))
> In [23]: %timeit s.evalf()
> 1 loops, best of 3: 196 ms per loop
>
> In [24]: s = summation(k**(-x), (k, 1, oo))
> In [26]: %timeit s.evalf(subs={x : 2.1})
> still calculating
>
> This seems like a bug?
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] Re: evalf with subs is oo times slower than without

[krastanov.ste...@gmail.com]

Actually the problem is in summation, not in evalf.

In [3]: %timeit(gamma(1000))
10 loops, best of 3: 11.3 us per loop
In [4]: %timeit(gamma(x).subs({x:1000}))
1 loops, best of 3: 57.1 us per loop



On 9 November 2011 16:51, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> few minutes after sending the mail I got this
>
> /home/stefan/Workspace/sympy/sympy/core/operations.pyc in
> _eval_template_is_attr(self, is_attr)
> 214 r = True
> --> 215 for t in self.args:
> 216 a = getattr(t, is_attr)
> 217 if a is None: return
>
> RuntimeError: maximum recursion depth exceeded
>
>
>
> On 9 November 2011 16:46, krastanov.ste...@gmail.com <
> krastanov.ste...@gmail.com> wrote:
>
>> In [21]: s = summation(k**(-2.1), (k, 1, oo))
>> In [23]: %timeit s.evalf()
>> 1 loops, best of 3: 196 ms per loop
>>
>> In [24]: s = summation(k**(-x), (k, 1, oo))
>> In [26]: %timeit s.evalf(subs={x : 2.1})
>> still calculating
>>
>> This seems like a bug?
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] evalf with subs is oo times slower than without

[krastanov.ste...@gmail.com]

2011/11/9 Ondřej Čertík 

> On Wed, Nov 9, 2011 at 7:46 AM, krastanov.ste...@gmail.com
>  wrote:
> > In [21]: s = summation(k**(-2.1), (k, 1, oo))
> > In [23]: %timeit s.evalf()
> > 1 loops, best of 3: 196 ms per loop
> >
> > In [24]: s = summation(k**(-x), (k, 1, oo))
> > In [26]: %timeit s.evalf(subs={x : 2.1})
> > still calculating
> >
> > This seems like a bug?
>
> What happens if you do:
>
> s.subs({x: 2.1}).evalf()
>
> ?
>
>
it works
In [3]: %timeit s.subs({x : 2.1}).evalf()
1 loops, best of 3: 195 ms per loop



> Ondrej
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] Should lambdify be permitted to return symbols?

[krastanov.ste...@gmail.com]

In [22]: lambdify([y], x + y)(1)
Out[22]: x + 1

I believe that this should raise an error. But maybe there are some
usecases that I'm missing.

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] evalf with subs is oo times slower than without

[krastanov.ste...@gmail.com]

I've created an issue for this one

http://code.google.com/p/sympy/issues/detail?id=2837&thanks=2837&ts=1320876163

On 9 November 2011 20:23, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> 2011/11/9 Ondřej Čertík 
>
>> On Wed, Nov 9, 2011 at 7:46 AM, krastanov.ste...@gmail.com
>>  wrote:
>> > In [21]: s = summation(k**(-2.1), (k, 1, oo))
>> > In [23]: %timeit s.evalf()
>> > 1 loops, best of 3: 196 ms per loop
>> >
>> > In [24]: s = summation(k**(-x), (k, 1, oo))
>> > In [26]: %timeit s.evalf(subs={x : 2.1})
>> > still calculating
>> >
>> > This seems like a bug?
>>
>> What happens if you do:
>>
>> s.subs({x: 2.1}).evalf()
>>
>> ?
>>
>>
> it works
> In [3]: %timeit s.subs({x : 2.1}).evalf()
> 1 loops, best of 3: 195 ms per loop
>
>
>
>> Ondrej
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to sympy@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sympy?hl=en.
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] problems with lambdify

[krastanov.ste...@gmail.com]

On 10 November 2011 00:21, Raoul  wrote:

> Hi,
>
> > > *concerning sums:
> > > *In [1]: s = summation(k**(-x),(k,1,oo))
> > >
> > > In [2]: s
> > > Out[2]:
> > >
> > >   ∞
> > >  ___
> > >  \  `
> > >   \-x
> > >   /   k
> > >  /__,
> > > k = 1
> > >
> > > In [3]: fs = lambdify([x], s) # I've added a print statement inside
> > > so I can see the lambda string
> > > lambda x: (Sum(k**(-x), (k, 1, oo)))
> > >
> > > In [4]: fs(2)
> > > /usr/lib/pymodules/python2.7/numpy/__init__.pyc in (x)
> > >
> > > NameError: global name 'Sum' is not defined
>
> I suppose the function "Sum" just is not "translated" to
> lamdified numpy/mpmath/... code.
>
> Yes, it is not translated and that is posing a problem.


> Further there is probably no equivalent to symbolic
> infinite sums.
>
There is - the approximation used in evalf().

>
> What would this sum be, for example in numerical code?
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] completely unused class DeferredVector?

[krastanov.ste...@gmail.com]

Hi,

While trying to wrap my head around lambdify I have found this commit:

commit bbddfc4e479f3387a5d839c237459c6f9578d4d3
Author: Andrew Straw 
Date:   Sat Jan 17 14:38:34 2009 -0800

DeferredVector implementation, allowing lambdification using arbitrary
vectors

 sympy/matrices/__init__.py|2 +-
 sympy/matrices/matrices.py|   11 +++
 sympy/printing/str.py |3 +++
 sympy/test_external/test_numpy.py |   28 
 4 files changed, 43 insertions(+), 1 deletions(-)

grep 'DeferredVector' -ir sympy/*
sympy/external/tests/test_numpy.py:X=sympy.DeferredVector('X')
sympy/matrices/matrices.py:class DeferredVector(object):
sympy/matrices/__init__.py: list2numpy, matrix2numpy, DeferredVector,
block_diag, symarray, ShapeError,
sympy/printing/str.py:def _print_DeferredVector(self, expr):
sympy/printing/codeprinter.py:_print_DeferredVector =
_print_not_supported


It seems it's completely unused. Should this be removed?

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] Re: completely unused class DeferredVector?

[krastanov.ste...@gmail.com]

I'm wrong, it's used and the tests show why one would want this, but the
lack of docstring makes it hard to understand. Shouldn't this be mentioned
at least in lambdify with some examples?

On 10 November 2011 16:01, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> Hi,
>
> While trying to wrap my head around lambdify I have found this commit:
>
> commit bbddfc4e479f3387a5d839c237459c6f9578d4d3
> Author: Andrew Straw 
> Date:   Sat Jan 17 14:38:34 2009 -0800
>
> DeferredVector implementation, allowing lambdification using arbitrary
> vectors
>
>  sympy/matrices/__init__.py|2 +-
>  sympy/matrices/matrices.py|   11 +++
>  sympy/printing/str.py |3 +++
>  sympy/test_external/test_numpy.py |   28 
>  4 files changed, 43 insertions(+), 1 deletions(-)
>
> grep 'DeferredVector' -ir sympy/*
> sympy/external/tests/test_numpy.py:X=sympy.DeferredVector('X')
> sympy/matrices/matrices.py:class DeferredVector(object):
> sympy/matrices/__init__.py: list2numpy, matrix2numpy, DeferredVector,
> block_diag, symarray, ShapeError,
> sympy/printing/str.py:def _print_DeferredVector(self, expr):
> sympy/printing/codeprinter.py:_print_DeferredVector =
> _print_not_supported
>
>
> It seems it's completely unused. Should this be removed?
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] Is lambdify for numeric calculations or not? Either it needs refactoring or I don't understand it at all...

[krastanov.ste...@gmail.com]

Hi,

I hope Aaron could comment as this concerns the plotting problem he was
working on (pull request 696).

So for the last day or so I was trying to understand lambdify. According to
the docstring it's used for numeric calculations - that's the whole idea
behind translating sympy functions to mpmath, numpy, etc.

Also according to the docstring lambdify is used for _fast_ calculations.
That's why it's not simply a shortcut for .subs(vars).evalf() which is so
much simpler but calls subs on every evaluation. (The guy that has created
the plotting module few years ago has some benchmarks on his blog)

And it seems that the original idea behind lambdify was to be used in the
plotting framework (see the author of the first commit in git log), giving
numerical values for the coordinates to be plotted. If I'm incorrect here
please correct me.

But all this falls apart when I look at the tests:

- the most hard for me to understand are the following:
 256 f = lambdify(x, x * y)
 257 assert f(z) == z * y
and
 250 f = Lambda(x, exp(-x**2))
 251 l = lambdify(x, Integral(f(x), (x, -oo, oo)), modules="sympy")
 252 assert l(x) == Integral(exp(-x**2), (x, -oo, oo))

Why would anyone ever want to do this instead of using a simple python
lambda? There is no translation to numpy or other modules. The only thing
that can happen is to mix numpy functions with sympy expressions, but why
would someone want to do this?

An enormous amount of the tests for lambdify show behaviour that _should_
be implemented with python lambda. And that makes lambdify that much harder
to implement. Why should lambdify care about lists, tuples, dictionaries
and whatnot when even in the docstring it's said that it's used for numeric
computation?


Or probably I'm simply missing the point of lambdify. Could some one
explain it to me?


notes:
the integral tests comes from this commit:
commit 558c862ac98e58a1d27bdc57a777d355cabee28d
Author: Ondrej Certik 
Date:   Sun Mar 29 17:49:24 2009 -0700
Make lambdify() work with Integral
but it does not address Sums, Products, any single one quantum expression,
etc. Why is integral so special (obviously those were not needed until
know, but the proposed solution does not scale at all)

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: Google Code-In

[krastanov.ste...@gmail.com]

I've just added some text to the page. The quality of the language is not
great at the moment, but if you like the structure I'll fix the language.

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Is lambdify for numeric calculations or not? Either it needs refactoring or I don't understand it at all...

[krastanov.ste...@gmail.com]

On 11 November 2011 02:26, Aaron Meurer  wrote:

> On Thu, Nov 10, 2011 at 8:58 AM, krastanov.ste...@gmail.com
>  wrote:
> > Hi,
> >
> > I hope Aaron could comment as this concerns the plotting problem he was
> > working on (pull request 696).
> >
> > So for the last day or so I was trying to understand lambdify. According
> to
> > the docstring it's used for numeric calculations - that's the whole idea
> > behind translating sympy functions to mpmath, numpy, etc.
> >
> > Also according to the docstring lambdify is used for _fast_ calculations.
> > That's why it's not simply a shortcut for .subs(vars).evalf() which is so
> > much simpler but calls subs on every evaluation. (The guy that has
> created
> > the plotting module few years ago has some benchmarks on his blog)
> >
> > And it seems that the original idea behind lambdify was to be used in the
> > plotting framework (see the author of the first commit in git log),
> giving
> > numerical values for the coordinates to be plotted. If I'm incorrect here
> > please correct me.
> >
> > But all this falls apart when I look at the tests:
> >
> > - the most hard for me to understand are the following:
> >  256 f = lambdify(x, x * y)
> >  257 assert f(z) == z * y
> > and
> >  250 f = Lambda(x, exp(-x**2))
> >  251 l = lambdify(x, Integral(f(x), (x, -oo, oo)), modules="sympy")
> >  252 assert l(x) == Integral(exp(-x**2), (x, -oo, oo))
> >
> > Why would anyone ever want to do this instead of using a simple python
> > lambda? There is no translation to numpy or other modules. The only thing
> > that can happen is to mix numpy functions with sympy expressions, but why
> > would someone want to do this?
> >
> > An enormous amount of the tests for lambdify show behaviour that
> _should_ be
> > implemented with python lambda. And that makes lambdify that much harder
> to
> > implement. Why should lambdify care about lists, tuples, dictionaries and
> > whatnot when even in the docstring it's said that it's used for numeric
> > computation?
> >
> >
> > Or probably I'm simply missing the point of lambdify. Could some one
> explain
> > it to me?
>
> If you look at the implementation of lambdify, and LambdaPrinter, it
> is just a wrapper around Python lambda that does some intelligent
> translation when going to other modules (like numpy).  Actually, it's
> particularly nice for using numpy or some other module because
> lambdify([x], sin(x), "numpy")(1) will use numpy's sin() function to
> evaluate sin(1), not mpmath.
>
I've looked at this and I agree, the problem is when not used to make
translations.

>
> But in general, I think the reason to use it instead of a straight
> Python lambda is because it will be cleaner, and also because for
> those cases where those translations matter, you don't have to worry
> about them.
>

About the translations I completely agree. The problem is that most of the
code assumes that lambdify is for numeric computations (most of the code
that I have seen). The same thing is stated in the docstring. But then the
tests permit stuff like this:
 250 f = Lambda(x, exp(-x**2))
 251 l = lambdify(x, Integral(f(x), (x, -oo, oo)), modules="sympy")
 252 assert l(x) == Integral(exp(-x**2), (x, -oo, oo))
Which seems wrong to me as it's not a numeric computation. The plotting
module has problems with this, and if this test is to be taken as correct
the fix for the plotting module is not trivial (creating a function
lambdify_numeric maybe?)

>
> And by the way, I'm not the best person to ask about lambdify(), as
> I've only used it a little; and similarly with the plotting: I only
> have used it a little (for the plotting, it's mostly because it
> usually doesn't work on Mac OS X, so I don't bother.  I definitely
> would use it more if it worked).  That pull request was fixing someone
> else's problem from IRC, for which I was immediately able to see the
> problem.
>
> Aaron Meurer
>
> >
> >
> > notes:
> > the integral tests comes from this commit:
> > commit 558c862ac98e58a1d27bdc57a777d355cabee28d
> > Author: Ondrej Certik 
> > Date:   Sun Mar 29 17:49:24 2009 -0700
> > Make lambdify() work with Integral
> > but it does not address Sums, Products, any single one quantum
> expression,
> > etc. Why is integral so special (obviously those were not needed until
> know,
> > but the proposed solution does not scale at all)
> >
> > --
> > You received this

Re: [sympy] Example plots from the new code

[krastanov.ste...@gmail.com]

Hi

I'm a bit ashamed that Aaron gave better introduction than me for my own
code :)
Anyway, I think the documentation of Plot and the module is quite detailed
so you can look also at help(Plot) and help(newplot).

About the warnings - my idea was to structure the base backend class in
such a way that any missing functionality in the backend subclass will just
raise a warning but not an error (unless it is some essential
functionality). So those will be addressed later.

It can plot Integrals (due to an old addition done to lambdify thanks to
Certik) but not Sums or anything fancy like product of Kets and Bras. To do
those a more in depth refactoring of lambda will be needed as Certik's
method for adding Integral to lambdify does not scale well. I think this is
an important problem.

Discontinuous functions may pose problems for the moment (none seen for the
moment, but this is mostly by chance).

About the bug in matplotlib - Aaron, you said that you will make a pull
request for them. Should I do something or you have already taken care of
this.

I'll start writing tests for the module in the near future. Then the core
devs should tell me if this code is going in and how.

About the '3d' string - you are right it's a bad default. It's just that
contour was written first, but I'll change this now.

Finally - I was squashing and rebasing this pull request quite a bit. Now
as it's getting more attention I'll stop doing it, so you are free to make
changes if you are interested.

On 11 November 2011 21:41, Aaron Meurer  wrote:

> Oh, I forgot to mention that I got the following warnings:
>
> In [6]: p = Plot(Heaviside(x)*(1 - x)*sin(y), (x, -1, 1), (y, -pi, pi))
>
> In [7]: p.show()
> /sw/lib/python2.7/site-packages/matplotlib/axes.py:4368: UserWarning:
> No labeled objects found. Use label='...' kwarg on individual plots.
>  warnings.warn("No labeled objects found. "
>
> In [8]: p = Plot(Heaviside(x)*(1 - x)*sin(y), (x, -1, 1), (y, -pi, pi),
> '3d')
>
> In [9]: p.show()
>
> /Users/aaronmeurer/Documents/python/sympy/sympy/sympy/plotting/newplot.py:901:
> UserWarning: xscale is not supported in 3D matplotlib backend.
>  warnings.warn('xscale is not supported in 3D matplotlib backend.')
>
> /Users/aaronmeurer/Documents/python/sympy/sympy/sympy/plotting/newplot.py:879:
> UserWarning: axis_center is not supported in 3D matplotlib backend.
>  warnings.warn('axis_center is not supported in 3D matplotlib backend.')
>
> /Users/aaronmeurer/Documents/python/sympy/sympy/sympy/plotting/newplot.py:895:
> UserWarning: xscale is not supported in 3D matplotlib backend.
>  warnings.warn('xscale is not supported in 3D matplotlib backend.')
>
> Aaron Meurer
>
> On Fri, Nov 11, 2011 at 1:39 PM, Aaron Meurer  wrote:
> > Hi.
> >
> > This looks great.  For others, to run the examples, download the
> > examples script and put in the sympy directory.  Then, checkout
> > Krastanov's branch (from the pull request). Then, run IPython, and
> > type %run examples.py.  And then type p0.show(), p1.show(), etc. (up
> > to p4).
> >
> > And if you just want to test the plotting of your own functions in
> > isympy, you have to run "from sympy.plotting.newplot import *", or
> > else it will use the old plotting.  The syntax is
> >
> > In [8]: p = Plot(Heaviside(x)*(1 - x)*sin(y), (x, -1, 1), (y, -pi, pi),
> '3d')
> >
> > In [9]: p.show()
> >
> > (if you don't add '3d' in this case, it will default to a contour
> > plot, which btw is maybe not the best default)
> >
> > Aaron Meurer
> >
> > On Fri, Nov 11, 2011 at 7:46 AM, krastanov.ste...@gmail.com
> >  wrote:
> >> The proposal that I made in https://github.com/sympy/sympy/pull/673may or
> >> may not became part of sympy but I like it and it's already quite
> useful for
> >> me.
> >>
> >> Here are some examples. I would like to know what do you think. The 3d
> stuff
> >> runs only on the latest version of matplotlib _after_ fixing a bug
> >> (mentioned in the commit history, but those will be squashed soon).
> >
> > I didn't have any problems with it, though you do seem to have found a
> > bug in matplotlib.  I would submit a pull request to them fixing it.
> >
> > Aaron Meurer
> >
> >>
> >> The script to produce them is also attached (as the api is probably more
> >> important than the visuals (the _series[index] stuff is just a
> workaround
> >> until getters are written)).
> >>
> >> Regards
> >> Stefan
> >>
> >> --
> >&

Re: [sympy] Example plots from the new code

[krastanov.ste...@gmail.com]

Some more examples are present in test.py (the second file in the pull
request) that can be used in the same way as examples.py.

On 11 November 2011 22:13, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> Hi
>
> I'm a bit ashamed that Aaron gave better introduction than me for my own
> code :)
> Anyway, I think the documentation of Plot and the module is quite detailed
> so you can look also at help(Plot) and help(newplot).
>
> About the warnings - my idea was to structure the base backend class in
> such a way that any missing functionality in the backend subclass will just
> raise a warning but not an error (unless it is some essential
> functionality). So those will be addressed later.
>
> It can plot Integrals (due to an old addition done to lambdify thanks to
> Certik) but not Sums or anything fancy like product of Kets and Bras. To do
> those a more in depth refactoring of lambda will be needed as Certik's
> method for adding Integral to lambdify does not scale well. I think this is
> an important problem.
>
> Discontinuous functions may pose problems for the moment (none seen for
> the moment, but this is mostly by chance).
>
> About the bug in matplotlib - Aaron, you said that you will make a pull
> request for them. Should I do something or you have already taken care of
> this.
>
> I'll start writing tests for the module in the near future. Then the core
> devs should tell me if this code is going in and how.
>
> About the '3d' string - you are right it's a bad default. It's just that
> contour was written first, but I'll change this now.
>
> Finally - I was squashing and rebasing this pull request quite a bit. Now
> as it's getting more attention I'll stop doing it, so you are free to make
> changes if you are interested.
>
>
> On 11 November 2011 21:41, Aaron Meurer  wrote:
>
>> Oh, I forgot to mention that I got the following warnings:
>>
>> In [6]: p = Plot(Heaviside(x)*(1 - x)*sin(y), (x, -1, 1), (y, -pi, pi))
>>
>> In [7]: p.show()
>> /sw/lib/python2.7/site-packages/matplotlib/axes.py:4368: UserWarning:
>> No labeled objects found. Use label='...' kwarg on individual plots.
>>  warnings.warn("No labeled objects found. "
>>
>> In [8]: p = Plot(Heaviside(x)*(1 - x)*sin(y), (x, -1, 1), (y, -pi, pi),
>> '3d')
>>
>> In [9]: p.show()
>>
>> /Users/aaronmeurer/Documents/python/sympy/sympy/sympy/plotting/newplot.py:901:
>> UserWarning: xscale is not supported in 3D matplotlib backend.
>>  warnings.warn('xscale is not supported in 3D matplotlib backend.')
>>
>> /Users/aaronmeurer/Documents/python/sympy/sympy/sympy/plotting/newplot.py:879:
>> UserWarning: axis_center is not supported in 3D matplotlib backend.
>>  warnings.warn('axis_center is not supported in 3D matplotlib backend.')
>>
>> /Users/aaronmeurer/Documents/python/sympy/sympy/sympy/plotting/newplot.py:895:
>> UserWarning: xscale is not supported in 3D matplotlib backend.
>>  warnings.warn('xscale is not supported in 3D matplotlib backend.')
>>
>> Aaron Meurer
>>
>> On Fri, Nov 11, 2011 at 1:39 PM, Aaron Meurer  wrote:
>> > Hi.
>> >
>> > This looks great.  For others, to run the examples, download the
>> > examples script and put in the sympy directory.  Then, checkout
>> > Krastanov's branch (from the pull request). Then, run IPython, and
>> > type %run examples.py.  And then type p0.show(), p1.show(), etc. (up
>> > to p4).
>> >
>> > And if you just want to test the plotting of your own functions in
>> > isympy, you have to run "from sympy.plotting.newplot import *", or
>> > else it will use the old plotting.  The syntax is
>> >
>> > In [8]: p = Plot(Heaviside(x)*(1 - x)*sin(y), (x, -1, 1), (y, -pi, pi),
>> '3d')
>> >
>> > In [9]: p.show()
>> >
>> > (if you don't add '3d' in this case, it will default to a contour
>> > plot, which btw is maybe not the best default)
>> >
>> > Aaron Meurer
>> >
>> > On Fri, Nov 11, 2011 at 7:46 AM, krastanov.ste...@gmail.com
>> >  wrote:
>> >> The proposal that I made in https://github.com/sympy/sympy/pull/673may or
>> >> may not became part of sympy but I like it and it's already quite
>> useful for
>> >> me.
>> >>
>> >> Here are some examples. I would like to know what do you think. The 3d
>> stuff
>> >> runs only on the latest version of matplotlib _afte

Re: [sympy] Example plots from the new code

[krastanov.ste...@gmail.com]

On 11 November 2011 23:31, Aaron Meurer  wrote:

> On Fri, Nov 11, 2011 at 2:13 PM, krastanov.ste...@gmail.com
>  wrote:
> > Hi
> >
> > I'm a bit ashamed that Aaron gave better introduction than me for my own
> > code :)
> > Anyway, I think the documentation of Plot and the module is quite
> detailed
> > so you can look also at help(Plot) and help(newplot).
> >
> > About the warnings - my idea was to structure the base backend class in
> such
> > a way that any missing functionality in the backend subclass will just
> raise
> > a warning but not an error (unless it is some essential functionality).
> So
> > those will be addressed later.
> >
> > It can plot Integrals (due to an old addition done to lambdify thanks to
> > Certik) but not Sums or anything fancy like product of Kets and Bras. To
> do
> > those a more in depth refactoring of lambda will be needed as Certik's
> > method for adding Integral to lambdify does not scale well. I think this
> is
> > an important problem.
>
> I agree.  Is there an issue for this?
>
No issue for the moment. I take responsibility for creating one when I
gather enough understanding of the code and the problem.

>
> >
> > Discontinuous functions may pose problems for the moment (none seen for
> the
> > moment, but this is mostly by chance).
>
> As far as I can tell, this is a nontrivial problem to solve, as many
> very good plotting systems choke on discontinuous functions.  Perhaps
> there can be some kind of symbolic heuristic applied to find
> discontinuities.
>
I think Maple has some option in its plotting module about detecting
asymptotes (numerically?) but I can not check it at the moment. Anyhow,
this is not the most important feature at the moment.

>
> >
> > About the bug in matplotlib - Aaron, you said that you will make a pull
> > request for them. Should I do something or you have already taken care of
> > this.
>
> Sorry for the misunderstanding, but this is not what I said.  I was
> suggesting to you that you do it.  I haven't even been able to
> reproduce the bug you are seeing, so I can't even tell with certainty
> what the correct fix is.
>
I'm sorry :D (my mistake). I'll do it.

>
> >
> > I'll start writing tests for the module in the near future. Then the core
> > devs should tell me if this code is going in and how.
>
> I definitely think it should go in.  I guess the question is how to
> properly replace/merge it with the old module, which isn't compatible
> (it uses different syntax, keywords, etc.)
>
> Actually, to what degree is the new Plot() function incompatible with
> the old one?  Would it be possible to merge the two without breaking
> compatibility with the old module?
>
There are some things about the api of the old module that I don't like,
but I'll check if there is a compromise that can be made. I understand the
importance of not breaking the api.

But I was thinking it would be best to have both modules and then a backend
for the old module in the new module. And maybe move the old module to
plotting.oldplot or leave the new module in plotting.newplot.

>
> >
> > About the '3d' string - you are right it's a bad default. It's just that
> > contour was written first, but I'll change this now.
>
> Cool.  By the way, will it be possible in the future to call something
> like p.change_plot_type('contour') (only with a better name than that
> :) and it will change it from 3d to a contour?
>
At the moment 3dsurface (not parametric) and contour are represented by
different classes. It makes sense to merge them and add an option (actually
there is a repetition of code at the moment). It would be something like:
p = Plot(blah blah)
p[0].visualisation_method = '3d' or 'contour'
the name of the attribute may be other ('plot_type', 'projection', ...)

>
> >
> > Finally - I was squashing and rebasing this pull request quite a bit.
> Now as
> > it's getting more attention I'll stop doing it, so you are free to make
> > changes if you are interested.
>
> Great.  This makes it easier to follow your progress.
>
> Aaron Meurer
>
> >
> > On 11 November 2011 21:41, Aaron Meurer  wrote:
> >>
> >> Oh, I forgot to mention that I got the following warnings:
> >>
> >> In [6]: p = Plot(Heaviside(x)*(1 - x)*sin(y), (x, -1, 1), (y, -pi, pi))
> >>
> >> In [7]: p.show()
> >> /sw/lib/python2.7/site-packages/matplotlib/axes.py:4368: UserWarning:
> >> No labeled objects found. Use label='...' kw

[sympy] lambdify again

[krastanov.ste...@gmail.com]

Hi,

I was bashing lambdify lately, but it seems this function is smarter than
me. I'll skip the details about what I incorrectly thought the problem was
and present the real problem.

This works great:

lambdify(x, Integral(y, (y, 0, x)))

_(2)  --->  Integral(y, (y, 0, 2))

float(_) ---> the right numeric answer

This also works great:

lambdify(x, Integral(sqrt(y), (y, 0, x)), *modules='sympy'*)

_(2)  --->  Integral(sqrt(y), (y, 0, 2))

float(_) ---> the right numeric answer

This does not work because sqrt is translated to the numpy function

lambdify(x, Integral(sqrt(y), (y, 0, x)))

_(2)  --->  ValueError: Symbolic value, can't compute

Any ideas? That is not a bug a priori but it should at least be very well
documented.


P.S. And the docstring should not tell people that lambdify is for numeric
calculation when it does not return floats.
P.P.S The fact that lambdify can not do Sums, stuff from the physics
module, etc is another problem.

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] abstract syntax tree

[krastanov.ste...@gmail.com]

Is there any way to get the expression tree from an expression (either
using the python abstract syntax tree module or just some tuples):

for example

get_tree( x+y*sin(z) ) would return

(Add, x, (Mul, y, (Sin z)))

or

(BinOp, Add, ((Symbol, x), (BinOp, Mul, (blah blah blah

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] Re: abstract syntax tree

[krastanov.ste...@gmail.com]

This:

import ast
ast.parse(repr(expression))

 will do the trick if repr is well coded.

How much faith should I put in the repr strings in sympy? Or there is
another way?

On 12 November 2011 18:20, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> Is there any way to get the expression tree from an expression (either
> using the python abstract syntax tree module or just some tuples):
>
> for example
>
> get_tree( x+y*sin(z) ) would return
>
> (Add, x, (Mul, y, (Sin z)))
>
> or
>
> (BinOp, Add, ((Symbol, x), (BinOp, Mul, (blah blah blah
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Example plots from the new code

[krastanov.ste...@gmail.com]

On 12 November 2011 20:43, Aaron Meurer  wrote:

> On Fri, Nov 11, 2011 at 4:25 PM, krastanov.ste...@gmail.com
>  wrote:
> >
> >
> > On 11 November 2011 23:31, Aaron Meurer  wrote:
> >>
> >> On Fri, Nov 11, 2011 at 2:13 PM, krastanov.ste...@gmail.com
> >>  wrote:
> >> > Hi
> >> >
> >> > I'm a bit ashamed that Aaron gave better introduction than me for my
> own
> >> > code :)
> >> > Anyway, I think the documentation of Plot and the module is quite
> >> > detailed
> >> > so you can look also at help(Plot) anhelp(newplot).
> >> >
> >> > About the warnings - my idea was to structure the base backend class
> in
> >> > such
> >> > a way that any missing functionality in the backend subclass will just
> >> > raise
> >> > a warning but not an error (unless it is some essential
> functionality).
> >> > So
> >> > those will be addressed later.
> >> >
> >> > It can plot Integrals (due to an old addition done to lambdify thanks
> to
> >> > Certik) but not Sums or anything fancy like product of Kets and Bras.
> To
> >> > do
> >> > those a more in depth refactoring of lambda will be needed as Certik's
> >> > method for adding Integral to lambdify does not scale well. I think
> this
> >> > is
> >> > an important problem.
> >>
> >> I agree.  Is there an issue for this?
> >
> > No issue for the moment. I take responsibility for creating one when I
> > gather enough understanding of the code and the problem.
> >>
> >> >
> >> > Discontinuous functions may pose problems for the moment (none seen
> for
> >> > the
> >> > moment, but this is mostly by chance).
> >>
> >> As far as I can tell, this is a nontrivial problem to solve, as many
> >> very good plotting systems choke on discontinuous functions.  Perhaps
> >> there can be some kind of symbolic heuristic applied to find
> >> discontinuities.
> >
> > I think Maple has some option in its plotting module about detecting
> > asymptotes (numerically?) but I can not check it at the moment. Anyhow,
> this
> > is not the most important feature at the moment.
> >>
> >> >
> >> > About the bug in matplotlib - Aaron, you said that you will make a
> pull
> >> > request for them. Should I do something or you have already taken care
> >> > of
> >> > this.
> >>
> >> Sorry for the misunderstanding, but this is not what I said.  I was
> >> suggesting to you that you do it.  I haven't even been able to
> >> reproduce the bug you are seeing, so I can't even tell with certainty
> >> what the correct fix is.
> >
> > I'm sorry :D (my mistake). I'll do it.
> >>
> >> >
> >> > I'll start writing tests for the module in the near future. Then the
> >> > core
> >> > devs should tell me if this code is going in and how.
> >>
> >> I definitely think it should go in.  I guess the question is how to
> >> properly replace/merge it with the old module, which isn't compatible
> >> (it uses different syntax, keywords, etc.)
> >>
> >> Actually, to what degree is the new Plot() function incompatible with
> >> the old one?  Would it be possible to merge the two without breaking
> >> compatibility with the old module?
> >
> > There are some things about the api of the old module that I don't like,
> but
> > I'll check if there is a compromise that can be made. I understand the
> > importance of not breaking the api.
>
> What are these specifically.  Is it possible to support both APIs at
> the same time, while deprecating the old one, r would they have to be
> completely different functions to prevent ambiguous input?
>

About the parts that I don't like: Using a big string for all the options
and the possibility to use an arbitrary big index when adding new plot.
That's all, I think. Those two (especially the first one) would be
difficult to support.

About supporting both apis - I think it's possible. For example: when there
is an ambiguity it will default to the old module, and when it is using the
old module it will raise a deprecation warning. All this will be done from
a proxy class Plot that is in sympy.plotting. The old module will be in
sympy.plotting.pyglet. The deprecation warning will read:

"To use directly the pyglet module do: 

Re: [sympy] Example plots from the new code

[krastanov.ste...@gmail.com]

"CGI student" should read "GCI student" for GoogleCodeIn

On 12 November 2011 22:04, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

>
>
> On 12 November 2011 20:43, Aaron Meurer  wrote:
>
>> On Fri, Nov 11, 2011 at 4:25 PM, krastanov.ste...@gmail.com
>>  wrote:
>> >
>> >
>> > On 11 November 2011 23:31, Aaron Meurer  wrote:
>> >>
>> >> On Fri, Nov 11, 2011 at 2:13 PM, krastanov.ste...@gmail.com
>> >>  wrote:
>> >> > Hi
>> >> >
>> >> > I'm a bit ashamed that Aaron gave better introduction than me for my
>> own
>> >> > code :)
>> >> > Anyway, I think the documentation of Plot and the module is quite
>> >> > detailed
>> >> > so you can look also at help(Plot) anhelp(newplot).
>> >> >
>> >> > About the warnings - my idea was to structure the base backend class
>> in
>> >> > such
>> >> > a way that any missing functionality in the backend subclass will
>> just
>> >> > raise
>> >> > a warning but not an error (unless it is some essential
>> functionality).
>> >> > So
>> >> > those will be addressed later.
>> >> >
>> >> > It can plot Integrals (due to an old addition done to lambdify
>> thanks to
>> >> > Certik) but not Sums or anything fancy like product of Kets and
>> Bras. To
>> >> > do
>> >> > those a more in depth refactoring of lambda will be needed as
>> Certik's
>> >> > method for adding Integral to lambdify does not scale well. I think
>> this
>> >> > is
>> >> > an important problem.
>> >>
>> >> I agree.  Is there an issue for this?
>> >
>> > No issue for the moment. I take responsibility for creating one when I
>> > gather enough understanding of the code and the problem.
>> >>
>> >> >
>> >> > Discontinuous functions may pose problems for the moment (none seen
>> for
>> >> > the
>> >> > moment, but this is mostly by chance).
>> >>
>> >> As far as I can tell, this is a nontrivial problem to solve, as many
>> >> very good plotting systems choke on discontinuous functions.  Perhaps
>> >> there can be some kind of symbolic heuristic applied to find
>> >> discontinuities.
>> >
>> > I think Maple has some option in its plotting module about detecting
>> > asymptotes (numerically?) but I can not check it at the moment. Anyhow,
>> this
>> > is not the most important feature at the moment.
>> >>
>> >> >
>> >> > About the bug in matplotlib - Aaron, you said that you will make a
>> pull
>> >> > request for them. Should I do something or you have already taken
>> care
>> >> > of
>> >> > this.
>> >>
>> >> Sorry for the misunderstanding, but this is not what I said.  I was
>> >> suggesting to you that you do it.  I haven't even been able to
>> >> reproduce the bug you are seeing, so I can't even tell with certainty
>> >> what the correct fix is.
>> >
>> > I'm sorry :D (my mistake). I'll do it.
>> >>
>> >> >
>> >> > I'll start writing tests for the module in the near future. Then the
>> >> > core
>> >> > devs should tell me if this code is going in and how.
>> >>
>> >> I definitely think it should go in.  I guess the question is how to
>> >> properly replace/merge it with the old module, which isn't compatible
>> >> (it uses different syntax, keywords, etc.)
>> >>
>> >> Actually, to what degree is the new Plot() function incompatible with
>> >> the old one?  Would it be possible to merge the two without breaking
>> >> compatibility with the old module?
>> >
>> > There are some things about the api of the old module that I don't
>> like, but
>> > I'll check if there is a compromise that can be made. I understand the
>> > importance of not breaking the api.
>>
>> What are these specifically.  Is it possible to support both APIs at
>> the same time, while deprecating the old one, r would they have to be
>> completely different functions to prevent ambiguous input?
>>
>
> About the parts that I don't like: Usin

Re: [sympy] Example plots from the new code

[krastanov.ste...@gmail.com]

On 12 November 2011 22:46, Aaron Meurer  wrote:

> On Sat, Nov 12, 2011 at 2:04 PM, krastanov.ste...@gmail.com
>  wrote:
> >
> >
> > On 12 November 2011 20:43, Aaron Meurer  wrote:
> >>
> >> On Fri, Nov 11, 2011 at 4:25 PM, krastanov.ste...@gmail.com
> >>  wrote:
> >> >
> >> >
> >> > On 11 November 2011 23:31, Aaron Meurer  wrote:
> >> >>
> >> >> On Fri, Nov 11, 2011 at 2:13 PM, krastanov.ste...@gmail.com
> >> >>  wrote:
> >> >> > Hi
> >> >> >
> >> >> > I'm a bit ashamed that Aaron gave better introduction than me for
> my
> >> >> > own
> >> >> > code :)
> >> >> > Anyway, I think the documentation of Plot and the module is quite
> >> >> > detailed
> >> >> > so you can look also at help(Plot) anhelp(newplot).
> >> >> >
> >> >> > About the warnings - my idea was to structure the base backend
> class
> >> >> > in
> >> >> > such
> >> >> > a way that any missing functionality in the backend subclass will
> >> >> > just
> >> >> > raise
> >> >> > a warning but not an error (unless it is some essential
> >> >> > functionality).
> >> >> > So
> >> >> > those will be addressed later.
> >> >> >
> >> >> > It can plot Integrals (due to an old addition done to lambdify
> thanks
> >> >> > to
> >> >> > Certik) but not Sums or anything fancy like product of Kets and
> Bras.
> >> >> > To
> >> >> > do
> >> >> > those a more in depth refactoring of lambda will be needed as
> >> >> > Certik's
> >> >> > method for adding Integral to lambdify does not scale well. I think
> >> >> > this
> >> >> > is
> >> >> > an important problem.
> >> >>
> >> >> I agree.  Is there an issue for this?
> >> >
> >> > No issue for the moment. I take responsibility for creating one when I
> >> > gather enough understanding of the code and the problem.
> >> >>
> >> >> >
> >> >> > Discontinuous functions may pose problems for the moment (none seen
> >> >> > for
> >> >> > the
> >> >> > moment, but this is mostly by chance).
> >> >>
> >> >> As far as I can tell, this is a nontrivial problem to solve, as many
> >> >> very good plotting systems choke on discontinuous functions.  Perhaps
> >> >> there can be some kind of symbolic heuristic applied to find
> >> >> discontinuities.
> >> >
> >> > I think Maple has some option in its plotting module about detecting
> >> > asymptotes (numerically?) but I can not check it at the moment.
> Anyhow,
> >> > this
> >> > is not the most important feature at the moment.
> >> >>
> >> >> >
> >> >> > About the bug in matplotlib - Aaron, you said that you will make a
> >> >> > pull
> >> >> > request for them. Should I do something or you have already taken
> >> >> > care
> >> >> > of
> >> >> > this.
> >> >>
> >> >> Sorry for the misunderstanding, but this is not what I said.  I was
> >> >> suggesting to you that you do it.  I haven't even been able to
> >> >> reproduce the bug you are seeing, so I can't even tell with certainty
> >> >> what the correct fix is.
> >> >
> >> > I'm sorry :D (my mistake). I'll do it.
> >> >>
> >> >> >
> >> >> > I'll start writing tests for the module in the near future. Then
> the
> >> >> > core
> >> >> > devs should tell me if this code is going in and how.
> >> >>
> >> >> I definitely think it should go in.  I guess the question is how to
> >> >> properly replace/merge it with the old module, which isn't compatible
> >> >> (it uses different syntax, keywords, etc.)
> >> >>
> >> >> Actually, to what degree is the new Plot() function incompatible with
> >> >> the old one?  Would it be possible to merge the two without breaking
> &

Re: [sympy] Re: abstract syntax tree

[krastanov.ste...@gmail.com]

Ok, but why are those printed differently (ipython --profile=sympy):

In [34]: sin(x).func
Out[34]: sympy.functions.elementary.trigonometric.sin

In [35]: str(sin(x).func)
Out[35]: sin

In [39]: Integral(x, (x,0,1)).func
Out[39]: sympy.integrals.integrals.Integral

In [40]: str(Integral(x, (x,0,1)).func)
Out[40]: 

What should I do to have them print in the same manner?

On 13 November 2011 00:42, Aaron Meurer  wrote:

> Hi.
>
> As far as I know, we don't have a function that does exactly that,
> though I could be wrong.  It would be nice to have one, though.
>
> On Sat, Nov 12, 2011 at 11:01 AM, Alexey U. Gudchenko 
> wrote:
> > 12.11.2011 21:42, krastanov.ste...@gmail.com пишет:
> >> This:
> >>
> >> import ast
> >> ast.parse(repr(expression))
>
> If you want a repr() representation, you should instead use srepr().
> (repr() is the same as str()).
>
> >>
> >>  will do the trick if repr is well coded.
>
> str() is coded so that it returns the same thing back from sympify(),
> but it may not give the same thing directly, because you can have
> int/int in an expression.  srepr() should always give the same thing
> back.
>
> >>
> >> How much faith should I put in the repr strings in sympy? Or there is
> >> another way?
> >>
> >> On 12 November 2011 18:20, krastanov.ste...@gmail.com <
> >> krastanov.ste...@gmail.com> wrote:
> >>
> >>> Is there any way to get the expression tree from an expression (either
> >>> using the python abstract syntax tree module or just some tuples):
> >>>
> >>> for example
> >>>
> >>> get_tree( x+y*sin(z) ) would return
> >>>
> >>> (Add, x, (Mul, y, (Sin z)))
> >>>
> >>> or
> >>>
> >>> (BinOp, Add, ((Symbol, x), (BinOp, Mul, (blah blah blah
> >>>
> >>
> >
> > I know only how to obtain the childes:
> >
> >>>> e = x+y*sin(z) + z
> >>>> e.args
> > (y*sin(z), z, x)
> >
> >>>> e.args[0]
> >>>> y*sin(z)
> >
> >>>> e.args[0].args
> > (y, sin(z))
> >
> >
> >
> > And test the classes:
> >
> >>>> e.is_Add
> > True
> >
>
> You can get the class name by using .func:
>
> In [25]: e = x + y
>
> In [26]: e.func
> Out[26]: sympy.core.add.Add
>
> In [27]: e.func(*e.args)
> Out[27]: x + y
>
> The invariant in [27] should always hold (except for possibly some
> differences in assumptions).
>
> Aaron Meurer
>
> >
> >
> >
> > In other words, the somewhat tree of the expressions exists.
> >
> > How to represent expression-tree in other formats (strings or
> > structures), I do not know.
> >
> > Regards.
> >
> > --
> > Alexey U.
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "sympy" group.
> > To post to this group, send email to sympy@googlegroups.com.
> > To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: abstract syntax tree

[krastanov.ste...@gmail.com]

Then I suppose I can just call a function that returns a string. Here is
the problem I have:

In [42]: lambdarepr(Integral(x, (x,0,1)).func)
Out[42]: 

In [43]: lambdarepr(Integral(x, (x,0,1)))
Out[43]: Integral(x, (x, 0, 1))

Why is out[42] not the same style as out[43]. This causes problems with
lambdify, so I would be very happy if somebody explains this to me. With
'sin' it gives the same style for both inputs:

In [46]: lambdarepr(sin(x).func)
Out[46]: sin

In [47]: lambdarepr(sin(x))
Out[47]: sin(x)

Is this difference between function and integral expected?


On 13 November 2011 02:09, Mateusz Paprocki  wrote:

> Hi,
>
> On 12 November 2011 17:00, krastanov.ste...@gmail.com <
> krastanov.ste...@gmail.com> wrote:
>
>> Ok, but why are those printed differently (ipython --profile=sympy):
>>
>> In [34]: sin(x).func
>> Out[34]: sympy.functions.elementary.trigonometric.sin
>>
>> In [35]: str(sin(x).func)
>> Out[35]: sin
>>
>> In [39]: Integral(x, (x,0,1)).func
>> Out[39]: sympy.integrals.integrals.Integral
>>
>> In [40]: str(Integral(x, (x,0,1)).func)
>> Out[40]: 
>>
>> What should I do to have them print in the same manner?
>
>
> This seems to be a problem with IPython's printing hooks. In CPython I get:
>
> >>> from sympy import *
> >>> init_printing()
> >>> var('x')
> x
> >>> sin(x).func
> sin
> >>> str(sin(x).func)
> sin
> >>> Integral(x, (x, 0, 1)).func
> 
> >>> str(Integral(x, (x, 0, 1)).func)
> 
>
> There reason for different output in IPython is that IPython not always
> uses SymPy's pretty printer, but sometimes uses its own printing hooks.
> It's better visible in the notebook where latex output is used (e.g. try to
> print data structures).
>
>
>>
>>
>> On 13 November 2011 00:42, Aaron Meurer  wrote:
>>
>>> Hi.
>>>
>>> As far as I know, we don't have a function that does exactly that,
>>> though I could be wrong.  It would be nice to have one, though.
>>>
>>> On Sat, Nov 12, 2011 at 11:01 AM, Alexey U. Gudchenko 
>>> wrote:
>>> > 12.11.2011 21:42, krastanov.ste...@gmail.com пишет:
>>> >> This:
>>> >>
>>> >> import ast
>>> >> ast.parse(repr(expression))
>>>
>>> If you want a repr() representation, you should instead use srepr().
>>> (repr() is the same as str()).
>>>
>>> >>
>>> >>  will do the trick if repr is well coded.
>>>
>>> str() is coded so that it returns the same thing back from sympify(),
>>> but it may not give the same thing directly, because you can have
>>> int/int in an expression.  srepr() should always give the same thing
>>> back.
>>>
>>> >>
>>> >> How much faith should I put in the repr strings in sympy? Or there is
>>> >> another way?
>>> >>
>>> >> On 12 November 2011 18:20, krastanov.ste...@gmail.com <
>>> >> krastanov.ste...@gmail.com> wrote:
>>> >>
>>> >>> Is there any way to get the expression tree from an expression
>>> (either
>>> >>> using the python abstract syntax tree module or just some tuples):
>>> >>>
>>> >>> for example
>>> >>>
>>> >>> get_tree( x+y*sin(z) ) would return
>>> >>>
>>> >>> (Add, x, (Mul, y, (Sin z)))
>>> >>>
>>> >>> or
>>> >>>
>>> >>> (BinOp, Add, ((Symbol, x), (BinOp, Mul, (blah blah blah
>>> >>>
>>> >>
>>> >
>>> > I know only how to obtain the childes:
>>> >
>>> >>>> e = x+y*sin(z) + z
>>> >>>> e.args
>>> > (y*sin(z), z, x)
>>> >
>>> >>>> e.args[0]
>>> >>>> y*sin(z)
>>> >
>>> >>>> e.args[0].args
>>> > (y, sin(z))
>>> >
>>> >
>>> >
>>> > And test the classes:
>>> >
>>> >>>> e.is_Add
>>> > True
>>> >
>>>
>>> You can get the class name by using .func:
>>>
>>> In [25]: e = x + y
>>>
>>> In [26]: e.func
>>> Out[26]: sympy.core.add.Add
>>>
>>> In [27]: e.func(*e.args)
>>> Out[27]: x + y
>>>
>>> The invariant in [27] should always hold

Re: [sympy] Re: abstract syntax tree

[krastanov.ste...@gmail.com]

Can the default printer be changed so lambdarepr(SomeClass(args)) and
lambdarepr(SomeClass(args).func) give always the same thing.

lambdarepr is using LambdaPrinter. What should be done there (or to a
subclass of LambdaPrinter) to ensure the behavior that I desire?

On 13 November 2011 02:21, Mateusz Paprocki  wrote:

> Hi,
>
> On 12 November 2011 17:16, krastanov.ste...@gmail.com <
> krastanov.ste...@gmail.com> wrote:
>
>> Then I suppose I can just call a function that returns a string. Here is
>> the problem I have:
>>
>> In [42]: lambdarepr(Integral(x, (x,0,1)).func)
>> Out[42]: 
>>
>> In [43]: lambdarepr(Integral(x, (x,0,1)))
>> Out[43]: Integral(x, (x, 0, 1))
>>
>> Why is out[42] not the same style as out[43]. This causes problems with
>> lambdify, so I would be very happy if somebody explains this to me. With
>> 'sin' it gives the same style for both inputs:
>>
>> In [46]: lambdarepr(sin(x).func)
>> Out[46]: sin
>>
>> In [47]: lambdarepr(sin(x))
>> Out[47]: sin(x)
>>
>
> Because sin is a Function and Function has a custom printer, which is not
> true for Integral, which is just an ordinary type (default printer).
>
>
>>
>> Is this difference between function and integral expected?
>>
>>
>>
>> On 13 November 2011 02:09, Mateusz Paprocki  wrote:
>>
>>> Hi,
>>>
>>> On 12 November 2011 17:00, krastanov.ste...@gmail.com <
>>> krastanov.ste...@gmail.com> wrote:
>>>
>>>> Ok, but why are those printed differently (ipython --profile=sympy):
>>>>
>>>> In [34]: sin(x).func
>>>> Out[34]: sympy.functions.elementary.trigonometric.sin
>>>>
>>>> In [35]: str(sin(x).func)
>>>> Out[35]: sin
>>>>
>>>> In [39]: Integral(x, (x,0,1)).func
>>>> Out[39]: sympy.integrals.integrals.Integral
>>>>
>>>> In [40]: str(Integral(x, (x,0,1)).func)
>>>> Out[40]: 
>>>>
>>>> What should I do to have them print in the same manner?
>>>
>>>
>>> This seems to be a problem with IPython's printing hooks. In CPython I
>>> get:
>>>
>>> >>> from sympy import *
>>> >>> init_printing()
>>> >>> var('x')
>>> x
>>> >>> sin(x).func
>>> sin
>>> >>> str(sin(x).func)
>>> sin
>>> >>> Integral(x, (x, 0, 1)).func
>>> 
>>> >>> str(Integral(x, (x, 0, 1)).func)
>>> 
>>>
>>> There reason for different output in IPython is that IPython not always
>>> uses SymPy's pretty printer, but sometimes uses its own printing hooks.
>>> It's better visible in the notebook where latex output is used (e.g. try to
>>> print data structures).
>>>
>>>
>>>>
>>>>
>>>> On 13 November 2011 00:42, Aaron Meurer  wrote:
>>>>
>>>>> Hi.
>>>>>
>>>>> As far as I know, we don't have a function that does exactly that,
>>>>> though I could be wrong.  It would be nice to have one, though.
>>>>>
>>>>> On Sat, Nov 12, 2011 at 11:01 AM, Alexey U. Gudchenko 
>>>>> wrote:
>>>>> > 12.11.2011 21:42, krastanov.ste...@gmail.com пишет:
>>>>> >> This:
>>>>> >>
>>>>> >> import ast
>>>>> >> ast.parse(repr(expression))
>>>>>
>>>>> If you want a repr() representation, you should instead use srepr().
>>>>> (repr() is the same as str()).
>>>>>
>>>>> >>
>>>>> >>  will do the trick if repr is well coded.
>>>>>
>>>>> str() is coded so that it returns the same thing back from sympify(),
>>>>> but it may not give the same thing directly, because you can have
>>>>> int/int in an expression.  srepr() should always give the same thing
>>>>> back.
>>>>>
>>>>> >>
>>>>> >> How much faith should I put in the repr strings in sympy? Or there
>>>>> is
>>>>> >> another way?
>>>>> >>
>>>>> >> On 12 November 2011 18:20, krastanov.ste...@gmail.com <
>>>>> >> krastanov.ste...@gmail.com> wrote:
>>>>> >>
>>>>> >>> Is there any way to get the expression tree from an expressio

Re: [sympy] Re: abstract syntax tree

[krastanov.ste...@gmail.com]

Thank you for the information.

On 13 November 2011 02:34, Mateusz Paprocki  wrote:

> Hi,
>
> On 12 November 2011 17:25, krastanov.ste...@gmail.com <
> krastanov.ste...@gmail.com> wrote:
>
>> Can the default printer be changed so lambdarepr(SomeClass(args)) and
>> lambdarepr(SomeClass(args).func) give always the same thing.
>>
>> lambdarepr is using LambdaPrinter. What should be done there (or to a
>> subclass of LambdaPrinter) to ensure the behavior that I desire?
>
>
> So, the difference comes from StrPrinter.emptyPrinter and
> FunctionClass.__repr__. You can override _print_FunctionClass or
> emptyPrinter in LambdaReprPrinter to fix the problem.
>
>
>>
>>
>> On 13 November 2011 02:21, Mateusz Paprocki  wrote:
>>
>>> Hi,
>>>
>>> On 12 November 2011 17:16, krastanov.ste...@gmail.com <
>>> krastanov.ste...@gmail.com> wrote:
>>>
>>>> Then I suppose I can just call a function that returns a string. Here
>>>> is the problem I have:
>>>>
>>>> In [42]: lambdarepr(Integral(x, (x,0,1)).func)
>>>> Out[42]: 
>>>>
>>>> In [43]: lambdarepr(Integral(x, (x,0,1)))
>>>> Out[43]: Integral(x, (x, 0, 1))
>>>>
>>>> Why is out[42] not the same style as out[43]. This causes problems with
>>>> lambdify, so I would be very happy if somebody explains this to me. With
>>>> 'sin' it gives the same style for both inputs:
>>>>
>>>> In [46]: lambdarepr(sin(x).func)
>>>> Out[46]: sin
>>>>
>>>> In [47]: lambdarepr(sin(x))
>>>> Out[47]: sin(x)
>>>>
>>>
>>> Because sin is a Function and Function has a custom printer, which is
>>> not true for Integral, which is just an ordinary type (default printer).
>>>
>>>
>>>>
>>>> Is this difference between function and integral expected?
>>>>
>>>>
>>>>
>>>> On 13 November 2011 02:09, Mateusz Paprocki  wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> On 12 November 2011 17:00, krastanov.ste...@gmail.com <
>>>>> krastanov.ste...@gmail.com> wrote:
>>>>>
>>>>>> Ok, but why are those printed differently (ipython --profile=sympy):
>>>>>>
>>>>>> In [34]: sin(x).func
>>>>>> Out[34]: sympy.functions.elementary.trigonometric.sin
>>>>>>
>>>>>> In [35]: str(sin(x).func)
>>>>>> Out[35]: sin
>>>>>>
>>>>>> In [39]: Integral(x, (x,0,1)).func
>>>>>> Out[39]: sympy.integrals.integrals.Integral
>>>>>>
>>>>>> In [40]: str(Integral(x, (x,0,1)).func)
>>>>>> Out[40]: 
>>>>>>
>>>>>> What should I do to have them print in the same manner?
>>>>>
>>>>>
>>>>> This seems to be a problem with IPython's printing hooks. In CPython I
>>>>> get:
>>>>>
>>>>> >>> from sympy import *
>>>>> >>> init_printing()
>>>>> >>> var('x')
>>>>> x
>>>>> >>> sin(x).func
>>>>> sin
>>>>> >>> str(sin(x).func)
>>>>> sin
>>>>> >>> Integral(x, (x, 0, 1)).func
>>>>> 
>>>>> >>> str(Integral(x, (x, 0, 1)).func)
>>>>> 
>>>>>
>>>>> There reason for different output in IPython is that IPython not
>>>>> always uses SymPy's pretty printer, but sometimes uses its own printing
>>>>> hooks. It's better visible in the notebook where latex output is used 
>>>>> (e.g.
>>>>> try to print data structures).
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On 13 November 2011 00:42, Aaron Meurer  wrote:
>>>>>>
>>>>>>> Hi.
>>>>>>>
>>>>>>> As far as I know, we don't have a function that does exactly that,
>>>>>>> though I could be wrong.  It would be nice to have one, though.
>>>>>>>
>>>>>>> On Sat, Nov 12, 2011 at 11:01 AM, Alexey U. Gudchenko <
>>>>>>> pr...@goodok.ru> wrote:
>>>>>>> > 12.11.2011 21:42, krastanov.ste...@gmail.com пишет:
>

[sympy] new experimental lambdify - now we can plot sums

[krastanov.ste...@gmail.com]

Hi,

You may know that lambdify was not working with Sums, quantum stuff, and
actually almost any nontrivial expression.

I have rewritten it for use in the plotting module using a very different
approach. It's experimental and I very much doubt that it will replace the
current lambdify (it has to many differences). But for the moment it works
great. And I'm actually very happy with the code. It's well documented and
it's in sympy/plotting/experimental_lambdify.py in my pull request branch.

See this plot for an example (the plotting module uses lambdify for
calculations):
In [2]: p = Plot(Sum(k, (k, 0, floor(x))), (x, 0, 10))
In [4]: p
Out[4]:
  Plot object containing:
[0]: cartesian line: Sum(k, (k, 0, floor(x))) for x over (0.0, 10.0)
In [5]: p.axis_center = (0, 0)
In [6]: p.title = str(p[0])
In [7]: p.show()

The old lambdify was not capable of this. All the explanations are in the
documentation.

Now that the plotting module almost works, I'll have to stop writing code
and focus on documentation - there were quite a bit of issues around
lambdify that are not yet in the issue tracker.

If anybody tests the code and find bugs, I would be glad to help with them.
But I do not think that it would be ready for merging soon. It' in pull
request 673.

Best regards
Stefan

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

<>

Re: [sympy] lambdify again

[krastanov.ste...@gmail.com]

On 13 November 2011 21:10, Aaron Meurer  wrote:

> On Sat, Nov 12, 2011 at 9:44 AM, krastanov.ste...@gmail.com
>  wrote:
> > Hi,
> >
> > I was bashing lambdify lately, but it seems this function is smarter than
> > me. I'll skip the details about what I incorrectly thought the problem
> was
> > and present the real problem.
> >
> > This works great:
> >
> > lambdify(x, Integral(y, (y, 0, x)))
> >
> > _(2)  --->  Integral(y, (y, 0, 2))
> >
> > float(_) ---> the right numeric answer
> >
> > This also works great:
> >
> > lambdify(x, Integral(sqrt(y), (y, 0, x)), modules='sympy')
> >
> > _(2)  --->  Integral(sqrt(y), (y, 0, 2))
> >
> > float(_) ---> the right numeric answer
> >
> > This does not work because sqrt is translated to the numpy function
> >
> > lambdify(x, Integral(sqrt(y), (y, 0, x)))
> >
> > _(2)  --->  ValueError: Symbolic value, can't compute
> >
> > Any ideas? That is not a bug a priori but it should at least be very well
> > documented.
>
> That looks like a bug to me.  It shouldn't use the numpy sqrt unless
> you pass "numpy" as the third argument.
>
Ok, but if I want to use numpy and sympy (eg
np.sqrt(y)*Integral(sympy.sqrt(x))) I can't do it. I would want to do this
for fast sqrt outside the integral, and for valid integral expression
inside the integral. But now I can not lambdify integrals containing sqrt
and at the same time translate the rest of the functions to numpy.

The experimental_lambdify that I wrote fixes this problem by not making
translation for arguments of functions if the function itself is not
translatable. Integral is not translatable, so only the sqrt outside the
integral will be translated.

>
> Aaron Meurer
>
> >
> >
> > P.S. And the docstring should not tell people that lambdify is for
> numeric
> > calculation when it does not return floats.
> > P.P.S The fact that lambdify can not do Sums, stuff from the physics
> module,
> > etc is another problem.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "sympy" group.
> > To post to this group, send email to sympy@googlegroups.com.
> > To unsubscribe from this group, send email to
> > sympy+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/sympy?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Example plots from the new code

[krastanov.ste...@gmail.com]

On 13 November 2011 21:19, Aaron Meurer  wrote:

> > Next release:
> > from sympy.plotting import plot # the function you proposed
> > from sympy.plotting import Plot # the old Plot with added deprecation
> > warning
> > from sympy.plotting.newplot import Plot # the new Plot
> > No complicated proxy object
>
> So how soon do you expect to have something workable enough (i.e., the
> API should be stable) to merge then?  We'll hopefully release in
> December or January when I get off of classes and have enough time to
> do it.
>
> A stable api by the end of the month, and documentation before the
release. It's not much work, almost all is already done. It's just that
'almost all' = 'the interesting part' and it will be harder to find time
for the rest. But it will be ready before the release.

The api for noncartesian plots wont be ready for the release. But that
would be an addition to the current api, not a change.


 Aaron Meurer
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

[sympy] Re: new experimental lambdify - now we can plot sums

[krastanov.ste...@gmail.com]

On 13 November 2011 19:34, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> Hi,
>
> You may know that lambdify was not working with Sums, quantum stuff, and
> actually almost any nontrivial expression.
>
> I have rewritten it for use in the plotting module using a very different
> approach. It's experimental and I very much doubt that it will replace the
> current lambdify (it has to many differences). But for the moment it works
> great. And I'm actually very happy with the code. It's well documented and
> it's in sympy/plotting/experimental_lambdify.py in my pull request branch.
>
> See this plot for an example (the plotting module uses lambdify for
> calculations):
> In [2]: p = Plot(Sum(k, (k, 0, floor(x))), (x, 0, 10))
> In [4]: p
> Out[4]:
>   Plot object containing:
> [0]: cartesian line: Sum(k, (k, 0, floor(x))) for x over (0.0, 10.0)
> In [5]: p.axis_center = (0, 0)
> In [6]: p.title = str(p[0])
> In [7]: p.show()
>
> The old lambdify was not capable of this. All the explanations are in the
> documentation.
>
> Now that the plotting module almost works, I'll have to stop writing code
> and focus on documentation - there were quite a bit of issues around
> lambdify that are not yet in the issue tracker.
>
> If anybody tests the code and find bugs, I would be glad to help with
> them. But I do not think that it would be ready for merging soon. It' in
> pull request 673.
>
I told Aaron that it should be ready before the next release (December).

>
> Best regards
> Stefan
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Example plots from the new code

[krastanov.ste...@gmail.com]

On 14 November 2011 17:36, Aaron Meurer  wrote:

> On Sun, Nov 13, 2011 at 1:35 PM, krastanov.ste...@gmail.com
>  wrote:
> >
> > On 13 November 2011 21:19, Aaron Meurer  wrote:
> >>
> >> > Next release:
> >> > from sympy.plotting import plot # the function you proposed
> >> > from sympy.plotting import Plot # the old Plot with added deprecation
> >> > warning
> >> > from sympy.plotting.newplot import Plot # the new Plot
> >> > No complicated proxy object
> >>
> >> So how soon do you expect to have something workable enough (i.e., the
> >> API should be stable) to merge then?  We'll hopefully release in
> >> December or January when I get off of classes and have enough time to
> >> do it.
> >>
> > A stable api by the end of the month, and documentation before the
> release.
> > It's not much work, almost all is already done. It's just that 'almost
> all'
> > = 'the interesting part' and it will be harder to find time for the rest.
> > But it will be ready before the release.
> >
> > The api for noncartesian plots wont be ready for the release. But that
> would
> > be an addition to the current api, not a change.
> >
>
> Awesome.  Is there an issue for this, or just a pull request?  If
> there's not an issue, can you create one, and put the
> milestone-release-0.7.2 tag on it, so that we don't forget about it
> come release time?
>
> Just created one: 2845
http://code.google.com/p/sympy/issues/detail?id=2845&thanks=2845&ts=1321305364

Stefan


> Aaron Meurer
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: Latex -> Sympy

[krastanov.ste...@gmail.com]

On 15 November 2011 18:25, Aaron Meurer  wrote:

> Does anyone know of a good framework to implement this in, so that it
> is easily extensible (something like the printer, only backwards)?
> Obviously, we can implement the simple cases like \frac{}{} and ^
>
Actually even the \frac{}{} stuff can not be done with only regular
expressions. They can't match parenthesis in nested expressions.

> using regular expressions, but it would be nice to have a more
> powerful (heuristic) parser in place, so that it's easy to extend to
> do many more things.
>
> Nonetheless, it would be good to have a module that starts even with
> simple regular expressions, because then we will start to see what
> needs to be done, and what the real limitations of it are.
>
> Aaron Meurer
>
> 2011/11/15 Ondřej Čertík :
> > On Sun, Nov 13, 2011 at 3:25 AM, Vincent MAILLE 
> wrote:
> >> OK, thanks for your answers. It's true that LaTeX is complexe to
> >> parse. My question was juste for very simple expressions :
> >>
> >> \frac{..}{..} => (...)/(...)
> >> 2x+x^2 => 2*x+x**2
> >
> > I think it's definitely doable, and someone just has to do it for
> > simple expressions and then (if there is interest) it can be improved
> > for more complex ones. It will never be able to parse 100% of all
> > latex, but I can imagine it to work just fine for normal math that
> > people use.
> >
> > Ondrej
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "sympy" group.
> > To post to this group, send email to sympy@googlegroups.com.
> > To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> > For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Re: Releasing SymPy 0.7.2

[krastanov.ste...@gmail.com]

In pull request 673 there is a new plotting module. It's functional and
Aaron and Ondrej were interested in merging it before the next release.

It seems that the release will be sooner than expected. Does this change
the plans about the pull request 673? As I've said the code is mostly
ready, but it is not reviewed at all and all the documentation is only in
docstrings. There are also no tests.

Stefan

On 15 November 2011 20:37, Mateusz Paprocki  wrote:

> Hi,
>
> On 14 November 2011 23:02, Mateusz Paprocki  wrote:
>
>> Hi,
>>
>> Is there a chance we could release SymPy 0.7.2 in two weeks? Early
>> December I will give a tutorial about SymPy and I would like to take
>> advantage of Python 3 support and new features.
>>
>
> I started https://github.com/sympy/sympy/wiki/Release-Notes-for-0.7.2.
> All developers are welcome to fill in the gaps. Major changes section
> should include new modules (mechanics, combinatorics, Python 3, etc.). If
> you feel that there are other changes that should be marked as "major"
> (e.g. PyPy support), feel free to add them there. There are almost 1200
> commits since last release, so there is a lot of work to be done.
>
> I set the release date to 1 December. This is the last day I can do
> release on my own. This date implies that 24 November should be the last
> day we accept changes for 0.7.2 release.
>
> Note that this release will require more testing than before, because we
> now support Python 3 (>= 3.2) and PyPy (>1.6.0, possibly nightly build).
> Other Python versions include 2.5, 2.6 and 2.7. Tests have to be run on
> 32-bit and 64-bit architectures, with and without GMPY, with and without
> NumPy/SciPy, on Windows, Linux and Mac.
>
> Ondrej, can sympy-bot be used to test release branch?
>
> If there are any issues that have to be fixed before release, please mark
> them as critical. There are currently 52 open issues targeted for 0.7.2
> release. Most of them won't be fixed until then so we have to either
> reschedule them or erase milestone information (I think the later should be
> done with most of those issues).
>
>
>>
>> Mateusz
>>
>
> Mateusz
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Google Code-In

[krastanov.ste...@gmail.com]

Hi,

I would be able to spent an hour or two on that Saturday afternoon
(European time, from 14UTC to 18UTC) and maybe Friday evening (22UTC) but:

1. I have no editing rights on the google docs document.
2. I have logged on melange, but there are no project pages or anything.
3. I may be missing something else, so don't shy from offering suggestions
for work that has to be done.

Stefan

On 17 November 2011 18:35, Aaron Meurer  wrote:

> On Thu, Nov 17, 2011 at 10:33 AM, Aaron Meurer  wrote:
> > I just looked at the bulk upload requirements, and we need to do some
> > more work on the spreadsheet.  Here are the requirements:
> >
> > 1. Title of the task.
> >
> > 2. Description, for markup use HTML.
> >
> > 3. Time to complete in hours, as integer.
> >
> > 4. Link ID's of mentors for this task, comma separated.
> >
> > 5. Difficulty, one of the allowed difficulties (Easy, Hard, Medium).
> >
> > 6. Task types, one or more of the allowed types (Code, Documentation,
> > Outreach, User Interface, Research, Training, Translation, Quality
> > Assurance), comma separated.
> >
> > 7. Task tags, any custom tags you want to add, comma separated.
> >
> > So we need to add the following to the spreadsheet:
> >
> > - Descriptions for everything.
> > - Time to complete data.
> > - Link ID's for mentors (since we don't have any mentors registered
> > yet, this may not be so easy...)
> > - Custom tags (maybe import the labels from the issue tracker)?
> >
> > Furthermore, it appears that a task can be a part of more than on
> > category at once.  I'll make this change in the issue tracker, but I
> > think for now, it may be easiest to just leave the ones we have alone,
> > and only consider this for future tasks.
> >
> > If someone can help me this weekend (or sooner) to fix this up, that
> > would be great. I'd like to have the tasks in by Monday, so the
> > students can start straight away.
> >
> > Aaron Meurer
>
> And also apparently that's a hard deadline, as any tasks submitted
> after Monday will not be added until December 16.
>
> One more note: tasks cannot be modified in the system after they are
> put online.  So I think for our description, most of them should just
> have some standard text that points to the issue.
>
> Aaron Meurer
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Google Code-In

[krastanov.ste...@gmail.com]

About all the video tutorial tasks and similar: Should we demand the use of
IPython or the explicit mention of IPython or something else to that
effect. I imagine someone looking at the tutorial saying 'Is this basic
python interpreter really the only option?' or 'That output/printing is
absolutely unreadable'.

On 18 November 2011 22:43, Aaron Meurer  wrote:

> For people who aren't yet in the melange system:
>
> You need to go to
> http://www.google-melange.com/gci/profile/mentor/google/gci2011 and
> create a profile.  Then (and only then) can I send you a mentor invite
> (or hopefully you can send a request, as soon as they implement that).
>  For some reason, there isn't a link to the profile creation page when
> you login.
>
> Aaron Meurer
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Google Code-In

[krastanov.ste...@gmail.com]

What is the state of the mentor Id requirement for the tasks? When and how
should those be added?

On 19 November 2011 15:49, krastanov.ste...@gmail.com <
krastanov.ste...@gmail.com> wrote:

> About all the video tutorial tasks and similar: Should we demand the use
> of IPython or the explicit mention of IPython or something else to that
> effect. I imagine someone looking at the tutorial saying 'Is this basic
> python interpreter really the only option?' or 'That output/printing is
> absolutely unreadable'.
>
>
> On 18 November 2011 22:43, Aaron Meurer  wrote:
>
>> For people who aren't yet in the melange system:
>>
>> You need to go to
>> http://www.google-melange.com/gci/profile/mentor/google/gci2011 and
>> create a profile.  Then (and only then) can I send you a mentor invite
>> (or hopefully you can send a request, as soon as they implement that).
>>  For some reason, there isn't a link to the profile creation page when
>> you login.
>>
>> Aaron Meurer
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to sympy@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sympy?hl=en.
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.

Re: [sympy] Google Code-In

[krastanov.ste...@gmail.com]

On 19 November 2011 18:38, Matthew Rocklin  wrote:

> Can we add tasks midstream? Can we add tasks now?
>
You can add tasks to the issue tracker, tag them appropriately and then
import them to the google spreadsheet. The spreadsheet will be imported in
the GCI tasklist on Monday and no changes will be possible until 16. Dec.
I'm sending you the google spreadsheet now.

Stefan

>
>
I was thinking it'd be nice to add module specific tutorials/documentation.
> I.e. it'd be nice to have a tutorial that tells you all about integration
> or a tutorial that tells you all about Matrices. These seem like important
> tasks that would be doable for high school students.
>
> -Matt
>
>
> On Sat, Nov 19, 2011 at 9:39 AM, krastanov.ste...@gmail.com <
> krastanov.ste...@gmail.com> wrote:
>
>> What is the state of the mentor Id requirement for the tasks? When and
>> how should those be added?
>>
>>
>> On 19 November 2011 15:49, krastanov.ste...@gmail.com <
>> krastanov.ste...@gmail.com> wrote:
>>
>>> About all the video tutorial tasks and similar: Should we demand the use
>>> of IPython or the explicit mention of IPython or something else to that
>>> effect. I imagine someone looking at the tutorial saying 'Is this basic
>>> python interpreter really the only option?' or 'That output/printing is
>>> absolutely unreadable'.
>>>
>>>
>>> On 18 November 2011 22:43, Aaron Meurer  wrote:
>>>
>>>> For people who aren't yet in the melange system:
>>>>
>>>> You need to go to
>>>> http://www.google-melange.com/gci/profile/mentor/google/gci2011 and
>>>> create a profile.  Then (and only then) can I send you a mentor invite
>>>> (or hopefully you can send a request, as soon as they implement that).
>>>>  For some reason, there isn't a link to the profile creation page when
>>>> you login.
>>>>
>>>> Aaron Meurer
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "sympy" group.
>>>> To post to this group, send email to sympy@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> sympy+unsubscr...@googlegroups.com.
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/sympy?hl=en.
>>>>
>>>>
>>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "sympy" group.
>> To post to this group, send email to sympy@googlegroups.com.
>> To unsubscribe from this group, send email to
>> sympy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/sympy?hl=en.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to 
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sympy?hl=en.