from:"Stefan Krastanov"

[sympy] test failure on pypy (in `integrals`)

2014-06-02 Thread Stefan Krastanov

I do not understand what is happening here:
https://travis-ci.org/sympy/sympy/jobs/26515720

It seems unrelated to the pull request being tested (I am going ahead
an merging it), but finding the root cause might be of interest.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAD8szLyN4U-HbPrTUmO31%2B%3DEL9-X-xYKa-OqvXDWaUXswoC2Ow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Re: help with the geometric module project api

2014-05-24 Thread Stefan Krastanov

 We could do it in the Plane class as you above described but that would also
 require a lot of if instance statements in the plane class as well  as we
 have to check whether a point is 2D or 3D and act accordingly.

I do not see why this would be the case. Could you give an example?
Projections work only on 3d points. Promotion to 3d works only on 2d
points. These are very different operations. There is no need of
switch/case statements.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAD8szLy4xpdsYEnZxuAjdzvcfXhxre9iqqFzaL6fHh42QR_oYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[sympy] help with the geometric module project api

2014-05-23 Thread Stefan Krastanov

Hi all,

It would be great if you can comment on the upcoming API for the 3D
geometry module.

The current module has a nice class structure for 2D objects (points,
planar figures, conics) and does not support anything in 3D.

For the moment this is the approach taken to extending it to 3D. It
nicely minimizes code duplication, but something does not seem right
to me.

- class Point3D
  - it receives 2 or 3 coordinates on creation
- 2 points means that the last one is set to zero by default
  - it has all the fancy methods to find midpoints, create lines, etc.

- class Point (it is Point2D, but for backward compatibility is called
just Point)
  - subclass of Point3D
  - it is a very shallow subclass of Point3D where the last coordinate
is set to 0
  - it has a method to convert to a 3D point and most of the
calculations are done with it


pros:
- very little code duplication
cons:
- a lot of `if isinstance` inside the Point3D code to check and
convert Point to Point3D
- Point and Point3D seem unnecessarily tightly coupled
- I do not like how a lot of the classification whether something is
3d or 2d is done by checking the number of coordinates (implicitly)
and not by classes (explicitly)


I think a better approach would be to not touch `Point` at all, and
implement Point3D independently. This will require some minor code
duplication. However total length of code will not be higher and the
code will be much easier to understand. Compare this to right now:
there are a lot of `isinstance` checks in the base implementation of
most methods, which is a serious antipattern.

When this is done we can see whether it makes sense to abstract
anything in a base class.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAD8szLy%3DazQhBt-a-ouq9Ynh7ner2Fp76B2FkBGEdxGwPS0X9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] help with the geometric module project api

2014-05-23 Thread Stefan Krastanov

@Joachim, you are right about what you say, but I do not think it
applies to the geometry module.

Everything below is just an opinion, moreover I am not the original
author the the geometry module, so take it with a grain of salt.

The geometry module was created as a tool for high school euclidean 2d
geometry and it was never meant to be used in advanced abstract math
or to work in any number of dimensions (e.g. nobody will use it for
elliptical curves cryptography or for geometry over a field that is
not the real numbers). We have two options to go forward:

- generalize it to N dimensions (which is not what this gsoc project
is doing and it will probably never be done (a completely new module
is more realistic))
- make it work in 3D (what this project is doing and what I discuss below)

Given that it is only 2d and 3d that we are working on, I think a
minor amount of code duplication[1] is a good thing, as it will make
the code simpler.

[1] at least in the beginning: during code reviews we can see whether
there is something worth abstracting away.

Going back to the current work in progress:
While I do not have a very strong opinion on the above, there is one
thing I insist on. A large amount of `if 2d:... elif 3d:...` snippets
is an obvious antipattern in an OO language. The current works has a
lot of them and it was the reason for which we decided to push the
conversation to the mailing list.

On 23 May 2014 15:08, Joachim Durchholz j...@durchholz.org wrote:
What's the status of those things that exist in the same way regardless of
number of dimensions?
Things like calculating a volume, constructing an orthogonal base,
calculating distances - all the linear algebra stuff that applies to
geometry.

Ideally, it would all be the same code base (or transformation rule set).

I know nothing about the geometric module project or its goals, so I'm not
sure whether this kind of thing is even useful for the project, let alone
doable.
But I'd like to know. The question which of the various geometric ADTs and
algorithms transfer neatly to higher dimensions, which do not, and which are
mere analogies has been haunting me since high school, so I'm too curious to
not ask ;-)

--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an
email to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/537F9CC3.5060501%40durchholz.org.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAD8szLzzvr4PvMRC8x0Rd%2B-6PR_NjPO0EQ3yBuKtUVjERSJ3Fw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Re: help with the geometric module project api

2014-05-23 Thread Stefan Krastanov

 The reason for the classes to be tightly coupled was to enable such
 computations
  a = Point3D(1,2,3)
  a.distance(Point(2,3)) This returns the distance between these two points.
 This is one of the possible four combinations(as in distance between 2 3D
 points, 2 2D points, 3D and 2D point)

 So i have a question
 1) Should the above code work as in should it give the result (sqrt(11)) in
 the above case or should it raise an nonimplement error as they are 2
 different classes(3D and 2D)

My opinion was that it does not make sense to calculate anything
between 3D and 2D points, as they live in different spaces. However
there should be a way to promote 2D point to 3D like the following:

 plane = ... # some object representing a 2D plane in 3D space
 point = ... # some 2d point
 point3D = promote_to_3D(point, plane)
# taking `point`, assuming that it is on `plane` and
# returning the corresponding 3D point

There can be a default plane (x,y,z=0)

There should also be a way to project a 3d point on a plane or a line.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAD8szLygrQUCGMPgWxpAJe50KSSB4RAq2di0jurkSYrRkaj6fA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] help with the geometric module project api

2014-05-23 Thread Stefan Krastanov

 What are you looking for in a geometry module.  Please give an example of a
 problem you wish to pose.

At the moment it is best adapted at simple euclidean geometry question
(high school geometry and stereometry + simple operations on conics):

Give me the intersection of this and that. Define this conic, rotate
it that much, give me the intersection with this circle, etc. Test
whether this point is in this triangle, test whether this line and
this figure intersect.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAD8szLyLY7SST9KjMSb3yqRXvKr11n3_s8_0GDWAsB%3D%2BSpV5PQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[sympy] visualization of recursion

2014-05-05 Thread Stefan Krastanov

You might find this interesting for debugging and code-diving.

https://zvzzt.wordpress.com/2014/05/03/python-recursion-visualization-with-rcviz/

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAD8szLyiAEkM-vmwCxokshVk4-nmcbr_XtmMByoRqhSbUQUJ-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Re: Parallel Processing

2014-04-29 Thread Stefan Krastanov

There is also the ipython cluster which seems quite similar to parallelpython.

On 27 April 2014 20:37, Aaron Meurer asmeu...@gmail.com wrote:
I've never heard of that before. I guess you can try importing sympy
and running the tests in it, and that will tell you what works and
what doesn't, at least as a start.

Aaron Meurer

On Sun, Apr 27, 2014 at 7:01 AM, Alan Bromborsky abro...@verizon.net wrote:
No I mean parallel python http://www.parallelpython.com/ which gets around
the problem of the GIL.

On 04/27/2014 06:48 AM, F. B. wrote:

I am not very expert of parallel processing in Python, but as no one else is
answering, and supposing you mean multithreading, I'll point out the problem
concerned with multithreading in Python.

Python's main implementation, CPython, has a Global Interpreter Lock (GIL),
which forbids the interpreter to create new threads. When you use modules
such as threads, CPython is still using a single thread which emulates
multithreading. I don't believe you will get some speedup, that threading
support looks more like a control flow on the code.

http://en.wikipedia.org/wiki/Global_Interpreter_Lock

Multiprocessing should be able to fork an independent process on the CPU,
but unfortunately a new process requires the memory space of the previous
process to be cloned as well, which may be not very comfortable. IPython
supports cluster distribution of computations on many computers.

PyPy should have a better support for multithreading, as far as I know.

On Friday, April 25, 2014 6:13:01 PM UTC+2, brombo wrote:

Has anyone had any experience in using parallel python with sympy. It
seems to me that there are probably a lot of loops that have independent
operations.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAD8szLxnKP93_zXej68WBLDKn4ct0drU_Xge27KVwQbW8Ldt%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Re: Tensor refactory

2014-03-30 Thread Stefan Krastanov

Here is an example why `__eq__` should correspond to structural equality:

 class a(object):
... def __eq__(self, other):
... raise NotImplementedError()
...

 i = a()

 list = [1,2,3,i]

 list.index(i)
Traceback (most recent call last):
  File stdin, line 1, in module
  File stdin, line 3, in __eq__
NotImplementedError



__eq__ is part of basic python protocols, we should not  make it do
other things.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAD8szLxfMiWvhFxkELqSwFdJTauce8jr0%3DHz-AmiCA3UnGs%2BSw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Re: Everything that i can plot using SymPy!

2014-03-29 Thread Stefan Krastanov

I am a bit confused by the question. You should be able to plot all
sympy expressions that can be evaluated to a number.

If you are asking about types of plots: In 3D it would be

- z=f(x,y)
- parametric lines
- parametric surfaces

On 29 March 2014 21:45, richard B rich...@boyd.org.nz wrote:
Tried numpy?

On Friday, March 21, 2014 10:30:42 PM UTC+13, SAHIL SHEKHAWAT wrote:

specially in matplotlib..
and specifically to 3D

On Friday, March 21, 2014 2:59:49 PM UTC+5:30, SAHIL SHEKHAWAT wrote:

I wanted some help, if someone can please shed light on all types of
things that we can plot using sympy?

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAD8szLyYx5K2mLfvzocy_W5rXAqTjtzaZ%2BOU%3Dy9D3PZxGxYACg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Tensor refactory

2014-03-28 Thread Stefan Krastanov

 I came to the conclusion that the best solution to implement Quantum Field
 Theory in SymPy is to use the unify module combined with the new tensor
 module.

I can not agree more with statement. I would be the happiest person on
Earth if you/the community succeeds at such a refactoring. I actually
tried to do it on one or two occasions (it actually happened exactly
when you joined us), but such a task is beyond me and regrettably I
will not have free time in the near future to help.

Sorry for this rather nonconstructive post, I just wanted to say that
I am happy that somebody is thinking about this.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAD8szLyr1qqFoKwUcOOCrcfs%2B%3DeretJ8g1bNAnb5CTJ0HrcY-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Tensor refactory

2014-03-28 Thread Stefan Krastanov

Stefan, can you give a brief explanation of your experience? In particular
what difficulties did you run into?

The current tensor canonicalization and representation for tensors
does not adhere to most of sympy's class invariants.

- eq is occasionally about mathematical equality, not structural one,
and it is even raising errors in some cases, which break dictionary
lookups and so on

- you can not recreate objects using func and args

- substitution does not work (nothing related to tree traversal works actually)

- many others in the same style

In one sentence: the implemented algorithms are very smart, but they
completely disregard the invariants that sympy uses to work with the
symbolic trees.

I tried to go step by step and reinstate these invariants, but my
knowledge of the module was insufficient. (actually, going in the
other direction might be easier: the module when I was looking at it
was not using any of sympy's methods, so it was not really necessary
to subclass Basic or Expr).

In any case Franz is more aware of these issues than me and he was
working on fixing some of them (I was not following the work so I do
not know how much of this is still relevant).

On Fri, Mar 28, 2014 at 6:17 PM, Stefan Krastanov
stefan.krasta...@yale.edu wrote:

I came to the conclusion that the best solution to implement Quantum
Field
Theory in SymPy is to use the unify module combined with the new tensor
module.

I can not agree more with statement. I would be the happiest person on
Earth if you/the community succeeds at such a refactoring. I actually
tried to do it on one or two occasions (it actually happened exactly
when you joined us), but such a task is beyond me and regrettably I
will not have free time in the near future to help.

Sorry for this rather nonconstructive post, I just wanted to say that
I am happy that somebody is thinking about this.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAD8szLw1M6E-OLrhsqqW0_RsocXywtF8Ost2%3D3kD7Vp4-3O_Kw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [sympy] Very Late GSoC application

2014-03-20 Thread Stefan Krastanov

@Matthew, in general I would agree, but the algorithms for translating
Lagrangian - Feynman rules or Feynman rules + initial and final
state - differential cross section are already both 1) non trivial
and 2) domain specific. Abstracting this away might not be worth it as
it is not really used anywhere else.

(but where it is used, it is used a lot. There is an entire standard
around it (UFO model files and Les Houches dump files as described in
the FeynRules and MadGraph projects))

Exception: It might be useful in calculating correlations of some
multivariate functions through series expansions. That might we worth
investigating somewhat more.


On 20 March 2014 14:34, Matthew Rocklin mrock...@gmail.com wrote:
 My thoughts on what's written so far are different from Ondrej's.  I am less
 excited by physics applications and more excited by the tools necessary to
 enable the expression of physics applications.  The extent to which a domain
 specific project like this can be broken into a generally applicable
 component (some mathy or algorithmic bit) and a domain specific application
 (some physics thing) is good.  This increases the applicability and
 relevance of a summer project to a wider audience.


 On Thu, Mar 20, 2014 at 11:25 AM, Ondřej Čertík ondrej.cer...@gmail.com
 wrote:

 On Thu, Mar 20, 2014 at 12:17 PM, Ondřej Čertík ondrej.cer...@gmail.com
 wrote:
  Hi Peter,
 
  I read through your ideas. First of all, I started SymPy as a
  theoretical physics student myself,
  and I wanted to automate the General Relativity as well as high energy
  QFT calculations. I am still
  very interested in that, but there are a lot of tough problems and
  parts that need to be in place.
 
  You need to be able to do integrals, handle potentially large
  formulas, tensor manipulation and simplification
  (e.g. gamma matrices), and so on. It's not easy at all, but we've done
  a long progress since the time I started
  SymPy in 2007 or so. Most of these things are in place, in some form.
  In order to efficiently handle very large
  expressions, I started developing CSymPy about half a year ago
  (https://github.com/certik/csympy), this
  will come very handy as well for these applications.
 
  The best way to get some ideas of what can be done is to look into
  existing packages, they are pretty much
  all in Mathematica. In fact, most theoretical physicist just use
  Mathematica. And let's be frank, it's currently the
  best if you just care about getting the results. There is also GiNaC
  (http://www.ginac.de/) that can be used for some of the
  high energy stuff, but CSymPy can now do pretty similar things,
  sometimes faster. So there is:
 
  http://www.feyncalc.org/
 
  there are all these various things people wrote for Mathematica:
 
  @article{huber2012crasydse,
title={CrasyDSE: A framework for solving Dyson--Schwinger equations},
author={Huber, Markus Q and Mitter, Mario},
journal={Computer Physics Communications},
volume={183},
number={11},
pages={2441--2457},
year={2012},
publisher={Elsevier}
  }
 
  @article{huber2012algorithmic,
title={Algorithmic derivation of functional renormalization group
  equations and Dyson--Schwinger equations},
author={Huber, Markus Q and Braun, Jens},
journal={Computer Physics Communications},
volume={183},
number={6},
pages={1290--1320},
year={2012},
publisher={Elsevier}
  }
 
  But the advantage of SymPy is that the whole stack is opensource, and
  SymPy is just a library, so it better integrates
  with things like IPython Notebook and you can create the whole
  application in it. For example, the physics.quantum
  module has some good stuff, that plays together much better than
  packages in Mathematica. Another great application is PyDy.
 
  So it would be really nice to have the project that you describe. You
  should have a look at work done by Francesco Bonazzi
  regarding the gamma matrices:
 
  https://github.com/Upabjojr
  https://github.com/sympy/sympy/pull/2601
 
  He has lots of PRs, closed and open. It's nontrivial. And those are
  just the gamma matrices. I think Francesco's goal
  could be summarized by your proposal, and he's done many months worth
  of work on it already. So the scope is just huge.
  So there is plenty of things that could be done for the summer.
 
  One of the things is for example just the Feynman diagrams generator
  for various Lagrangians. I am sure there must be some
  packages that do that, but it'd be nice to integrate this with SymPy
  and create nice IPython Notebooks that generate all the correct
  diagrams, for example from Peskin  Schroeder. This will be good for

 I.e. this would involve some classes for representation of Feynman
 diagrams,
 that would also know how to nicely visualize themselves in the IPython
 Notebook,
 and then code that generates them for various interactions.
 And so on.

 For other ideas, I have some derivations of various things here:

Re: [sympy] Re: GSoC 2014: Regarding Plotting ideas.

2014-03-05 Thread Stefan Krastanov

We will probably also require documentation (in docstrings, which were
not modified in your attachment) and tests.

On 5 March 2014 11:22, Ondřej Čertík ondrej.cer...@gmail.com wrote:
On Wed, Mar 5, 2014 at 7:13 AM, Shashank Aggarwal
shashank.agarwa...@gmail.com wrote:

Hi Ondrej.
Thanks for the reply.

I have modified sympy/plotting/plot.py to include the option for domain
detection of periodic functions.Kindly have a look,and suggest any feedback.

Usage: plot(sin(x*4),auto_domain=True)

Send it as a PR, so that we can quickly see what changes you made and
can just checkout your branch to play with it.

Ondrej

--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAD8szLwCddbOBHQfxuatLh3Ce8t_QRwrwJus0xf5OaTrt-bR7w%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: GSoC: Introducing Optical Physics

2014-03-03 Thread Stefan Krastanov

Why is physics.vector better for optics compared to just a column matrix?

On 3 March 2014 07:23, Sudhanshu Mishra mrsu...@gmail.com wrote:
 To get started should I add a module to solve problems related to Kepler's
 laws? It will give me a basic idea of physics.vector.


 On Monday, March 3, 2014 5:39:35 PM UTC+5:30, Sachin Joglekar wrote:

 I would suggest you to go through the API of physics.vector package and
 see if you have all the functionality you need. I think you should. Once you
 have done that, you can start thinking of how you will base your work on
 that module, the target API, etc. Once you have some idea, you can start
 putting down your proposal on the SymPy wiki, so that we can help you refine
 it.
 (Dont forget about the PR requirement)

 On Monday, March 3, 2014 4:13:29 PM UTC+5:30, Sudhanshu Mishra wrote:

 Hi

 I am a second year undergraduate student of Information Systems from BITS
 Pilani, India.
 I like Physics and I've been using Python for an year. I started
 developing a Python package called BinPy for electronics computation and
 simulation.
 This is my Github profile.

 I want to propose an idea to introduce a new package for optical physics
 in sympy. I want to do this as a project under GSoC14.

 Since we already have vector, optical physics can easily be implemented.
 As of now only Guassian optics is available.
 If we add more things like Newtonian optics, Maxwell's equation, Fermat's
 principle, Snell's laws and many more concepts,
 It would be very helpful for the users to do scientific computations
 related to optics using sympy.

 If you like this idea, guide me what should I do now to get familiar with
 the physics package of sympy.

 With Regards
 Sudhanshu Mishra

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/sympy/93b54396-439e-4c0f-b8db-4f3b93bf2048%40googlegroups.com.

 For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAD8szLx4h0mh%2BBi2KkXkMDQuGMdb-uAB%2BMmxx8SPT-8h_0NWzQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Sympy Project Idea : Improve the Plotting Module

2014-02-17 Thread Stefan Krastanov


  Firstly I would like to discuss about writing/fixing/ extening the
  backends
  for the plotting module
  of Sympy. Currently Sympy makes use of pyglet for plotting 3D plots.

 For quite some time pyglet is not used. The code is still there, but
 the new plotting module does not use it. The code is not tested
 anymore either, so it might already be broken. Removing the pyglet
 module completely is an option if the latest matplotlib works well
 with 3D.


 So, Currently matplotlib works only for 2D or for both 2D and 3D but not
 well with 3D.

 Could you provide with some idea so that matplotlib works well with 3D. We
 are
 currently having the backend of matplotlib.

 https://github.com/NitinAgarwal/sympy/blob/master/sympy/plotting/plot.py


Matplotlib supports 3d plots, and sympy uses that functionality,
however it is nowhere near what mayavi has (moreover the performance
in matplotlib is horrible as it does not use 3d acceleration).



  Since
  it is mentioned that
  we can add backends : matplotlib, Google Chart API link, pyglet,
  asciart,
  d3.js and mayavi.
  I think working on this would be better. I had tried my hands working
  with
  the d3.js and mayavi
  backend and can start off working on this after seeking appropriate
  guidance
  from the mentor.

 Sounds as a plan. Be sure to check how much of this is already done
 (or can be done) in matplotlib itself. We do not want to reinvent the
 wheel.


 Yes I am thinking to implement a backend for d3.js and mayavi but I would
 like to
 know which would be more appropriate. I had looked at the matplotlib backend
 currently implemented.

 So which one shall I start working on : backend for d3.js or backend for
 mayavi.


Unless somebody else has a better suggestion, start with whatever is
more convenient for you.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Plotting Module for Sympy

2014-01-19 Thread Stefan Krastanov

Sympy Gamma and Sympy are not the same thing. Sympy has a plotting
module that can use multiple backends, but only the matplotlib backend
is mature enough (and the only one provided with sympy besides a small
text-based backend).

There is an example d3js backend but it is far from ready for use.
There is no mayavi backend. Both would be nice additions.

There was an old plotting module based on pyglet (and still available
in sympy), but it has a few drawbacks and it has not been tested for a
long time. It is much more responsive for 3d plots than the current
matplotlib backend. If we have mayavi, the pyglet module can be
removed. Even if it is kept, it needs a lot of cleanup and it needs to
be integrated with the new plotting module (as a backend).

Sympy Gamma does not use the plotting module at all and it plots only a
subset of sympy's function (at least that was the case a few months
ago).

On 17 January 2014 22:34, Nitin Agarwal nitinagarwal3...@gmail.com wrote:
 Hi,

 As I was trying to put my hands on improving the plotting module for sympy
 Gamma, I could not get an idea for what all functions the plots are being
 plotted on Sympy Gamma both 2D and 3D plots. After going through the ideas
 list there are lots of things that needs to be done for improving the
 Plotting module for Sympy. After coversing with David, I got to know the
 plotting is not getting done for multivariate functions.
 http://www.sympygamma.com/input/?i=x^2+-+y^2
 and currently sympy uses d3.js for plotting both 2D and 3D and in the
 documentation its been mentioned that Presently the plots are rendered
 using matplotlib as a backend.

 So I would like to know what all things are working and what needs to be
 improved in this module. Currently I am not sure backend for Mayavi has been
 implemented for plotting 3D plots or not. I can get it working for sympy.
 Does any work needs to be done in Pyglet module for plotting.

  --

 Nitin Agarwal

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] GSOC 2014

2013-12-13 Thread Stefan Krastanov

You might want to look at the interval arithmetic already implemented
in the implicit plotting submodule and also in the mpmath module
shipped with sympy.

On 13 December 2013 13:54, Aaron Meurer asmeu...@gmail.com wrote:
 Sounds like a plan. Keep us updated on your project ideas.

 Aaron Meurer

 On Thu, Dec 12, 2013 at 12:46 PM, Harsh Gupta gupta.hars...@gmail.com wrote:
 Hi,
 I'm Harsh Gupta a second year undergraduate student of Mathematics and
 Computing at IIT Kharagpur and I would be a applicant to sympy for GSOC
 2014.
 I'm following the community  for quite some time and I have also got two
 trivial patches merged in the code base.
 Though I've not decided upon the project yet, I'm working to implement a
 basic interval arithmetics module.
 Since we have a lot of time before the deadlines, I want to get a
 significant amount of work done before I write and discuss a proposal.

 Thank you

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.

 --
 You received this message because you are subscribed to the Google Groups 
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Status of text-based plotting?

2013-11-12 Thread Stefan Krastanov

@Sergey: Our plotting module is build to use various backends, not
only matplotlib. It does couple to textplot.

On 11 November 2013 03:41, Sergey Kirpichev skirpic...@gmail.com wrote:
 On Saturday, November 9, 2013 11:23:33 PM UTC+4, Aaron Meurer wrote:

 Yes, textplot. It is used by default when there is nothing else. See also
 https://github.com/sympy/sympy/pull/2060 where I made a small improvement.
 There's also an example there.


 Gnuplot has a text backend.  matplotlib, unfortunately, not...

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: GSoC 2014

2013-10-16 Thread Stefan Krastanov

I have CC-ed Prasoon so he can give you some further details about his
GSoC project when he is available.

On 16 October 2013 06:52, Sachin Joglekar srjoglekar...@gmail.com wrote:
 I am not the best person to talk about the Math part, but for vector
 calculus, you can have a look at Stefan's differential geometry module. To
 be more precise according to your interests, you can have a look at
 Prasoon's work this summer on the new vector calculus module. I helped him
 with parts of it, so I can give you pointers on where you could work and
 how. Have a look at his work (I am not sure of the timeline that has been
 planned for the module though) - there is a lot of work that can be done on
 it, so you can send talk to Prasoon about any enhancements/bugs you can
 think of.

 On a general note, for any particular module, look at the issue tracker to
 find bugs related to it and have a go at them :-).



 On Wednesday, October 16, 2013 1:10:27 AM UTC+5:30, Sumol wrote:

  Hi,
 My name is Sumol Lodha. I'm a 3rd year Computer Science Engineering
 student. I'm
 interested to work for SymPy for GSoC 2014 and seeing the previous years
 projects, I have very much interest in topics related Maths and
 Physics(especially vector calculus). Any pointers on how should I proceed ?.
 Also I am new to open source development and would like to explore it.
 Any help would be greatly appreciated.

 Thank you,
 Sumol.

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] 1:1 aspect ratio in plot?

2013-10-16 Thread Stefan Krastanov

See the docstring of the `Plot` class. It says that there is an
`aspect_ratio` aesthetics that can be modified as:

p = plot(...)
p.aspect_ratio = ...

The issue is that the our matplotlib backend does not use this yet. A
patch for this would be most welcomed. You can add it to  the
`process_series` method of the `MatplotlibBackend` class on line 958
in plotting/plot.py. Something like `if parent.aspect_ratio != 'auto':
do stuff`

On 14 October 2013 22:00, Aaron Meurer asmeu...@gmail.com wrote:
 I guess the autoscale option will do it for you. It's documentation is
 buried in the docstring of the Plot object.

 Aaron Meurer

 On Sun, Oct 13, 2013 at 8:30 PM, Aaron Watters awatt...@enthought.com wrote:
 Hi folks,

 I have a sequence of calculations which ends up with the equation for an
 ellipse.
 When I plot it (or half of it) using sympy.plot it looks like a circle
 because the plot
 automatically adjusts the aspect ratio to even out the plot.  I'd like to
 have a 1:1
 aspect ratio.  Any automatic way to get a 1:1 aspect ratio using sympy.plot?
 (I know there are
 ways to do it using matplotlib directly...)

 You can test with a formula like x**2 + 9*y**2 = 10 or something.  It always
 plots
 looking like a circle.

 Thanks in advance!  -- Aaron Watters

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.

 --
 You received this message because you are subscribed to the Google Groups 
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] CSymPy and mobile programming

2013-10-02 Thread Stefan Krastanov

On 2 October 2013 13:29, F. B. franz.bona...@gmail.com wrote:



 On Tuesday, October 1, 2013 11:39:36 PM UTC+2, Stefan Krastanov wrote:

 @Franz, while I do not have an opinion on what is discussed here, I would
 like to correct an error that was repeated a few times: The Pypy
 interpreter for Python2.7 does *not* restrict what you can do - it is a
 *fully* compliant python interpreter.

 You are probably thinking about the RPython language, which indeed is a
 part of the Pypy project and it is a very restricted subset of Python2. But
 RPython is *not* meant for use outside of writing the interpreter itself.


 PyPy has an issue about not being able to run numpy. The set of
 CPython-compatible libraries contains non-PyPy-compliant ones.



Indeed, but that is quite a different problem and it does not concern sympy
(which is pure-python + optional dependencies on PyPy supported
non-pure-python libraries).

Concerning numpy: pypy already has a numpy implementation that covers more
than what sympy uses. Moreover PyPy provides a high performance C-api that
also works in CPython. Finally, even these libraries which (due to the use
of the CPython C-api) do not work directly under pypy can be used in pypy
with a (very hackish) embedding of the CPython interpreter.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Accepting line_color attribute for individual expressions

2013-10-02 Thread Stefan Krastanov

You can call plot once and then modify the resulting Plot object.

p[0].line_color = whatever
p[1].line_color = something

Using strings for colors is an implementation detail (so it might stop
being available in the future) and in any case it works only for the
matplotlib backend.

I dislike the suggested patch because of:

1. The there should be only one way philosophy.
2. It works only for line_color, not for all the other possible aesthetics.


On 2 October 2013 13:31, Amit Saha amitsaha...@gmail.com wrote:

 Hello,

 From what I can see, if I want to choose different colors for my
 plots, I would have to do something like this:

  p1 = plot(x, show=False, line_color='r')
  p2 = plot(x**2, show=False, line_color='b')
  # append the plot p1 to p2 or vice-versa
  p2.show()


 I cannot do something like this:

  plot(x,x**2, line_color=['r','b'])

 This will result in both the lines having r and b colors alternately
 (zebra-isc manner).

 It is so because the series objects are created as follows:

 series = [LineOver1DRangeSeries(*arg, **kwargs) for arg in plot_expr]

 So, the line_color is the same for both the lines in the above example.

 To make this possible, I modified the series creation as follows:

 diff --git a/sympy/plotting/plot.py b/sympy/plotting/plot.py
 index 2c6c5ea..31912bc 100644
 --- a/sympy/plotting/plot.py
 +++ b/sympy/plotting/plot.py
 @@ -1209,7 +1209,15 @@ def plot(*args, **kwargs):
  show = kwargs.pop('show', True)
  series = []
  plot_expr = check_arguments(args, 1, 1)
 -series = [LineOver1DRangeSeries(*arg, **kwargs) for arg in plot_expr]
 +
 +
 +# special processing for line_color kwargs
 +if kwargs.get('line_color', None):
 +line_colors = kwargs.get('line_color')
 +
 +for i, arg in enumerate(plot_expr):
 +kwargs['line_color'] = line_colors[i]
 +series.append(LineOver1DRangeSeries(*arg, **kwargs))

 I am not sure if this is the most compact way this can be done, but it
 does what I wanted it to do:

  plot(x**2, x, line_color=['r','b'])


 The above statement will plot the x**2 plot in red and the other in blue.

 Is this an acceptable change or is there another way to do what I want
 to and is not clear to me?

 Thanks,
 Amit.


 --
 http://echorand.me

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] CSymPy and mobile programming

2013-10-01 Thread Stefan Krastanov

@Franz, while I do not have an opinion on what is discussed here, I would
like to correct an error that was repeated a few times: The Pypy
interpreter for Python2.7 does *not* restrict what you can do - it is a
*fully* compliant python interpreter.

You are probably thinking about the RPython language, which indeed is a
part of the Pypy project and it is a very restricted subset of Python2. But
RPython is *not* meant for use outside of writing the interpreter itself.


On 1 October 2013 17:19, F. B. franz.bona...@gmail.com wrote:



 On Tuesday, October 1, 2013 8:15:21 PM UTC+2, Joachim Durchholz wrote:

 That's a good thing, though they'd still have to upgrade the system with
 each new Python version, so it's not buying the project THAT much.


 Well, that's partially true. Compared to PyPy, Jython, IronPython and
 Cython, I think that work in Nuitka is minimal, as the language interpreter
 is Python's own ast library. The other alternative interpreters often
 reimplement again the whole of Python's language.

 But yes it makes sure that no deviations creep into the parsing, which
 is good.


 PyPy's problem is that not all of Python's code is compatible, and the
 same is true for Jython and IronPython. Cython instead should be able (I
 think) to compile almost all of Python, but if you want to use static
 typing, you need to use *cdef*, which breaks compatibility with CPython.

 In a few words, PyPy restricts the Python standard language, Cython
 extends it.

 Nuitka is very interesting because it neither restricts nor extends the
 Python language. Besides, they plan to add static typing upon translation
 to C++ without breaking compatibility (it is suggested to use decorators).

 Here are some considerations by Nuitka's developers:
 http://nuitka.net/posts/static-compilation-that-is-the-point.html


 The main question, then, is: Is Nuitka viable?
 I.e. is it going to stay around as long as Sympy will? How fast do they
 fix showstopper bugs? Are type decorators and (hopefully) something
 smart for the data representation going to be implemented within our
 lifetimes?


 Nuitka is relatively young as a project (I suppose around 2 years old),
 and it is already able to compile almost every python library (at least so
 they claim).

 Their first aim was to achieve an almost 100% compatibility with CPython,
 after that, their second step will focus on performance. As far as I know,
 they have just finished the compatibility part. Let's see what is coming
 out of it in the future. It looks like a great replacement for both PyPy
 and Cython.

 Alternatively, we could do our own Python-to-C++ translator. This would
 be easier than a full-fledged translator because we'd have to cover only
 those constructs that are actually used in Sympy, so we could take
 considerable shortcuts (at the cost of needing a list of coding
 restrictions, so this option would still come with attached strings).


 That would be a lot of work. In any case, regarding a possible
 construction of our own translator, I would suggest to use Nuitka still,
 then compile its C++ result to XML using *gccxml*, applying
 transformation rules to the XML-equivalent C++ code, and then transforming
 back to C++.

 XML has a lot of parsers, tree walkers, interpreters. C++ instead is hard
 to edit as it is.

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] ANN: CSymPy, fast symbolic manipulation library, written in C++

2013-09-21 Thread Stefan Krastanov

 Being written by physicists, CERN or no, isn't necessarily a sign of high
software quality.

Actually, it is a pretty reliable sign of bad quality ;)

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] ANN: CSymPy, fast symbolic manipulation library, written in C++

2013-09-20 Thread Stefan Krastanov

I have heard a lot of bad opinions on CINT - that it covers only
partial ill-defined subset of the language standard. However I have
not tried it myself.

On 20 September 2013 17:50, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Fri, Sep 20, 2013 at 2:49 PM, F. B. franz.bona...@gmail.com wrote:
 Any thought at CINT for C++ developing?

 http://root.cern.ch/drupal/content/cint

 This could help in order to avoid complications stemming from compilers. It
 was developed by physicists at CERN :)

 As far as I know, it does not work with CSymPy. But otherwise I have
 nothing against it.

 Ondrej

 --
 You received this message because you are subscribed to the Google Groups 
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: Feynman diagrams

2013-09-16 Thread Stefan Krastanov

The generation of diagrams is indeed written in python and the
algorithm is fairly simple and easy to implement (I even have an
implementation in my repo). You can see the algorithm here
http://arxiv.org/abs/1106.0522 (and in a few other links already
posted on this mail thread).

However this algorithm requires the Feynman rules as an input. While
the algorithm for computing the rules from the Lagrangian is not that
complicated, it is not part of MadGraph. You can look at the FeynRules
mathematica package if you are interested in that.

On 16 September 2013 13:32, F. B. franz.bona...@gmail.com wrote:
 Concerning MadGraph5, it's written in Python (with exceptions), it's license
 is the UoI-NCSA open source license:

 http://www.opensource.org/licenses/UoI-NCSA.php

 http://en.wikipedia.org/wiki/University_of_Illinois/NCSA_Open_Source_License

 It is similar to the New BSD (as used in SymPy), but not the same. Does that
 allow to import excerpts of code from MadGraph5 ?

 MadGraph5 automatically generates Feynman diagrams, though I don't know
 whether the part doing it is written in Python.

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Divide by zero when transforming to numerics

2013-09-10 Thread Stefan Krastanov

 In this case, real and positive assumptions don't help for the lambdify call. 
 I guess making lambdify assumption aware could be an option.

I was actually expecting that one would always use `simplify` before
`lambdify`. This would make a big difference, because with the
appropriate assumptions `simplify` would remove all such removable
singularities[1], which is the technical term for these point.
Unfortunately a quick google search for numerical removable
singularity does not show anything promising.

[1]: https://en.wikipedia.org/wiki/Removable_singularity

On 10 September 2013 14:19, Jason Moore moorepa...@gmail.com wrote:
 In this case, real and positive assumptions don't help for the lambdify
 call. I guess making lambdify assumption aware could be an option.

 I think we should define dynamicsymbols in mechanics to have a default real
 assumption, this could help in simplification.

 The different basis is an interesting idea. Do you have an example of that?


 Jason
 moorepants.info
 +01 530-601-9791


 On Tue, Sep 10, 2013 at 2:01 PM, Stefan Krastanov
 stefan.krasta...@yale.edu wrote:

 The poorman's solution that I used when I had this problem was to do
 the calculations in a different basis. I do not know how
 general/automatic this solution would be.

 However, a common reason for bad/no simplification is lack of
 appropriate assumptions. Define all you symbols as real/positive and
 half of the issues will go away.

 On 10 September 2013 12:17, Jason Moore moorepa...@gmail.com wrote:
  In the mechanics package we sometimes end up with symbolic expressions
  that
  can give a divide by zero error if we use the expression in a numerical
  function. Below is a simple example of an expression that could be
  generated
  by the mechanics package. It should evaluate to zero (i.e the limit as
  vx -
  zero. evalf says it's zero but if I use lambdify (or probably any code
  generator) to transform the expression to something that is purely
  numeric
  we get divide by zeros. I feel like this must be a common issue when
  transforming symbolic expressions to numerical functions. Does anyone
  know
  how or if this is dealt with? It be nice if we could generate equations
  of
  motion in the mechanics package and generate code from them that
  wouldn't
  have divide by zero errors, requiring some fix on the numerical side.
 
  In [1]: from sympy import symbols, sqrt, lambdify
 
  In [2]: k, vx, vy, vz = symbols('k vx vy vz')
 
  In [3]: f = k * sqrt(vx ** 2 + vy ** 2 + vz ** 2)
 
  In [4]: dfdvx = f.diff(vx)
 
  In [5]: dfdvx
  Out[5]: k*vx/sqrt(vx**2 + vy**2 + vz**2)
 
  In [6]: dfdvx.evalf(subs={k: 1.0, vx: 0.0, vy: 0.0, vz: 0.0})
  Out[6]: 0
 
  In [7]: numeric_dfdvx = lambdify((k, vx, vy, vz), dfdvx)
 
  In [8]: numeric_dfdvx(1.0, 0.0, 0.0, 0.0)
 
  ---
  ZeroDivisionError Traceback (most recent call
  last)
  ipython-input-8-55e44f8ab1bf in module()
   1 numeric_dfdvx(1.0, 0.0, 0.0, 0.0)
 
  /usr/local/lib/python2.7/dist-packages/numpy/__init__.pyc in
  lambda(_Dummy_26, _Dummy_27, _Dummy_28, _Dummy_29)
 
  ZeroDivisionError: float division by zero
 
  In [9]: numeric_dfdvx = lambdify((k, vx, vy, vz), dfdvx,
  modules='numpy')
 
  In [10]: numeric_dfdvx(1.0, 0.0, 0.0, 0.0)
  /usr/local/lib/python2.7/dist-packages/numpy/__init__.py:1:
  RuntimeWarning:
  invalid value encountered in double_scalars

  Out[10]: nan
 
  In [11]: numeric_dfdvx = lambdify((k, vx, vy, vz), dfdvx,
  modules='mpmath')
 
  In [12]: numeric_dfdvx(1.0, 0.0, 0.0, 0.0)
 
  ---
  ZeroDivisionError Traceback (most recent call
  last)
  ipython-input-12-55e44f8ab1bf in module()
   1 numeric_dfdvx(1.0, 0.0, 0.0, 0.0)
 
  string in lambda(k, vx, vy, vz)
 
  /usr/local/lib/python2.7/dist-packages/sympy/mpmath/ctx_mp_python.pyc in
  __rdiv__(s, t)
  206 if t is NotImplemented:
  207 return t
  -- 208 return t / s
  209
  210 def __rpow__(s, t):
 
  /usr/local/lib/python2.7/dist-packages/sympy/mpmath/ctx_mp_python.pyc in
  __div__(self, other)
 
  /usr/local/lib/python2.7/dist-packages/sympy/mpmath/libmp/libmpf.pyc in
  mpf_div(s, t, prec, rnd)
  928 if not sman or not tman:
  929 if s == fzero:
  -- 930 if t == fzero: raise ZeroDivisionError
  931 if t == fnan: return fnan
  932 return fzero
 
  ZeroDivisionError:
 
  In [19]: dfdvx.limit(vx, 0.0)
  Out[19]: 0
 
 
  Jason
  moorepants.info
  +01 530-601-9791
 
  --
  You received this message because you are subscribed to the Google
  Groups
  sympy group.
  To unsubscribe from this group and stop receiving emails from it, send
  an
  email to sympy+unsubscr...@googlegroups.com.
  To post to this group, send email to sympy@googlegroups.com.
  Visit this group at http

Re: [sympy] Divide by zero when transforming to numerics

2013-09-10 Thread Stefan Krastanov

The poorman's solution that I used when I had this problem was to do
the calculations in a different basis. I do not know how
general/automatic this solution would be.

However, a common reason for bad/no simplification is lack of
appropriate assumptions. Define all you symbols as real/positive and
half of the issues will go away.

On 10 September 2013 12:17, Jason Moore moorepa...@gmail.com wrote:
 In the mechanics package we sometimes end up with symbolic expressions that
 can give a divide by zero error if we use the expression in a numerical
 function. Below is a simple example of an expression that could be generated
 by the mechanics package. It should evaluate to zero (i.e the limit as vx -
 zero. evalf says it's zero but if I use lambdify (or probably any code
 generator) to transform the expression to something that is purely numeric
 we get divide by zeros. I feel like this must be a common issue when
 transforming symbolic expressions to numerical functions. Does anyone know
 how or if this is dealt with? It be nice if we could generate equations of
 motion in the mechanics package and generate code from them that wouldn't
 have divide by zero errors, requiring some fix on the numerical side.

 In [1]: from sympy import symbols, sqrt, lambdify

 In [2]: k, vx, vy, vz = symbols('k vx vy vz')

 In [3]: f = k * sqrt(vx ** 2 + vy ** 2 + vz ** 2)

 In [4]: dfdvx = f.diff(vx)

 In [5]: dfdvx
 Out[5]: k*vx/sqrt(vx**2 + vy**2 + vz**2)

 In [6]: dfdvx.evalf(subs={k: 1.0, vx: 0.0, vy: 0.0, vz: 0.0})
 Out[6]: 0

 In [7]: numeric_dfdvx = lambdify((k, vx, vy, vz), dfdvx)

 In [8]: numeric_dfdvx(1.0, 0.0, 0.0, 0.0)
 ---
 ZeroDivisionError Traceback (most recent call last)
 ipython-input-8-55e44f8ab1bf in module()
  1 numeric_dfdvx(1.0, 0.0, 0.0, 0.0)

 /usr/local/lib/python2.7/dist-packages/numpy/__init__.pyc in
 lambda(_Dummy_26, _Dummy_27, _Dummy_28, _Dummy_29)

 ZeroDivisionError: float division by zero

 In [9]: numeric_dfdvx = lambdify((k, vx, vy, vz), dfdvx, modules='numpy')

 In [10]: numeric_dfdvx(1.0, 0.0, 0.0, 0.0)
 /usr/local/lib/python2.7/dist-packages/numpy/__init__.py:1: RuntimeWarning:
 invalid value encountered in double_scalars
   
 Out[10]: nan

 In [11]: numeric_dfdvx = lambdify((k, vx, vy, vz), dfdvx, modules='mpmath')

 In [12]: numeric_dfdvx(1.0, 0.0, 0.0, 0.0)
 ---
 ZeroDivisionError Traceback (most recent call last)
 ipython-input-12-55e44f8ab1bf in module()
  1 numeric_dfdvx(1.0, 0.0, 0.0, 0.0)

 string in lambda(k, vx, vy, vz)

 /usr/local/lib/python2.7/dist-packages/sympy/mpmath/ctx_mp_python.pyc in
 __rdiv__(s, t)
 206 if t is NotImplemented:
 207 return t
 -- 208 return t / s
 209
 210 def __rpow__(s, t):

 /usr/local/lib/python2.7/dist-packages/sympy/mpmath/ctx_mp_python.pyc in
 __div__(self, other)

 /usr/local/lib/python2.7/dist-packages/sympy/mpmath/libmp/libmpf.pyc in
 mpf_div(s, t, prec, rnd)
 928 if not sman or not tman:
 929 if s == fzero:
 -- 930 if t == fzero: raise ZeroDivisionError
 931 if t == fnan: return fnan
 932 return fzero

 ZeroDivisionError:

 In [19]: dfdvx.limit(vx, 0.0)
 Out[19]: 0


 Jason
 moorepants.info
 +01 530-601-9791

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] -n test failing

2013-09-07 Thread Stefan Krastanov

You are testing whether the result from simplify is structurally the
same as a predefined answer, but simplify does not guarantee that it
will give the same result each time.

It is giving mathematically equivalent result, it just decided that it
should factor out a minus sign.

The simplest solution would be to rewrite tests of the form:

 a.simplify()
b

into

 (a-b).simplify()
0

but this is somewhat ugly, especially for doctests which should be
more of a documentation tool. However, if a doctest is so complicated
it might be a good idea to move it to a test file and write a new,
simpler doctest.

On 7 September 2013 16:52, Sachin Joglekar srjoglekar...@gmail.com wrote:
 I am currently working on a PR to modify the mechanics core - #2412. The
 Travis build seems to be failing for a couple of doctests in the
 doc/src/modules/physics/mechanics/bicycle_example.rst file. Have a look here
 - https://travis-ci.org/sympy/sympy/jobs/11069792
 The problem is, neither Gilbert nor I are able to figure out why. The
 weirder stuff is, doing
 ./bin/doctest -n doc/src/modules/physics/mechanics/bicycle_example.rst
 on my machine gives no error once, and 5 errors the next time I run it
 (Without altering any code in the meantime). Same goes for the command
 without the '-n' parameter.
 Can anybody help us out with this? The PR is stuck at this issue, and we
 need to resolve it soon. (I have attached a file with the errors shown)

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] -n test failing

2013-09-07 Thread Stefan Krastanov

If you are interested, such non-determinism stems from code like

for _ in A_DICTIONARY.items():
...

where the datastructure (or something else) does not preserve order,
but just orders by some transient (wrt restart of the interpreter)
value like hash or memory address.

On 7 September 2013 17:43, Stefan Krastanov stefan.krasta...@yale.edu wrote:
 You are testing whether the result from simplify is structurally the
 same as a predefined answer, but simplify does not guarantee that it
 will give the same result each time.

 It is giving mathematically equivalent result, it just decided that it
 should factor out a minus sign.

 The simplest solution would be to rewrite tests of the form:

 a.simplify()
 b

 into

 (a-b).simplify()
 0

 but this is somewhat ugly, especially for doctests which should be
 more of a documentation tool. However, if a doctest is so complicated
 it might be a good idea to move it to a test file and write a new,
 simpler doctest.

 On 7 September 2013 16:52, Sachin Joglekar srjoglekar...@gmail.com wrote:
 I am currently working on a PR to modify the mechanics core - #2412. The
 Travis build seems to be failing for a couple of doctests in the
 doc/src/modules/physics/mechanics/bicycle_example.rst file. Have a look here
 - https://travis-ci.org/sympy/sympy/jobs/11069792
 The problem is, neither Gilbert nor I are able to figure out why. The
 weirder stuff is, doing
 ./bin/doctest -n doc/src/modules/physics/mechanics/bicycle_example.rst
 on my machine gives no error once, and 5 errors the next time I run it
 (Without altering any code in the meantime). Same goes for the command
 without the '-n' parameter.
 Can anybody help us out with this? The PR is stuck at this issue, and we
 need to resolve it soon. (I have attached a file with the errors shown)

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: simplification of expressions with indexed array type of objects

2013-09-05 Thread Stefan Krastanov

Is there a reason not to use Symbols? From your explanations I do not see
one. If your issue is how to couple the result to something like numpy,
checkout `lambdify`.

On 5 September 2013 15:54, david r...@iwm.mw.tu-dresden.de wrote:

For better explanation I have done the simplification in MatCad where
unassigned variables are seen as symbols in sympy.

https://lh4.googleusercontent.com/-uq82CF7JYZw/UijhDNbjPvI/AAM/bPAnd8PQSpI/s1600/simplify+with++arrays.tiff

Am Donnerstag, 5. September 2013 15:19:14 UTC+2 schrieb david:

I have explored the sympy features and i was very impressed with both the
amount of features and the ease of testing with the doc and the coupled
Live Shell.
I want to write a programm that simplifies expressions as much as
possible to minimize calculation time because they will later be numericaly
evaluated very often.
The most features I need work very well. But with arrays I have a problem.
I need to define an array object as an symbol, so that the following is
possible:

simplify(2.0*2.0*t[0])
is simplified to:
4.0*t[0]

and:
idx = 2
simplify(2.0*2.0*t[idx])
shold be simplified to:
4.0*t[2]

Is there any way to do this?

david

--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an
email to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] SymPy and IPython

2013-09-01 Thread Stefan Krastanov

This is partly done in isympy, which I think uses Ipython when
available. Check ./bin/isympy.

On 1 September 2013 11:27, F. B. franz.bona...@gmail.com wrote:
 I have to questions about SymPy and IPython:

 is it possible to configure IPython to autowrap Python's int? Like it is
 already happening is Sage.
 is it possible to automatically capture NameError and autodeclare missing
 variables as SymPy's symbols() ?

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: Caching problem

2013-08-29 Thread Stefan Krastanov

We have discussed this a bit at the beginning of the summer. It has to
do mainly with the assumptions on the various objects.  Verify that
all subs/replace/atoms/free_symbols methods work first as these are
quite important for correctly working simplifications. Then we should
just start adding the appropriate hardcoded assumptions.

On 29 August 2013 11:48, Prasoon Shukla prasoon92.i...@gmail.com wrote:
 Sorry for the late reply. I'm buried neck deep in academics. Anyway, setting
 the hashable_content method clears things up.

 The problem now is this:

 We have the expression sin(theta) * cos(phi)

 Here are the relations for substitution:

 tan(theta) = sqrt(x**2 + y**2) /z
 tha(phi) = y/x

 Substituting this back, we get
 x / (x**2 + y**2 + z**2)

 Except that SymPy is returning a huge expression - that does simplify to the
 above expression, manually. Running simplify() on the expression returns the
 same expression with no simplification.

 This means that things are at least working correctly - the maths and the
 code. I am proceeding with the debugging.


 On Wednesday, August 28, 2013 6:59:15 PM UTC+5:30, Prasoon Shukla wrote:

 I have ran into a caching problem while working on my project for the
 vector calcculus module. This occurred while I was debugging the express
 method on vector (this isn't really relevant though).

 So, I have a symbol theta and another symbol phi.

  cs.theta
 cs.theta

  cs.phi
 cs.phi

 cs is an instance of the CoordSysSph class (again, not really relevant to
 the problem at hand).

 The problem:
  sin(cs.theta) * sin(cs.phi)
 sin(cs.theta) ** 2

 Well, in the definition for the cacheit decorator, the dicitionary
 func_cache_it_cache exists. Now, when sin(cs.theta) is called, a key, value
 pair gets added to the dictionary:

 ((sin, class 'sympy.core.function.FunctionClass'), (cs.theta, class
 'sympy.vector.vector.BaseScalar'))  : sin(cs.theta)

 Now, when SymPy needs to calculate sin(cs.phi), the cacheit decorator is
 called again. The lookup key for sin(cs.phi) is generated as:
 ((sin, class 'sympy.core.function.FunctionClass'), (cs.phi, class
 'sympy.vector.vector.BaseScalar'))

 At this point, the func_cache_it_cache does not have the key correspondind
 to sin(cs.phi), as it shouldn't. But, here's the catch: running the has_key
 method on func_cache_it_cache for this second key (for sin(cs.phi)) returns
 True. That means, the cache returns sin(cs.theta). And that is what is
 causing the problem.

 What can I possibly do here? For the time being, I am going to proceed
 with the debugging. When there is a solution for this problem, we can go
 ahead and fix this.

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Caching problem

2013-08-28 Thread Stefan Krastanov

If I remember correctly, this issue stems from subclassing Symbol,
which has empty args and specific eq.

On 28 August 2013 15:13, Gilbert Gede gilbertg...@gmail.com wrote:
 Prasoon,
 Take a look at these outputs.

 In [5]: cs.theta.args
 Out[5]: ()

 In [7]: cs.theta._hashable_content()
 Out[7]: ()

 cs.theta.__eq__ uses Basic's .__eq__, which in turn compares
 _hashable_content() between the two objects. So, I think you should be using
 .args instead of .coord_sys and .position.


 On Wed, Aug 28, 2013 at 11:22 AM, Prasoon Shukla prasoon92.i...@gmail.com
 wrote:

 You're right. It seems to be a problem with equality checking. Here's some
 code that I just ran:

 In [3]: cs.theta == cs.phi
 Out[3]: True

 In [4]: cs.theta
 Out[4]: cs.theta

 In [5]: cs.phi
 Out[5]: cs.phi

 In [6]: id(cs.theta)
 Out[6]: 169351684

 In [7]: id(cs.phi)
 Out[7]: 169350004

 How come the == operator returns True even though the ids are different?
 Also, I didn't implement __eq__ or __hash__ on BaseScalars.

 Anyway, to reproduce the problem, you can run this (I'm just pasting from
 my Ipython session):

 In [1]: from sympy import *;from sympy.vector.vector import *;from
 sympy.vector.integrate import *;q0, q1, q2 = symbols('q0 q1 q2');from
 sympy.abc import x, y, z;c0 = CoordSysRect('c0');c1 = CoordSysRect('c1');cs
 = CoordSysSph('cs')

 In [2]: cs.theta * cs.phi
 Out[2]: cs.theta**2

 Should I implement __eq__ on BaseScalar?
 (I probably won't be able to respond for 7-8 hours. Going to sleep. Have
 classes tomorrow morning).

 On Wednesday, August 28, 2013 10:17:39 PM UTC+5:30, Aaron Meurer wrote:

 On Wed, Aug 28, 2013 at 7:29 AM, Prasoon Shukla
 prasoon...@gmail.com wrote:
  I have ran into a caching problem while working on my project for the
  vector
  calcculus module. This occurred while I was debugging the express
  method on
  vector (this isn't really relevant though).
 
  So, I have a symbol theta and another symbol phi.
 
  cs.theta
  cs.theta
 
  cs.phi
  cs.phi
 
  cs is an instance of the CoordSysSph class (again, not really relevant
  to
  the problem at hand).
 
  The problem:
  sin(cs.theta) * sin(cs.phi)
  sin(cs.theta) ** 2
 
  Well, in the definition for the cacheit decorator, the dicitionary
  func_cache_it_cache exists. Now, when sin(cs.theta) is called, a key,
  value
  pair gets added to the dictionary:
 
  ((sin, class 'sympy.core.function.FunctionClass'), (cs.theta, class
  'sympy.vector.vector.BaseScalar'))  : sin(cs.theta)
 
  Now, when SymPy needs to calculate sin(cs.phi), the cacheit decorator
  is
  called again. The lookup key for sin(cs.phi) is generated as:
  ((sin, class 'sympy.core.function.FunctionClass'), (cs.phi, class
  'sympy.vector.vector.BaseScalar'))

 Oh, just noticed this. phi and theta are not Symbols, they are
 BaseScalars. So you probably did something wrong implementing equality
 comparison on BaseScalars. What does cs.phi == cs.theta give?

 Can you give a complete code snipped to reproduce this in your branch?

 Aaron Meurer

 
  At this point, the func_cache_it_cache does not have the key
  correspondind
  to sin(cs.phi), as it shouldn't. But, here's the catch: running the
  has_key
  method on func_cache_it_cache for this second key (for sin(cs.phi))
  returns
  True. That means, the cache returns sin(cs.theta). And that is what is
  causing the problem.
 
  What can I possibly do here? For the time being, I am going to proceed
  with
  the debugging. When there is a solution for this problem, we can go
  ahead
  and fix this.
 
  --
  You received this message because you are subscribed to the Google
  Groups
  sympy group.
  To unsubscribe from this group and stop receiving emails from it, send
  an
  email to sympy+un...@googlegroups.com.
  To post to this group, send email to sy...@googlegroups.com.
  Visit this group at http://groups.google.com/group/sympy.
  For more options, visit https://groups.google.com/groups/opt_out.

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.


 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to

Re: [sympy] solve piecewise unhashable type list

2013-08-04 Thread Stefan Krastanov

Hi

I what version of SymPy did you try this?


On 4 August 2013 15:33, George Gerber george.ger...@gmail.com wrote:

 Good day,
 I am trying to solve three force equilibrium equations. I have simplified
 the code below to only 1 equation to better show the error i get
 (typeerror: unhashable type list). The problem appears to be the use of
 piecewise. Would somebody be so kind as to show how to make piecewise and
 solve play along?

 from sympy import symbols,solve,Piecewise
 e,emax,smax=symbols('e emax smax')
 s=Piecewise((0,e=0),(e/emax*smax,eemax),(smax,True))
 print solve([sigma-1],[e])




 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: Contributing to SymPy

2013-08-01 Thread Stefan Krastanov

Pyglet is not part of sympy, but if installed it can be used for plotting.
In your case the test runner detected that you have installed pyglet and
ran the appropriate tests. It found a problem with pyglet and it raised an
error. The thing is, the problem is not in sympy, it is in pyglet, so there
is not much that we can do. If you do not use it, you can just uninstall it
(however I do not know how to do this on windows).


On 1 August 2013 06:59, Ben Lucato ben.luc...@gmail.com wrote:

 For the newbie here (me) - how come this isn't reflected in the master
 branch yet?


 On 1 August 2013 14:00, Aaron Meurer asmeu...@gmail.com wrote:

 Yeah, I ended up uninstalling pyglet because of the bugs that cause
 test failures.  The pyglet plotting module is already deprecated in
 favor of the matplotlib one.

 Aaron Meurer

 On Wed, Jul 31, 2013 at 10:52 PM, Ondřej Čertík ondrej.cer...@gmail.com
 wrote:
  Ok, so this is a pyglet bug:
 
File c:\Python27\lib\site-packages\pyglet\window\__init__.py, line
 686, in _
  _init__
  self._create()
File c:\Python27\lib\site-packages\pyglet\window\win32\__init__.py,
 line 467
  , in _create
  _user32.RegisterClassW(byref(self._window_class))
  WindowsError: exception: access violation reading 0x
 
  that we cannot do much about. Unfortunately it seems that pyglet is
  not actively developed anymore, so maybe we should using something
  else, preferably inside the IPython notebook, which is very actively
  developed.
 
  Ondrej
 
  On Wed, Jul 31, 2013 at 9:31 PM, Ben Lucato ben.luc...@gmail.com
 wrote:
  Hey I re-ran the tests. I wasn't sure how much of the output to grab
 (most
  of it was successful tests), so I have just copied all of the error
 output
  with a bit of the successful tests - it's attached to this post as a
 text
  post.
 
 
  On Thursday, 1 August 2013 11:20:53 UTC+10, Ben Lucato wrote:
 
  Hello, I've made a couple of posts here asking questions, but now I'd
 like
  to start contributing ^^.
 
  I've gone through the guide to contributing, how to document, etc. and
  done everything I need to.
 
  I've been writing Python for over a year now, but am very new to
 things
  like Git/GitHub.
 
  Two questions I had:
 
  Yesterday I did a totally new clone+pull of the git master, yet on
 running
  tests via ./bin/test, one of the tests fail prompting a *DO NOT
 COMMIT*
  message?
  I couldn't find it in the issues tracker, but I'm not sure if I'm
  searching right anyway - what I'd like to work on is when you do
 something
  like solve(x - pi  0), a NotImplementedError is returned
 
 
  Yay! SymPy will be the first thing I've contributed to :- )
 
  --
  You received this message because you are subscribed to the Google
 Groups
  sympy group.
  To unsubscribe from this group and stop receiving emails from it, send
 an
  email to sympy+unsubscr...@googlegroups.com.
  To post to this group, send email to sympy@googlegroups.com.
  Visit this group at http://groups.google.com/group/sympy.
  For more options, visit https://groups.google.com/groups/opt_out.
 
 
 
  --
  You received this message because you are subscribed to the Google
 Groups sympy group.
  To unsubscribe from this group and stop receiving emails from it, send
 an email to sympy+unsubscr...@googlegroups.com.
  To post to this group, send email to sympy@googlegroups.com.
  Visit this group at http://groups.google.com/group/sympy.
  For more options, visit https://groups.google.com/groups/opt_out.
 
 

 --
 You received this message because you are subscribed to a topic in the
 Google Groups sympy group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/sympy/awNx8CHhWo8/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 sympy+unsubscr...@googlegroups.com.

 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.





 --


 Ben Lucato

 --
 Phone: +61 400 159 632 | Email: ben.luc...@gmail.com

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: plot DiracDelta(x)

2013-07-29 Thread Stefan Krastanov

It is because the integral can not be solved symbolically by sympy so it
has to be evaluated numerically _for each point t that is plotted_.

first plot: evaluate the integral symbolically (slow), calculate the value
of the result at each t (fast as it is only arithmetics)

last plot: try to evaluate the integral symbolically (slow and useless as
it fails), fallback to numeric integrations at each t (slow because numeric
integration needs a lot of sampling)


On 29 July 2013 08:45, horn...@gmail.com wrote:

 Ok, i see this isn't implemented yet. But could you give me a hint why
 while the last plot the kernel is busy all the time ?



 import sympy
 from sympy.plotting import plot
 from sympy.abc import t,tau

 u_t = 2 * DiracDelta(t)
 g_t = 0.5 * ( Heaviside(t)-Heaviside(t-2) )

 plot( integrate( u_t.subs(t,tau)*g_t.subs(t,t-tau), (tau,-10, 10)),
 (t,-10,10))
 plot( integrate( u_t.subs(t,tau)*u_t.subs(t,t-tau), (tau,-10, 10)),
 (t,-10,10))
 plot( integrate( g_t.subs(t,tau)*g_t.subs(t,t-tau), (tau,-10, 10)),
 (t,-10,10))

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: plot DiracDelta(x)

2013-07-29 Thread Stefan Krastanov

The fallback is just to call `evalf` instead something like `lambdify`. It
is always slower, but works even on the most bizarre expressions. For
integrals, indeed, there are many points that are resampled with this naive
solution (the algorithm becomes n^2 instead of n).

Numeric libraries like scipy provide routines for doing this in a single
pass, however one provides the points to be sampled beforehand. mpmath
which is used in this case does not provide this as far as I know.

Even if it is provided we will have to somehow link this routine to
`Integral.evalf`, because if we just write a special case for the plotting
module, it will work for `Integral(...)` but not for something more general
like `exp(Integral(...))` or `x*Integral(...)`.

So yes, we can implement the single-pass algorithm, but it will require
some creativity so 1) it will work without us explicitly telling the
algorithm beforehand which points are to be sampled and 2) it is callable
like an ordinary `evalf`.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: plot DiracDelta(x)

2013-07-29 Thread Stefan Krastanov

There is also `Sum(1/x**constant, (x, 1, t))` plotted for t in [1, 10] that
exhibits the same problem.


On 29 July 2013 19:33, Stefan Krastanov krastanov.ste...@gmail.com wrote:

 The fallback is just to call `evalf` instead something like `lambdify`. It
 is always slower, but works even on the most bizarre expressions. For
 integrals, indeed, there are many points that are resampled with this naive
 solution (the algorithm becomes n^2 instead of n).

 Numeric libraries like scipy provide routines for doing this in a single
 pass, however one provides the points to be sampled beforehand. mpmath
 which is used in this case does not provide this as far as I know.

 Even if it is provided we will have to somehow link this routine to
 `Integral.evalf`, because if we just write a special case for the plotting
 module, it will work for `Integral(...)` but not for something more general
 like `exp(Integral(...))` or `x*Integral(...)`.

 So yes, we can implement the single-pass algorithm, but it will require
 some creativity so 1) it will work without us explicitly telling the
 algorithm beforehand which points are to be sampled and 2) it is callable
 like an ordinary `evalf`.


-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: plot DiracDelta(x)

2013-07-29 Thread Stefan Krastanov

Concerning Sum: the same problem as integral (repeated sampling).

About the noninteger limits: it seems to transform sum into an integral,
but I guess this is just a coincidence/implementation detail somewhere in
sympy and not anything documented.

About cse and other optimizations: Matthew has written some interesting
things about using sympy to optimize numerics on his blog.

Slightly offtopic: there is a flag that can be set when plotting so that
the lineplot is in a staircase pattern. It is quite useful, for instance,
when making plots about approximations of integrals or plots of Sum. It is
described in the plot_advanced notebook in the examples folder.


On 29 July 2013 20:38, Aaron Meurer asmeu...@gmail.com wrote:

 The same problem as Integral sampling or the same problem as
 DiracDelta (how is Sum defined for non-integer limits?).

 I think in general we should expand out the computation to a symbolic
 formula and use cse() to make it more efficient (what's the point of
 being symbolic if we can't do cool tricks like this).

 Aaron Meurer

 On Mon, Jul 29, 2013 at 12:35 PM, Stefan Krastanov
 krastanov.ste...@gmail.com wrote:
  There is also `Sum(1/x**constant, (x, 1, t))` plotted for t in [1, 10]
 that
  exhibits the same problem.
 
 
  On 29 July 2013 19:33, Stefan Krastanov krastanov.ste...@gmail.com
 wrote:
 
  The fallback is just to call `evalf` instead something like `lambdify`.
 It
  is always slower, but works even on the most bizarre expressions. For
  integrals, indeed, there are many points that are resampled with this
 naive
  solution (the algorithm becomes n^2 instead of n).
 
  Numeric libraries like scipy provide routines for doing this in a single
  pass, however one provides the points to be sampled beforehand. mpmath
 which
  is used in this case does not provide this as far as I know.
 
  Even if it is provided we will have to somehow link this routine to
  `Integral.evalf`, because if we just write a special case for the
 plotting
  module, it will work for `Integral(...)` but not for something more
 general
  like `exp(Integral(...))` or `x*Integral(...)`.
 
  So yes, we can implement the single-pass algorithm, but it will require
  some creativity so 1) it will work without us explicitly telling the
  algorithm beforehand which points are to be sampled and 2) it is
 callable
  like an ordinary `evalf`.
 
 
  --
  You received this message because you are subscribed to the Google Groups
  sympy group.
  To unsubscribe from this group and stop receiving emails from it, send an
  email to sympy+unsubscr...@googlegroups.com.
  To post to this group, send email to sympy@googlegroups.com.
  Visit this group at http://groups.google.com/group/sympy.
  For more options, visit https://groups.google.com/groups/opt_out.
 
 

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] GSoC midterm evaluations

2013-07-29 Thread Stefan Krastanov

For the vector module (and for the electromagnetism stuff if I am not told
to do otherwise), I will submit on Wednesday (unless Gilbert submits before
me, I think we both have the same administrative privileges).

Stefan


On 29 July 2013 21:03, Aaron Meurer asmeu...@gmail.com wrote:

 The GSoC midterm evaluations are now open. All mentors and students
 must submit them. The deadline is Friday, but please do me a favor and
 submit it well before then.

 To submit, go to http://www.google-melange.com/, click on My
 Dashboard, and then My evaluations.

 Aaron Meurer

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: plot DiracDelta(x)

2013-07-28 Thread Stefan Krastanov

Below I try to answer the question (basically there is no way for the
moment), but could you tell us how you actually expected this figure to
look like?

There does not seem to be a satisfactory way to do it. After all DiracDelta
is zero at all points besides x=0, so simple sampling will miss this point.
If x=0 is actually sampled, it returns infinity which either will cause the
code to crash or it will mask the point as a NaN so it will be invisible.

A step forward to solving this would be to have some kind of asymptote
detector that changes the scale of the plot accordingly.

Another way to solve this would be to provide an appropriate api for
functions to tell the plotting module that they have such degenerate points.

In any case, a lot of work is necessary for the implementation of a
satisfactory solution.


On 28 July 2013 18:00, horn...@gmail.com wrote:

 Here is my python notebook script

 while the last plot the ipython kernel seems to be busy all the time

 ==
 import sympy
 from sympy.plotting import plot
 from sympy.abc import t,tau

 u_t = 2 * DiracDelta(t)
 g_t = 0.5 * ( Heaviside(t)-Heaviside(t-2) )

 plot(g_t, (t, -5, 5))
 ==

 plot( integrate( u_t.subs(t,tau)*g_t.subs(t,t-tau), (tau,-10, 10)),
 (t,-10,10))
 plot( integrate( u_t.subs(t,tau)*u_t.subs(t,t-tau), (tau,-10, 10)),
 (t,-10,10))
 plot( integrate( g_t.subs(t,tau)*g_t.subs(t,t-tau), (tau,-10, 10)),
 (t,-10,10))

  --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Subclassing Symbol and caching problem

2013-07-25 Thread Stefan Krastanov

You almost never want to generate a symbol yourself (in library code)
because you never know whether the user is using a the same name (pretty
much the whole point of symbols are that they are things identified only
by name).

So you have two options:

1. use Dummy
2. appropriately add additional information to the `args` of your class

You are almost doing 2, but...

... is there a reason to use __new__ here. __init__ seems to be sufficient.

Unless there is some magic involved, in you code you are not saving
`coord_sys` in `args`, which is the actual reason that equality checks and
caching are misbehaving. I think that if you are using __init__ `args` will
be correctly populated automatically.




On 25 July 2013 17:17, Prasoon Shukla prasoon92.i...@gmail.com wrote:

 I have subclassed Symbol, like so:

 class BaseScalar(Symbol):
 
 BaseScalar instances are used to express coordinate variables for
 field.
 Not to be instantiated by the user.
 
 def __new__(cls, name, coord_sys, position, **assumptions):
 if (position not in ['1', '2', '3']
 and not isinstance(coord_sys, CoordSysRect)):
 raise ValueError(Position of scalar not specified. \
 See `position` in docstring of `BaseScalar`)
 if name is None:
 name = 'Dummy_' + str(Dummy._count)
 obj = Symbol.__new__(cls, name, **assumptions)
 obj.coord_sys = coord_sys
 return obj

 The problem is this:
 An instance of this class is created with name 'x' (say). Fine. Everything
 works as it should. Then, another instance of this class is created - again
 with the name 'x'. The returned object is actually the same 'x' which was
 made before. This is happening because __new__ of Symbol is cached - when
 the new object is created, it returns the cached object from before.

 What can I do for to generate a new instance of the class instead of
 returning the already created object?


 P.S.: If you are wondering why I am creating the objects with the same
 name, it is because the objects are instantiated within another object. So,
 it's perfectly alright.

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: Subclassing Symbol and caching problem

2013-07-25 Thread Stefan Krastanov

 But, that's what's happening right now as well. Symbol.__new__ is called
and it is cached. Therefore, the problem persists.

Except that you will probably have the correct `args`. Check this first.

I do not understand what is the issue with Symbol's __new__ could you show
the code that actually raises this error?

 So, how am I to add args?

Answering the above question about `new` and `init` will probably show us
what you are doing wrong and why you can not modify the `args`. If you
insist doing it manually, just modify `_args`. But if you need to do it,
you are probably doing something wrong.


On 25 July 2013 18:30, Prasoon Shukla prasoon92.i...@gmail.com wrote:

 @Stefan : Let us say I use __init__ instead. When I initialize a
 BaseScalar, since a __new__ method isn't defined, that means the __new__ of
 superclass (Symbol) will be called.

 But, that's what's happening right now as well. Symbol.__new__ is called
 and it is cached. Therefore, the problem persists.

 Also, if I use __init__, then since Symbol.__new__ will be called first.
 But, it throws an error:
 __new__() takes exactly 2 arguments (4 given)
 which is why I was using __new__ instead of __init__ in the first place.

 @Aaron: The symbols are initialized within another class instance.
 Specifically, it represents field variables in a coordinate system. So, you
 can initialize any number of rectangular coordinate system objects and each
 will have a 'x' attribute that will represent the x coordinate variable.
 Thus the same name. I took the position as strings initially - when the
 BaseScalars were to be initialized by users - but that has changed now. I
 can use ints instead.

 Anyway, here are the things I can do:

 I can change the superclass to Dummy since using __init__ instead of
 __new__ doesn't work for the reasons I mentioned. I still do not see how to
 fix this. You mention adding args to the object but how am I to do that?
 Symbol.__new__ needs to be called one way or the other - and, it doesn't
 allow for anything else but name and assumptions. And when it is called, it
 returns a cached object. So, how am I to add args?

 One thing I can think of doing is to initialize a different named symbol
 and change its name later on. How about that?

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: Subclassing Symbol and caching problem

2013-07-25 Thread Stefan Krastanov

Have you tried? I assure you, you can create classes with constructors
which signature differs from the signature of the superclass constructor.

Anyway, even if you prefer to use `__new__`, you still need to pay
attention to the `args` attribute.

Also, keep in mind that what you are doing mixes together printing and
identification. Your objects are completely defined by the tuple
(coordinate_system, index). You do not need name. The name comes into play
only during pretty printing.

It would be much better if you just subclass Basic or Expr and keep only
the aforementioned tuple as args.

You can also look at `diffgeom`. It solves the exact problem that you have
for three different classes: BaseScalar, BaseVector and BaseForm.


On 25 July 2013 18:46, Prasoon Shukla prasoon92.i...@gmail.com wrote:

 Okay. So, this is what happens if I use __init__:

 Symbol.__new__ is called. Here's the definition:

 def __new__(cls, name, **assumptions):
Symbols are identified by name and assumptions::

 As you can see, the method expects 2 positional arguments and rest are
 keyword arguments (the assumptions). When I use __init__, the function call
 is something like this:

 def __init__(self, name, coord_sys, position, **assumptions):

 And that's the error.

 Now, even if I can use __init__, here's what will happen:

 Symbol.__new__ still gets called first. Inside Symbol.__new__, it makes
 this call:
 return Symbol.__xnew_cached_(cls, name, **assumptions)

 The method __xnew_cached is cached. So, if the symbol with the same name
 had already been defined, that gets returned instead of a new object.
 Therefore, we are back to our original problem - that symbol doesn't
 support any extra args. In fact, if we have a symbol, doing:
  symbol.args
 returns an empty tuple.

  --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] MatrixSymbol and TensorProduct

2013-07-24 Thread Stefan Krastanov

From what submodules of sympy are you importing these classes?


On 24 July 2013 09:38, Sreeraj Rajendran rsree...@gmail.com wrote:


 Hi,

 With
  X = MatrixSymbol('X', 3, 3)
  Y = MatrixSymbol('Y', 3, 3)

  TensorProduct(X,Y) throws me the following error
  AttributeError: 'MatrixSymbol' object has no attribute 'args_cnc'

 TensorProduct(Matrix(X),Matrix(Y)) works fine.
 Is tensorproduct over matrixsymbols is currently under development or am I
 doing something terribly wrong?
 --
 Regards
 Sreeraj Rajendran
 http://home.iitb.ac.in/~rsreeraj


  --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Representing domains in SymPy

2013-07-24 Thread Stefan Krastanov

It depends what exactly you want to do.

If you need it just for typography purposes (e.g. writing something in
IPython notebook and wanting to print the expression) you are using sympy
incorrectly. SymPy is not a typography library. (if you insists there are
hacks to do it)

On the other hand quite frequently you need this for meaningful mathematics.

- if you want to work on polynomials and do certain operations (finding
roots, etc) over a given field, you do this by specifying the field during
the creation of the polynomial.

- there is some work in progress to be able to do the same for matrices,
but it is not ready.

- in general, there is the assumption module. It is a bit of a mess,
because we have an old and a new assumption module and we try to move to
the new one. If all that you want is for abs(x) to automatically return x
(or something similar) it suffices to define x as `x=Symbol('x',
positive=True)`. There are a few other handles like `real` and `integer`.

- if you need something more general or more fancy, we may have it in some
(possibly unfinished, mostly unused) form, but it goes deeper in SymPy so a
more precise question will help us give you a more precise answer.


On 24 July 2013 13:10, Ben Lucato ben.luc...@gmail.com wrote:

 We can represent domains on paper quite easily - for instance we can write
 x  0, or alternatively x (epsilon symbol) R-, or even x (epsilon symbol)
 (-infinity, 0)

 I looked around but couldn't really find that - is there a canonical way
 to be writing domains in SymPy?

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] MatrixSymbol and TensorProduct

2013-07-24 Thread Stefan Krastanov

I guess you will have to implement the Kroenecker product yourself. Matthew
Rocklin might have more details (he did most of the matrix symbols stuff).


On 24 July 2013 13:44, Sreeraj Rajendran rsree...@gmail.com wrote:

 Let me explain my needs. MatrixSymbol supports basic matrix operations
 like

 With
  X = MatrixSymbol('X', 3, 3)
  Y = MatrixSymbol('Y', 3, 3)

  (X*Y).T will give me

  T  T
 Y ⋅X

 I just wanted to try similar properties of kronecker product i.e
 KP(X,Y).T = KP(X.T, Y.T). What is the best way to implement these?
 What if I want to try some basic decompositions, say KP(X,Y) = KP(X,I_m)
 KP(X,I_n)?

 I am just a beginner in to sympy. Should I implement some new methods to
 work on kronecker product (http://en.wikipedia.org/wiki/Kronecker_product)
 on matrix symbols?

 Thank you for your previous comments.



 On Wednesday, July 24, 2013 2:05:53 PM UTC+5:30, Stefan Krastanov wrote:

 Well, these two modules do not have anything in common, they are not
 meant to be inter-operable.

 The matrixexpr do not have a notion of basis, vector space or linear
 operator. `MatrixSymbol` is meant to represent a matrix, not an operator
 (though if you wish, you can make the mental assumption that you are
 working in certain basis and just consider all matrices to be operators).

 The quantum module has all this (different bases, Hilbert spaces,
 operators, etc). If that is what you need just use it.

 There is also the `diffgeom` module for differential geometry which you
 might find useful depending on what exactly you want to do.


 On 24 July 2013 10:22, Sreeraj Rajendran rsre...@gmail.com wrote:

 Stefan,

 My imports
 from sympy.physics.quantum import TensorProduct
 from sympy import MatrixSymbol


 On Wednesday, July 24, 2013 1:35:38 PM UTC+5:30, Stefan Krastanov wrote:

 From what submodules of sympy are you importing these classes?


 On 24 July 2013 09:38, Sreeraj Rajendran rsre...@gmail.com wrote:


 Hi,

 With
  X = MatrixSymbol('X', 3, 3)
  Y = MatrixSymbol('Y', 3, 3)

  TensorProduct(X,Y) throws me the following error
  AttributeError: 'MatrixSymbol' object has no attribute 'args_cnc'

 TensorProduct(Matrix(X),**Matrix**(Y)) works fine.
 Is tensorproduct over matrixsymbols is currently under development or
 am I doing something terribly wrong?

 --
 Regards
 Sreeraj Rajendran
 http://home.iitb.ac.in/~**rsreer**ajhttp://home.iitb.ac.in/%7Ersreeraj


  --
 You received this message because you are subscribed to the Google
 Groups sympy group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to sympy+un...@**googlegroups.com.
 To post to this group, send email to sy...@googlegroups.com.

 Visit this group at 
 http://groups.google.com/**group**/sympyhttp://groups.google.com/group/sympy
 .
 For more options, visit 
 https://groups.google.com/**grou**ps/opt_outhttps://groups.google.com/groups/opt_out
 .




  --
 You received this message because you are subscribed to the Google
 Groups sympy group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to sympy+un...@**googlegroups.com.
 To post to this group, send email to sy...@googlegroups.com.
 Visit this group at 
 http://groups.google.com/**group/sympyhttp://groups.google.com/group/sympy
 .
 For more options, visit 
 https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
 .




  --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Mul, Add for everything

2013-07-22 Thread Stefan Krastanov

They _could_ be rewritten, but it is always easier to start from scratch,
mainly because of all the assumptions that were silently admitted when
writing any of these.

Add and Mul were sufficient for the vectors, forms and multiforms in
`diffgeom`, but there are still corner cases causing bizarre results there.

However they proved to have too many assumptions for the matrix expressions
submodule, so Matthew Rocklin wrote new simpler, more modular containers
(MatAdd and MatMul). Hopefully in the distant future Add and Mul will be
refactored so they are just as simple.

Concerning the other containers, I think that it is not clear whether they
are really necessary.

An argument against what I have said and in favor of the existence of
various containers, is that the paradigms followed by Mathematica (rewrite
rules, functional programing, lisp-like expressions) is different from that
of python (object oriented programing), so following the example of
Mathematica is not obviously correct. I do not consider this a very strong
or well articulated argument.

One can also start talking about type systems but 1) Mathematica does not
have one; 2) Python's one is not strict; 3) SymPy's ad-hoc type system is a
mess. Hence, I do not think that any immediate conclusions can be reached
from this line of thought.


On 22 July 2013 21:16, F. B. franz.bona...@gmail.com wrote:

 Wolfram Mathematica has Plus and Times which are used for every expression
 overloading the + and   operators.

 I see here that SymPy has Mul, Add, MatMul, MatAdd, VectMul, VectAdd,
 TensMul, TensAdd, and so on...

 Do we really need all these ones? Couldn't Mul and Add be rewritten in
 such a way as to correctly handle all those cases?

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Problem matrices applyfunc with conjugate

2013-07-15 Thread Stefan Krastanov

I do not know where this extremely bizarre bug comes from, but I would like
to remark that you can access the hermitian conjugate of a matrix through
`matrix.H` or the transpose through `matrix.T`.

(It does not fix the issue of `Symbol('a')` automatically being considered
hermitian)


On 15 July 2013 11:01, Alex Bredariol Grilo abgr...@gmail.com wrote:

 Hi,
 I've starting using sympy and I really like it.

 But I would like to report a bug I had on online shell.

 I was running the following piece of code:
 ===
 a, b, c, d = symbols('a b c d')
 Matrix([[a,b,0,0], [c,d,0,0], [0,0, a,b], [0,0,
 c,d]]).transpose().applyfunc(conjugate)
 ===

 But the conjugate is not being applied to a and b entries of the
 matrix. I tried with other
 functions and it seemed ok, only with conjugate I'm having this issue.

 Thanks in advance,
 Alex

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: Exponentiation for non-diagonalizable matrices

2013-07-15 Thread Stefan Krastanov

In the mamueller's PR there are removed tests, but otherwise is seems
closer to completion. Given that you have already merged it, *if* it passes
the tests that are already in master feel free to use it instead of mine.

Please be sure that there are not two parallel implementations created this
way, because there are already some placeholders and tests in master (by
Alexey (@goodok) I think).


On 15 July 2013 15:40, F. B. franz.bona...@gmail.com wrote:

 OK, you pointed me out two pending PR about the Jordan form.

 I worked on mamueller's one and I've merged it with the latest master
 branch. I did not inspect Krastanov's PR yet, but it looks like they are
 clashing against each other.

 In mamueller's one the Matrix.exp( ) already works on non-diagonalizable
 matrices, which seems good.

 Which PR do you suggest I should look for?


 On Monday, July 15, 2013 2:47:59 AM UTC+2, Rick Muller wrote:

 You're right. I guess I see the world through a numeric lens that I don't
 even notice anymore.

 On Sunday, July 14, 2013 5:59:47 PM UTC-6, Aaron Meurer wrote:

 That paper mainly deals with numeric methods, and maintaining
 numerical stability, which are not issues for symbolic matrices, but
 the Jordan method is described (briefly) as method 16. It does
 actually give a closed form for the exponential of a Jordan block,
 which can be built much more efficiently by using the form of it than
 by taking the powers of the matrices directly.

 But maybe some other method there is also useful for symbolic
 computation.

 Aaron Meurer

 On Sun, Jul 14, 2013 at 6:21 PM, Rick Muller rpmu...@gmail.com wrote:
  There's a great article from SIAM Review of matrix exponentiation
 called 19
  Dubious Ways to Exponentiate a Matrix that's fun reading if people
 aren't
  already familiar with it. May have some useful tricks.
 
 
  On Sunday, July 14, 2013 8:35:32 AM UTC-6, F. B. wrote:
 
   m = Matrix([[0, 1], [0, 0]])
   exp(m)
  NotImplementedError: Exponentiation is implemented only for
 diagonalizable
  matrices
 
 
  What is the best way to implement the exponentiation for
 non-diagonalibale
  matrices?
 
  I thought a way to fix it could be by Taylor expansion (hoping
  non-diagonalizable matrices over the complexes are nilpotent).
 
  Any better ideas? Just suggest me something and I'll try to fix it.
 
  --
  You received this message because you are subscribed to the Google
 Groups
  sympy group.
  To unsubscribe from this group and stop receiving emails from it, send
 an
  email to sympy+un...@googlegroups.com.
  To post to this group, send email to sy...@googlegroups.com.
  Visit this group at 
  http://groups.google.com/**group/sympyhttp://groups.google.com/group/sympy.

  For more options, visit 
  https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out.

 
 

  --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: Exponentiation for non-diagonalizable matrices

2013-07-15 Thread Stefan Krastanov

By the way, finishing this is one of the necessary conditions for the
systems of ODEs solver. However in the coming weeks I will not have the
time to help with all this.


On 15 July 2013 15:47, Stefan Krastanov krastanov.ste...@gmail.com wrote:

 In the mamueller's PR there are removed tests, but otherwise is seems
 closer to completion. Given that you have already merged it, *if* it passes
 the tests that are already in master feel free to use it instead of mine.

 Please be sure that there are not two parallel implementations created
 this way, because there are already some placeholders and tests in master
 (by Alexey (@goodok) I think).


 On 15 July 2013 15:40, F. B. franz.bona...@gmail.com wrote:

 OK, you pointed me out two pending PR about the Jordan form.

 I worked on mamueller's one and I've merged it with the latest master
 branch. I did not inspect Krastanov's PR yet, but it looks like they are
 clashing against each other.

 In mamueller's one the Matrix.exp( ) already works on non-diagonalizable
 matrices, which seems good.

 Which PR do you suggest I should look for?


 On Monday, July 15, 2013 2:47:59 AM UTC+2, Rick Muller wrote:

 You're right. I guess I see the world through a numeric lens that I
 don't even notice anymore.

 On Sunday, July 14, 2013 5:59:47 PM UTC-6, Aaron Meurer wrote:

 That paper mainly deals with numeric methods, and maintaining
 numerical stability, which are not issues for symbolic matrices, but
 the Jordan method is described (briefly) as method 16. It does
 actually give a closed form for the exponential of a Jordan block,
 which can be built much more efficiently by using the form of it than
 by taking the powers of the matrices directly.

 But maybe some other method there is also useful for symbolic
 computation.

 Aaron Meurer

 On Sun, Jul 14, 2013 at 6:21 PM, Rick Muller rpmu...@gmail.com
 wrote:
  There's a great article from SIAM Review of matrix exponentiation
 called 19
  Dubious Ways to Exponentiate a Matrix that's fun reading if people
 aren't
  already familiar with it. May have some useful tricks.
 
 
  On Sunday, July 14, 2013 8:35:32 AM UTC-6, F. B. wrote:
 
   m = Matrix([[0, 1], [0, 0]])
   exp(m)
  NotImplementedError: Exponentiation is implemented only for
 diagonalizable
  matrices
 
 
  What is the best way to implement the exponentiation for
 non-diagonalibale
  matrices?
 
  I thought a way to fix it could be by Taylor expansion (hoping
  non-diagonalizable matrices over the complexes are nilpotent).
 
  Any better ideas? Just suggest me something and I'll try to fix it.
 
  --
  You received this message because you are subscribed to the Google
 Groups
  sympy group.
  To unsubscribe from this group and stop receiving emails from it,
 send an
  email to sympy+un...@googlegroups.com.
  To post to this group, send email to sy...@googlegroups.com.
  Visit this group at 
  http://groups.google.com/**group/sympyhttp://groups.google.com/group/sympy.

  For more options, visit 
  https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out.

 
 

  --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Problem matrices applyfunc with conjugate

2013-07-15 Thread Stefan Krastanov

I have only tested it on live.sympy and there the bug is present.


On 15 July 2013 17:11, Aaron Meurer asmeu...@gmail.com wrote:

 It looks like it works to me.

 In [1]: a, b, c, d = symbols('a b c d')
 M
 In [2]: print Matrix([[a,b,0,0], [c,d,0,0], [0,0, a,b], [0,0,
 c,d]]).transpose().applyfunc(conjugate)
 Matrix([[conjugate(a), conjugate(c), 0, 0], [conjugate(b),
 conjugate(d), 0, 0], [0, 0, conjugate(a), conjugate(c)], [0, 0,
 conjugate(b), conjugate(d)]])

 Aaron Meurer


 On Mon, Jul 15, 2013 at 8:54 AM, Matthew Rocklin mrock...@gmail.com
 wrote:
  In [1]: print conjugate(Symbol('a'))
  conjugate(a)
 
 
 
  On Mon, Jul 15, 2013 at 5:35 AM, Stefan Krastanov
  krastanov.ste...@gmail.com wrote:
 
  I do not know where this extremely bizarre bug comes from, but I would
  like to remark that you can access the hermitian conjugate of a matrix
  through `matrix.H` or the transpose through `matrix.T`.
 
  (It does not fix the issue of `Symbol('a')` automatically being
 considered
  hermitian)
 
 
  On 15 July 2013 11:01, Alex Bredariol Grilo abgr...@gmail.com wrote:
 
  Hi,
  I've starting using sympy and I really like it.
 
  But I would like to report a bug I had on online shell.
 
  I was running the following piece of code:
  ===
  a, b, c, d = symbols('a b c d')
  Matrix([[a,b,0,0], [c,d,0,0], [0,0, a,b], [0,0,
  c,d]]).transpose().applyfunc(conjugate)
  ===
 
  But the conjugate is not being applied to a and b entries of the
  matrix. I tried with other
  functions and it seemed ok, only with conjugate I'm having this issue.
 
  Thanks in advance,
  Alex
 
  --
  You received this message because you are subscribed to the Google
 Groups
  sympy group.
  To unsubscribe from this group and stop receiving emails from it, send
 an
  email to sympy+unsubscr...@googlegroups.com.
  To post to this group, send email to sympy@googlegroups.com.
  Visit this group at http://groups.google.com/group/sympy.
  For more options, visit https://groups.google.com/groups/opt_out.
 
 
 
 
  --
  You received this message because you are subscribed to the Google
 Groups
  sympy group.
  To unsubscribe from this group and stop receiving emails from it, send
 an
  email to sympy+unsubscr...@googlegroups.com.
  To post to this group, send email to sympy@googlegroups.com.
  Visit this group at http://groups.google.com/group/sympy.
  For more options, visit https://groups.google.com/groups/opt_out.
 
 
 
 
  --
  You received this message because you are subscribed to the Google Groups
  sympy group.
  To unsubscribe from this group and stop receiving emails from it, send an
  email to sympy+unsubscr...@googlegroups.com.
  To post to this group, send email to sympy@googlegroups.com.
  Visit this group at http://groups.google.com/group/sympy.
  For more options, visit https://groups.google.com/groups/opt_out.
 
 

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Exponentiation for non-diagonalizable matrices

2013-07-14 Thread Stefan Krastanov

Concerning generalized eigenvector and jordan forms, somebody already
provided tests for them, but no implementation. A 3/4 finished
implementation can be found here[1], but probably it is not mergeable
anymore.


[1]: https://github.com/krastanov/sympy/tree/jordan_1


On 14 July 2013 18:40, Aaron Meurer asmeu...@gmail.com wrote:

 No, each non-diagonalizable matrix can be put into Jordan form, which is
 is a matrix of blocks that are a sum of a diagonal part and a nilpotent
 part (if you don't believe me, try finding the taylor expansion of m =
 Matrix([[2, 1, 0, 0], [0, 2, 0, 0], [0, 0, 1, 0], [0, 0, 0, 1]])).

 This is indeed how you compute the exponential (or at least how I was
 taught). You find the Jordan blocks lambda*I + N and use the fact that
 exp(lambda*I + N) = exp(lambda*I)*exp(N), where the first exponential is
 just exp(lambda)*I and the second has a finite taylor expansion, so can
 just be computed by I + N + 1/2!*N**2 + ..., which is a finite sum. (I
 think there are more efficient ways of computing exp(N) than using the
 taylor expansion, but even doing it the stupid way would be better than
 nothing).

 Aaron Meurer


 On Sun, Jul 14, 2013 at 11:15 AM, F. B. franz.bona...@gmail.com wrote:

 What about a temporary quick fix using the nilpotent matrix trick?
 Wikipedia claims that if the matrix is non-diagonalizable over the complex
 field, it is nilpotent. This means finite Taylor expansion.


 On Sunday, July 14, 2013 5:59:45 PM UTC+2, Aaron Meurer wrote:

 The usual way to do it is to use generalized eigenvectors and Jordan
 form. Some work was started at 
 https://github.com/sympy/**sympy/pull/677https://github.com/sympy/sympy/pull/677,
 but it needs to be finished.

 See also these issues: https://code.google.**com/p/sympy/issues/list?q=
 **jordan https://code.google.com/p/sympy/issues/list?q=jordan

 Aaron Meurer


 On Sun, Jul 14, 2013 at 9:35 AM, F. B. franz@gmail.com wrote:

   m = Matrix([[0, 1], [0, 0]])
  exp(m)
 NotImplementedError: Exponentiation is implemented only for
 diagonalizable matrices


 What is the best way to implement the exponentiation for
 non-diagonalibale matrices?

 I thought a way to fix it could be by Taylor expansion (hoping
 non-diagonalizable matrices over the complexes are nilpotent).

 Any better ideas? Just suggest me something and I'll try to fix it.

  --
 You received this message because you are subscribed to the Google
 Groups sympy group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to sympy+un...@**googlegroups.com.
 To post to this group, send email to sy...@googlegroups.com.

 Visit this group at 
 http://groups.google.com/**group/sympyhttp://groups.google.com/group/sympy
 .
 For more options, visit 
 https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
 .




  --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




  --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Exponentiation for non-diagonalizable matrices

2013-07-14 Thread Stefan Krastanov

The commit itself is here[1]. The code is very simple and there is
documentation.

[1]:
https://github.com/Krastanov/sympy/commit/ac37a577bcbdf5ef196a3fc210920bc5e2c7128c


On 14 July 2013 23:55, Stefan Krastanov krastanov.ste...@gmail.com wrote:

 Concerning generalized eigenvector and jordan forms, somebody already
 provided tests for them, but no implementation. A 3/4 finished
 implementation can be found here[1], but probably it is not mergeable
 anymore.


 [1]: https://github.com/krastanov/sympy/tree/jordan_1


 On 14 July 2013 18:40, Aaron Meurer asmeu...@gmail.com wrote:

 No, each non-diagonalizable matrix can be put into Jordan form, which is
 is a matrix of blocks that are a sum of a diagonal part and a nilpotent
 part (if you don't believe me, try finding the taylor expansion of m =
 Matrix([[2, 1, 0, 0], [0, 2, 0, 0], [0, 0, 1, 0], [0, 0, 0, 1]])).

 This is indeed how you compute the exponential (or at least how I was
 taught). You find the Jordan blocks lambda*I + N and use the fact that
 exp(lambda*I + N) = exp(lambda*I)*exp(N), where the first exponential is
 just exp(lambda)*I and the second has a finite taylor expansion, so can
 just be computed by I + N + 1/2!*N**2 + ..., which is a finite sum. (I
 think there are more efficient ways of computing exp(N) than using the
 taylor expansion, but even doing it the stupid way would be better than
 nothing).

 Aaron Meurer


 On Sun, Jul 14, 2013 at 11:15 AM, F. B. franz.bona...@gmail.com wrote:

 What about a temporary quick fix using the nilpotent matrix trick?
 Wikipedia claims that if the matrix is non-diagonalizable over the complex
 field, it is nilpotent. This means finite Taylor expansion.


 On Sunday, July 14, 2013 5:59:45 PM UTC+2, Aaron Meurer wrote:

 The usual way to do it is to use generalized eigenvectors and Jordan
 form. Some work was started at https://github.com/sympy/**
 sympy/pull/677 https://github.com/sympy/sympy/pull/677, but it needs
 to be finished.

 See also these issues: https://code.google.**
 com/p/sympy/issues/list?q=**jordanhttps://code.google.com/p/sympy/issues/list?q=jordan

 Aaron Meurer


 On Sun, Jul 14, 2013 at 9:35 AM, F. B. franz@gmail.com wrote:

   m = Matrix([[0, 1], [0, 0]])
  exp(m)
 NotImplementedError: Exponentiation is implemented only for
 diagonalizable matrices


 What is the best way to implement the exponentiation for
 non-diagonalibale matrices?

 I thought a way to fix it could be by Taylor expansion (hoping
 non-diagonalizable matrices over the complexes are nilpotent).

 Any better ideas? Just suggest me something and I'll try to fix it.

  --
 You received this message because you are subscribed to the Google
 Groups sympy group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to sympy+un...@**googlegroups.com.
 To post to this group, send email to sy...@googlegroups.com.

 Visit this group at 
 http://groups.google.com/**group/sympyhttp://groups.google.com/group/sympy
 .
 For more options, visit 
 https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
 .




  --
 You received this message because you are subscribed to the Google
 Groups sympy group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




  --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.






-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

2013-07-10 Thread Stefan Krastanov

@Prasoon, maybe I misunderstood what you suggest, but on first glance it
seems it will work awfully in the following case:

coordinate systems:

A (carthesian) - B - many more - U - V

where U and V have the same origin and orientation but U is carthesian
while V is polar.

How will something defined in U will be expressed in V according to your
suggestion?

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Unbundle mpmath

2013-07-10 Thread Stefan Krastanov

The issue is that `mpmath.whatever` and `sympy.mpmath.whatever` are
considered by the interpreter to be different classes even if the same
versions of mpmath are used, hence methods like `__add__` raise
NotImplementedError. I have heard this issue to be raised occasionally
before.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Differential of a parametric equation

2013-07-09 Thread Stefan Krastanov

What is diff(y, x, 2) and diff(y, x)? y and x should be the variables, so
dy/dx is zero. What is the unknown function?

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Differential of a parametric equation

2013-07-09 Thread Stefan Krastanov

Oh, now I see, you are searching for the curvature of a graph. So you have
y as a function of x.

From what you have written I presume that you want the expression for the
curvature of a curve when the curve is given in the form r as a function
of theta.

I guess that the easiest way to do it is to start from x and y as
functions of a parameter instead of y as a function of x. See
http://en.wikipedia.org/wiki/Curvature#Local_expressions

So here you go:

# The parameter
t = Symbol('t')

# These are FUNCTIONS, not symbols
x, y, r, theta = [Function(_)(t) for _ in ['x', 'y', 'r', 'theta']]
x, y, r, theta

# The substitutions
x_in_polar = r*sin(theta)
y_in_polar = r*cos(theta)

# The general expression for the curvature taken from wikipedia (not too
hard to derive)
curvature = (x.diff(t)*y.diff(t,t) - y.diff(t)*x.diff(t,t)) / (x.diff(t)**2
+ y.diff(t)**2)**(S(3)/2)

# After substitution
curvature_in_polar = curvature.subs({x:x_in_polar,
y:y_in_polar}).doit().simplify()

# Now we say: the parameter is actually theta itself, so theta(t) is just
theta
# This is the SYMBOL theta, not the same as the FUNCTION theta
stheta = Symbol('theta')
curvature_in_polar_parametrized_by_theta = \
curvature_in_polar.subs({theta: stheta, t:stheta}).doit().simplify()

print curvature_in_polar_parametrized_by_theta

result:

(-r(theta)**2 + r(theta)*Derivative(r(theta), theta, theta) -
2*Derivative(r(theta), theta)**2)/(r(theta)**2 + Derivative(r(theta),
theta)**2)**(3/2)

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Saving figures with plot()

2013-07-06 Thread Stefan Krastanov

A small correction: It is not a matplotlib object. However, if you use
the matplotlib backend
you can access the encapsulated matplotlib objects through `p._backend`.

On 6 July 2013 20:43, Aaron Meurer asmeu...@gmail.com wrote:
 Yes, our documentation for plot() could be better (pull requests welcome!).
 Basically, plot(show=False) just returns the matplotlib object, and so you
 can call all the normal matplotlib functions on it.

 Aaron Meurer


 On Sat, Jul 6, 2013 at 12:31 PM, Amit Saha amitsaha...@gmail.com wrote:

 This is something which was not obvious to me (or I don't read well),
 so posting it in case it helps someone:

  from sympy import plot
  from sympy import Symbol

  x=Symbol('x')
  p = plot(2*x+3,show=False)

 Now, you have a object of the Plot class returned in p.

 So, you can either see the graph now:
  p.show()

 Or save it:

  p.save('/tmp/foo1.png')

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Unbundle mpmath

2013-07-04 Thread Stefan Krastanov

I am pretty much ok with any of the _non-complex_ suggestions
mentioned in the thread (for an appropriate definition of complex),
but I guess the following datapoint could be useful whenever you
decide to continue the discussion:

- on more than one occasion I have wanted to install only the
polynomials module without the rest of sympy

- the same goes for the core+polynomials without anything else

The reasons were usually revolving around building a better mental
model of the library, searching for unnecessary or even stupid
dependencies, etc.

It would also be very useful for experimentation. Currently sympy does
_not_ have a simple core. At least in the mental model of more casual
user like myself.

On 4 July 2013 04:35, Joachim Durchholz j...@durchholz.org wrote:
 Am 03.07.2013 20:17, schrieb Ondřej Čertík:

 So we can create all these little or bigger packages, like mpmath,
 memoization, polys, decorators, cythonutils, parsing. And make the
 user install all those in order to run sympy. I don't think it would
 make things simpler for the user. I think it would make things more
 complex.


 Erm... no?
 If a user needs one package, the other packages can be pulled as needed via
 dependencies.
 Plus a meta-package that just contains dependencies on every module in
 SymPy.

 Sholdn't make the users' lives more complex, except that they have more
 options (which can be a complication in itself, but if smaller packages are
 desired ... *shrug*).

 It would make development harder because dependencies between packages would
 have to be spelled out, and the correctness of the dependency information
 would need to be unit tested. (I have no idea to do that kind of dependency
 check in Python, so maybe it's not reasonably feasible at all.)


 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Sympy and MathML... ideas?

2013-07-02 Thread Stefan Krastanov

This is probably not very helpful, but why require the students to
write their results in MathML? It is not a very natural way to write
expression. On the other hand, if you use valid python expression it
would probably be much easier.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Sympy and MathML... ideas?

2013-07-02 Thread Stefan Krastanov

I am sorry, I do not think there is an out-of-the-box way to do this currently.

What I can suggest is to use the xml2dict python library to parse the
openmath xml and then write your own small routine for traversing the
dictionary and transforming it into a sympy expression.

If you do this I am sure that the sympy team would be very interested
to have your work merged.


On 2 July 2013 18:22, peibol pabe...@gmail.com wrote:
 Hehe, they don't write the expression in MathML, I'm not that kind of demon.

 They enter expressions in a textarea by means of
 http://mathdox.org/formulaeditor/, from which I can get the openmath or the
 (presentation) mathml .The web app is for K12 students, well 12-16 years
 old, so I think this way to enter mathematical expressions is one of the
 easiest...

 El martes, 2 de julio de 2013 18:17:19 UTC+2, Stefan Krastanov escribió:

 This is probably not very helpful, but why require the students to
 write their results in MathML? It is not a very natural way to write
 expression. On the other hand, if you use valid python expression it
 would probably be much easier.

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Solving a quadratic symbolically (Sympy vs. Mathematica)

2013-06-30 Thread Stefan Krastanov

f_1 = x + s1 + s2 + s5 - t1

this is all that you need to do if I understand your question correctly

Or if you wish, you can create 'Eq(right_hand, left_hand)' instances.

On 30 June 2013 21:09, Justin Carden carden.jus...@gmail.com wrote:
 Hi all,

 I'm trying to make the switch from Mathematica to Python in the lab, but I'm
 running into a small problem binding the result space to a boundary.
 Specifically, I'm trying to assign equality to each polynomial equation in a
 system to a total t1,t2 and t3 to solve the system symbolically. Since
 double equals (==)
 tests equality exactly and not symbolically in Sympy, setting the equations
 to t1,t2 or t3 does not work. This works in Mathematica with no problem.

 How would I go about doing this with Sympy ?
 (Complete code for the system in both mathematica and Sympy below)

 Mathematica:

 f1 = x + s1 + s2 + s5 == t1
 f2 = y + s2 + s3 + s6 == t2
 f3 = z + s4 + s5 + s6 == t3

 Current Sympy:
 f_1 = x + s1 + s2 + s5
 f_2 = y + s2 + s3 + s6
 f_3 = z + s4 + s5 + s6



 =
 Sympy
 =
 k1 = kdAA = 0.11
 k2 = kdBB = 0.0
 k3 = kdCC = 0.0
 k4 = kdAB = 0.25
 k5 = kdAC = 0.5
 k6 = kdBC = 0.33

 kineticRates = [k1,k2,k3,k4,k5,k6]


 t1 = totA = 1000
 t2 = totB = 500
 t3 = totC = 100

 totals = [t1,t2,t3]

 freeA = x
 freeB = y
 freeC = z

 free = [freeA,freeB,freeC]

 s1 = kdAA*x**2
 s2 = kdAB*x*y
 s3 = kdBB*y**2
 s4 = kdCC*z**2
 s5 = kdAC*x*z
 s6 = kdBC*y*z

 states = [s1,s2,s3,s4,s5,s6]

 f_1 = x + s1 + s2 + s5
 f_2 = y + s2 + s3 + s6
 f_3 = z + s4 + s5 + s6

 system = [f_1,f_2,f_3]

 results = solve(system, x,y,z, dict=True, set=True)

 --

 [{x: -9.09090909090909, z: 0, y: 0},
 {x: -4.00, z: 0, y: -2.24},
 {x: -2.00, z: -1.56, y: 0},
 {x: -1.96537201684605, z: -1.54138483572269, y: -0.0524666411423548},
 {x: 0, z: -3.03030303030303, y: -3.03030303030303},
 {x: 0, z: 0, y: 0}]


 =
 Mathematica
 =

 eq1 = kdAA = 0.11
 eq2 = kdBB = 0.0
 eq3 = kdCC = 0.0
 eq4 = kdAB = 0.25
 eq5 = kdAC = 0.5
 eq6 = kdBC = 0.33

 t1 = totA = 1000
 t2 = totB = 500
 t3 = totC = 100

 freeA = x
 freeB = y
 freeC = z

 s1 = kdAA*x^2
 s2 = kdAB*x*y
 s3 = kdBB*y^2
 s4 = kdCC*z^2
 s5 = kdAC*x*z
 s6 = kdBC*y*z

 f1 = x + s1 + s2 + s5 == t1
 f2 = y + s2 + s3 + s6 == t2
 f3 = z + s4 + s5 + s6 == t3

 NSolve[{f1, f2, f3}, {x, y, z}]

 --

 Out[22] =

 {{x - -1.4282, y - -1.08259, z - -1401.51},

 {x - -6.67923, y - -598.932,  z - -0.500032},

 {x - -2.17279 - 53.7467 I, y - -1.88296 + 63.8985 I, z - -2.08239 +
 17.0259 I},

  {x - -2.17279 + 53.7467 I,  y - -1.88296 - 63.8985 I, z - -2.08239 -
 17.0259 I},

 {x - -66.1313, y - -30.6463, z - -2.37085},

  {x - 61.528, y - 29.1041, z - 2.41731}}

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Solving a quadratic symbolically (Sympy vs. Mathematica)

2013-06-30 Thread Stefan Krastanov

The equations are nonlinear and it seems that sympy is unable to solve
them. Maybe there is a way to instruct sympy how to deal with them but
I do not know how.

However, there is a very big difference between your mathematica code
and your sympy code. In mathematica you are calling `NSolve`, which is
a numeric solver, not a symbolic one. In sympy you are calling
`solve`, which is searching for a general symbolic solution. You
should either use `sympy.nsolve` or something from `scipy`.
`sympy.nsolve` returns only one solution and needs a starting point.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Feynman diagrams

2013-06-30 Thread Stefan Krastanov

@Brian, what would be the correct way to write something like

gluon(lorentz_index, su3_index) * group_generator(su3_index,
antispinor_index, spinor_index) * top_quark(spinor_index)

in the physics.quantum module?

On 30 June 2013 21:31, Brian Granger elliso...@gmail.com wrote:
 Extra bonus points if this stuff can be integrated with sympy.physics
 or even better sympy.physics.quantum...otherwise we just keep creating
 new corners of sympy that don't work together.  I know it is easier,
 but in the long run it is a horrible situation.  The stuff in
 sympy.physics.quantum is completely general and should be able to
 handle all of this with some work.  It would also be great to get
 secondquant.py into sympy.physics.quantum so it doesn't reinvent the
 wheel.  It even has wicks theorem, which is the foundation of all
 Feynman diagrams.  Let's do this right!

 Cheers,

 Brian

 On Sun, Jun 30, 2013 at 10:38 AM, Ondřej Čertík ondrej.cer...@gmail.com 
 wrote:
 Hi Stefan,

 This is cool. I would be interested in having this in sympy. Long time
 ago I wrote some diagram generating code for scalar diagrams:

 https://github.com/certik/sympy/blob/wick/t.py

 but I didn't have time to polish it up and send a PR. As you correctly
 mentioned, there are lots of steps and actually several approaches to
 this problem and we should simply start adding such codes to sympy.
 What I wrote is just one little tiny bit, but it is still useful to
 check scalar particle diagrams. This is for relativistic theory.

 Then I have code here that generates the non-relativistic perturbation
 theory diagrams for total energy:

 https://github.com/certik/hfsolver/blob/master/src/diagrams_mbpt.py

 here is the corresponding Fortran code for evaluating them:

 https://github.com/certik/hfsolver/blob/master/src/mbpt.f90

 these 3 files are generated:

 https://github.com/certik/hfsolver/blob/master/src/mbpt2.f90
 https://github.com/certik/hfsolver/blob/master/src/mbpt3.f90
 https://github.com/certik/hfsolver/blob/master/src/mbpt4.f90

 and then the same for Green's functions:

 https://github.com/certik/hfsolver/blob/master/src/diagrams_gf.py

 and the Fortran code (this one I wrote by hand):

 https://github.com/certik/hfsolver/blob/master/src/gf2.f90


 Anyway, we should have this in sympy.

 Ondrej

 --
 You received this message because you are subscribed to the Google Groups 
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.





 --
 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 unsubscribe from this group and stop receiving emails from it, send an 
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Solving a quadratic symbolically (Sympy vs. Mathematica)

2013-06-30 Thread Stefan Krastanov

For the moment mathematica is more advanced than sympy both in finding
symbolic solutions and in finding _multiple_ numeric solutions. This
explains most of the differences in results.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Unbundle mpmath

2013-06-28 Thread Stefan Krastanov

I am also of the opinion that we should unbundle it. Python has an
extremely easy dependency tracking system and libraries can be easily
installed without root privileges (with virtualenv and pip). Moreover,
for the lazy scientists there are many pre-bundled python
distributions ready to use. Even if considering the google app engine,
installing mpmath is as difficult/easy as installing sympy.

On 28 June 2013 15:42, Sergey Kirpichev skirpic...@gmail.com wrote:
 There is a long term issue [1] to make mpmath an external dependency.  It
 was suggested by
 Aaron (see discussion in PR [2]), that we should discuss this on the mailing
 list.

 Perhaps, the main reason to prefer bundled mpmath copy is a
 mystical complex installation.  Not clear enough.  For example, I don't
 think that additional steps for package installation from mpmath manual does
 matter.  For non-root users
 there shouldn't be any problems too, at least for Python 2.6+ (per-user
 site-package directory).

 [1] http://code.google.com/p/sympy/issues/detail?id=2482
 [2] https://github.com/sympy/sympy/pull/2192

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Unbundle mpmath

2013-06-28 Thread Stefan Krastanov

@Sergey, I think Ondrej's point is that installing dependencies is not
as easy as I have suggested. I guess this is open for debate.

There is probably also a psychological barrier. `mpmath` is the only
hard requirement for running sympy, and having it bundled permits the
project to say that it has no dependencies (to be fair, I was left
with the impression that most of mpmath was developed under the
umbrella of sympy).

On 28 June 2013 23:44, Sergey B Kirpichev skirpic...@gmail.com wrote:
 On Fri, Jun 28, 2013 at 04:20:29PM -0500, Ondřej Čertík wrote:
 As far as physically removing sympy.mpmath, is the issue its size?
 The sympy/ dir on my computer has 15M, sympy/mpmath has 1.9M. So the
 size of mpmath can hardly be a reason.

 Not the size, of course.  The reasons to drop this bundled library is
 exactly the reasons why people prefer to use external libraries
 instead of bundled copies.  Independent (security) updates for
 library, prevent forking, etc.

 That being said, if projects like binstar (https://binstar.org/),
 which was announced *yesterday*, take off and allow easy
 installation on all platforms (including Windows...), we can revisit
 this. Clearly, the issue of distribution of packages has not been
 fixed *today*.

 I don't see any reasons why this new project is an argument.  Can
 you list some real problems (better for python = 2.5)?

 --
 You received this message because you are subscribed to the Google Groups 
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Problem when plotting geometric entities (circles)

2013-06-27 Thread Stefan Krastanov

By the way, you probably do not need to specify the ranges anyway. Just use:

plot_implicit(geometry.Circle(geometry.Point(1,1),2).equation())

On 27 June 2013 18:23, Stefan Krastanov krastanov.ste...@gmail.com wrote:
 In sympy symbols are just instances of the `Symbol` class. Usually
 they are identified only by their name so `Symbol('x') == Symbol('x')`
 is always True and the two instances created by this expression
 evaluate in the same way, have the same hash, etc (and probably are
 the same datastructure in memory (there are some other details but
 they do not matter here)).

 The geometric module adds assumptions to these symbols (that they are
 real for instance). So now, because of issues surrounding our
 assumptions subsystem `Symbol('x') != Symbol('x', positive=True)`.

 So now the plotting module thinks that your expressions involve 4 symbols.

 What you can do is either get the symbols out of the equations with
 `equation().free_symbols` or specify the symbols to be used yourself
 with `equation(x=my_x_symbol, y=my_y_symbol)`.

 offtopic 1: you do not need to use `Eq(..., 0)`

 offtopic 2: do not use floats when you can use integers if you care
 about precision (sympy transforms integer division into rationals
 (infinite precision), but float division into high-but-not-infinite
 precision floats). This is especially true in geometry, when you do
 intersection checks.

 offtopic 3: try to send cleaned up minimal code samples, so it is
 easier to track down the problem

 offtopic 4: implementing a dedicated plotting helper for these objects
 would be many orders of magnitude faster than the raster implicit
 plotting.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Problem when plotting geometric entities (circles)

2013-06-27 Thread Stefan Krastanov

In sympy symbols are just instances of the `Symbol` class. Usually
they are identified only by their name so `Symbol('x') == Symbol('x')`
is always True and the two instances created by this expression
evaluate in the same way, have the same hash, etc (and probably are
the same datastructure in memory (there are some other details but
they do not matter here)).

The geometric module adds assumptions to these symbols (that they are
real for instance). So now, because of issues surrounding our
assumptions subsystem `Symbol('x') != Symbol('x', positive=True)`.

So now the plotting module thinks that your expressions involve 4 symbols.

What you can do is either get the symbols out of the equations with
`equation().free_symbols` or specify the symbols to be used yourself
with `equation(x=my_x_symbol, y=my_y_symbol)`.

offtopic 1: you do not need to use `Eq(..., 0)`

offtopic 2: do not use floats when you can use integers if you care
about precision (sympy transforms integer division into rationals
(infinite precision), but float division into high-but-not-infinite
precision floats). This is especially true in geometry, when you do
intersection checks.

offtopic 3: try to send cleaned up minimal code samples, so it is
easier to track down the problem

offtopic 4: implementing a dedicated plotting helper for these objects
would be many orders of magnitude faster than the raster implicit
plotting.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

2013-06-25 Thread Stefan Krastanov

Make a pull request please, so we can have diffs and line comments
visible for everybody.

On 25 June 2013 13:11, Prasoon Shukla prasoon92.i...@gmail.com wrote:
 Okay, so since there hasn't been any activity on this thread, let me post
 the link to my code :
 http://github.com/prasoon2211/sympy/tree/vector

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Plotting geometric objects

2013-06-24 Thread Stefan Krastanov

It is not supported yet.

If you want, you can use the old plotting module (the only difference
is the import path).

If you are willing, feel free to contribute the needed routines for
the new plotting module. You will need to create a new `Series`
subclass and mostly copy the code from the old module. We would be
happy to help and grateful for the contribution.

On 24 June 2013 12:12, Amit Saha amitsaha...@gmail.com wrote:
 Hello,

 I saw a few examples of plotting geometric objects using the pyglet
 module here [1]. I also learned that this is not going to be developed
 actively going ahead.

 Could someone please point to me an example of plotting geometric
 objects using the plot() function? (Is it supported yet?)


 [1] 
 http://docs.sympy.org/dev/modules/plotting.html#plotting-geometric-entities


 Thanks,
 Amit.

 --
 http://echorand.me

 --
 You received this message because you are subscribed to the Google Groups 
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Plotting geometric objects

2013-06-24 Thread Stefan Krastanov

Check this:
http://docs.sympy.org/dev/modules/geometry.html#sympy.geometry.line.LinearEntity.arbitrary_point

I guess that subclassing the class for parametric 2d curves should be
sufficient. Then just hardcode the range for 't' (be sure to use a
Dummy and not a Symbol for it).

Concerning `list(args[0].arbitrary_point())` I do not know why it does
not work. Probably something was changed and this code is simply
broken now as there are no tests for it. I guess the author meant to
write `args[0].arbitrary_point().args` in order to get the parametric
expressions.

On 24 June 2013 13:19, Amit Saha amitsaha...@gmail.com wrote:
On Mon, Jun 24, 2013 at 8:27 PM, Amit Saha amitsaha...@gmail.com wrote:
Hello Stefan,

On Mon, Jun 24, 2013 at 8:21 PM, Stefan Krastanov
krastanov.ste...@gmail.com wrote:
It is not supported yet.

If you want, you can use the old plotting module (the only difference
is the import path).

If you are willing, feel free to contribute the needed routines for
the new plotting module. You will need to create a new `Series`
subclass and mostly copy the code from the old module. We would be
happy to help and grateful for the contribution.

Okay, i am trying to get a very rough idea of how the geometric
objects are being plotted and i come across these lines in
plotting/pygletplot/plot_mode.py:

if isinstance(args[0], GeometryEntity):
for coords in list(args[0].arbitrary_point()):
functions.append(coords)
intervals.append(PlotInterval.try_parse(args[0].plot_interval()))

To experiment, I create a circle:

c
Circle(Point(0, 0), 2)

and then:

list(c.arbitrary_point())
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: 'Point' object is not iterable

which is expected. How does the above code work then? Or is args[0]
something other than a single GeometricEntity instance?

Thanks,
Amit.

Thanks, I will try.

Did you mean 'BaseSeries' class btw?

For example, I see: class Line2DBaseSeries(BaseSeries):

On 24 June 2013 12:12, Amit Saha amitsaha...@gmail.com wrote:
Hello,

I saw a few examples of plotting geometric objects using the pyglet
module here [1]. I also learned that this is not going to be developed
actively going ahead.

Could someone please point to me an example of plotting geometric
objects using the plot() function? (Is it supported yet?)

[1]
http://docs.sympy.org/dev/modules/plotting.html#plotting-geometric-entities

Thanks,
Amit.

--
http://echorand.me

--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an
email to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

--
http://echorand.me

--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an
email to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Diophantine Equation Module

2013-06-20 Thread Stefan Krastanov

Unnamed dummies print with some numeric index, right?

Anyway, I very strongly feel that arguments about printing should be
considered only when there are no other concerns: SymPy is not a
typesetting library.

The other concerns:

- assumptions: If we were going to solve one simple equation, yes it
might be sufficient to mention assumptions only in the docstring, but
in a general api this will fail: What about intersections of some
algebraic curves where the parameter can take only certain values, or
(in other solvers) solutions to differential or functional equations
where there is something like a bifurcation and completely different
solutions arise for different values of a parameter (double roots in
the characteristic equation for instance)?

- Providing the appropriate number of parameters as a keyword will
require from the user to actually study the equation and deduce how
many parameters are needed. While I am always for forcing the user to
think about what he is writing, this is a bit too far: the whole idea
of the solver is that the user should not solve the equation by
himself. We have an algorithm to classify the equations, we should
just use it.


I am ok with the idea of providing an optional keyword argument for
the parameter name, but this should just be an afterthought, not the
main way to work with the api.

On 20 June 2013 08:40, Chris Smith smi...@gmail.com wrote:
 Dummy is insufficient to give a visually distinguished symbol as I
 indicated. Getting a results that looks like `{x: _t + _t + 2}`. But
 actually, if I'm not mistaken the coefficients will always be integers so at
 worst one might get {_t: _t + 2} where the dict key is the original Symbol
 and the `_t` in the value of the dict, the dummy parameter.

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] newbie question : exporting sympy plots to svg

2013-06-19 Thread Stefan Krastanov

The plot object has a `save` method. Calling it with a filename ending
on `.svg` should be enough if you use the matplotlib backend. The
capabilities of the plotting module depend a lot on the backend that
you are using.

 a=plot(...)
 a.save(*.svg)

On 19 June 2013 09:32,  a.ja...@gmail.com wrote:
 Hello everybody, bonjour tout le monde,
 I wonder if there's a way to export sympy plots to svg, as savefig with
 matplotlib ?
 Actually my aim is to convert this svg file to tkz from inkscape...

 thank you,
 merci d'avance,

 alex

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Diophantine Equation Module

2013-06-19 Thread Stefan Krastanov

Inputting the parameter as a keyword to the solver seems like an
extremely fragile solutions. What if we need two parameters? What if
we do not need any? How we add appropriate assumptions to the
parameter (integer or whatever)?

Moreover, this would create two divergent styles for the different
solvers: why should the additional symbols needed to represent
solutions to differential equations (the integration constants) follow
a different api from the Diophantine equations solver.

On 19 June 2013 17:13, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Tue, Jun 18, 2013 at 11:23 PM, Thilina Rathnayake
 thilina.r...@gmail.com wrote:


 When we ask the user to specify the parameter to be used, what should
 be the input? should it be a symbol or a string which contain the symbol
 to be used. What I am asking is whether we should use,

var(t)
diop_solve(3*x*y + 5*y -7, param=t)

 Yes, it should be a symbol.

 Ondrej


 or

diop_solve(3*x*y + 5*y -7, param=t)


 On Wed, Jun 19, 2013 at 10:35 AM, Thilina Rathnayake
 thilina.r...@gmail.com wrote:

 Thank you Ondrej for the reply.

 I think that's the way we should go at it. I can implement the
 moduels to find the solution and return those naturally as a list.
 Later we consider about the high level API's.


 On Wed, Jun 19, 2013 at 1:28 AM, Ondřej Čertík ondrej.cer...@gmail.com
 wrote:

 Hi Thilina,

 On Tue, Jun 18, 2013 at 12:39 PM, Thilina Rathnayake
 thilina.r...@gmail.com wrote:
  Hi everyone,
 
  Before continuing further with the Diophantine module development (PR
  #2168)
  I thought it would be better for me to get other people's views on the
  representation
  of solutions returned by diop_solve().

 Thanks for discussing it.

 
  The main routine of the module is diop_solve(), which takes a
  Diophantine
  equation
  as an argument and returns the solution of the equation. Currently the
  solution is
  returned as a dictionary. Ex:
 
  diop_solve(4*x + 6*y - 4)
  {x: 6*t - 2, y: -4*t + 2}
  diop_solve(3*x - 5*y + 7*z -5)
  {x: -25*t - 14*z + 10, y: -15*t - 7*z + 5, z: z}
 
 
  Everything works fine here because the solutions are parametric.

 Right. For these equations I think a dictionary is the best solution,
 as it is simple and clear.  You should allow the user to specify the
 t symbol, e.g. something like:

 var(x y z t)
 diop_solve(3*x - 5*y + 7*z -5, param=t)

 so that the user can specify other variables names besides t as well.

 
  But when I was trying to solve quadratic Diophantine equation ( this
  has the
  form
  Ax**2 + Bxy + Cy**2 + Dx + Ey + F), they involve solutions which are
  not
  parametric.
  For example, the equation 2*x*y + 5*x + 56*y + 7 = 0 (which is a
  special
  case of the
  quadratic equation) has 8 solution pairs (x, y). (-27, 64), (-29, -69),
  (-21, 7) and five more.
 
  To represent these in a dictionary which has the above form, we have to
  split the solution
  pair and put it in to two lists which are keyed under x and y in the
  dict.
  if the user want
  to retrieve a solution pair he would have to find the x value and the y
  value of the solution
  separately. Returned value would look like,
 
  {x: [-27, -29, -21, ...], y: [64, -69, 7, ...]}
 
 
  Is this a good way to cope with this situation? I personally feel that
  it is
  not natural to
  split a solution pair and enable the access of it's elements
  separately.
 
  I would like to know what the others have to say on this.


 So for this I agree with Aaron:

  You may want to look at
  https://code.google.com/p/sympy/issues/detail?id=3560 and some of the
  ideas for a unified solve object.

 We definitely need a consistent interface to the solve() command.

  Already you have the issue that you
  are returning a parameter, but there is no easy way to access that
  parameter (and what happens if t is one of the variables?).

 The user can specify his own symbols as params, as I suggested above.

 I would also look how Mathematica does it:

 http://reference.wolfram.com/mathematica/guide/DiophantineEquations.html

 e.g.:

 http://reference.wolfram.com/mathematica/ref/Reduce.html



 In general, I would suggest you simply write the low level modules for
 actually solving the equation.
 Those can return pretty much any representation that you think is the
 best for that particular type of the equation.

 Then we need a consistent high level API, and that will take some time
 to get right. But no matter what API we settle on in the end, it
 should be quite simple to call the low level solver and convert the
 result if needed. What do you think Aaron?

 Ondrej

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Diophantine Equation Module

2013-06-19 Thread Stefan Krastanov

Inputting the parameter as a keyword to the solver seems like a
fragile solutions. What if we need two parameters? What if we do not
need any? How we add appropriate assumptions to the parameter (integer
or whatever)?

Moreover, this would create two divergent styles for the different
solvers: why should the additional symbols needed to represent
solutions to differential equations (the integration constants) follow
a different api from the Diophantine

On 19 June 2013 17:13, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Tue, Jun 18, 2013 at 11:23 PM, Thilina Rathnayake
 thilina.r...@gmail.com wrote:


 When we ask the user to specify the parameter to be used, what should
 be the input? should it be a symbol or a string which contain the symbol
 to be used. What I am asking is whether we should use,

var(t)
diop_solve(3*x*y + 5*y -7, param=t)

 Yes, it should be a symbol.

 Ondrej


 or

diop_solve(3*x*y + 5*y -7, param=t)


 On Wed, Jun 19, 2013 at 10:35 AM, Thilina Rathnayake
 thilina.r...@gmail.com wrote:

 Thank you Ondrej for the reply.

 I think that's the way we should go at it. I can implement the
 moduels to find the solution and return those naturally as a list.
 Later we consider about the high level API's.


 On Wed, Jun 19, 2013 at 1:28 AM, Ondřej Čertík ondrej.cer...@gmail.com
 wrote:

 Hi Thilina,

 On Tue, Jun 18, 2013 at 12:39 PM, Thilina Rathnayake
 thilina.r...@gmail.com wrote:
  Hi everyone,
 
  Before continuing further with the Diophantine module development (PR
  #2168)
  I thought it would be better for me to get other people's views on the
  representation
  of solutions returned by diop_solve().

 Thanks for discussing it.

 
  The main routine of the module is diop_solve(), which takes a
  Diophantine
  equation
  as an argument and returns the solution of the equation. Currently the
  solution is
  returned as a dictionary. Ex:
 
  diop_solve(4*x + 6*y - 4)
  {x: 6*t - 2, y: -4*t + 2}
  diop_solve(3*x - 5*y + 7*z -5)
  {x: -25*t - 14*z + 10, y: -15*t - 7*z + 5, z: z}
 
 
  Everything works fine here because the solutions are parametric.

 Right. For these equations I think a dictionary is the best solution,
 as it is simple and clear.  You should allow the user to specify the
 t symbol, e.g. something like:

 var(x y z t)
 diop_solve(3*x - 5*y + 7*z -5, param=t)

 so that the user can specify other variables names besides t as well.

 
  But when I was trying to solve quadratic Diophantine equation ( this
  has the
  form
  Ax**2 + Bxy + Cy**2 + Dx + Ey + F), they involve solutions which are
  not
  parametric.
  For example, the equation 2*x*y + 5*x + 56*y + 7 = 0 (which is a
  special
  case of the
  quadratic equation) has 8 solution pairs (x, y). (-27, 64), (-29, -69),
  (-21, 7) and five more.
 
  To represent these in a dictionary which has the above form, we have to
  split the solution
  pair and put it in to two lists which are keyed under x and y in the
  dict.
  if the user want
  to retrieve a solution pair he would have to find the x value and the y
  value of the solution
  separately. Returned value would look like,
 
  {x: [-27, -29, -21, ...], y: [64, -69, 7, ...]}
 
 
  Is this a good way to cope with this situation? I personally feel that
  it is
  not natural to
  split a solution pair and enable the access of it's elements
  separately.
 
  I would like to know what the others have to say on this.


 So for this I agree with Aaron:

  You may want to look at
  https://code.google.com/p/sympy/issues/detail?id=3560 and some of the
  ideas for a unified solve object.

 We definitely need a consistent interface to the solve() command.

  Already you have the issue that you
  are returning a parameter, but there is no easy way to access that
  parameter (and what happens if t is one of the variables?).

 The user can specify his own symbols as params, as I suggested above.

 I would also look how Mathematica does it:

 http://reference.wolfram.com/mathematica/guide/DiophantineEquations.html

 e.g.:

 http://reference.wolfram.com/mathematica/ref/Reduce.html



 In general, I would suggest you simply write the low level modules for
 actually solving the equation.
 Those can return pretty much any representation that you think is the
 best for that particular type of the equation.

 Then we need a consistent high level API, and that will take some time
 to get right. But no matter what API we settle on in the end, it
 should be quite simple to call the low level solver and convert the
 result if needed. What do you think Aaron?

 Ondrej

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.




 --
 You received this

Re: [sympy] Diophantine Equation Module

2013-06-19 Thread Stefan Krastanov

sorry for  the dupe, problem with my drafts

On 19 June 2013 19:14, Stefan Krastanov krastanov.ste...@gmail.com wrote:
 Inputting the parameter as a keyword to the solver seems like a
 fragile solutions. What if we need two parameters? What if we do not
 need any? How we add appropriate assumptions to the parameter (integer
 or whatever)?

 Moreover, this would create two divergent styles for the different
 solvers: why should the additional symbols needed to represent
 solutions to differential equations (the integration constants) follow
 a different api from the Diophantine

 On 19 June 2013 17:13, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Tue, Jun 18, 2013 at 11:23 PM, Thilina Rathnayake
 thilina.r...@gmail.com wrote:


 When we ask the user to specify the parameter to be used, what should
 be the input? should it be a symbol or a string which contain the symbol
 to be used. What I am asking is whether we should use,

var(t)
diop_solve(3*x*y + 5*y -7, param=t)

 Yes, it should be a symbol.

 Ondrej


 or

diop_solve(3*x*y + 5*y -7, param=t)


 On Wed, Jun 19, 2013 at 10:35 AM, Thilina Rathnayake
 thilina.r...@gmail.com wrote:

 Thank you Ondrej for the reply.

 I think that's the way we should go at it. I can implement the
 moduels to find the solution and return those naturally as a list.
 Later we consider about the high level API's.


 On Wed, Jun 19, 2013 at 1:28 AM, Ondřej Čertík ondrej.cer...@gmail.com
 wrote:

 Hi Thilina,

 On Tue, Jun 18, 2013 at 12:39 PM, Thilina Rathnayake
 thilina.r...@gmail.com wrote:
  Hi everyone,
 
  Before continuing further with the Diophantine module development (PR
  #2168)
  I thought it would be better for me to get other people's views on the
  representation
  of solutions returned by diop_solve().

 Thanks for discussing it.

 
  The main routine of the module is diop_solve(), which takes a
  Diophantine
  equation
  as an argument and returns the solution of the equation. Currently the
  solution is
  returned as a dictionary. Ex:
 
  diop_solve(4*x + 6*y - 4)
  {x: 6*t - 2, y: -4*t + 2}
  diop_solve(3*x - 5*y + 7*z -5)
  {x: -25*t - 14*z + 10, y: -15*t - 7*z + 5, z: z}
 
 
  Everything works fine here because the solutions are parametric.

 Right. For these equations I think a dictionary is the best solution,
 as it is simple and clear.  You should allow the user to specify the
 t symbol, e.g. something like:

 var(x y z t)
 diop_solve(3*x - 5*y + 7*z -5, param=t)

 so that the user can specify other variables names besides t as well.

 
  But when I was trying to solve quadratic Diophantine equation ( this
  has the
  form
  Ax**2 + Bxy + Cy**2 + Dx + Ey + F), they involve solutions which are
  not
  parametric.
  For example, the equation 2*x*y + 5*x + 56*y + 7 = 0 (which is a
  special
  case of the
  quadratic equation) has 8 solution pairs (x, y). (-27, 64), (-29, -69),
  (-21, 7) and five more.
 
  To represent these in a dictionary which has the above form, we have to
  split the solution
  pair and put it in to two lists which are keyed under x and y in the
  dict.
  if the user want
  to retrieve a solution pair he would have to find the x value and the y
  value of the solution
  separately. Returned value would look like,
 
  {x: [-27, -29, -21, ...], y: [64, -69, 7, ...]}
 
 
  Is this a good way to cope with this situation? I personally feel that
  it is
  not natural to
  split a solution pair and enable the access of it's elements
  separately.
 
  I would like to know what the others have to say on this.


 So for this I agree with Aaron:

  You may want to look at
  https://code.google.com/p/sympy/issues/detail?id=3560 and some of the
  ideas for a unified solve object.

 We definitely need a consistent interface to the solve() command.

  Already you have the issue that you
  are returning a parameter, but there is no easy way to access that
  parameter (and what happens if t is one of the variables?).

 The user can specify his own symbols as params, as I suggested above.

 I would also look how Mathematica does it:

 http://reference.wolfram.com/mathematica/guide/DiophantineEquations.html

 e.g.:

 http://reference.wolfram.com/mathematica/ref/Reduce.html



 In general, I would suggest you simply write the low level modules for
 actually solving the equation.
 Those can return pretty much any representation that you think is the
 best for that particular type of the equation.

 Then we need a consistent high level API, and that will take some time
 to get right. But no matter what API we settle on in the end, it
 should be quite simple to call the low level solver and convert the
 result if needed. What do you think Aaron?

 Ondrej

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http

Re: [sympy] Diophantine Equation Module

2013-06-19 Thread Stefan Krastanov

 How we add appropriate assumptions to the
 parameter (integer or whatever)?

 I am not sure what you mean here.

I guess that the solution is valid only for an integer t (if we are
talking about a Diophantine equation). This information should be
provided, through the new assumption module I guess.

 Moreover, this would create two divergent styles for the different
 solvers: why should the additional symbols needed to represent
 solutions to differential equations (the integration constants) follow
 a different api from the Diophantine equations solver.

 We should follow the same API everywhere. Do you have some suggestions
 what the correct API should be?


I have an opinion, but it seems everybody has a different opinion
about it. I vote for something similar to

list of substitution dicts with an assumptions key and the use of
Parameter or IntegrationConstant subclass of Dummy:

example:

[{x:expr_of_t, y: other_expr_of_t, 'assumptions':
assumptions_object_with_info_about_t}]

It might be appropriate for assumptions to not be a key of the same
dict, but it is necessary to have it somewhere as data.

Parameters then can be gathered with atom(Parameter) if the user wants
to substitute them with something that prints better than Dummy.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

[sympy] is planet.sympy.org not updating again?

2013-06-18 Thread Stefan Krastanov

The last post is from some time ago.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

2013-06-17 Thread Stefan Krastanov

Thanks for the summary. I will be on IRC at the specified time.

On 16 June 2013 21:24, Prasoon Shukla prasoon92.i...@gmail.com wrote:
 I, Gilbert and Sachin met up today on the IRC. We talked about how exactly
 will we implement the Reference Frames - that is - how the data regarding
 position and orientation will be stored. Here's the conclusion we reached:

 1. The vector module will have a RefFrame class that supports positioning
 and orienting frames while Sachin will separately implement time support for
 a time variable.

 2. For positioning and orienting the reference frames : we will store the
 position/orientation with respect to a '0 reference' - which effectively
 means that we aren't saving what frame we are positioning/orienting against.

 3. Finding out relative position is a trivial task under such an
 implementation. The problem comes with finding proper relative orientation
 between two frames, as I shall describe in point 4.

 4. We will save a direction cosine matrix (dcm) that stores the orientation
 of each frame with respect to the zero reference. Then, going from one frame
 to other, the dcm matrices will follow such an order: frame_A - global
 (zero reference) - frame_B. The problem with this is that many expressions
 might not decompose/collapse as they should in this matrix.

 5. To address this problem of collapsability, we have decided to do some
 research. Since the elements of the matrix will be only terms involving
 sines and cosines, therefore, we will try to investigate ways by which we
 can ensure that the expressions collapse properly. Should we achieve a
 consistent result with these methods, we will proceed with above mentioned
 scheme.

 6. There were some other ideas too, involving storing DCMs into cache - but
 that will come later; we first need to make sure that the expressions
 collapse. But this will also be researched in the time tomorrow by me and
 Sachin.

 There were other ideas that we discussed but I have refrained from adding
 them here so as to not dilute the content. The discussion was carried on the
 IRC so the logs are available.

 The three of us will meet at 9:30 pm (Indian time) tomorrow again.
 Hopefully, Stefan will be able to join us as well.

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: Plotting: how to set line colors

2013-06-17 Thread Stefan Krastanov

I will write a more complete answer soon, but in the meantime you can
check the `examples` folder. In the docs for the plotting module
search for aesthetics.

On 17 June 2013 21:00, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Mon, Jun 17, 2013 at 12:58 PM, Ondřej Čertík ondrej.cer...@gmail.com 
 wrote:
 Hi,

 Here is one of my notebooks (work in progress) for the sympy tutorial:

 http://nbviewer.ipython.org/5799312

 How can I set line colors in the plot at the prompt [8]? I didn't find
 it in the docs:

 http://docs.sympy.org/dev/modules/plotting.html

 I assume I should save it to a variable p and then do something like

 p[0].line_color = red

 Except I didn't figure out the exact syntax yet.

 Also, is it possible to create a legend?

 I'll probably just use matplotlib for the more advanced plots, but I
 want to show the best we can do so far with plotting. Or maybe there
 is some way to call matplotlib commands on the plot? That might be the
 best solution.

 Ondrej

 --
 You received this message because you are subscribed to the Google Groups 
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: Plotting: how to set line colors

2013-06-17 Thread Stefan Krastanov

And by the way, as you mentioned, the docs for the plotting module can
indeed be better.

On 17 June 2013 21:56, Stefan Krastanov krastanov.ste...@gmail.com wrote:
 I answer your question in the attached notebook. But you should really
 check the 4 or 5 `example/beginner/plot*` ipython notebooks as they
 show much nicer examples (and some nice fancy options).

 On 17 June 2013 21:13, Stefan Krastanov krastanov.ste...@gmail.com wrote:
 I will write a more complete answer soon, but in the meantime you can
 check the `examples` folder. In the docs for the plotting module
 search for aesthetics.

 On 17 June 2013 21:00, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Mon, Jun 17, 2013 at 12:58 PM, Ondřej Čertík ondrej.cer...@gmail.com 
 wrote:
 Hi,

 Here is one of my notebooks (work in progress) for the sympy tutorial:

 http://nbviewer.ipython.org/5799312

 How can I set line colors in the plot at the prompt [8]? I didn't find
 it in the docs:

 http://docs.sympy.org/dev/modules/plotting.html

 I assume I should save it to a variable p and then do something like

 p[0].line_color = red

 Except I didn't figure out the exact syntax yet.

 Also, is it possible to create a legend?

 I'll probably just use matplotlib for the more advanced plots, but I
 want to show the best we can do so far with plotting. Or maybe there
 is some way to call matplotlib commands on the plot? That might be the
 best solution.

 Ondrej

 --
 You received this message because you are subscribed to the Google Groups 
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: Plotting: how to set line colors

2013-06-17 Thread Stefan Krastanov

Indeed, the example notebooks assume that certain setup was performed.
I guess it is a leftover from before I learned that it is an ipython
antipattern.

On 17 June 2013 22:49, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 Hi Stefan,

 This is awesome, thanks a lot! I tested your notebook, it works great.
 As far as the

 examples/beginner/plot_colors.ipynb

 goes, I had to add the following two lines into the first cell:

 from sympy import sin, var, cos, pi, sqrt
 var(x y)

 I guess it was assumed it would do this automatically somehow. But
 then things work excellent as well.

 Anyway, thanks, this will get me going.

 On Mon, Jun 17, 2013 at 1:57 PM, Stefan Krastanov
 krastanov.ste...@gmail.com wrote:
 And by the way, as you mentioned, the docs for the plotting module can
 indeed be better.

 On 17 June 2013 21:56, Stefan Krastanov krastanov.ste...@gmail.com wrote:
 I answer your question in the attached notebook. But you should really
 check the 4 or 5 `example/beginner/plot*` ipython notebooks as they
 show much nicer examples (and some nice fancy options).

 On 17 June 2013 21:13, Stefan Krastanov krastanov.ste...@gmail.com wrote:
 I will write a more complete answer soon, but in the meantime you can
 check the `examples` folder. In the docs for the plotting module
 search for aesthetics.

 On 17 June 2013 21:00, Ondřej Čertík ondrej.cer...@gmail.com wrote:
 On Mon, Jun 17, 2013 at 12:58 PM, Ondřej Čertík ondrej.cer...@gmail.com 
 wrote:
 Hi,

 Here is one of my notebooks (work in progress) for the sympy tutorial:

 http://nbviewer.ipython.org/5799312

 How can I set line colors in the plot at the prompt [8]? I didn't find
 it in the docs:

 http://docs.sympy.org/dev/modules/plotting.html

 I assume I should save it to a variable p and then do something like

 p[0].line_color = red

 Except I didn't figure out the exact syntax yet.

 Also, is it possible to create a legend?

 I'll probably just use matplotlib for the more advanced plots, but I
 want to show the best we can do so far with plotting. Or maybe there
 is some way to call matplotlib commands on the plot? That might be the
 best solution.

 Ondrej

 --
 You received this message because you are subscribed to the Google Groups 
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



 --
 You received this message because you are subscribed to the Google Groups 
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



 --
 You received this message because you are subscribed to the Google Groups 
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

2013-06-16 Thread Stefan Krastanov

Maybe I am simply missing something, but I do not understand why
anything more complicated than option (a) would be considered. Prasoon
just implements vector fields as they are meant in math (with static
orientations) and Sachin adds a parametrization to these orientations
(the parameter being time) that happens to be used in physics.

On 16 June 2013 11:06, Prasoon Shukla prasoon92.i...@gmail.com wrote:
 Okay so I just talked with Sachin on this. As Gilbert says, we should plan
 before we start work.

 Initially, my proposal had a distinction between a CoordSys class and a
 RefFrame class. We are at a similar point now. Nevertheless, the two ways we
 thought this could work was by:

 a) Subclassing the coordinate system class from the vector module in the
 appropriate physics module. Or,
 b) Having an attribute, `coord_sys`, in the class defined in the physics
 module through which all the functionality of the vector module is accessed.

 Stefan has pointed out some problems with the second approach though. So,
 should we go with (a) or is there a better way to do this?

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

2013-06-16 Thread Stefan Krastanov

Considering IRC - I can attend on Monday for instance (in the
morning for the West Coast, evening in Europe and India)

On 16 June 2013 12:16, Stefan Krastanov krastanov.ste...@gmail.com wrote:
 Maybe I am simply missing something, but I do not understand why
 anything more complicated than option (a) would be considered. Prasoon
 just implements vector fields as they are meant in math (with static
 orientations) and Sachin adds a parametrization to these orientations
 (the parameter being time) that happens to be used in physics.

 On 16 June 2013 11:06, Prasoon Shukla prasoon92.i...@gmail.com wrote:
 Okay so I just talked with Sachin on this. As Gilbert says, we should plan
 before we start work.

 Initially, my proposal had a distinction between a CoordSys class and a
 RefFrame class. We are at a similar point now. Nevertheless, the two ways we
 thought this could work was by:

 a) Subclassing the coordinate system class from the vector module in the
 appropriate physics module. Or,
 b) Having an attribute, `coord_sys`, in the class defined in the physics
 module through which all the functionality of the vector module is accessed.

 Stefan has pointed out some problems with the second approach though. So,
 should we go with (a) or is there a better way to do this?

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] solve() and it's argument type

2013-06-15 Thread Stefan Krastanov

I think you will find this useful:

http://docs.sympy.org/tutorial/tutorial/index.html

Especially the part about anti-patterns.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

2013-06-15 Thread Stefan Krastanov

I agree with Sachin: Prasoon continues with what he has described but
does not care about time variables or kinematics, only about static
orientation between reference frames. Sachin builds the time
dependence, time derivatives and kinematics on top of that.

Of course, you will probably address each others tasks from time to time.

If you are in the same city (or city district) you might plan some
coding sessions together. Also, while working, try to be on IRC so you
can talk to each other if necessary.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

2013-06-15 Thread Stefan Krastanov

Actually I do not see any issue. You still have to do all coordinate
transformations, translated and rotated references, etc.

Just do not occupy yourself with time variables, angular velocity and
linear velocity of the references.

On 15 June 2013 16:06, Prasoon Shukla prasoon92.i...@gmail.com wrote:
 Alright then. How should we proceed with this differentiation? My initial
 idea of having a CoordSys class and a RefFrame class can perhaps be used.

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

2013-06-15 Thread Stefan Krastanov

I actually am very much against separating coordsys and refframe
again. I really do not see the point. Prasoon just continues his work
on the api he suggested last time and Sachin adds time derivatives.
These two have nothing in common.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] solve() and it's argument type

2013-06-15 Thread Stefan Krastanov

This is the new tutorial that Aaron is currently building (It should
be merged soon). I guess it was a lot of work. It does a great job at
clearing up many of the antipatterns that one can see (especially on
stackoverflow answers).

On 15 June 2013 16:44, Amit Saha amitsaha...@gmail.com wrote:
 On Sat, Jun 15, 2013 at 11:56 PM, Stefan Krastanov
 krastanov.ste...@gmail.com wrote:
 I think you will find this useful:

 http://docs.sympy.org/tutorial/tutorial/index.html

 Especially the part about anti-patterns.

 Thanks Stefan, it certainly answers a lot of my queries.

 Which version of sympy is this built from? I was thinking it could be
 the version in git. However, I cloned the sympy repo and built the
 docs/ but I don't see this version of the page.
 Thanks for any pointers.

 Best,
 Amit.

 --
 http://echorand.me

 --
 You received this message because you are subscribed to the Google Groups 
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] solve() and it's argument type

2013-06-15 Thread Stefan Krastanov

Oh, sorry. I remembered reading both the antipatterns page and the
tutorial and mistakenly remembered that they were both at the same
place.

On 15 June 2013 18:50, Aaron Meurer asmeu...@gmail.com wrote:
 The new tutorial is from my branch at
 https://github.com/sympy/sympy/pull/2106.

 But Stefan is mistaken. I have not incorporated this material into the
 tutorial yet. So far, it only lives on the wiki at
 https://github.com/sympy/sympy/wiki/Idioms-and-Antipatterns#strings-as-input.

 I am not sure what the best way to incorporate this is. So far, my
 strategy has been to just introduce things the right way, and to not
 mention the wrong way.  My fear was that even mentioning the wrong
 ways would confuse people.  If anyone has any thoughts on this, I
 would love to hear them.

 I also just added a new section to the wiki on creating Symbols. If
 you can think of any other common antipatterns, please add them there.

 Aaron Meurer

 On Sat, Jun 15, 2013 at 10:19 AM, Stefan Krastanov
 krastanov.ste...@gmail.com wrote:
 This is the new tutorial that Aaron is currently building (It should
 be merged soon). I guess it was a lot of work. It does a great job at
 clearing up many of the antipatterns that one can see (especially on
 stackoverflow answers).

 On 15 June 2013 16:44, Amit Saha amitsaha...@gmail.com wrote:
 On Sat, Jun 15, 2013 at 11:56 PM, Stefan Krastanov
 krastanov.ste...@gmail.com wrote:
 I think you will find this useful:

 http://docs.sympy.org/tutorial/tutorial/index.html

 Especially the part about anti-patterns.

 Thanks Stefan, it certainly answers a lot of my queries.

 Which version of sympy is this built from? I was thinking it could be
 the version in git. However, I cloned the sympy repo and built the
 docs/ but I don't see this version of the page.
 Thanks for any pointers.

 Best,
 Amit.

 --
 http://echorand.me

 --
 You received this message because you are subscribed to the Google Groups 
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



 --
 You received this message because you are subscribed to the Google Groups 
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



 --
 You received this message because you are subscribed to the Google Groups 
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

2013-06-14 Thread Stefan Krastanov

Why the asymmetry Mul vs VectAdd?

On 14 June 2013 09:48, Prasoon Shukla prasoon92.i...@gmail.com wrote:
 Alright then. Looking at the answers that Matthew has provided, here's what
 we will do:

 Coordinate systems and reference frames will not be implemented separately.
 There will be RefFrame class from which specialized classes will inherit,
 such as RefFrameRect, RefFrameSph etc.
 RefFrame objects will be immutable.
 Vector object will be immutable as well.
 Vector class will subclass from Expr.
 We will have a VectAdd class which inherits from Add and adds required
 methods.
 Generalized vector fields will be of the form : VectAdd( Mul(scalar,
 base_vector1), Mul(scalar, base_vector2), Mul(scalar, base_vector3) ) where
 base_vectorx is an instance of the Vector class.

 Notice that we are using the VectAdd class – this class inherits from Add
 and supports methods required on vectors. Initially, these methods (eg,
 curl, div, integrate etc) were supposed to go in Vector class but since we
 have decided that Vectors will just be base_vectors - therefore the VectAdd
 class will take care of this.


 So, is everyone okay with this?

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.

 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

2013-06-14 Thread Stefan Krastanov

Any additional methods that are provided will _not work_ if they do
not have access to the RefFrame objects (in order to know how to
transform between coordinates). Your proposal does not explain how
these RefFrame objects will be accessed.

Because of this, the only advantage of subclassing Add and Mul that I
see is that it will have garbage checks (which as I mentioned can be
postponed to precondition checks in any of the functions to be
implemented). On the other hand it keeps all the disadvantages
mentioned by Matthew (Add and Mul make many assumptions, that you will
keep by subclassing them).

So, if you want new container classes for any of the reasons mentioned
by Matthew, subclassing Add and Mul does not seem the right way - you
should start from Basic as it is done in MatExpr. On the other hand,
as I mentioned in the last two paragraph, I do not think you have
given appropriate reasons for creating new container classes.

If the main reason for new container classes is garbage checks you can
just use MatExpr (its add, mul, matsymbol, etc).

This MatExpr approach has another unrelated advantage: the author of
MatExpr (Matthew) has both addressed most (probably not all) of the
issues that are problematic for diffgeom, mechanics or quantum in
terms of following sympy conventions and he is still very active
within the project so you will be able to question him for details
(sorry to volunteer you like that, Matthew ;)

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

2013-06-14 Thread Stefan Krastanov

I see. This makes sense. I dislike the creation of a new class just
for the sake of adding helper methods (it mixes functions and data in
an unaesthetic way), but this is just my preference, so I will not
raise an objection if this is what you prefer.

The big issue now is how well will this work with mechanics. I am
against making big compromises in the future architecture in order to
accommodate mechanics, but a well working interface must be created.

While RefFrames will have to be immutable to be used within Sympy
trees (or at least have consistent hash and eq as is done with the
mutable coordSystems from diffgeom) you might want to think about some
nice (mutable) tree of RefFrames structure that will accomodate
mechanics.



On 14 June 2013 12:14, Prasoon Shukla prasoon92.i...@gmail.com wrote:

 Any additional methods that are provided will _not work_ if they do
 not have access to the RefFrame objects (in order to know how to
 transform between coordinates). Your proposal does not explain how
 these RefFrame objects will be accessed.


 But they do.

 I'll try to explain the structure one more time.
 Basic-Expr-Vector

 Every Vector has an attribute, `ref_frame`, that specifies the RefFrame
 object that we are using for that vector. (Also,Vector objects are just
 basis vectors)

 Now, let us say we have a vector field like this:

 v = x * e_x + y * e_y + z * e_z

 Without the VectAdd class, v is just an Add and we would have none of the
 methods we need for operating on vectors. Instead, if we have v as a VectAdd
 object, we can extend the Add class to provide methods that are required on
 vectors.

 Initially, when we weren't following the basis vector based approach, v
 would have been a Vector object. In that case, we would have had these
 methods defined in the Vector class. But since we are following the approach
 where a Vector is just a basis vector, therefore we need something to deal
 with vector fields that are not instances of Vector. Hence the requirement
 for these two classes.

 Here's the hierarchy:
 Basic-Expr-Add-VectAdd

 Basic-Expr-Mul-VectMul

 I hope this clarifies the issue. Any more problems?

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

2013-06-14 Thread Stefan Krastanov

 Also, Gilbert and I had a small question. How do you plan to implement
 expression of Vectors in different frames? Also, the relationships between
 the frames? Could you give an API and the basic idea of how those methods
 will work?
 The main concern the mechanics group has, is the modeling of relationships
 among frames themselves, and those with vectors. Clearing up this part would
 make things much clearer.


 Again, I really do not see what is so confusing. I'll try to be clear this
 time.

Prasoon, in this case I do not think the issue is someones confusion
with what the suggestion is. `mechanics` has a very specific goal and
it is optimized for it - easily traversing a very deep tree of
relations between reference systems. While indeed what you have
suggested is sufficient to make such traversals possible, one should
be wary of whether it will work _well_ with deep trees.

One issue that you will meet very soon is that expressing
cart-spherical-cart transformation will often fail to symplify to an
identity transformation (a lot of information must be specified for
stuff like cos(acos(cos(a))) to return cos or for sqrt(x)*sqrt(1/x) to
return 1).

While the above is probably not the exact concern of Gilbert and the
others in the mechanics team I am sure they have similar worries.

And do not forget that mechanics is fast at the moment. With your
methodology it might be hard to keep up with its performance.

-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

2013-06-13 Thread Stefan Krastanov

I do not see any problem with using MatExpr instead of Expr for this
GSoC project. The only difference from what we discussed on IRC
yesterday is that instead of using Symbol as a superclass for
BaseScalarField (i.e. x y z) and BaseVector (i.e. the unit vectors
along x y z) you will use MatrixSymbol for the vectors and Symbol for
the scalars.

However, I do not know well all the details around MatExpr - if you
choose this path, please explain why (and give actual examples, not
just statements like garbage detection will be easier). I insist on
this, because currently the only problems with using Expr seems to be
garbage detection, which can simply be postponed to function calls
(much like the use of sympify).

On 13 June 2013 15:36, Sachin Joglekar srjoglekar...@gmail.com wrote:
 Personally, I like Mathew's idea of using MatrixExprs to represent vectors.
 This will not just ensure smooth functioning with the rest of sympy, but
 will also help in easing the 'garbage detection' process. Plus,
 representation (as well as stuff like pretty printing) would get easier.
 The only 'oddity', once again, would be vectors that are an addition of
 bases from two different frames. Maybe use something on the lines of MatAdd?


 On Thu, Jun 13, 2013 at 6:55 PM, Matthew Rocklin mrock...@gmail.com wrote:

 I don't remember enough of the details to give you a comprehensive answer.
 Here are a few thoughts that come to mind.

 You won't be able to change much of the Add and Mul code to handle
 Vectors.  For example you won't be able to add shape checking at
 construction time.  This forces you to follow the Garbage in, Garbage out
 philosophy (which isn't necessarily bad)

 In [18]: A = MatrixSymbol('A', n, 1)
 In [19]: B = MatrixSymbol('B', m, 1)
 In [20]: x = Symbol('x')
 In [21]: Add(x, A, B)
 Out[21]: x + A + B

 In [22]: MatAdd(x, A, B)
 TypeError: Mix of Matrix and Scalar symbols

 In [23]: MatAdd(A, B)
 ShapeError: Matrices A and B are not aligned

 Add and Mul inherit from Expr.  The Expr codebase in general assumes that
 its elements are scalars.  This pops up in many of the methods on Expr
 classes.

 In [26]: Mul(A, A, B)
 AttributeError: 'MatrixSymbol' object has no attribute 'as_base_exp'

 I really don't think I should have to implement as_base_exp for matrices
 but I do if I want to use Mul.  Actually this sort of thing usually isn't so
 bad, the defaults you get from inheriting from Expr are reasonable.  I
 remember having lots of trouble with some of the more aggressive scalar
 functions.  People kept using expand and factor on matrix expressions.  They
 sometimes got errors and filed bug reports that were very difficult to
 resolve without completely rewriting these functions to be more general.

 Using Mul and Add is fine.  It'll work for a while.  Every once in a while
 you'll come across a wart.  I'm personally biased against the Expr codebase;
 I think it's the result of a lot of glomming on of special cased code.  By
 my aesthetic MatrixExprs are a lot cleaner and more extensible.  I'm
 personally happy with the choice not to inherit from Expr.  Other groups
 have gone other ways though.  You could look at physics.quantum if you
 wanted to see how Exprs work on non-scalars.

 Also, just a thought, but if you're just using vectors you could
 presumably build off of MatrixExprs.  The container classes (MatAdd, MatMul)
 make very few assumptions about the things they hold other than that they
 are Basics and have a shape.


 On Thu, Jun 13, 2013 at 1:52 AM, Prasoon Shukla prasoon92.i...@gmail.com
 wrote:

 @Matthew Rocklin:

 Can you please tell what exactly would be the advantage of having a
 separate VectAdd class? I mean I don't see the problems with using the
 current Add and Mul classes.

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.

 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy?hl=en-US.
 For more options, visit https://groups.google.com/groups/opt_out.




 --
 You received this message because you are subscribed to a topic in the
 Google Groups sympy group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/sympy/t-Je0beTIIU/unsubscribe?hl=en-US.
 To unsubscribe from this group and all its topics, send an email to
 sympy+unsubscr...@googlegroups.com.

 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy?hl=en-US.
 For more options, visit https://groups.google.com/groups/opt_out.




 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this

Re: [sympy] Re: The Vectors and Electromagnetism GSoC projects

2013-06-12 Thread Stefan Krastanov

 I just feel that we are getting stuck with and spending too much time on 
 things that we shouldn't be taking this much time. Therefore, I request again 
 to all parties involved : Please voice your views/problems with these 
 structural changes suggested so that we can move ahead with things.

I understand that you are eager to start writing code, but you should
understand that having an actual design is a prerequisite for writing
useful code. There are a lot of SymPy conventions that you and Sachin
have not learned about yet and that are not respected in your designs.
If we proceed that way most of what you write, even if functional will
not be of great use for sympy.

Anyway, if you two want to move faster, just contact each-other as I
have suggested and propose a common API. I have made a few suggestions
in https://github.com/sympy/sympy/wiki/Vectors-EM-framework#another-proposal.
These suggestions fix the issues with tree traversal, scalar+vector
errors and immutability but do not address interoperability with
mechanics for instance. No ScalarField and no Vector classes are
necessary for what I have written. Reuse whatever you find useful.

And remember: when you start codding does depend on you - show an api
design that you both have previously agreed on and that addresses:

- immutability
- tree traversal and sympy conventions
- scalar+vector error detection
- interoperability with mechanics

On 11 June 2013 13:26, Prasoon Shukla prasoon92.i...@gmail.com wrote:
 Let us get some things clear here. Vector is going to be subclassed from
 Basic. Also, after seeing the discussions/problems above,  Vector + Vector
 will give an Add on which we can call something akin to a .doit() to result
 in a Vector. I do not see any problems with this approach.

 Next, reference frames. First thing is the distinction between RefFrame
 class and CoordSys class. Stefan has pointed out that there is no need to
 implement the classes differently. Okay, then we will have just one,
 immutable, CoordSys class. The parameters required for intialization of
 kinematic parameters will have to be provided when declaring the coordinate
 system. New CoordSys object will result from methods like rotate, orient
 etc.

 With these suggestions, I do not think that there should be any more
 structural issues. If there are any more of these issues, please mention
 them here now and please mention them as early as possible.

 These changes are justified, I hope, because this module has to play nice
 with the rest of SymPy.

 I just feel that we are getting stuck with and spending too much time on
 things that we shouldn't be taking this much time. Therefore, I request
 again to all parties involved : Please voice your views/problems with these
 structural changes suggested so that we can move ahead with things.

 --
 You received this message because you are subscribed to the Google Groups
 sympy group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to sympy+unsubscr...@googlegroups.com.
 To post to this group, send email to sympy@googlegroups.com.
 Visit this group at http://groups.google.com/group/sympy?hl=en-US.
 For more options, visit https://groups.google.com/groups/opt_out.



-- 
You received this message because you are subscribed to the Google Groups 
sympy group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

1 2 3 4 >

1 - 100 of 382 matches

Mail list logo