Re: [sage-devel] Proposal for inclusion of GINAC/pynac-0.1 in Sage.
Ondrej Certik
> [ ] Yes, include Pynac in Sage
> [ ] No, do not (please explain)
> [ ] Hmm, I have questions (please ask).
I don't know if my vote counts, but I am of course +1.
Thanks for pioneering the use of Python in C projects, I hope people
will now try much more to reuse C/C++ code.
> (e) how does this relate to sympy?
> (I dont' know.
> Sympy does several things Ginac doesn't, such as symbolic
> integration and
> sophisticated limits. I would like to find a way to somehow
> reuse that code directly,
> especially since sympy is in sage already, and is already often better
> than using Sage's current maxima + pexpect symbolic manipulation.
> On the other hand, Burcin is I think driven mostly by his Ph.D. thesis
> research, and has told me he will only write GPL'd code, which means
> it can't go into Sympy.)
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.
As to integration, that will be I think a little more difficult to
port, but definitely doable as well.
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.
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), 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.
Ondrej
William Stein
>
>> VOTE:
>> [ ] Yes, include Pynac in Sage
>> [ ] No, do not (please explain)
>> [ ] Hmm, I have questions (please ask).
>
> I don't know if my vote counts, but I am of course +1.
Your vote counts.
> Thanks for pioneering the use of Python in C projects, I hope people
> will now try much more to reuse C/C++ code.
>
>> (e) how does this relate to sympy?
>> (I dont' know.
>> Sympy does several things Ginac doesn't, such as symbolic
>> integration and
>> sophisticated limits. I would like to find a way to somehow
>> reuse that code directly,
>> especially since sympy is in sage already, and is already often better
>> than using Sage's current maxima + pexpect symbolic manipulation.
>> On the other hand, Burcin is I think driven mostly by his Ph.D. thesis
>> research, and has told me he will only write GPL'd code, which means
>> it can't go into Sympy.)
>
> 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?
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.
> 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.
> 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...
> 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 ;-) ).
> 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.
William
Ondrej Certik
>> 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
Ondrej Certik
>> 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.
But to make this clear: Yes, if it's at least a bit possible, I'd like
to stay BSD, because clearly the BSD market is good.
But if staying BSD means that people will not help with sympy but
rather help with a GPLed package, I think that getting the job done
(=good symbolics in python) is more important than BSD vs GPL
flamewar.
We had the discussion BSD/GPL here:
http://groups.google.com/group/sympy/browse_thread/thread/e5f77a57874d2135/
a good summary is for example this email:
http://groups.google.com/group/sympy/msg/183cad529117b758
Ondrej
------------
But also I think it's good to say my own opinion on this, and that is,
that I personally think that given that I am paid from tax payers
money (i.e. grants, stipends, etc.), which are individuals or
companies (in my case mostly Czech and European and soon hopefully
US), I really think it's fair if the companies can use the work that
was produced by their money in the way they want. I.e. BSD fits nice,
GPL doesn't. LGPL is somewhere shady, but many companies don't like it
either. But I understand that those are complicated questions and and
one argument for (L)GPL is the fear that someone will take the code
and close it, improve it, sell it and make a lot of money with BSD,
while with GPL he is forced to open it and that is better over all,
because it brings the code back to the project, that otherwise would
not be available. I believe though that less restrictions are better
in the long term, i.e. if people and companies can do things that they
want and use code as they want, it is better for all of us in the end.
But I am not fundamental on this, as I said above, getting the job
done and getting people to work together is way more important for me.
If you have opposite opinion than I do, I'd love if you could oppose,
but please no flamewars.
William Stein
>
> sin(x).seires(x, 5)
Actually, more precisely pynac uses:
sin(x).series(x == 3, 5)
to get a taylor expansion about x = 3. I did this
only for consistency with GiNaC, since that is what
GiNaC does.
>
> sympy uses
>
> sin(x).series(x, 0, 5)
>
> and sage uses
>
> sin(x).taylor(x, 0, 5)
Using taylor is really dumb. It is inconsistent with
every other system and is confusion since it can
give Laurent series.
>
> and this is unfortunate. I would like to use just one interface.
Yep. That's precisely what we'll have to have in order to
have a sympy + pynac system.
William
William Stein
>
> On Mon, Aug 25, 2008 at 10:58 AM, William Stein <wst...@gmail.com> wrote:
>
>>> 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...
>
> realistic/valid/interesting solution or not, but how about using LGPL
> as a middle solution?
This is not an option because Pynac derives from Ginac and Ginac
is GPL'd: http://www.ginac.de/ So for this project I have absolutely
no choice in the matter.
> Just a suggestion to consider, though obviously ultimately the
> decision rests with the code authors.
Yep, and it turns out they already made that choice a decade ago.
> ps - I find the pynac idea extremely cool: using python itself as the
> rich native support for a C/C++ library in replacement of another
> heavyweight system (CLN in this case) is a great show of the utility
> and quality of the language. FWIW I'm +1 on it going in, though I'm
> not really a sage developer myself.
Thanks.
-- William
Ondrej Certik
>
> On Tue, 26 Aug 2008 08:29:33 +0200
> "Ondrej Certik" <ond...@certik.cz> wrote:
>
>>
>> On Tue, Aug 26, 2008 at 12:49 AM, William Stein <wst...@gmail.com> wrote:
>> >
>> >> BTW, one important warning: ginac and sympycore are missing
>> >> assumptions and sympy only has very trivial ones, like positive,
>> >> negative, integer, even, odd, etc. This is really important for any
>> >> nontrivial things in a CAS and I changes to the core may be needed. I
>> >> really want to have assumptions in sympy first before saying -- yes,
>> >> this approach to do the core is the best.
>> >>
>> >> Ondrej
>> >
>> > Why are assumptions "really important for any nontrivial things in a CAS"?
>> > In my entire life I've only ever used assumptions to get maxima to do
>> > a symbolic integration. I've never used them in any other context.
>> > Can you please educate me on why they are so important? Thanks.
>>
>> Basically all more nontrivial simplifications. Things like to simplify
>> sqrt(1-sin(x)**2) etc. Or acos(cos(x)). All of those are things that
>> are needed to be automatic, but only work sometimes, e.g. if 0 < x <
>> pi, or -pi/2 < x < pi/2 etc. This is obivously needed in integration
>> and in solvers and also just when the user wants to simplify the
>> expression. So in particular this is done inside ginac, so ginac need
>> some way to handle these. Do you have any ideas how to do it?
>
> Looking briefly at the MMA documentation, I can't find any reference to
> a general assumption context, which can be queried to get information
> on variables/expressions.
>
> It seems that you can give assumptions only for specific functions,
> such as
>
> In[]:= Simplify[ArcCos[Cos[x]],{0<x,x<Pi/2}]
> Out[]= x
>
> same goes for Refine, FullSimplify and FunctionExpand (whatever that
> is).
>
> As already mentioned in another thread, the automatic evaluation (basic
> simplification) in GiNaC is meant to be a cheap operation. MMA doesn't
> do automatic simplification of this statement either,
>
> In[]:= Assuming[0<x, Assuming[x<Pi/2 ,ArcCos[Cos[x]]]]
> Out[]= ArcCos[Cos[x]]
If mathematica really doesn't do this in the core, e.g. you need to
tell the simplifiy -- hey, use these assumptions, then I think we
should do exactly this. We actually converged to this solution too in
sympy, because I really don't want to make the core complicated.
On Tue, Aug 26, 2008 at 9:15 AM, David Philp <david...@anu.edu.au> wrote:
>
>
> On 26/08/2008, at 5:09 PM, Burcin Erocal wrote:
>> In[]:= Assuming[0<x, Assuming[x<Pi/2 ,ArcCos[Cos[x]]]]
>> Out[]= ArcCos[Cos[x]]
>
> In[]:= Simplify[ArcCos[Cos[x]], Assumptions -> 0 < x < Pi/2]
> Out[] = x
Exactly, you pass the assumptions as an object to the simplify
function. That's the point, it's very explicit and what I like.
I really need to learn mathematica and then just do the same, instead
of trying to do something and then burn myself.
On Tue, Aug 26, 2008 at 9:06 AM, Fernando Perez <fpere...@gmail.com> wrote:
>
> On Mon, Aug 25, 2008 at 10:58 AM, William Stein <wst...@gmail.com> wrote:
>
>>> 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...
>
> I don't know if for this particular project it's a
> realistic/valid/interesting solution or not, but how about using LGPL
> as a middle solution? I happen to actually really like the LGPL: I
> find that it protects my code from flat out abuse, while not imposing
> my conditions beyond my own code boundaries. But for many cases I
> find that LGPL strikes an excellent balance and fully protects the
> original code from closed modifications (though not from use as an
> unmodified library), which is what I consider most important.
>
> In fact, I'd originally licensed ipython as LGPL, and switched to BSD
> only to make it easier to share code back and forth with
> numpy/scipy/matplotlib. In this case I'm happy having switched to BSD,
> but I still like the LGPL a lot.
>
> Just a suggestion to consider, though obviously ultimately the
> decision rests with the code authors.
Thanks Fernando for mentioning LPGL. Actually, in fact Kirill, another
sympy developer who works on the core of sympy a lot, he didn't have
time to advocate it yet, but he also very much like LGPL and always
wanted sympy to be LGPL to prevent code abuse. I don't think such code
abuse is actually happening though, so I think it's more of an
irrational fear, but I am in no way trying to make it invaluable
argument -- I may well be completely wrong on this.
But did it ever happen to you Fernando that someone would plainly
abuse ipython/numpy/scipy? Clearly ipython is way more popular than
sympy, so if it doesn't happen for numpy/scipy/ipython, I don't think
we have to fear. (btw. fear of what actually?)
But as I said several times, I am not fundamental in this, if it helps
all the sympy developers to sleep well at night, let's do it. I am not
making fun of it, I mean it. It's simply not worhty if many people
feel that their code will be abused and it's not a question if, but
when. So this clearly has to be resolved in some way. My way is to
question this very fear itself, I suspect it's not happening this way.
The other option is to switch to LGPL or GPL.
Burcin, would LGPL be suitable for you to contribute to sympy, or is
LGPL not protective enough for you?
Ondrej
William Stein
>>
>>
>> On 26/08/2008, at 5:09 PM, Burcin Erocal wrote:
>>> In[]:= Assuming[0<x, Assuming[x<Pi/2 ,ArcCos[Cos[x]]]]
>>> Out[]= ArcCos[Cos[x]]
>>
>> In[]:= Simplify[ArcCos[Cos[x]], Assumptions -> 0 < x < Pi/2]
>> Out[] = x
>
> Exactly, you pass the assumptions as an object to the simplify
> function. That's the point, it's very explicit and what I like.
>
> I really need to learn mathematica and then just do the same, instead
> of trying to do something and then burn myself.
Strong +1. At a bare minimum it is best to at least *understand* what
Mathematica (and Maple and Giac/Maxima/Axiom, etc.) do, and then
make choices justifying why you think you can do better, rather than
starting from scratch. I am extremely appreciative that there are
so many expert Mathematica/Maple/Giac/Maxima/Axiom, etc. users
posting in this thread, since this is making our job of understanding
what those systems do in various situations *vastly* easier.
(In particular, notice how many mistakes some of us core sage
devs make when making assertions about what Mathematica
or Maxima or whatever does or can do. It's really awesome that users
of those systems are regularly helping us out.)
Thanks!
> On Tue, Aug 26, 2008 at 9:06 AM, Fernando Perez <fpere...@gmail.com> wrote:
> Thanks Fernando for mentioning LPGL. Actually, in fact Kirill, another
> sympy developer who works on the core of sympy a lot, he didn't have
> time to advocate it yet, but he also very much like LGPL and always
> wanted sympy to be LGPL to prevent code abuse. I don't think such code
> abuse is actually happening though, so I think it's more of an
> irrational fear, but I am in no way trying to make it invaluable
> argument -- I may well be completely wrong on this.
>
> But did it ever happen to you Fernando that someone would plainly
> abuse ipython/numpy/scipy? Clearly ipython is way more popular than
> sympy, so if it doesn't happen for numpy/scipy/ipython, I don't think
> we have to fear. (btw. fear of what actually?)
Ah, to be young and idealistic. :-)
> But as I said several times, I am not fundamental in this, if it helps
> all the sympy developers to sleep well at night, let's do it. I am not
> making fun of it, I mean it. It's simply not worhty if many people
> feel that their code will be abused and it's not a question if, but
> when. So this clearly has to be resolved in some way. My way is to
> question this very fear itself, I suspect it's not happening this way.
> The other option is to switch to LGPL or GPL.
>
> Burcin, would LGPL be suitable for you to contribute to sympy, or is
> LGPL not protective enough for you?
Since Burcin's whole proposal is to use GiNaC, I suspect that he is only going
to write something if it builds on GiNaC. As GiNaC is GPL'd
the above question might be moot, since it seems difficult
to build an LGPL'd Sympy on top of GiNaC...
-- William