[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
+1 from me to include Pynac/GiNaC in Sage, Martin Albrecht asked about the Windows porting issue: I looked at the GiNaC code and it is very clean C++. The maintainer is willing to merge MSVC related patches where needed, i.e. export statements for the symbols we need. I am not aware of any other issues that need fixing. The current reason that there is no MSVC target to build GiNaC is the lack of an non-gcc port of CLN which does not apply any more since William removed the dependency on CLN. So I will fix the problem with MSVC during the Windows port. There are now also CLN patches to build with MSVC, but I have not taken a closer look at those. Considering the alternatives (GIAC, code written from scratch) this is by far the best solution IMHO. Cheers, Michael --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Tue, Aug 26, 2008 at 12:49 AM, William Stein [EMAIL PROTECTED] 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? 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 11:29 PM, Ondrej Certik [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 12:49 AM, William Stein [EMAIL PROTECTED] 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? From reading the GiNaC docs I have the impression the *only* assumption it supports is the assumption x is a positive real number. I think there are no other assumptions in GiNaC, though I could be wrong. I think GiNaC makes it a point not to simplify stuff automatically by making assumptions, instead providing good pattern matching, substitution, expression traversal and other tools. In fact somewhere on their webpage they have the moto in bold simplification is evil. Don't read the above as making any implications about what I think Sage should do. We can of course tack on something more sophisticated, and also decide to make our simplifications more sophisticated too, if we so desire... -- William --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Tue, Aug 26, 2008 at 8:43 AM, William Stein [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 11:29 PM, Ondrej Certik [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 12:49 AM, William Stein [EMAIL PROTECTED] 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? From reading the GiNaC docs I have the impression the *only* assumption it supports is the assumption x is a positive real number. I think there are no other assumptions in GiNaC, though I could be wrong. I think GiNaC makes it a point not to simplify stuff automatically by making assumptions, instead providing good pattern matching, substitution, expression traversal and other tools. In fact somewhere on their webpage they have the moto in bold simplification is evil. Yep I know all ginac documentation and I fully agree with simplification is evil, that's why I wrote in our own simplify function's docstring: Naively simplifies the given expression. Simplification is not a well defined term and the exact strategies this function tries can change in the future versions of SymPy. If your algorithm relies on simplification (whatever it is), try to determine what you need exactly - is it powsimp(), or radsimp(), or together(), or something else? And use this particular function directly, because those are well defined and thus your algorithm will be robust. Don't read the above as making any implications about what I think Sage should do. We can of course tack on something more sophisticated, and also decide to make our simplifications more sophisticated too, if we so desire... I don't know either what the best way forward is, until we actually have something that is general and robust and maintainable. 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 10:58 AM, William Stein [EMAIL PROTECTED] 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. Cheers, f 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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Tue, 26 Aug 2008 08:29:33 +0200
Ondrej Certik [EMAIL PROTECTED] wrote:
On Tue, Aug 26, 2008 at 12:49 AM, William Stein [EMAIL PROTECTED] 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]],{0x,xPi/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[0x, Assuming[xPi/2 ,ArcCos[Cos[x
Out[]= ArcCos[Cos[x]]
Cheers,
Burcin
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On 26/08/2008, at 5:09 PM, Burcin Erocal wrote: In[]:= Assuming[0x, Assuming[xPi/2 ,ArcCos[Cos[x Out[]= ArcCos[Cos[x]] In[]:= Simplify[ArcCos[Cos[x]], Assumptions - 0 x Pi/2] Out[] = x == David J Philp Postdoctoral Fellow National Centre for Epidemiology and Population Health Building 62, cnr Mills Rd Eggleston Rd The Australian National University Canberra ACT 0200 Australia T: +61 2 6125 8260 F: +61 2 6125 0740 M: 0423 535 397 W: http://nceph.anu.edu.au/ CRICOS Provider #00120C --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Tue, Aug 26, 2008 at 12:09 AM, William Stein [EMAIL PROTECTED] wrote: 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? 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. Ah, I see. Thanks for the clarification. BTW, numpy/scipy/mpl/ipython pretty much have to stay away from GPL code because it would force them to relicense completely (something impossible to do in practice even if someone wanted to, given the long history and large developer pool). But there's a fair amount of use of LGPL code in all those projects and related. for example Mayavi and all the Enthought GUI stuff is based on WXPython, which is itself LGPL. Since that code is used as a library and not to copy/paste, the LGPL is not really an issue at all in such cases. In any case, I'm really happy to see better symbolics coming. This will be a huge step forward, and I really hope that you guys all figure out a technical way for sympy to continue, perhaps with an optional pynac backend (I'd have no problem using it myself in research, like I use tons of GPL code elsewhere, I just don't copy any of it in ipython/numpy). Cheers, f --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Tue, Aug 26, 2008 at 9:09 AM, Burcin Erocal [EMAIL PROTECTED] wrote:
On Tue, 26 Aug 2008 08:29:33 +0200
Ondrej Certik [EMAIL PROTECTED] wrote:
On Tue, Aug 26, 2008 at 12:49 AM, William Stein [EMAIL PROTECTED] 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]],{0x,xPi/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[0x, Assuming[xPi/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 [EMAIL PROTECTED] wrote:
On 26/08/2008, at 5:09 PM, Burcin Erocal wrote:
In[]:= Assuming[0x, Assuming[xPi/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 [EMAIL PROTECTED] wrote:
On Mon, Aug 25, 2008 at 10:58 AM, William Stein [EMAIL PROTECTED] 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
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Tue, Aug 26, 2008 at 12:25 AM, Ondrej Certik [EMAIL PROTECTED] wrote: 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?) Well, I've heard at times that plenty of places are using ipython internally in commercial settings, and I'm happy with that. I don't think anyone is going to try to go out and 'sell ipython' since it's so easy to get for free :) Overall for ipython the BSD license approach has worked well, as it's easy for me to take code from matplotlib, numpy or python itself and viceversa without worrying about licensing, and we get users from rather unexpected places (especially in industry). But each license does have its place. For example, I *strongly* support the GPL as the right choice for things like the Linux kernel, so I'm not a fanatic on any front either. My take on this is that I tend to 'go with the flow': if I contribute/extend an existing project I just follow its original license, and for my own things I tend to oscillate between LGPL and BSD depending on the specifics of the case. And I might one day find that I want to use the GPL for a new project, because I do see use cases for it as well. Cheers, f ps - I know this is getting off topic. I'm going to bed and will be happy to discuss this further, but off list to avoid derailing the discussion on symbolics with too much licensing chat. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
An assumption framework is non-trivial as it is basically computational real algebraic geometry. Recenty there was a post about QEPCAD (http://www.cs.usna.edu/~qepcad/ B/QEPCAD.html). Perhaps this might fit the bill? Michel On Aug 26, 8:43 am, William Stein [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 11:29 PM, Ondrej Certik [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 12:49 AM, William Stein [EMAIL PROTECTED] 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? From reading the GiNaC docs I have the impression the *only* assumption it supports is the assumption x is a positive real number. I think there are no other assumptions in GiNaC, though I could be wrong. I think GiNaC makes it a point not to simplify stuff automatically by making assumptions, instead providing good pattern matching, substitution, expression traversal and other tools. In fact somewhere on their webpage they have the moto in bold simplification is evil. Don't read the above as making any implications about what I think Sage should do. We can of course tack on something more sophisticated, and also decide to make our simplifications more sophisticated too, if we so desire... -- William --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Tue, 26 Aug 2008 00:40:22 -0700 (PDT) Michel [EMAIL PROTECTED] wrote: An assumption framework is non-trivial as it is basically computational real algebraic geometry. Recenty there was a post about QEPCAD (http://www.cs.usna.edu/~qepcad/ B/QEPCAD.html). Perhaps this might fit the bill? AFAIK, MMA indeed uses cylindrical algebraic decomposition (CAD) for this, and it would be great to have an efficient CAD implementation in Sage. I am not an expert on this issue, but from what I have heard, qepcad has its advantages (more flexible?) and disadvantages (slow?) compared to the CAD implementation in MMA. qepcad relies on an aging library saclib for the algebraic data structures. It would be a worthwhile project to implement CAD/port qepcad so that it is modular, and can work with more recent/better libraries. Maybe someone (Carl Witty?) will take this on (or already has?). :) Cheers, Burcin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Tue, Aug 26, 2008 at 10:16 AM, Burcin Erocal [EMAIL PROTECTED] wrote: On Tue, 26 Aug 2008 00:40:22 -0700 (PDT) Michel [EMAIL PROTECTED] wrote: An assumption framework is non-trivial as it is basically computational real algebraic geometry. Recenty there was a post about QEPCAD (http://www.cs.usna.edu/~qepcad/ B/QEPCAD.html). Perhaps this might fit the bill? AFAIK, MMA indeed uses cylindrical algebraic decomposition (CAD) for this, and it would be great to have an efficient CAD implementation in Sage. I am not an expert on this issue, but from what I have heard, qepcad has its advantages (more flexible?) and disadvantages (slow?) compared to the CAD implementation in MMA. qepcad relies on an aging library saclib for the algebraic data structures. It would be a worthwhile project to implement CAD/port qepcad so that it is modular, and can work with more recent/better libraries. Maybe someone (Carl Witty?) will take this on (or already has?). :) Yes, but this is not necessary to get the infrustructure in and get the easy cases working and working fast. qepcad or other things will come handy when doing the general cases, where simple heuristics will fail. E.g. it's like with limits, the gruntz algorithm is nice and working, but all easy cases can be done (and are done) with heuristics, because it is simpler and way faster. 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Tue, Aug 26, 2008 at 1:19 AM, Ondrej Certik [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 10:16 AM, Burcin Erocal [EMAIL PROTECTED] wrote: On Tue, 26 Aug 2008 00:40:22 -0700 (PDT) Michel [EMAIL PROTECTED] wrote: An assumption framework is non-trivial as it is basically computational real algebraic geometry. Recenty there was a post about QEPCAD (http://www.cs.usna.edu/~qepcad/ B/QEPCAD.html). Perhaps this might fit the bill? AFAIK, MMA indeed uses cylindrical algebraic decomposition (CAD) for this, and it would be great to have an efficient CAD implementation in Sage. I am not an expert on this issue, but from what I have heard, qepcad has its advantages (more flexible?) and disadvantages (slow?) compared to the CAD implementation in MMA. qepcad relies on an aging library saclib for the algebraic data structures. It would be a worthwhile project to implement CAD/port qepcad so that it is modular, and can work with more recent/better libraries. Maybe someone (Carl Witty?) will take this on (or already has?). :) I think Carl Witty has done a bunch. He gave a talk about this at Sage Days 8.5. Maybe he'll comment on this thread. Yes, but this is not necessary to get the infrustructure in and get the easy cases working and working fast. qepcad or other things will come handy when doing the general cases, where simple heuristics will fail. E.g. it's like with limits, the gruntz algorithm is nice and working, but all easy cases can be done (and are done) with heuristics, because it is simpler and way faster. Interesting. -- William --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Aug 26, 1:27 am, William Stein [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 1:19 AM, Ondrej Certik [EMAIL PROTECTED] wrote: SNIP qepcad relies on an aging library saclib for the algebraic data structures. It would be a worthwhile project to implement CAD/port qepcad so that it is modular, and can work with more recent/better libraries. Maybe someone (Carl Witty?) will take this on (or already has?). :) I think Carl Witty has done a bunch. He gave a talk about this at Sage Days 8.5. Maybe he'll comment on this thread. Carl and Jason Grout have been fixing build and 64 bit issues, but saclib is still not 64 bit. They have been pushing the fixes upstream and there ought to be an experimental spkg soon - the current one got rejected in review. Yes, but this is not necessary to get the infrustructure in and get the easy cases working and working fast. qepcad or other things will come handy when doing the general cases, where simple heuristics will fail. E.g. it's like with limits, the gruntz algorithm is nice and working, but all easy cases can be done (and are done) with heuristics, because it is simpler and way faster. Interesting. Yeah, the code in qepcad looks funny since at least some of it was translated from Fortran and hence has odd indentation for example. -- William Cheers, Michael --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Tue, 26 Aug 2008 00:42:21 -0700 William Stein [EMAIL PROTECTED] wrote: 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... My main objection to using sympy was not the license, but not having access to the fast basic routines in Sage, such as linear algebra, gcd's or polynomial arithmetic. Being trained as a mathematician, I also like the typed magma approach, and I can't deal with just handling symbolic expressions. This also fits well into my work. Since for most of these symbolic tasks, e.g. integration, summation, you model the problem algebraically, solve it using your algebraic tools, then convert it back. This doesn't mean that I'm ok with using licenses other than GPL, but I think the points above make that irrelevant anyhow. Cheers, Burcin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Tue, Aug 26, 2008 at 10:35 AM, Burcin Erocal [EMAIL PROTECTED] wrote: On Tue, 26 Aug 2008 00:42:21 -0700 William Stein [EMAIL PROTECTED] wrote: 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... My main objection to using sympy was not the license, but not having access to the fast basic routines in Sage, such as linear algebra, gcd's or polynomial arithmetic. Being trained as a mathematician, I also like the typed magma approach, and I can't deal with just handling symbolic expressions. This also fits well into my work. Since for most of these symbolic tasks, e.g. integration, summation, you model the problem algebraically, solve it using your algebraic tools, then convert it back. Right. For me, symbolic expressions are exactly what I need. The system should be clever enough to figure everything out and automatically use the best tool to solve the job. This doesn't mean that I'm ok with using licenses other than GPL, but I think the points above make that irrelevant anyhow. Thanks for the clarification, yes, I think now everything is clear. 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Aug 26, 1:19 am, Ondrej Certik [EMAIL PROTECTED] wrote: On Tue, Aug 26, 2008 at 10:16 AM, Burcin Erocal [EMAIL PROTECTED] wrote: On Tue, 26 Aug 2008 00:40:22 -0700 (PDT) Michel [EMAIL PROTECTED] wrote: An assumption framework is non-trivial as it is basically computational real algebraic geometry. Recenty there was a post about QEPCAD (http://www.cs.usna.edu/~qepcad/ B/QEPCAD.html). Perhaps this might fit the bill? I'm not sure what sort of assumptions are really useful/used in practice, but I can certainly imagine assumptions that QEPCAD couldn't handle. For example, it can't handle x is an integer, or x^2 + x + e^x 2, or anything that involves a mixture of x and sin(x). AFAIK, MMA indeed uses cylindrical algebraic decomposition (CAD) for this, and it would be great to have an efficient CAD implementation in Sage. I am not an expert on this issue, but from what I have heard, qepcad has its advantages (more flexible?) and disadvantages (slow?) compared to the CAD implementation in MMA. qepcad relies on an aging library saclib for the algebraic data structures. It would be a worthwhile project to implement CAD/port qepcad so that it is modular, and can work with more recent/better libraries. Maybe someone (Carl Witty?) will take this on (or already has?). :) I am indeed working on a CAD implementation for Sage, but I can't commit to any sort of schedule... it might be months, years, or never, before I get anything useful. (I do have something now, but it's 100x slower than QEPCAD on trivial examples.) If people want CAD- based assumptions in the near term, it would probably be better to start with QEPCAD. I do think that this would be feasible, although it would be take some work on QEPCAD (for instance, it doesn't yet build on OSX). I won't be working on a port of QEPCAD to not use saclib; I'm not willing to spend that much time working with its ported-from-Fortran code. It's unclear how much work such a port would be; I can't tell to what extent QEPCAD depends on internals of saclib. Yes, but this is not necessary to get the infrustructure in and get the easy cases working and working fast. qepcad or other things will come handy when doing the general cases, where simple heuristics will fail. E.g. it's like with limits, the gruntz algorithm is nice and working, but all easy cases can be done (and are done) with heuristics, because it is simpler and way faster. Yes; if you can handle some particular class of assumptions without CAD, it will likely be faster. CAD is particularly horrible with mutliple variables; constructing a CAD of a polynomial with k variables and maximal degree d in each variable ends up constructing a univariate polynomial of degree d^(2^(k-1)) in the generic case, if I'm remembering right. (So a polynomial with 6 variables, that is degree 2 in each variable, would end up with a base case of a polynomial of degree 2^32.) (Interesting cases are likely to be better, because intermediate polynomials are not irreducible; this helps a lot.) Similarly, you can do linear programming with CAD; but it will take time exponential in the number of variables. On the other hand, for one or two variables, CAD should be able to handle fairly large problems. Carl --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
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. 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 4:59 AM, William Stein [EMAIL PROTECTED] wrote: Hi, I propose that pynac be included in Sage. Pynac is a rewrite of Ginac to seamlessly use native Python objects instead of CLN -- for inclusion in Sage. Pynac is a C++ library plus extensive Cython bindings. Pynac is about 30K lines, is very well documented and commented, and as C++ code goes is extremely readable. VOTE: [x ] Yes, include Pynac in Sage [ ] No, do not (please explain) [ ] Hmm, I have questions (please ask). Looks very nice! MANY MORE DETAILS: ... I think with polish and proper refereeing, the code Burcin and I have already written should be included in Sage, so that others can start using it and developing it further. -- William -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
I still do not understand why giac is not even mentionned in the symbolic discussion considering the fact that like ginac, it is a C++ library, but unlike ginac (Ginac Is Not A Cas), giac (Giac Is A Cas) has much more advanced calculus functions (either functionnalities like limits, integration) and good benchmarks. I thought sage was an effort to build a free alternative to maple or mathematica and that collaboration between projects having this goal would prevail, not competition (how much time lost duplicating the functionnalities already available in giac for pynac?). By the way, I installed in ~parisse on sage the 64 bits binaries version of giac (icas) and xcas so that everybody can test benchmarks. Unfortunately a few system libraries on sage have bad rights, e.g. libstdc++.so.6 is rw instead of rwx, hence one must run export LD_LIBRARY_PATH=~parisse before running ~parisse/icas For example g:=(x+y+z+1)^20; h:=(x-y+2z-2)^20; time(r:=normal(g*h)); time(factor(r)); --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 10:12 AM, parisse [EMAIL PROTECTED] wrote: I still do not understand why giac is not even mentionned in the symbolic discussion considering the fact that like ginac, it is a C++ library, but unlike ginac (Ginac Is Not A Cas), giac (Giac Is A Cas) has much more advanced calculus functions (either functionnalities like limits, integration) and good benchmarks. I thought sage was an effort to build a free alternative to maple or mathematica and that collaboration between projects having this goal would prevail, not competition (how much time lost duplicating the functionnalities already available in giac for pynac?). I can't speak for anyone else (hence I can't really answer your question) but I have had problems compiling giac for amd64 hardy heron. I'm fairly impatient though, and maybe if I tried harder I could have gotten something to compile. I did spend maybe 30 minutes on it and gave up. I also tried installing it on an intel macbook but the package refused to install on my firewire drive. It's actually the first application I've run across which has refused to install on my firewire drive (my tiny HD is full:-). Is it possible to fix this? Can you create a system for which someone using amd64 hardy heron (a very popular distribution) can compile it from source (at least after a specific number of dependencies are installed using apt-get). In other words, can you create the analog of http://modular.math.washington.edu/sage/doc/inst/node5.html ? If so, I'd be happy to test it out. Also, is there any documentation in English? (I mean something more than a 5 page tutorial.) Sorry if I seem to hijack your thread. Actually, giac seems potentially interesting but it is difficult for me to say more. By the way, I installed in ~parisse on sage the 64 bits binaries version of giac (icas) and xcas so that everybody can test benchmarks. Unfortunately a few system libraries on sage have bad rights, e.g. libstdc++.so.6 is rw instead of rwx, hence one must run export LD_LIBRARY_PATH=~parisse before running ~parisse/icas For example g:=(x+y+z+1)^20; h:=(x-y+2z-2)^20; time(r:=normal(g*h)); time(factor(r)); --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
Hi, On Mon, 25 Aug 2008 07:12:27 -0700 (PDT) parisse [EMAIL PROTECTED] wrote: I still do not understand why giac is not even mentionned in the symbolic discussion considering the fact that like ginac, it is a C++ library, but unlike ginac (Ginac Is Not A Cas), giac (Giac Is A Cas) has much more advanced calculus functions (either functionnalities like limits, integration) and good benchmarks. I think the only reason giac is not mentioned in the benchmarks is that it wasn't available. There are already interfaces to MMA and Maple from Sage, so they are easy to time. Sympy and sympycore are already in Python, so no trouble there. GiNaC was easy to build and understand, so I could create packages and write an interface in a matter of hours. There was already an attempt (by Ondrej) to make a package for giac, which is the first step to writing an interface. However, IIRC, it didn't succeed. There is also the question why use GiNaC and not giac as the symbolic arithmetic engine in Sage. The answer lies in the formulation of the question, and the word arithmetic. We already have a pretty good symbolic engine in Sage, maxima does quite a good job of solving integrals, limits, etc. The main problem with Maxima is that we cannot extend it. The situation would be the same if we adopted yet another system, such as giac. The point of the pynac effort (at least from my pov), is to acquire a fast and capable arithmetic and manipulation engine and write the higher level algorithms on top of that. This way Sage can advance from being a user interface to become a research environment. I thought sage was an effort to build a free alternative to maple or mathematica and that collaboration between projects having this goal would prevail, not competition (how much time lost duplicating the functionnalities already available in giac for pynac?). snip Pynac is a modification of GiNaC to use python objects as coefficients in its data types. This was a rather tricky, but well isolated change, since GiNaC already abstracts this functionality into a single class. I don't think this is duplicating any functionality already in giac. Cheers, Burcin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
I've been trying to get an answer for this question for the last few weeks: Is the plan to extend ginac (write algorithms in C) or to extend sage (write new algorithms in Sage) using cython/python? This is very much a design related question, and in the hurry to get GiNaC through review I feel that design issues and questions have been very much ignored. To put the question somewhat differently, are algorithms using the new symbolics system going to be use GiNaC/pynac enough that switching to any other low level system will be very, very difficult (because new code such as sums may depend directly on GiNaC specific behavior)? If this is not intended, what will be done to try to prevent Sage from becoming overly dependent on GiNaC in the long term? --Bill On Mon, Aug 25, 2008 at 8:24 AM, Burcin Erocal [EMAIL PROTECTED] wrote: Hi, On Mon, 25 Aug 2008 07:12:27 -0700 (PDT) parisse [EMAIL PROTECTED] wrote: I still do not understand why giac is not even mentionned in the symbolic discussion considering the fact that like ginac, it is a C++ library, but unlike ginac (Ginac Is Not A Cas), giac (Giac Is A Cas) has much more advanced calculus functions (either functionnalities like limits, integration) and good benchmarks. I think the only reason giac is not mentioned in the benchmarks is that it wasn't available. There are already interfaces to MMA and Maple from Sage, so they are easy to time. Sympy and sympycore are already in Python, so no trouble there. GiNaC was easy to build and understand, so I could create packages and write an interface in a matter of hours. There was already an attempt (by Ondrej) to make a package for giac, which is the first step to writing an interface. However, IIRC, it didn't succeed. There is also the question why use GiNaC and not giac as the symbolic arithmetic engine in Sage. The answer lies in the formulation of the question, and the word arithmetic. We already have a pretty good symbolic engine in Sage, maxima does quite a good job of solving integrals, limits, etc. The main problem with Maxima is that we cannot extend it. The situation would be the same if we adopted yet another system, such as giac. The point of the pynac effort (at least from my pov), is to acquire a fast and capable arithmetic and manipulation engine and write the higher level algorithms on top of that. This way Sage can advance from being a user interface to become a research environment. I thought sage was an effort to build a free alternative to maple or mathematica and that collaboration between projects having this goal would prevail, not competition (how much time lost duplicating the functionnalities already available in giac for pynac?). snip Pynac is a modification of GiNaC to use python objects as coefficients in its data types. This was a rather tricky, but well isolated change, since GiNaC already abstracts this functionality into a single class. I don't think this is duplicating any functionality already in giac. Cheers, Burcin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 5:24 PM, Burcin Erocal [EMAIL PROTECTED] wrote: Hi, On Mon, 25 Aug 2008 07:12:27 -0700 (PDT) parisse [EMAIL PROTECTED] wrote: I still do not understand why giac is not even mentionned in the symbolic discussion considering the fact that like ginac, it is a C++ library, but unlike ginac (Ginac Is Not A Cas), giac (Giac Is A Cas) has much more advanced calculus functions (either functionnalities like limits, integration) and good benchmarks. I think the only reason giac is not mentioned in the benchmarks is that it wasn't available. There are already interfaces to MMA and Maple from Sage, so they are easy to time. Sympy and sympycore are already in Python, so no trouble there. GiNaC was easy to build and understand, so I could create packages and write an interface in a matter of hours. There was already an attempt (by Ondrej) to make a package for giac, which is the first step to writing an interface. However, IIRC, it didn't succeed. It did: http://groups.google.com/group/sage-devel/browse_thread/thread/40abd4b2825c0331/ giac builds, but it takes 72, while pynac takes 2 minutes. Also noone has tried to write the Cython wrappers for it, I hoped Bernard would try it, but I really don't have time for this now. 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
I can't speak for anyone else (hence I can't really answer your question) but I have had problems compiling giac for amd64 hardy heron. I'm fairly impatient though, and maybe if I tried harder I could have gotten something to compile. I did spend maybe 30 minutes on it and gave up. For a full-featured giac, you will need several packages. That's why I provide binaries. The binaries on sage should work on any amd64 (first install xcas_root.tgz (http://www-fourier.ujf-grenoble.fr/~parisse/ giac/xcas_root.tgz) to have the doc, then unarchive xcas64.tgz (ftp:// ftp-fourier.ujf-grenoble.fr/xcas/xcas64.tgz) in /usr/local/bin). For compilation, get the latest giac_unstable.tgz or try the spkg built by Ondrej which is in my directory on sage (it is up to date and compiles on sage). I also tried installing it on an intel macbook but the package refused to install on my firewire drive. It's actually the first application I've run across which has refused to install on my firewire drive (my tiny HD is full:-). Is it possible to fix this? There is perhaps some problem since a part of the installation goes in /usr/local. You are the first one reporting this and I'm not a mac expert therefore I can't answer right now:-( Can you create a system for which someone using amd64 hardy heron (a very popular distribution) can compile it from source (at least after a specific number of dependencies are installed using apt-get). In other words, can you create the analog ofhttp://modular.math.washington.edu/sage/doc/inst/node5.html? The INSTALL file from the source should help you compile giac. Where does it fail for you? If so, I'd be happy to test it out. Also, is there any documentation in English? (I mean something more than a 5 page tutorial.) There is a user guide in English for the xcas application. http://www-fourier.ujf-grenoble.fr/~parisse/giac/doc/en/casref_en/casref_en.html and a very short introduction on how to program with giac http://www-fourier.ujf-grenoble.fr/~parisse/giac_us.html --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 4:59 AM, William Stein [EMAIL PROTECTED] wrote: Hi, I propose that pynac be included in Sage. VOTE: [ ] Yes, include Pynac in Sage [ ] No, do not (please explain) [ ] Hmm, I have questions (please ask). I have a question: what will happen to gfurnish's work? Is it going to be completely abandoned? didier --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
Also noone has tried to write the Cython wrappers for it, I hoped Bernard would try it, but I really don't have time for this now. Ondrej I don't have the time right now to learn how to write Cython wrappers. Unfortunately I may end up being obliged (once again) to do it myself to attract python developpers:-( It will most probably not be as good as if a true python developers write one. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 7:12 AM, parisse [EMAIL PROTECTED] wrote: I still do not understand why giac is not even mentionned in the symbolic discussion considering the fact that like ginac, it is a C++ I was able to very quickly get a good understanding of the Ginac codebase, and make fundamental changes that allowed me to modify it to work at its core throughout with Python objects instead of CLN. Every single question I have had about Ginac I have literally been able to answer for myself in minutes by reading the source code. And when I change things in Ginac I can rebuild the whole system in just over a minute. My experience with Giac is that: (a) I can't build it, (b) even on systems where I could, I'm not patient enough, and (c) looking at the source code from the point of view of doing what I want makes me dizzy and I get nowhere, (d) and Giac is HUGE -- about five times the size of Ginac, and much of that code in Giac overlaps with what Sage already does, and (e) my technical build guy tells me that Giac isn't a model of super high quality code. So to me Giac cannot solve any of our problems today, unless we want Sage to be bloated, and we want to take months or years rather than a few days to get this stuff done. Perhaps I could take code from Giac, e.g., for limits or symbolic integration, but (a) you're using GPLv3, so I can't, and (b) probably that would make you unhappy anyways, and (c) I would rather such functionality comes from the sympy project, since that is in Python. By the way, I installed in ~parisse on sage the 64 bits binaries version of giac (icas) and xcas so that everybody can test benchmarks. Unfortunately a few system libraries on sage have bad rights, e.g. libstdc++.so.6 is rw instead of rwx, hence one must run export LD_LIBRARY_PATH=~parisse before running ~parisse/icas For example g:=(x+y+z+1)^20; h:=(x-y+2z-2)^20; time(r:=normal(g*h)); Wow, that particular synthetic benchmark is really fast in Giac. -- William --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 8:54 AM, didier deshommes [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 4:59 AM, William Stein [EMAIL PROTECTED] wrote: Hi, I propose that pynac be included in Sage. VOTE: [ ] Yes, include Pynac in Sage [ ] No, do not (please explain) [ ] Hmm, I have questions (please ask). I have a question: what will happen to gfurnish's work? Is it going to be completely abandoned? If he clearly licenses it under GPLv2+ then hopefully it won't be, and somebody will find ways to use it. gfurnish -- are you willing to post a version of all your code with GPLv2+ headers? -- William --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 8:35 AM, Gary Furnish [EMAIL PROTECTED] wrote: I've been trying to get an answer for this question for the last few weeks: Is the plan to extend ginac (write algorithms in C) or to extend sage (write new algorithms in Sage) using cython/python? The plan is definitely to extend sage (write new algorithms in Sage) using cython/python. To put the question somewhat differently, are algorithms using the new symbolics system going to be use GiNaC/pynac enough that switching to any other low level system will be very, very difficult (because new code such as sums may depend directly on GiNaC specific behavior)? Probably not. If this is not intended, what will be done to try to prevent Sage from becoming overly dependent on GiNaC in the long term? Make it so sympy also runs on top of GiNaC. This will force the creation of a clear interface specification. -- William --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 2:42 AM, Ondrej Certik [EMAIL PROTECTED] wrote: 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 --~--~-~--~~~---~--~~ 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
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
Make it so sympy also runs on top of GiNaC. This will force the creation of a clear interface specification. If there is going to be a clear interface spec, then we should go and make a clear interface spec so that anyone, not just GiNaC can potentially conform to it. Perhaps this is the best long term solution? My symbolics code is already GPLv2+ so fixing the headers is just a technicality. On Mon, Aug 25, 2008 at 10:24 AM, William Stein [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 8:54 AM, didier deshommes [EMAIL PROTECTED] wrote: On Mon, Aug 25, 2008 at 4:59 AM, William Stein [EMAIL PROTECTED] wrote: Hi, I propose that pynac be included in Sage. VOTE: [ ] Yes, include Pynac in Sage [ ] No, do not (please explain) [ ] Hmm, I have questions (please ask). I have a question: what will happen to gfurnish's work? Is it going to be completely abandoned? If he clearly licenses it under GPLv2+ then hopefully it won't be, and somebody will find ways to use it. gfurnish -- are you willing to post a version of all your code with GPLv2+ headers? -- William --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: [sympy] Re: [sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
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 ╲╱ _w29⋅_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
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 10:41 PM, Gary Furnish [EMAIL PROTECTED] wrote: Make it so sympy also runs on top of GiNaC. This will force the creation of a clear interface specification. If there is going to be a clear interface spec, then we should go and make a clear interface spec so that anyone, not just GiNaC can potentially conform to it. Perhaps this is the best long term solution? My symbolics code is already GPLv2+ so fixing the headers is just a technicality. Exactly. Especially if you believe you can be way faster than ginac. It'd be really awesome. Maybe William has some ideas how to do it the best, I think it just needs to be done iteratively. We will have 2 production cores soon -- pynac and sympy. Then there is sympycore and your symbolics, so that should give us enough data to see what all the cores have in common and what is different. 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: [sympy] Re: [sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
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. 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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Mon, Aug 25, 2008 at 1:41 PM, Gary Furnish [EMAIL PROTECTED] wrote: Make it so sympy also runs on top of GiNaC. This will force the creation of a clear interface specification. If there is going to be a clear interface spec, then we should go and make a clear interface spec so that anyone, not just GiNaC can potentially conform to it. Perhaps this is the best long term solution? It will not be clear what that spec should be until 2 systems use it. In my opinion, specs should not be written by committee, but by abstracted away from an actual working solution. When Sage and Sympy can both run on top of a Pynac core, we'll see how it works and have a clear interface as a result. My symbolics code is already GPLv2+ so fixing the headers is just a technicality. Please do so and make an official release as a tarball or something. On Mon, Aug 25, 2008 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: [sympy] Re: [sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
For example pynac uses 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
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. william --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Aug 25, 2008, at 1:59 AM, William Stein wrote: Hi, I propose that pynac be included in Sage. Pynac is a rewrite of Ginac to seamlessly use native Python objects instead of CLN -- for inclusion in Sage. Pynac is a C++ library plus extensive Cython bindings. Pynac is about 30K lines, is very well documented and commented, and as C++ code goes is extremely readable. VOTE: [x] Yes, include Pynac in Sage [ ] No, do not (please explain) [ ] Hmm, I have questions (please ask). Very enthusiastic about this! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sage-devel] Re: Proposal for inclusion of GINAC/pynac-0.1 in Sage.
On Aug 25, 2008, at 8:35 AM, Gary Furnish wrote: I've been trying to get an answer for this question for the last few weeks: Is the plan to extend ginac (write algorithms in C) or to extend sage (write new algorithms in Sage) using cython/python? I don't think this was addressed in the email, but my understanding is that the plan is very much the latter. Perhaps (I hope) that much of this will not be re-implementation so much as porting SymPy algorithms/getting SymPy to run on top of GiNaC. This is very much a design related question, and in the hurry to get GiNaC through review I feel that design issues and questions have been very much ignored. To put the question somewhat differently, are algorithms using the new symbolics system going to be use GiNaC/pynac enough that switching to any other low level system will be very, very difficult (because new code such as sums may depend directly on GiNaC specific behavior)? If this is not intended, what will be done to try to prevent Sage from becoming overly dependent on GiNaC in the long term? --Bill --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
