missing things from Mathematica
Ondrej Certik
SymPy is quite close to replace Mathematica for most basic things.
Some features are still missing though, so I will try to implement
those, but I wanted to discuss my plan here too, in case you would
have some suggestions, comments:
1) MatrixForm, TableForm
http://reference.wolfram.com/mathematica/ref/TableForm.html
this I plan to put next to Tuple (sympy/core/containers.py). And
printers for it into printers.
2) NumPy array()
So that you can use syntax like:
xdata = array([1, 2, 3, 4, 5])
ydata = xdata ** 2
data2 = array([xdata, 1.5 * ydata])
which just works in Mathematica (it's in the core language).
If you have numpy installed, then all is fine, but sometimes numpy is
not available, for example when you only have pure Python and install
SymPy. An example is google app engine, or when you don't have root
access to your computer and so on. So I could imagine having the
array() function in sympy, and it would try to import numpy lazily
(when you use it), and if it fails, use sympy's pure Python
implementation. So that users can simply count, that when they do
from sympy import array
it will just work, always. I plan to put it into
sympy/utilities/numpy.py so far.
3) Plot()
it should be refactored, so that it only holds the information about
the plot and handles common parameters. Then there would be
"printers", to print it using pyglet, or ascii art, or matplotlib, or
return a link using google chart api, and so on.
4) Manipulate
the logic and the class will be in sympy, but to be actually usable,
it will need some frontend (e.g. browser+ javascript), or Qt GUI. The
GUI part will not be in sympy.
The above are things that I am aware of at least.
The hard part above is that SymPy should stay as a *library*, which
means that it should have all the logic, but in order to build an end
product like Mathematica, one needs to plug in more pieces, in
particular some gui (and there is tons of options here, e.g. Qt,
mobile phones, web gui, ...), and faster libraries for doing numerics
(numpy, scipy, ...), some "data package" (with tons of physical data,
like chemistry tables, astronomical data, cities, ....) and so on. So
SymPy is just a component of the whole thing, kind of like "standard
library" to make Python directly usable for mathematics.
Ondrej
Christophe BAL
>>> SymPy is quite close to replace Mathematica for most basic things.
>>> Some features are still missing though, so I will try to implement
>>> those, but I wanted to discuss my plan here too, in case you would
>>> have some suggestions, comments:
1) One module for symbolic calculations.
2) One module for numeric calculations.
3) One module for plotting. A plotting class "easy" to extend would be a good thing. For example, this will allow exporting plots for pstriks or tikz formats so as to have LaTeX outputs.
>>> the logic and the class will be in sympy, but to be actually usable,
>>> it will need some frontend (e.g. browser+ javascript), or Qt GUI. The
>>> GUI part will not be in sympy.
The user can type things in the HTML page and a simple JavaScript can be used to type things in a textarea for example, and then the text will be send to Python for "sympy manipulations".
This approachs have the advantage to reuse an HTML frontend (browser+ javascript).
Best regards.
Christophe.
Ronan Lamy
> Hi,
>
> SymPy is quite close to replace Mathematica for most basic things.
The major thing that's missing is a nice graphical front-end with a
notebook interface, LaTeX rendering, integrated plots, ...
> Some features are still missing though, so I will try to implement
> those, but I wanted to discuss my plan here too, in case you would
> have some suggestions, comments:
>
> 1) MatrixForm, TableForm
>
> http://reference.wolfram.com/mathematica/ref/TableForm.html
>
> this I plan to put next to Tuple (sympy/core/containers.py). And
> printers for it into printers.
This is only for printing so I don't see why you want to handle these
wrappers as containers.
> 2) NumPy array()
>
> So that you can use syntax like:
>
> xdata = array([1, 2, 3, 4, 5])
> ydata = xdata ** 2
> data2 = array([xdata, 1.5 * ydata])
>
> which just works in Mathematica (it's in the core language).
>
> If you have numpy installed, then all is fine, but sometimes numpy is
> not available, for example when you only have pure Python and install
> SymPy. An example is google app engine, or when you don't have root
> access to your computer and so on. So I could imagine having the
> array() function in sympy, and it would try to import numpy lazily
> (when you use it), and if it fails, use sympy's pure Python
> implementation. So that users can simply count, that when they do
>
> from sympy import array
>
> it will just work, always. I plan to put it into
> sympy/utilities/numpy.py so far.
I don't really see the point of having this in sympy. Which actual
problems does it solve?
> 3) Plot()
>
> it should be refactored, so that it only holds the information about
> the plot and handles common parameters. Then there would be
> "printers", to print it using pyglet, or ascii art, or matplotlib, or
> return a link using google chart api, and so on.
+1
> 4) Manipulate
>
> the logic and the class will be in sympy, but to be actually usable,
> it will need some frontend (e.g. browser+ javascript), or Qt GUI. The
> GUI part will not be in sympy.
As I understand it, a Manipulate object is a graphical widget that can
query the 'kernel' and update itself interactively. I don't think much
needs to be done on the sympy side.
>
> The above are things that I am aware of at least.
>
>
> The hard part above is that SymPy should stay as a *library*, which
> means that it should have all the logic, but in order to build an end
> product like Mathematica, one needs to plug in more pieces, in
> particular some gui (and there is tons of options here, e.g. Qt,
> mobile phones, web gui, ...), and faster libraries for doing numerics
> (numpy, scipy, ...), some "data package" (with tons of physical data,
> like chemistry tables, astronomical data, cities, ....) and so on. So
> SymPy is just a component of the whole thing, kind of like "standard
> library" to make Python directly usable for mathematics.
I agree. But I think that the best way of enabling the creation of good
front-ends is to actually start building one, instead of trying to
anticipate potential problems.
Chris Smith
> Le mercredi 16 février 2011 à 22:24 -0800, Ondrej Certik a écrit :
>> 2) NumPy array()
>>
>> So that you can use syntax like:
>>
>> xdata = array([1, 2, 3, 4, 5])
>> ydata = xdata ** 2
>> data2 = array([xdata, 1.5 * ydata])
>>
>> which just works in Mathematica (it's in the core language).
>>
>
> problems does it solve?
It's just sugar, and I think that's what is meant by "it just works". I'm guessing the above means the following in python:
ydata = [xi**2 for xi in xdata]
data2 = zip(xdata, [yi*1.5 for yi in ydata])
/c
Ondrej Certik
Well, this is what it means:
In [1]: from numpy import array
In [2]: xdata = array([1, 2, 3, 4, 5])
In [3]: ydata = xdata ** 2
In [4]: data2 = array([xdata, 1.5 * ydata])
In [5]: data2
Out[5]:
array([[ 1. , 2. , 3. , 4. , 5. ],
[ 1.5, 6. , 13.5, 24. , 37.5]])
Btw, we already have a similar concept in SymPy: Matrix. But it
represents a math matrix and that's it. I think we need an array
concept as well.
Ronan --- the actual problem that it solves is that in Mathematica,
people do use the syntactic sugar for arrays. So I would like to use
the same thing in SymPy. Which I can, using numpy, but as I said,
sometimes numpy is not available, and I want this to always work.
Ondrej
Ondrej Certik
> Le mercredi 16 février 2011 à 22:24 -0800, Ondrej Certik a écrit :
>> Hi,
>>
>> SymPy is quite close to replace Mathematica for most basic things.
>
> The major thing that's missing is a nice graphical front-end with a
> notebook interface, LaTeX rendering, integrated plots, ...
>
>> Some features are still missing though, so I will try to implement
>> those, but I wanted to discuss my plan here too, in case you would
>> have some suggestions, comments:
>>
>> 1) MatrixForm, TableForm
>>
>> http://reference.wolfram.com/mathematica/ref/TableForm.html
>>
>> this I plan to put next to Tuple (sympy/core/containers.py). And
>> printers for it into printers.
>
> This is only for printing so I don't see why you want to handle these
> wrappers as containers.
That's what I thought first too. The MatrixForm should print something
in ascii, something in latex and something else in html. So I thought,
that MatrixForm would be a sympy class, and then the StrPrinter would
know how to print it to ascii, PrettyPrinter would know how to use
ascii art, LatexPrinter would know how to print MatrixForm class in
latex, and finally HTMPrinter (if we have any) would print it in html.
So this I know how to implement.
How would you implement just a printer? If you can show me how to do
it, maybe it's a better way.
>
>> 2) NumPy array()
>>
>> So that you can use syntax like:
>>
>> xdata = array([1, 2, 3, 4, 5])
>> ydata = xdata ** 2
>> data2 = array([xdata, 1.5 * ydata])
>>
>> which just works in Mathematica (it's in the core language).
>>
>> If you have numpy installed, then all is fine, but sometimes numpy is
>> not available, for example when you only have pure Python and install
>> SymPy. An example is google app engine, or when you don't have root
>> access to your computer and so on. So I could imagine having the
>> array() function in sympy, and it would try to import numpy lazily
>> (when you use it), and if it fails, use sympy's pure Python
>> implementation. So that users can simply count, that when they do
>>
>> from sympy import array
>>
>> it will just work, always. I plan to put it into
>> sympy/utilities/numpy.py so far.
>
> I don't really see the point of having this in sympy. Which actual
> problems does it solve?
I replied to that in the other email.
>
>> 3) Plot()
>>
>> it should be refactored, so that it only holds the information about
>> the plot and handles common parameters. Then there would be
>> "printers", to print it using pyglet, or ascii art, or matplotlib, or
>> return a link using google chart api, and so on.
>
> +1
>
>> 4) Manipulate
>>
>> the logic and the class will be in sympy, but to be actually usable,
>> it will need some frontend (e.g. browser+ javascript), or Qt GUI. The
>> GUI part will not be in sympy.
>
> As I understand it, a Manipulate object is a graphical widget that can
> query the 'kernel' and update itself interactively. I don't think much
> needs to be done on the sympy side.
The syntax should be in sympy side, so that each frontend doesn't
implement a different syntax and behavior.
>
>>
>> The above are things that I am aware of at least.
>>
>>
>> The hard part above is that SymPy should stay as a *library*, which
>> means that it should have all the logic, but in order to build an end
>> product like Mathematica, one needs to plug in more pieces, in
>> particular some gui (and there is tons of options here, e.g. Qt,
>> mobile phones, web gui, ...), and faster libraries for doing numerics
>> (numpy, scipy, ...), some "data package" (with tons of physical data,
>> like chemistry tables, astronomical data, cities, ....) and so on. So
>> SymPy is just a component of the whole thing, kind of like "standard
>> library" to make Python directly usable for mathematics.
>
> I agree. But I think that the best way of enabling the creation of good
> front-ends is to actually start building one, instead of trying to
> anticipate potential problems.
Yes, I am building one. Another frontend is Sage, yet another is
Femhub, and another is Qsnake (http://qsnake.com/). And I want SymPy
to have all the logic, so that once you learn SymPy, you can
immediately use it everywhere. Each frontend has it's pro and cons,
and my anticipation is that there will not be a single frontend to
satisfy everybody.
Ondrej
Ondrej Certik
Yes, exactly. That is the way to do it, to only write a nice
javascript frontend once, and use it both for the online application,
as well as a desktop application.
Ondrej
Ondrej Certik
Here is a preliminary implementation, so that you can comment on it:
https://github.com/certik/sympy/commit/00a77c35dd0d603826aa29fe1c9528e34d08142e
as you can see, it's very simple. So far it's only 1D arrays, I still
have to implement multidimensional arrays, and conversions from
Matrix.
Ondrej
Aaron Meurer
> Ondrej
I strongly agree with this point.
I also agree with Ronan that the biggest disparity between SymPy and
Mathematica is the lack of a nice GUI, especially for the adoption of
new users who may not be so comfortable with the command line.
Also, plotting basically doesn't work at all for me due to various
bugs. I think it should be completely restructured to be independent
of pyglet.
Aaron Meurer
Ondrej Certik
>> The hard part above is that SymPy should stay as a *library*,
> <snip>
>> Ondrej
>
> I strongly agree with this point.
>
> I also agree with Ronan that the biggest disparity between SymPy and
> Mathematica is the lack of a nice GUI, especially for the adoption of
> new users who may not be so comfortable with the command line.
Definitely. (This is my main goal to create such a web gui.) However,
all guis should be a separate projects. I would encourage people to
try to create such an all in one "mathematica like" package. I can
imagine, that the best GUI projects could be linked from the main page
of sympy. (e.g. we link Sage and symbide already).
>
> Also, plotting basically doesn't work at all for me due to various
> bugs. I think it should be completely restructured to be independent
> of pyglet.
Yep, that's for sure (and remove pyglet from sympy). It's on my todo list.
So here is a preliminary TableForm implementation:
https://github.com/certik/sympy/commit/5faba9ebd9a57d929eb28a560b752a12ebced300
and example usage:
In [1]: from sympy import TableForm, array
In [2]: a = array([4, 2, 3])
In [3]: TableForm(zip(a, a**3))
Out[3]:
4 64
2 8
3 27
In [4]: TableForm([["a", "b"], ["c", "d"], ["e", "f"]], headings="automatic")
Out[4]:
| 1 2
-------
1 | a b
2 | c d
3 | e f
In [5]: TableForm([["a", "b"], ["c", "d"], ["e", "f"]],
...: headings=("automatic", None))
Out[5]:
1 | a b
2 | c d
3 | e f
In [6]: TableForm([["a", "b"], ["c", "d"], ["e", "f"]],
...: headings=(None, "automatic"))
Out[6]:
1 2
---
a b
c d
e f
In [7]: TableForm([[5, 7], [4, 2], [10, 3]],
...: headings=[["Group A", "Group B", "Group C"], ["y1", "y2"]])
Out[7]:
| y1 y2
---------------
Group A | 5 7
Group B | 4 2
Group C | 10 3
In [8]: TableForm([[5, 7], [4, 2], [10, 3]],
...: headings=[["Group A", "Group B", "Group C"], ["y1", "y2"]],
...: alignment="right")
Out[8]:
| y1 y2
---------------
Group A | 5 7
Group B | 4 2
Group C | 10 3
Ondrej
Chris Smith
> In [8]: TableForm([[5, 7], [4, 2], [10, 3]],
> ...: headings=[["Group A", "Group B", "Group C"], ["y1",
> "y2"]],
> ...: alignment="right")
> Out[8]:
> | y1 y2
> ---------------
> Group A | 5 7
> Group B | 4 2
> Group C | 10 3
>
>
I like it! One thing that I do with my ASCII tables is to use what I call a "flag" label. A wrap option might be nice, too:
default mode:
h[1] >>> TableForm([["a", "b"], ["c", "d"], ["e", "f"]],headings=(None,
['this is long', 'y']))
this is long y
--------------
a b
c d
e f
wrap mode
this is
long y
----------
a b
c d
e f
flag mode
this is long
| y
------------
a b
c d
e f
wrap/flag mode
this is
long
| y
---------
a b
c d
e f
For more than two columns, flags get progressively lower
like
| this
| | here
---------
x y z
/c
Ondrej Certik
Nice! So I will try to finish this pull request soon and send it in.
Once it gets in, you can then implement this.
This reminds me, that for the Plot() command, one of the output
(besides the obvious ones, like html, png, google chart api link)
should be ascii art, so that one can at least see something in the
console, immediately, there is one example at the bottom of this page:
http://www.cs.hmc.edu/~vrable/gnuplot/using-gnuplot.html
it exactly fits into my terminal.
Ondrej
Aaron S. Meurer
This is what the command line Maple does. It even has ASCII 3-D plots, which are pretty cool (though admittedly of limit usage :)
Aaron Meurer
Christophe BAL
do you have an example of an ASCII 3-D plot ?
Christophe
2011/2/18, Aaron S. Meurer <asme...@gmail.com>:
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sympy?hl=en.
>
>
Aaron S. Meurer
|\^/| Maple 12 (APPLE UNIVERSAL OSX)
._|\| |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple Inc. 2008
\ MAPLE / All rights reserved. Maple is a trademark of
<____ ____> Waterloo Maple Inc.
| Type ? for help.
> with(plots);
[animate, animate3d, animatecurve, arrow, changecoords, complexplot,
complexplot3d, conformal, conformal3d, contourplot, contourplot3d,
coordplot, coordplot3d, densityplot, display, dualaxisplot, fieldplot,
fieldplot3d, gradplot, gradplot3d, graphplot3d, implicitplot,
implicitplot3d, inequal, interactive, interactiveparams, intersectplot,
listcontplot, listcontplot3d, listdensityplot, listplot, listplot3d,
loglogplot, logplot, matrixplot, multiple, odeplot, pareto, plotcompare,
pointplot, pointplot3d, polarplot, polygonplot, polygonplot3d,
polyhedra_supported, polyhedraplot, rootlocus, semilogplot, setcolors,
setoptions, setoptions3d, spacecurve, sparsematrixplot, surfdata, textplot,
textplot3d, tubeplot]
> plot3d(sin(x*y), x=-4..4, y=-4..4);
/- \\
--- \//\-/\\\ --\
|-- / |\ / \/\//\/ \ /| \ ---
- | |----//|-/--\--|--/--\-|-\----| | -
\ ----\ | || |-/////-- /---\ --\\\\\-| || | /---- /
/\ ||/|-- || | || |-/ ///-/\\-\\\ \-| || | || --|\|| /\
//\ ||||/\| || | || / /-/ // \\ \-\ \||| | || |/\|||| /\\
|/\\ |/||\-\\||-|| | ////-////\\\-\\\\ ||||-||////|||| //\|
| || || |//\ |\\\\||-|-|/-\\-- \\ // --//-\|-|-||////| /\\| || || |
| || ||| |||-\||\|\|\---| \/\/\ /\ /\ /\/\/ |---/|/|/||/-||| ||| || |
| | |||/||||||||| \\\| ||\/|//\/\ ///\\|\/-| |/// |||||||||\||| | |
| | ||/|||| |||||\/| |/|| / \/\ /\/ \ ||\| |\/||||| ||\|\|| | |
| | || ||| ||||||| | |/ |||| \--/ -/ |||| \| | ||-|||| ||| || | |
|| | \|| || || ||| |\ || ||| | | ||| || /| ||| || || ||/ | ||
| |\| |-|||||| || | | ||||| ||||| | | || ||||| || |/|
|/| \| |||| || |\| || ||||| || |/| || ||||||/ |\|
\||-| |/||||\| | ||||| | |/ |||\| |-||/
| ||-|//\|/| /\|/\ |\|/\\|-|| |
| |/\//\//\\/\| |
| / / \ |
> quit
memory used=3.2MB, alloc=2.6MB, time=0.05
You can't really drag it around like you could with a real 3D plot (there might be ways to change the orientation through arguments to the function; I haven't really played around with it that much), so it's of limit use like I said. But still, it's very cool.
Aaron Meurer
Ondrej Certik
Wow, what a mess. :) I don't see any sin(x*y) in there (even with
monospace fonts).
Ondrej
Aaron S. Meurer
Well, I made that one 80 characters wide so it would fit in this email. It looks better if your terminal is fullscreen. See https://gist.github.com/834538. That also shows an image of what it's supposed to look like (you can clone gists as git repos, and add images or anything to them, and then they will just show up on the page!)
Aaron Meurer
Ondrej Certik
Nice! Gists are cool.
Ondrej
Alexander Eberspächer
On Thursday, February 17, 2011 7:24:35 AM UTC+1, Ondrej Certik wrote:
SymPy is quite close to replace Mathematica for most basic things.
Some features are still missing though, so I will try to implement
those, but I wanted to discuss my plan here too, in case you would
have some suggestions, comments:
Alex
[1] http://en.wikipedia.org/wiki/Pad%C3%A9_approximant
Ondrej Certik
<alex.ebe...@gmail.com> wrote:
> Hello,
>
> On Thursday, February 17, 2011 7:24:35 AM UTC+1, Ondrej Certik wrote:
>>
>> SymPy is quite close to replace Mathematica for most basic things.
>> Some features are still missing though, so I will try to implement
>> those, but I wanted to discuss my plan here too, in case you would
>> have some suggestions, comments:
>
> I have a small suggestion to share: Pade approximants [1] are quite useful.
> Maybe a candidate for inclusion in SymPy?
Indeed, that would be a great addition. Do you know the algorithm for that?
Ondrej
Aaron S. Meurer
Aaron Meurer
Alexander Eberspächer
On Friday, February 25, 2011 4:11:41 AM UTC+1, asmeurer wrote:
The Wikipedia page mentions some epsilon algorithm. There is also some algorithm mentioned at http://mathworld.wolfram.com/PadeApproximant.html (I don't know if it is the same thing).
Me neither. However, the algorithm described at Wolfram looks implementable. SciPy has some related functionality (scipy.misc.pade). However, I haven't found a method the specify the degree of both polynomials with the SciPy routine.
Cheers
Alex
Vinzent Steinberg
wrote:
>
> On Friday, February 25, 2011 4:11:41 AM UTC+1, asmeurer wrote:
>
> > The Wikipedia page mentions some epsilon algorithm. There is also some
> Me neither. However, the algorithm described at Wolfram looks implementable.
> SciPy has some related functionality (scipy.misc.pade). However, I haven't
> found a method the specify the degree of both polynomials with the SciPy
> routine.
Vinzent
[1] http://mpmath.googlecode.com/svn/trunk/doc/build/calculus/approximation.html?highlight=pade#mpmath.pade
Brian Granger
Great thoughts, comments inline...
> 1) MatrixForm, TableForm
>
> http://reference.wolfram.com/mathematica/ref/TableForm.html
>
> this I plan to put next to Tuple (sympy/core/containers.py). And
> printers for it into printers.
Sounds great.
> 2) NumPy array()
>
> So that you can use syntax like:
>
> xdata = array([1, 2, 3, 4, 5])
> ydata = xdata ** 2
> data2 = array([xdata, 1.5 * ydata])
>
> which just works in Mathematica (it's in the core language).
>
> If you have numpy installed, then all is fine, but sometimes numpy is
> not available, for example when you only have pure Python and install
> SymPy. An example is google app engine, or when you don't have root
> access to your computer and so on. So I could imagine having the
> array() function in sympy, and it would try to import numpy lazily
> (when you use it), and if it fails, use sympy's pure Python
> implementation. So that users can simply count, that when they do
>
> from sympy import array
>
> it will just work, always. I plan to put it into
> sympy/utilities/numpy.py so far.
I think this is a good idea, but I think we should handle this like
numpy does and have Matrix subclass array.
> 3) Plot()
>
> it should be refactored, so that it only holds the information about
> the plot and handles common parameters. Then there would be
> "printers", to print it using pyglet, or ascii art, or matplotlib, or
> return a link using google chart api, and so on.
We definitely need to abstract the plotting libraries out of the core
plotting. At some level, the core printing logic in sympy involves
things like:
* Deciding on the limits and points to plot at.
* Evaluating the function at the points.
From there, having renderers (seems more like rendering rather than
"printing" - in IPython we are using the notion of "display" to
distinguish rich display of data from "printing" which has a very low
level connotation) take the data and render it appropriately is a
great design.
> 4) Manipulate
>
> the logic and the class will be in sympy, but to be actually usable,
> it will need some frontend (e.g. browser+ javascript), or Qt GUI. The
> GUI part will not be in sympy.
I don't think that sympy is the place for this. Manipulate logic much
more belongs in places like IPython, traits, etc. At some level
Manipulate *is* equivalent to traits - we just want an HTML5/JS
version of it. We are starting to move forward on this and I think I
see how to support this in a very general manner. But this stuff is
of interest far beyond just sympy.
Part of this is how I think about Python and Sympy. For me:
Sympy != Mathematica
But
IPython+Sympy+Matplotlib+Traits+Numpy+Scipy == Something even better
than Mathematica+Matlab+...
>
> The above are things that I am aware of at least.
I think the most important things are related to patterns, rules,
replace, and sets/elements. There is also logic like Hold and
distinguishing between Mutable (which we don't have) and Immutable
types.
>
> The hard part above is that SymPy should stay as a *library*, which
> means that it should have all the logic, but in order to build an end
> product like Mathematica, one needs to plug in more pieces, in
> particular some gui (and there is tons of options here, e.g. Qt,
> mobile phones, web gui, ...), and faster libraries for doing numerics
> (numpy, scipy, ...), some "data package" (with tons of physical data,
> like chemistry tables, astronomical data, cities, ....) and so on. So
> SymPy is just a component of the whole thing, kind of like "standard
> library" to make Python directly usable for mathematics.
As you know I *completely* share your vision here. I just think the
GUI/numerics/plotting/etc should be kept in
numpy/scipy/matplotlib/traits/...
I *love* the loosely coupled/library approach of sympy and how it
plays with the other tools. But the balance is quite subtle. For
example, right now, having the quantum stuff in sympy makes a good
amount of sense. BUT, given the magnitude of some of the things we
are thinking about doing with it, I am not sure it really does make
sense in the long run. But, having the quantum stuff as part of the
sympy *community* does make sense. This is where I *really* wish we
had solid namespace packages. What about a simple version of it using
pkgutil:
http://docs.python.org/library/pkgutil.html
That would allow us to have different sympy packages with their own
release schedules, installation scripts, dependencies, etc. Not sure
if this makes sense...
Cheers,
Brian
> Ondrej
>
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>
>
--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgra...@calpoly.edu
elli...@gmail.com
Aaron S. Meurer
> than Mathematica+Matlab+…
So maybe it makes sense to put Manipulate in a separate project. Remember that we want SymPy to remain dependency free, but other projects can depend on SymPy (and other things).
> if this makes sense…
>
It might make sense to fork the quantum module, or maybe just the entire physics module, if it becomes too large. Right now it is not, so there is no problem with it. I don't see any problem with keeping the fork under the sympy community. If it happens, we could just give it its own project in GitHub in the SymPy organization (i.e., just a separate repository here: https://github.com/sympy/).
Aaron Meurer
Brian Granger
I think forking the entire physics package would make the most sense
as it is very likely that different submodule of sympy.physics would
depend on each other. What do you think the best to name and manage
forked subprojects would be? It would be great to have sympy.physics
still be the same name, but just a separate project.
Cheers,
Brian
Ondrej Certik
Well, I agree with Aaron, that if it is small, and manageable, it
should be part of SymPy. Only when it becomes large, and there are
people around it being able to manage it and release it separately, it
makes sense to split it. At least my intuition tells me, that it is
too early to split it.
However, allowing people to create packages and host it under the
sympy github organization is a great idea, that is for sure. To have a
well defined one module for one thing, e.g. let's say the quantum
stuff. E.g. not Ondrej's quantum, Brian's quantum, but SymPy's
quantum, part of the SymPy community. For now, I would keep it as part
of the sympy repository, it makes things easier, but later on, yes, we
can definitely split it.
Overall, I think we all agree, that SymPy should stay as the common
denominator for all these things, and play very well with other
libraries, so that people can take it and build upon it. The line
(what should and should not be part of SymPy) is obviously subtle, and
we just have to use common sense.
Ondrej
Brian Granger
> Well, I agree with Aaron, that if it is small, and manageable, it
> should be part of SymPy. Only when it becomes large, and there are
> people around it being able to manage it and release it separately, it
> makes sense to split it. At least my intuition tells me, that it is
> too early to split it.
I fully agree.
> However, allowing people to create packages and host it under the
> sympy github organization is a great idea, that is for sure. To have a
> well defined one module for one thing, e.g. let's say the quantum
> stuff. E.g. not Ondrej's quantum, Brian's quantum, but SymPy's
> quantum, part of the SymPy community. For now, I would keep it as part
> of the sympy repository, it makes things easier, but later on, yes, we
> can definitely split it.
This sounds like a great plan. I will play around with pkgutils to
see if we can do this without using setuptools.
> Overall, I think we all agree, that SymPy should stay as the common
> denominator for all these things, and play very well with other
> libraries, so that people can take it and build upon it. The line
> (what should and should not be part of SymPy) is obviously subtle, and
> we just have to use common sense.
Well put!
Brian
> Ondrej
Robert Kern
> Ondrej,
>> However, allowing people to create packages and host it under the
>> sympy github organization is a great idea, that is for sure. To have a
>> well defined one module for one thing, e.g. let's say the quantum
>> stuff. E.g. not Ondrej's quantum, Brian's quantum, but SymPy's
>> quantum, part of the SymPy community. For now, I would keep it as part
>> of the sympy repository, it makes things easier, but later on, yes, we
>> can definitely split it.
>
> This sounds like a great plan. I will play around with pkgutils to
> see if we can do this without using setuptools.
I'm not sure he is suggesting that they be part of a sympy namespace
package, just that their github repositories can be hosted under the
sympy github organization. After pushing for scikits, I think umbrella
namespace packages (distinct from organization-owned namespace
packages like enthought) are more trouble than they're worth, whether
implemented with setuptools or pkgutils.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
-- Umberto Eco
Ondrej Certik
> On Tue, Mar 8, 2011 at 13:50, Brian Granger <elli...@gmail.com> wrote:
>> Ondrej,
>
>>> However, allowing people to create packages and host it under the
>>> sympy github organization is a great idea, that is for sure. To have a
>>> well defined one module for one thing, e.g. let's say the quantum
>>> stuff. E.g. not Ondrej's quantum, Brian's quantum, but SymPy's
>>> quantum, part of the SymPy community. For now, I would keep it as part
>>> of the sympy repository, it makes things easier, but later on, yes, we
>>> can definitely split it.
>>
>> This sounds like a great plan. I will play around with pkgutils to
>> see if we can do this without using setuptools.
>
> I'm not sure he is suggesting that they be part of a sympy namespace
> package, just that their github repositories can be hosted under the
I was not expressing an opinion whether or not to have modules as part
of the sympy namespace.
> sympy github organization. After pushing for scikits, I think umbrella
> namespace packages (distinct from organization-owned namespace
> packages like enthought) are more trouble than they're worth, whether
> implemented with setuptools or pkgutils.
Given that, I would simply have modules outside of the sympy
namespace, and then there should be no problem and no need for
pkgutils/setuptools.
Ondrej
Brian Granger
>>> sympy github organization is a great idea, that is for sure. To have a
>>> well defined one module for one thing, e.g. let's say the quantum
>>> stuff. E.g. not Ondrej's quantum, Brian's quantum, but SymPy's
>>> quantum, part of the SymPy community. For now, I would keep it as part
>>> of the sympy repository, it makes things easier, but later on, yes, we
>>> can definitely split it.
>>
>> This sounds like a great plan. I will play around with pkgutils to
>> see if we can do this without using setuptools.
>
> I'm not sure he is suggesting that they be part of a sympy namespace
> package, just that their github repositories can be hosted under the
> sympy github organization. After pushing for scikits, I think umbrella
> namespace packages (distinct from organization-owned namespace
> packages like enthought) are more trouble than they're worth, whether
> implemented with setuptools or pkgutils.
You (and everyone at Enthought) definitely has more experience with
these things than we do. We have long wanted to use namespace
packages for IPython, but we are unwilling to rely on setuptools. The
main advantage of using namespace packages is that users will see the
relationship between the different packages. Using names that are
completely unrelated could be a bit confusing for users. But, we
could also use "fake" namespace packages such as "sympyphysics"
instead of setuptools or pkgutils.
Cheers,
Brian
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
> -- Umberto Eco
>
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>
>
--
Tim Lahey
On 03-08-2011, at 4:07 PM, Brian Granger wrote:
>
> You (and everyone at Enthought) definitely has more experience with
> these things than we do. We have long wanted to use namespace
> packages for IPython, but we are unwilling to rely on setuptools. The
> main advantage of using namespace packages is that users will see the
> relationship between the different packages. Using names that are
> completely unrelated could be a bit confusing for users. But, we
> could also use "fake" namespace packages such as "sympyphysics"
> instead of setuptools or pkgutils.
>
My request is that any tensor improvements get added to the tensor module, rather than the physics one. What specifically is in the physics module? Just Quantum mechanics and possibly General Relativity?
Tensors are useful beyond just those areas. We use tensors in continuum mechanics so I'd like a fully functional tensor package without needing to include GR and QM.
Thanks,
Tim.
---
Tim Lahey
PhD Candidate, Systems Design Engineering
University of Waterloo
http://about.me/tjlahey
Brian Granger
>> You (and everyone at Enthought) definitely has more experience with
>> these things than we do. We have long wanted to use namespace
>> packages for IPython, but we are unwilling to rely on setuptools. The
>> main advantage of using namespace packages is that users will see the
>> relationship between the different packages. Using names that are
>> completely unrelated could be a bit confusing for users. But, we
>> could also use "fake" namespace packages such as "sympyphysics"
>> instead of setuptools or pkgutils.
>>
>
> My request is that any tensor improvements get added to the tensor module, rather than the physics one. What specifically is in the physics module? Just Quantum mechanics and possibly General Relativity?
Absolutely. This is true for anything in the physics module. There
are even some things in quantum that we plan on migrating to the core
(Commutator, AntiCommutator and possible others) and tensors are of
broad interest.
> Tensors are useful beyond just those areas. We use tensors in continuum mechanics so I'd like a fully functional tensor package without needing to include GR and QM.
+1
Cheers,
Brian
> Thanks,
>
> Tim.
>
> ---
> Tim Lahey
> PhD Candidate, Systems Design Engineering
> University of Waterloo
> http://about.me/tjlahey
>
smichr
eliminating variables from expressions: Mathematica's Eliminate.
Sometimes this is couched in terms of "matching coefficients" (which
sympy somewhat handles for a 2 equation case).
>>> solve([x**2+3*x+4, (x+a)**2+b], [a,b]) # no solution
>>> solve_undetermined_coeffs(Eq(x**2+3*x+4, (x+a)**2+b),[a,b],x)
[(3/2, 7/4)]
But it would be nice to have this for more than one equation and also
have it be more flexible so it would work if there were more than one
variable to be eliminated (e.g. x and y).
Aaron S. Meurer
Aaron Meurer
Chris Smith
>> I don't know what Mathematica's Eliminate does, but it seems to me
>> that the solve() line below should just work, without the user
>> having to consider what kind of solving procedure is necessary to
>> solve it.
>>
It's more subtle than that: if I say that `a + 3*b = 0` and `a + c*b + d = 0` and I want to match coefficients keeping only c and d then I infer that `c, d = 3, 0`. But if I were not matching coefficients then I could only infer that `d = b*(3-c)` and although the solution found before satisfies this, there are also other solutions like `c, d = 1, 4` when `b = 2`.
smichr
way so you could say `rewrite(Eq(y, x**2+4*x+10), Eq((x-h)**2 - 4*p*(y-
k), 0), match=[x, y]) -> {p: 1/4, h: -2, k: 6}`.
'Eliminate' is not so descriptive to me...the real-world phrase I
would say is "rewrite THIS as THAT matching THESE constants". And that
is your point, I think: solve should be able to handle that. What was
not subtle in the first example and in this one is that the variables
to be solved for are all in one equation and everything else in the
other equation appears in the 2nd equation.
Ondrej Certik
I have just send a pull request for TableForm and Array here:
https://github.com/sympy/sympy/pull/268
Ondrej