>> I think porting the limits is quite easy, but unfortunately ginac
>> series expansion is not sophisticated enough for more complicated
>> limits (at least last time I tried, it was I think 2 years ago), so
>> you will have to port the sympy's series expansion as well, or improve
>> ginac series expansion.
>
> Or hopefully find a way to just directly use sympy's series expansion code?
I hope so too, see below.
> Could you give an example to illustrate where you maybe found shortcomings
> in Ginac's series code? It's pretty straightforward code for the most part,
> and
> I don't know how it could go wrong.
Basically any more complicated limit.
I put a print statement in sympy to print the series that needs to work:
In [1]: limit(sqrt(x)/sqrt(x+sqrt(x+sqrt(x))),x,oo)
1/(((1/_w + _w**(-1/2))**(1/2) + 1/_w)**(1/2)*_w**(1/2)) _w
Out[1]: 1
So you can try it in sympy:
In [2]: e = sympify("1/(((1/_w + _w**(-1/2))**(1/2) + 1/_w)**(1/2)*_w**(1/2))")
In [9]: e
Out[9]:
1
──────────────────────────────────────
⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽
╱ ⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽⎽
⎽⎽⎽⎽ ╱ ╱ 1 1 1
╲╱ _w ⋅ ╱ ╱ ── + ────── + ──
╱ ╱ _w ⎽⎽⎽⎽ _w
╲╱ ╲╱ ╲╱ _w
In [5]: var("_w")
Out[5]: _w
In [6]: e.series(_w, 0, 2)
Out[6]:
⎽⎽⎽⎽
_w ╲╱ _w
1 + ── - ────── + O(_w**(3/2))
8 2
In [8]: e.series(_w, 0, 3)
Out[8]:
⎽⎽⎽⎽ 2 3/2
_w ╲╱ _w 29⋅_w _w
1 + ── - ────── - ────── + ───── + O(_w**(5/2))
8 2 128 8
Use a fixed width font or look here:
http://paste.debian.net/15584/plain/15584
alternatively:
In [10]: print e.series(_w, 0, 3)
1 + _w/8 - 1/2*_w**(1/2) - 29*_w**2/128 + 1/8*_w**(3/2) + O(_w**(5/2))
Now compare maxima:
sage: var("_w")
_w
sage: e = 1/(((1/_w + _w**(-1/2))**(1/2) + 1/_w)**(1/2)*_w**(1/2))
sage: e.taylor(_w, 0, 2)
1 - sqrt(_w)/2 + _w/8 + _w^(3/2)/8 - 29*_w^2/128
which is the same as sympy, although without the O term. And compare pynac:
sage: var("_w", ns=1)
_w
sage: e = 1/(((1/_w + _w**(-1/2))**(1/2) + 1/_w)**(1/2)*_w**(1/2))
sage: e.series(_w, 2)
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
/home/ondrej/<ipython console> in <module>()
/home/ondrej/expression.pyx in
sage.symbolic.expression.Expression.series
(sage/symbolic/expression.cpp:3948)()
RuntimeError: power::eval(): division by zero
And there are many more like this. This was one of the reasons when I
abandoned swiginac, because I really didn't want to fix this in C++, I
rather wanted to play with these things in Python first, until we
figure out what needs to work and how.
At that time I didn't know how to call maxima from python, nor how to
fix ginac easily, so I just wrote everything in Python. But now it may
be easier to just go through all the limits and fix all the series in
ginac itself. Btw I believe Bernard fixed all of these in giac, didn't
you? How difficult was it?
This situation reminds me a year ago when Pearu wrote sympycore and it
was about 100x faster, just like ginac is now 10x to 100x faster than
sympy. So we massively switched to it, and then I had to fix all these
series problems and many other things, it's a lot of work. And I am
almost 100% sure we could (=should) have sped up sympy iteratively. So
you can imagine, I myself am not really keen on absolving the same
thing again, especially if we think we can speedup sympy to the level
of ginac (or very close) in matter of months from now.
However, if Burcin or others come up and help us with it, I am all for
it. I believe ginac is in a better state than our new core was. Also
the pynac core will be optional, so I think it could work.
>
>> As to integration, that will be I think a little more difficult to
>> port, but definitely doable as well.
>
> By "port" I will take it to mean "improve sympy so it can manipulate
> Pynac symbolic expressions in addition to its own". I.e., it's basically
> a "duck typing" thing, where as long as Pynac exports the right
> interface, sympy should be able to work with it.
Yes, I believe it is worthy to do it.
>
>> As to GPL vs BSD, I am sad that some people will not contribute to a
>> BSD project and some other people will not use a GPL project. But my
>> intuition says that the license is not the main reason. If sympy was
>> as fast as ginac (as I hope it will be in not so distant future), I am
>> sure it'd be ok, even if it's BSD. BTW, I told Burcin and William that
>> if the license was the only reason, I am willing to consider switching
>> to GPL (i.e. try to persuade all 44+ contributors), if that would mean
>> more people would be developing sympy. Currently it seems to be the
>> opposite, i.e. when we switched from GPL to BSD, people and developers
>> seemed to like it, but I may well be mistaken. But as I said, I think
>> the main problem of sympy is not the license, but speed.
>
> The GPL/BSD split in the mathematical Python community is
> unfortunate and a is very real problem. At scipy'08 it was
> the source of tension for some people...
If it was only GPL/BSD, but there also some who want LGPL.
I am not saying that some of these opinions is right or wrong, but
this situation is really sad.
>> I myself like the way sympy is designed, e.g. pure python + now we are
>> working on the Cython core (+possibly pynac if it's a better
>> alternative, even though some sympy developers seems to prefer pure
>> Cython solution if we can made it as fast as pynac),
>
> Why not both? Having the option of multiple pluggable cores is probably
> the best way to do a good job designing the right interface for the core.
> The only option for sympy is both or "no pynac", since pynac is GPL'd
> (as was decided by the Ginac developers long ago). So I can imagine
> some sympy users using pynac as the core because it is maybe better
> for large problems, and other users using csympycore or something,
> because it is BSD licensed. Yet others would use the purepython core
> for portability (e.g., me on my cell phone ;-) ).
Yes, if we have enough manpower, I'd like to have pluggable cores. I
believe that's the way: not to force users to use some core, but let
users choose what they want. Clearly there are people who want their
cores, so it's nice to be able to use their work.
I myself can only promise what I am able to actually do, given my
school and everything, and that is to bring our experimental core in
sympy, thus speeding sympy to the level of our Cython core, which
currently is about 2x to 5x slower, depending on the benchmark. We
need to do that anyway for sympy.
If there is enough will and someone actually interested in doing the
work of getting sympy working on top of pynac, it has my 100% support
and I'll help with this.
>
>> because that
>> allows to use sympy easily in the google app engine, hopefully soon in
>> pypy and jython, and also as a compiled library when we get the core
>> in with exactly the same interface, i.e., whenever there is python, it
>> should work on it.
>>
>> On the other hand, if you are willing to release and maintain pynac
>> outside sage, so that it's easy to use and basically implement or port
>> all sympy to it, I'll be more than happy that someone else will do my
>> job and I can move to do some more advanced things. I really don't
>> want to have two codebases for the same thing.
>
> I definitely want to have a version of pynac outside sage. But keep
> in mind again that pynac is GPL'd, and given your mission statement
> for sympy, I think it is not an option for you to depend only on something
> GPL'd as the only option. As I see it, an important part of the
> sympy mission is to be the CAS for the "we will only use BSD'd code"
> side of the Python math software world, which is a very substantial
> important and well funded group of people.
As far as I know we don't have anything about BSD vs GPL in our
missing statement.
Mission of sympy is to be a Python library for symbolic mathematics.
That's what I want now and what I always wanted (I should say in
engineering/physics, e.g. mainly calculus, linear algebra, tensors
etc.). My vision has not changed a bit, and that is to be able to play
with symbolic things in Python and in an easy and extensible way. And
being competitive (in terms of features and speed) to other programs,
of course, that's implicit.
Also I want to stay in pure python by default and do everything else
as optional modules.
For example we need symbolic things in our finite element package
sfepy, so we use sympy, we don't want to depend on a 200MB+ package.
On the other hand, I am only interested in doing a package, that
people actually use. I am not at all interested in doing something
that is useless to other people.
And pynac comes very close to what I want. I think the best thing is
to simply get it to Sage, get people use it, see if they like it, see
if people are still interested in the sympy approach, or rather
everyone will prefer to just use pynac and extend it/improve it etc.
And then we'll just do what is the most effective way of using each
other's work.
I think everything will come out very naturally, imho one just needs
to listen what people want to use and what people want too develop and
help with developing.
Also I very much would like to merge sympy with Sage in a sense, that
people can start let's say with pure python and sympy and gradually
add more things (i.e. Cython core, or ginac, or other Sage modules)
and all the time using just one interface, so that everything is
smooth and they don't have to fix their programs or learn new things.
For example pynac uses
sin(x).seires(x, 5)
sympy uses
sin(x).series(x, 0, 5)
and sage uses
sin(x).taylor(x, 0, 5)
and this is unfortunate. I would like to use just one interface.
Ondrej
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
