Proposal for inclusion of GINAC/pynac-0.1 in Sage.
William Stein
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:
[ ] Yes, include Pynac in Sage
[ ] No, do not (please explain)
[ ] Hmm, I have questions (please ask).
MANY MORE DETAILS:
The idea to rewrite Ginac so it can manipulate native Python objects
directly appears to be new, and hasn't been tried before.
After thinking through all the options in detail, having experimented
with gfurnish's symbolics approach, watching how sympycore and sympy
have developed, and seeing what is possible using Maxima and Axiom,
I think Burcin's proposal to use a rewritten Ginac as the core symbolics
library for Sage is by far the best, given the goal of having a very solid
nearly-bug-free-well-documented-robust-fast symbolic system in literally
weeks from when we start. Absolutely all other approaches result in
something that either doesn't scale speedwise, is buggy, is slow, or
will take a long time to finish. I'm so convinced that Burcin is right
about the Ginac approach that I've invested most of my time during
the last two weeks in this.
The new Pynac:
(1) doesn't depend at all on (the heavy) CLN library,
(2) can manipulate Python objects instead of CLN classes,
(3) has Cython bindings that replicate roughly 50% (?) of the
functionality of the current Sage calculus, and at the same time
works with many more data types in Sage (e.g., interval arithmetic)
unlike the current calculus code which only works with types
that Maxima supports. Currently the new code is 100% independent
of the Maxima-base calculus code in sage, and in many cases
much faster and potentially more powerful.
To try it out:
(a) if you have an account on sage.math, just run the system-wide sage.
(b) To install yourself into sage-3.1.1, see
http://sage.math.washington.edu/home/was/pynac/
In particular, do
sage -i http://sage.math.washington.edu/home/was/pynac/pynac-0.1.spkg
The above build should take between 2 and 6 minutes depending on how fast
your computer is. On one of my test machines with export MAKE="make -j4"
it takes 45 seconds realtime to build.
Then do:
sage: hg_sage.pull()
sage: hg_sage.apply('http://sage.math.washington.edu/home/was/pynac/pynac.hg')
sage: hg_sage.merge() # possibly not needed
sage: hg_sage.ci() # possibly not needed
and exit and do:
sage -br
You can create symbolic expression in the new symbolic ring
by doing e.g.,
sage: var('x,y,z',ns=1)
(x, y, z)
sage: f = (x+y+sin(z)^x)^3
sage: f.expand()
3*sin(z)^x*x^2 + 3*sin(z)^x*y^2 + 3*(sin(z)^x)^2*x + ...[snip]
sage: f.[tab]
An example with interval coefficients:
sage: f = x^3 + x^RIF(1) + y*RIF(pi)
sage: f
x^3 + x^(1.0000000000000000?) + (3.141592653589794?)*y
sage: expand(f^2).diff(y)
(6.283185307179587?)*x^3 + (6.283185307179587?)*x + (19.73920880217872?)*y
Arithmetic with relations is fully supported, including squaring both
sides:
sage: f = (x^3 + x - 2/3 + y < x^3)
sage: f^2
(x^3 + x + y - 2/3)^2 < x^6
sage: f - x^3
x + y - 2/3 < 0
Arithmetic with formal functions -- something that Burcin was originally
very concerned about -- is well supported. Here's an example illustrating
applying a differential operator and extracting off coefficients of
it, a feature
that somebody recently wanted but the current Sage calculus didn't have:
sage: from sage.symbolic.function import function
sage: r, kappa = var('r,kappa', ns=1)
sage: psi = function('psi', 1)(r)
sage: g = 1/r^2*(2*r*psi.diff(r,1) + r^2*psi.diff(r,2)); g
(2*psi(1,r)*r + psi(2,r)*r^2)*r^(-2)
sage: g.coeff(psi.diff(r,2))
1
sage: g.coeff(psi.diff(r,1))
2*r^(-1)
See the directory SAGE_ROOT/devel/sage/sage/symbolic for nearly 500 lines of
input examples or point your browser here:
http://sage.math.washington.edu/home/was/d/sage/symbolic/
Let me know if you have any questions.
There are still a lot of questions that I didn't answer above. Including:
(a) who will do the actual work? (mainly Burcin at this point)
(b) what will the new design look like? How much
will change from the current symbolic calculus interface?
In particular, how are we ensuring that the many requests
from users in recent threads are addressed in this redesign?
(See http://wiki.sagemath.org/symbench)
(c) how does all this relate to the coercion model?
(That will help with, e.g., a symbolic complex number type.)
(d) what's the time frame for completely replacing the current calculus code?
(Two months?)
(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.)
(f) How did you rewrite ginac to work with Python objects?
(This basically involved creating
a hybrid Cython/C++ wrapper of Python's object system; this same technique
could be used to change Pari/Gap/Singular, etc. so they could
also manipulate
any Sage arithmetic data types, e.g., intervals, finite field
elements, flint
polynomials, etc. I'm not sure why nobody has done this before with Sage.)
(g) Are you proposing forking Ginac? (Ans: No, definitely not. We'll just
merge in their changes when they make new releases. It's a mature old
project, hence quite stable, so this should be easy, especially given the
high quality of their work.)
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
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
David Joyner
>
> 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:
> [ ] No, do not (please explain)
> [ ] Hmm, I have questions (please ask).
>
Looks very nice!
>
> MANY MORE DETAILS:
>
...
parisse
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));
David Joyner
<bernard...@ujf-grenoble.fr> 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.
Burcin Erocal
On Mon, 25 Aug 2008 07:12:27 -0700 (PDT)
parisse <bernard...@ujf-grenoble.fr> 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
Gary Furnish
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
Ondrej Certik
>
> Hi,
>
> On Mon, 25 Aug 2008 07:12:27 -0700 (PDT)
> parisse <bernard...@ujf-grenoble.fr> 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
parisse
> 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.
>
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?
>
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?
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.)
>
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
Martin Albrecht
Hi there,
I totally agree with you that it is annoying that your e-mails don't get
addressed properly. Thus, I'm answering however I don't really use symbolics,
so my expertice is very limited in that area.
The official guidelines for inclusion of new packages are:
> = License =
> GPL version 2+ compatible license. (This will be publicly revisited around
> Jan 15, 2009.)
GIAC seems to be GPL v3+ according to Michael Abshoff?
> = Build Support =
> "The package must build on our supported architectures and compilers [and
> intended port targets]: * Linux: x86, x86_64, Itanium, ppc, ppc64, Sparc
> (gcc 3.4-4.3)
> * Apple Mac OS X: ppc, ppc64, x86, x86-64 (Xcode 2.5+)
> * Microsoft Windows: x86, x86_64 MSVC 2005/Intel Fortran [MinGW or Cygwin
> * support is insufficient!] * Solaris 10: Sparc, x86, x86_64 (Sun Forte 12)
> Remarks:
> Some Sage developers are willing to help you port to OSX, Solaris and
> Windows. But this is no guarantee and you or your project are expected to
> do the heavy lifting and also support those ports upstream if there is no
> Sage developer who is willing to share the burden. Potential future ports:
> FreeBSD: x86, x86-64
> OpenBSD: x86, x86-64
> HPUX: Itanium
> AIX: PPC64
> ARM: OSX
As far as I know there were a couple of build issues with GIAC in the past.
But you replied fast to any issue brought up on this list.
Michael Abshoff wrote about this on [sage-devel]:
The code doesn't seem to have MSVC support and due to its size the
size/benefit ratio doesn't look good. Since I will likely end up
porting the code I am not too excited to have to deal with another
150k lines of code.
I am not aware of any build issue with GINAC because I never tried. However,
it seems that this issue was not addressed in William's proposal. William,
can you clarify where you tried to build GINAC and how it worked? Also, since
MSVC support is now a *requirement*, does Pynac compile with MSVC?
> Quality
> The package should be "better" than anything else (that passes the two
> above criteria) and an argument should be made for this. The comparison
> should be made to both Python and other software. Criteria in passing the
> quality test include:
> Speed
As far as I understand it there is an issue defining what "Speed" is in that
context. But both Ginac and Giac seem to do well overall. Someone else needs
to address this in more detail
> Documentation
Ginac seems to be fairly well documented from what I gather: Tutorial,
reference manual. Same goes for Giac which also seems to have a tutorial and
a reference manual. This seems to be focused on Xcas though, which is not
what Sage could use. Is there any C++ level reference manual?
Michael Abshoff wrote about this:
The code is sparingly commented and seems to conform to its own
coding style. We specifically looked at the Risch code and also
infrastructure like vecteur - this is really a big issue since dealing
with sparingly documented code in the past had proven to be a huge
pain in case we had to fix bugs
> Usability
I have no clue. However, Ginac seems to be extendible since it is designed as
a C++ library rather than a full system. Libraries are obviously better for
Sage since they are easier to integrate.
> Memory leaks
No clue.
> Maintainable
That seems to be an issue, since people complaint about the lack of code
documentation, module separation and so on for Giac. I'm just repeating what
others said already on this list, I personally never tried.
Also Giac comes with a lot of stuff that is already in Sage, while Ginac only
does stuff that is not there yet (fast symbolic arithmetic)
> Reasonable build time, size, dependencies
Ondrej reported that building Giac required 72 minutes on sage.math which is
way too long. Ginac builds in up to 6 minutes. Also Giac seems much larger
than Ginac.
> Voting
> JSAGE vote (majority)
> A certain number of sage-devel +1 votes (and sage-support votes)
> Every spkg *must* be available as an optional spkg until at least 5 people
> download it.
The vote for Ginac is ongoing. One is of course free to open a vote on Giac
too. However, I do appreciate that William Stein calling a vote would
outweight competing attempts. Still, no harm in trying.
I hope this addresses some of your questions,
Cheers,
Martin
--
name: Martin Albrecht
_pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99
_www: http://www.informatik.uni-bremen.de/~malb
_jab: martinr...@jabber.ccc.de
didier deshommes
>
> I propose that pynac be included in Sage.
>
> [ ] 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
parisse
>
> > = License =
> > GPL version 2+ compatible license. (This will be publicly revisited around
> > Jan 15, 2009.)
>
> GIAC seems to be GPL v3+ according to Michael Abshoff?
>
be linked with).
> As far as I understand it there is an issue defining what "Speed" is in that
> context. But both Ginac and Giac seem to do well overall. Someone else needs
> to address this in more detail
>
ginac and giac are probably on the same scale.
I did not try ginac recently, but I don't think they have for example
a modular GCD algorithm, they rely on heuristic GCD and subresultant.
> > Documentation
>
> Ginac seems to be fairly well documented from what I gather: Tutorial,
> reference manual. Same goes for Giac which also seems to have a tutorial and
> a reference manual. This seems to be focused on Xcas though, which is not
> what Sage could use. Is there any C++ level reference manual?
>
used. The user guide is focused on Xcas since that's where users
currently are. It is anyway useful for writing code using giac, since
(almost) every xcas function has an equivalent giac function with the
same name + an initial _ and the same arguments (groupped in a vector)
and sometimes a context argument (for thread-safe parallel execution).
I'm waiting for interested contributors before writing a more complete
guide.
> > Usability
>
> I have no clue. However, Ginac seems to be extendible since it is designed as
> a C++ library rather than a full system. Libraries are obviously better for
> Sage since they are easier to integrate.
>
> Also Giac comes with a lot of stuff that is already in Sage, while Ginac only
> does stuff that is not there yet (fast symbolic arithmetic)
>
What do you mean by fast symbolic arithmetic? Ginac does basic fast
symbolic arithmetic (+,*), Giac does in addition gcd, factor,
integration, etc. Of course, maxima or axiom can be called from inside
sage to do these kinds of computations, but they will not benefit from
speed or functionnality improvements from other libraries (e.g. maxima
will not benefit from the inclusion of ginac or NTL or whatever will
be in sage).
Dismissing giac means that some sage developers will take time and
efforts to duplicate what's already in giac from the ginac base.
>
> Ondrej reported that building Giac required 72 minutes on sage.math which is
> way too long. Ginac builds in up to 6 minutes. Also Giac seems much larger
> than Ginac.
>
features. It is indeed long to build with -O2 but with -g it is about
10mn or less. I never build with -O2 for development, only for
distributing final binaries.
parisse
> 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
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.
Martin Albrecht
> > only does stuff that is not there yet (fast symbolic arithmetic)
>
> ???
> What do you mean by fast symbolic arithmetic? Ginac does basic fast
> symbolic arithmetic (+,*), Giac does in addition gcd, factor,
> integration, etc. Of course, maxima or axiom can be called from inside
> sage to do these kinds of computations, but they will not benefit from
> speed or functionnality improvements from other libraries (e.g. maxima
> will not benefit from the inclusion of ginac or NTL or whatever will
> be in sage).
> Dismissing giac means that some sage developers will take time and
> efforts to duplicate what's already in giac from the ginac base.
I meant stuff like this:
"""
Installing the required libraries from source (recommended)
....
* CoCoA 0.99 (for faster Groebner basis).
"""
Sage already has "faster Groebner bases" since it included Singular. There is
a lot of stuff like that in Xcas/Giac like that Sage already has. This makes
sense since Giac/Xcas is a stand-alone system just like Sage.
> > Ondrej reported that building Giac required 72 minutes on sage.math which
> > is way too long. Ginac builds in up to 6 minutes. Also Giac seems much
> > larger than Ginac.
>
> Of course, giac is much larger since it has much more calculus
> features. It is indeed long to build with -O2 but with -g it is about
> 10mn or less. I never build with -O2 for development, only for
> distributing final binaries.
Sage is built from source by many people. One of the design goals was to
enable each end user easily to contribute and thus there is no such stark
distinction between "development" and "final binaries". This might change
eventually, but a build time of 72 minutes seems way too long.
William Stein
<bernard...@ujf-grenoble.fr> 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
William Stein
>
> 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
William Stein
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
William Stein
<bernard...@ujf-grenoble.fr> wrote:
>
>> The official guidelines for inclusion of new packages are:
>>
>> > = License =
>> > GPL version 2+ compatible license. (This will be publicly revisited around
>> > Jan 15, 2009.)
>>
>> GIAC seems to be GPL v3+ according to Michael Abshoff?
>>
>
> I can re-license it to GPL 2 (maybe some optional libraries should not
> be linked with).
>
>> As far as I understand it there is an issue defining what "Speed" is in that
>> context. But both Ginac and Giac seem to do well overall. Someone else needs
>> to address this in more detail
>>
>
> It all depends on what you are benchmarking. For basic arithmetic,
> ginac and giac are probably on the same scale.
> I did not try ginac recently, but I don't think they have for example
> a modular GCD algorithm, they rely on heuristic GCD and subresultant.
I have already looked at the gcd algorithm in Ginac, and it would
be easy to completely replace it by calls to Singular, so we could
completely eliminate the GCD (etc.) code from pynac.
In any case, we're using Ginac almost entirely as a foundation
for fast basic arithmetic, and for not much else.
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
parisse
>
> """
> Installing the required libraries from source (recommended)
> ....
> * CoCoA 0.99 (for faster Groebner basis).
> """
>
> Sage already has "faster Groebner bases" since it included Singular. There is
> a lot of stuff like that in Xcas/Giac like that Sage already has. This makes
> sense since Giac/Xcas is a stand-alone system just like Sage.
>
linked in giac. There are other parts of giac that might be
interesting for sage or are fast inside giac. Like gcd, limit,
integration, contexts...
> Sage is built from source by many people. One of the design goals was to
> enable each end user easily to contribute and thus there is no such stark
> distinction between "development" and "final binaries". This might change
> eventually, but a build time of 72 minutes seems way too long.
>
CXXFLAGS=-g so that it compiles without optimization in less than 10
minutes by default. If you develop around giac, you will most likely
want to use gdb, hence -O2 is bad even with -g. Optimization is only
required from time to time when one needs to make benchmarks.
Re: William
>(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.
(c) Did you first look at the giac.info page?
(d) Yes, giac/xcas is large (maybe 100K lines for giac, you don't have
to look at the interface code), but that's the price to have a CAS!
(e) Perhaps. From my own experience, it is not easy to enter into a
large library (e.g. cocoa, pari, etc.).
>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.
interoperate. Even if it take months, that should be compared to the
time required to get the same level of functionnalities at a
comparable speed over ginac.
>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.
is highly improbable that you could take code slices without taking
almost all of the library. Higher level code depends on the low level
routines and data structures (e.g. rational fraction integration from
multivariate polynoms) + many parts are interconnected (e.g.
integration requires linear algebra) which BTW makes modularization
difficult.
Ok, it's probably time lost for both parts, I'm afraid I won't
convince you to use giac and you will certainly not convince me to
abandon giac in favor of re-developing over ginac or inside sympy
(which I find interesting, I wonder how the speed problem will be
fixed).
The real fight should be with closed-source systems. I will keep
looking at symbolic threads, it's always interesting to test examples
and benchmarks.
Gary Furnish
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.
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
>
> "
> 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
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
Even at 10 minutes with no optimization
that seriously tests my patience. And 72 minutes with
optimization is real deal breaker.
> (c) Did you first look at the giac.info page?
I don't know what that is. However, I expect to be able
to cd to the source directory, start looking around, and make
progress. I was very pleasantly surprised by how well
this worked with ginac, which certainly passes that test.
> (d) Yes, giac/xcas is large (maybe 100K lines for giac, you don't have
> to look at the interface code), but that's the price to have a CAS!
True. I'm not saying giac is at all bad -- I just don't think it is the
right tool for the problem that I need to solve.
> (e) Perhaps. From my own experience, it is not easy to enter into a
> large library (e.g. cocoa, pari, etc.).
I don't know what you mean here. Pari is also a fairly unpleasant
library to work with. Ginac is one of the better ones I've seen, similar
maybe to NTL which is also quite good as far as usability goes.
PARI is terrible to use as a library.
>
>>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.
>
> I can't believe it would take years to make sage and giac
> interoperate. Even if it take months, that should be compared to the
> time required to get the same level of functionnalities at a
> comparable speed over ginac.
>>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.
>
> (a) is not recevable since I could relicense it to GPL v2. Anyway, it
> is highly improbable that you could take code slices without taking
> almost all of the library. Higher level code depends on the low level
> routines and data structures (e.g. rational fraction integration from
> multivariate polynoms) + many parts are interconnected (e.g.
> integration requires linear algebra) which BTW makes modularization
> difficult.
This nicely illustrates issues with using giac for sage. Again, it is
not to say that giac is "bad"; just that it isn't suitable for my purposes.
> Ok, it's probably time lost for both parts, I'm afraid I won't
> convince you to use giac and you will certainly not convince me to
> abandon giac in favor of re-developing over ginac or inside sympy
> (which I find interesting, I wonder how the speed problem will be
> fixed).
I am not at all trying to convince you to do anything differently.
> The real fight should be with closed-source systems. I will keep
> looking at symbolic threads, it's always interesting to test examples
> and benchmarks.
I'm not even trying to fight with closed source systems. I just want
to get Sage's symbolic manipulation capabilities to be "up to snuff for
research level work", which is something they are not right now,
except for say calculus teaching.
William
William Stein
>
> "
> 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.
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
> 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
Robert Bradshaw
> 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!
Robert Bradshaw
> 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.
mabshoff
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
Ondrej Certik
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
William Stein
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
Ondrej Certik
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
Fernando Perez
>> 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.
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...
>
> 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.
> 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
Burcin Erocal
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]]
Cheers,
Burcin
David Philp
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
==================================
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
Fernando Perez
>> 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
Ondrej Certik
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
Fernando Perez
> 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.
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
Michel
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
Burcin Erocal
Michel <saartje.v...@gmail.com> 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
Ondrej Certik
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
William Stein
>
> On Tue, Aug 26, 2008 at 10:16 AM, Burcin Erocal <bur...@erocal.org> wrote:
>>
>> On Tue, 26 Aug 2008 00:40:22 -0700 (PDT)
>> Michel <saartje.v...@gmail.com> 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
mabshoff
On Aug 26, 1:27 am, "William Stein" <wst...@gmail.com> wrote:
> On Tue, Aug 26, 2008 at 1:19 AM, Ondrej Certik <ond...@certik.cz> wrote:
> >> 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.
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.
translated from Fortran and hence has odd indentation for example.
> -- William
Cheers,
Michael
Burcin Erocal
"William Stein" <wst...@gmail.com> 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
Ondrej Certik
>
> On Tue, 26 Aug 2008 00:42:21 -0700
> "William Stein" <wst...@gmail.com> 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
parisse
> that seriously tests my patience. And 72 minutes with
> optimization is real deal breaker.
>
> > (c) Did you first look at the giac.info page?
>
> I don't know what that is. However, I expect to be able
> to cd to the source directory, start looking around, and make
> progress. I was very pleasantly surprised by how well
> this worked with ginac, which certainly passes that test.
>
emacs session (Ctrh-H I if the info file is installed or Ctrt-U Ctrl-H
I otherwise). giac.info is also available as HTML from my webpage. It
is not up to date but it gives an introduction that will greatly help
everyone who wants to program with giac. I strongly recommend to look
at it before looking at the source code.
>
> > (e) Perhaps. From my own experience, it is not easy to enter into a
> > large library (e.g. cocoa, pari, etc.).
>
> I don't know what you mean here. Pari is also a fairly unpleasant
> library to work with. Ginac is one of the better ones I've seen, similar
> maybe to NTL which is also quite good as far as usability goes.
> PARI is terrible to use as a library.
>
style of the reader and writer. I had a look at singular 2 years ago,
and I did not find it easy at all (and it was not available as a
library anyway).
I didn't look at ginac recently, but I did 8 years ago when I started
giac. At the beginning giac was based over ginac, I first wrote a
polynomial library extension with ginac since it had (and still does
not have stable) factorization code. Then I decided to abandon ginac,
since I didn't like to use cln and I could not access easily to the
underlying symbolic representation for the conversions. Maybe it's
because I do not really master C++, but I find much easier to have
union and explicit type information in a structure like giac::gen.
> > is highly improbable that you could take code slices without taking
> > almost all of the library. Higher level code depends on the low level
> > routines and data structures (e.g. rational fraction integration from
> > multivariate polynoms) + many parts are interconnected (e.g.
> > integration requires linear algebra) which BTW makes modularization
> > difficult.
>
> This nicely illustrates issues with using giac for sage. Again, it is
> not to say that giac is "bad"; just that it isn't suitable for my purposes.
>
independant components. Of course it's cleaner.
You will end up requiring the same amount of code.
William Stein
<bernard...@ujf-grenoble.fr> wrote:
>
>> Even at 10 minutes with no optimization
>> that seriously tests my patience. And 72 minutes with
>> optimization is real deal breaker.
>>
>
> !
I am very impatient.
>> > (e) Perhaps. From my own experience, it is not easy to enter into a
>> > large library (e.g. cocoa, pari, etc.).
>>
>> I don't know what you mean here. Pari is also a fairly unpleasant
>> library to work with. Ginac is one of the better ones I've seen, similar
>> maybe to NTL which is also quite good as far as usability goes.
>> PARI is terrible to use as a library.
>>
>
> I didn't find NTL that easy to use. Perhaps it depends on the code
> style of the reader and writer. I had a look at singular 2 years ago,
> and I did not find it easy at all (and it was not available as a
> library anyway).
> I didn't look at ginac recently, but I did 8 years ago when I started
> giac. At the beginning giac was based over ginac, I first wrote a
> polynomial library extension with ginac since it had (and still does
> not have stable) factorization code. Then I decided to abandon ginac,
> since I didn't like to use cln and I could not access easily to the
> underlying symbolic representation for the conversions.
> Maybe it's
> because I do not really master C++, but I find much easier to have
> union and explicit type information in a structure like giac::gen.
That's interesting, since the first thing I did with Ginac over
the last 10 days was completely replace all use by Ginac
of cln by use of PyObject*'s, which are more like giac::gen,
I guess.
Incidentally, I invested a significant amount of time systematically learning
C++ when I was an undergrad computer science major, so you're
right that this likely affects my perspective.
William
Carl Witty
> On Tue, Aug 26, 2008 at 10:16 AM, Burcin Erocal <bur...@erocal.org> wrote:
>
> > On Tue, 26 Aug 2008 00:40:22 -0700 (PDT)
> > Michel <saartje.vandenbe...@gmail.com> 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?
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?). :)
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.
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
Ondrej Certik
>> style of the reader and writer. I had a look at singular 2 years ago,
>> and I did not find it easy at all (and it was not available as a
>> library anyway).
>> I didn't look at ginac recently, but I did 8 years ago when I started
>> giac. At the beginning giac was based over ginac, I first wrote a
>> polynomial library extension with ginac since it had (and still does
>> not have stable) factorization code. Then I decided to abandon ginac,
>> since I didn't like to use cln and I could not access easily to the
>> underlying symbolic representation for the conversions.
>> Maybe it's
>> because I do not really master C++, but I find much easier to have
>> union and explicit type information in a structure like giac::gen.
>
>
> That's interesting, since the first thing I did with Ginac over
> the last 10 days was completely replace all use by Ginac
> of cln by use of PyObject*'s, which are more like giac::gen,
> I guess.
>
> Incidentally, I invested a significant amount of time systematically learning
> C++ when I was an undergrad computer science major, so you're
> right that this likely affects my perspective.
This is indeed interesting. If you say that ginac is nicely written,
then I really should consider myself an education in C++ (as btw the
ginac developers told me!). :) And I will do it and educate myself.
Ondrej
William Stein
I definitely do recommend learning C++, if for no other reason that there
is a *lot* of valuable code written in that language, and understanding it
helps expand your options. Also, I think C/C++ code is the "closest" code
to the Python ecosystem. Just be sure you don't like C++ too much!
If you look at TIOBE:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
then you'll see that together C/C++ is the according to that site the
"world's most popular language".
-- William
Disclaimer: I don't like C++ too much. But it is worth knowing.
Ondrej Certik
>>> C++ when I was an undergrad computer science major, so you're
>>> right that this likely affects my perspective.
>>
>> This is indeed interesting. If you say that ginac is nicely written,
>> then I really should consider myself an education in C++ (as btw the
>> ginac developers told me!). :) And I will do it and educate myself.
>
> I definitely do recommend learning C++, if for no other reason that there
> is a *lot* of valuable code written in that language, and understanding it
> helps expand your options. Also, I think C/C++ code is the "closest" code
> to the Python ecosystem. Just be sure you don't like C++ too much!
>
> If you look at TIOBE:
> http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
> then you'll see that together C/C++ is the according to that site the
> "world's most popular language".
>
> -- William
>
> Disclaimer: I don't like C++ too much. But it is worth knowing.
Thanks! I will. Last time I did serious C++ programming was in 2002
while still at high school, I remember I sit down and wrote this game:
http://sourceforge.net/projects/bino/
the main part I did in about 3 weeks, each day about 10 hours of C++.
Wow, that's fun, I downloaded this now, but it doesn't even compile on
a recent g++ compiler, but I looked at the code now and I don't like
it, I should learn C++ much better.
I was using lua as a scripting language. Lua was extremely easy to
embed and learn.
I then got annoyed how difficult was to refactor C++ and how lua
didn't give me the power of Python and I learned Python and that was
my language ever since. That's why I am so happy with Cython, it
allows me to easily do what I always wanted.
BTW, the game I was writing is the same as this (also in C++ and lua),
which begun at about the same time:
I was corresponding with the author of it back in 2002 and we both
agreed that should we do it again, we would definitely use python
(+pygame for example).
Ondrej
P.S. If you don't know the game oxyd or enigma above, I can greatly
recommend, I spent weeks with it as a child back on old macintoshes.