presentation about Maxima at Sage developer days

53 views
Skip to first unread message

Robert Dodier

unread,
Jun 18, 2008, 10:56:30 AM6/18/08
to maxima mailing list, sage-devel
Hello,

I was invited to the on-going Sage developer days workshop.
http://sagemath.org http://wiki.sagemath.org/dev1
I gave a little presentation about Maxima.
http://maxima.sourceforge.net/misc/maxima-opinions.pdf

Sage is a really exciting project in many ways. I think merging
different computational systems is a very useful goal. In Maxima
there is a similar trend although less extensive since at present
it is required that stuff be translated to Lisp. The new
computational stuff for exact linear algebra, modular forms, and
other topics is very interesting and a great contribution.
Maybe in some form some of that would someday be ported
to Maxima.

I'm somewhat less excited by the subproject to write new
symbolic manipulation code for Sage. Sorry to say it, but it seems
like a reinvention of the wheel. Maybe that's unavoidable;
and maybe you'll do a better job of it than Maxima!

Sage is a great project and it was terrific to meet William Stein
and everyone else. Many thanks to William for the invitation.
I look forward to further collaboration.

best

Robert Dodier

Ondrej Certik

unread,
Jun 18, 2008, 1:09:42 PM6/18/08
to sage-...@googlegroups.com, maxima mailing list

I am glad you liked it, it was also very terrific for me to meet
William, Michael and all the other Sage developers for the first time
in Bristol and then in Austin.
I like your 4th slide (A laissez-faire attitude), that's how I view
mathematics and I think it's how most physcists access mathematics.

As to symbolics, I can answer that one easily. New code gets written
when the current projects don't satisfy the needs of those writing the
new code.

I know you once written to the SymPy mailinglist asking us to rather
join (or use) Maxima [1], instead of reinventing the wheel. Well, Sage
does exactly what you wanted, i.e. using maxima from Python, instead
of reinventing the wheel. But lisp is just too difficult for me (and
all other people I personally know) to fix. The other reason is that I
think lisp is dead.

Compare this:

http://maxima.cvs.sourceforge.net/maxima/maxima/src/limit.lisp?revision=1.53&view=markup

to this:

http://hg.sympy.org/sympy/file/ccebd03423df/sympy/series/gruntz.py

it has more or less the same functionality now. Which is more
readable? I guess there are people who will find the lisp version more
readable, but I and most people I know find the python version more
readable/maintainable.


However, on a positive note, I think this game is not a game with a
sum of 1, but rather it seems to me that all Sage, Maxima, SymPy and
other packages are getting new users and developers. In the end, all I
want is to get the job done and I think it's important to make sure
all the packages talk to each other well, and also to try to find
common grounds of cooperation, if possible.

Ondrej

[1] http://groups.google.com/group/sympy/browse_thread/thread/8a761b6a710e5319/a620d45d9048a0fb

parisse

unread,
Jun 20, 2008, 6:45:24 AM6/20/08
to sage-devel
> I know you once written to the SymPy mailinglist asking us to rather
> join (or use) Maxima [1], instead of reinventing the wheel. Well, Sage
> does exactly what you wanted, i.e. using maxima from Python, instead
> of reinventing the wheel. But lisp is just too difficult for me (and
> all other people I personally know) to fix. The other reason is that I
> think lisp is dead.
>
> Compare this:
>
> http://maxima.cvs.sourceforge.net/maxima/maxima/src/limit.lisp?revisi...
>
> to this:
>
> http://hg.sympy.org/sympy/file/ccebd03423df/sympy/series/gruntz.py
>
> it has more or less the same functionality now. Which is more
> readable? I guess there are people who will find the lisp version more
> readable, but I and most people I know find the python version more
> readable/maintainable.
>

But you should not forget that the question of the class of problemes
solved is what is relevant to the users. Looking for example at the
sympy implementation of the mrv algorithm, it is far from being able
to solve even simple limits, like
limit((3**x+5**x)**(1/x),x,oo)
and many limits that are solved by the mrv algorithm fail:
limit(x*ln(x)*ln(x*exp(x)-x**2)**2/
ln(ln(x**2+2*exp(exp(3*x**3*ln(x))))),x,oo)
limit(exp(exp(exp(x)))/exp(exp(exp(x-exp(-exp(exp(x)))))),x,oo)
...
or return wrong answer
limit(exp(exp(exp(x)))/exp(exp(exp(x-exp(-x)))),x,oo)
With sufficient hard work, there is no reason for sympy not being able
to solve these problems, but it will be interesting to compare the
complexity to maintain/extend the limit algorithm of sympy with maxima
or giac *when* sympy will be able to do it and do it not too slowly
(as well as other calculus tasks like e.g. integration)
And then I ask the question : is it really worth the effort to
duplicate the work done in maxima or giac? How hard is it compared to
making sympy interoperable with maxima or giac?
I believe that many people are underestimating the work required to
have common calculus tasks properly done and that might explain the
current roadmap of sympy.

> However, on a positive note, I think this game is not a game with a
> sum of 1, but rather it seems to me that all Sage, Maxima, SymPy and
> other packages are getting new users and developers. In the end, all I
> want is to get the job done and I think it's important to make sure
> all the packages talk to each other well, and also to try to find
> common grounds of cooperation, if possible.
>

Then I hope you will reconsider making sympy interoperable either with
maxima or giac or both.

Ondrej Certik

unread,
Jun 20, 2008, 8:32:07 AM6/20/08
to sage-...@googlegroups.com

Yes, I am well aware of that. The problem is not in the mrv algorithm
itself, but in series expansion, which needs to support
very general series. My original code from a year ago was able to
handle all the cases you wrote above and it took me about 3 weeks to
write and debug.
However, it was built on a little fragile series expansion code.

In SymPy, we were fixing bugs that people discover and need fixed
urgently, and people don't need these limits often, so that's why we
were fixing other issues first.
But it's definitely on my TODO list.

> With sufficient hard work, there is no reason for sympy not being able
> to solve these problems, but it will be interesting to compare the
> complexity to maintain/extend the limit algorithm of sympy with maxima
> or giac *when* sympy will be able to do it and do it not too slowly
> (as well as other calculus tasks like e.g. integration)

Yep.

> And then I ask the question : is it really worth the effort to
> duplicate the work done in maxima or giac? How hard is it compared to
> making sympy interoperable with maxima or giac?

Actually, I think it is easier to write it from scratch than to
maintain wrappers to maxima/giac/ginac. Remember that I wrote swiginac
with Ola Skavhaug, so I know what I am talking about. And you can ask
Sage developers about their opinion on maxima wrappers and why Gary is
writing symbolics from scratch.

I thought that if I try to integrate sympy in Sage, the Sage develpers
will not have to write the symbolics from scratch. But I was wrong,
because I don't have enough time to do it myself and noone else have
step up to help with this. And the reason is not that other people
don't "see the light". The reason is that it is simply easier to do it
from scratch and do it right within the constrains that you have and
the tools you have. I.e. in the case of Sage -- cython+other Sage
parts, in the case of sympy -- pure Python + maybe cython, but without
other sage parts.

Then you might think -- ok, so pure Python, maybe Cython, so why have
Pearu started sympycore as another project? Well, again, it is easier
to start from scratch.

On the other hand, I find this scatter of resources also bad. So I try
as much as I can to talk to people and to try common grounds and try
to make things in a way, so that people feel motivated by themselves
(without me forcing them) to cooperate on one thing, instead of each
of us doing things on our own.

> I believe that many people are underestimating the work required to
> have common calculus tasks properly done and that might explain the
> current roadmap of sympy.

Well, since I started sympy and I am still active in its development I
know first hand, that it's very hard to be robust and get all the
corner cases right.

But the last time I tried giac it didn't built and it required several
emails between you and me to get things fixed. That's a show stopper.
With sympy, it's maybe slower, but at least it works. Also having it
in pure Python it has many other advantages, like running on the
google app engine, being native on windows, and similar. But of
course, there are many other use cases, where Giac or Sage are better.

>
>> However, on a positive note, I think this game is not a game with a
>> sum of 1, but rather it seems to me that all Sage, Maxima, SymPy and
>> other packages are getting new users and developers. In the end, all I
>> want is to get the job done and I think it's important to make sure
>> all the packages talk to each other well, and also to try to find
>> common grounds of cooperation, if possible.
>>
>
> Then I hope you will reconsider making sympy interoperable either with
> maxima or giac or both.

Yep. In fact, we always wanted sympy to by interoperable, that's why I
wrote Sage interface code and why we have a simple maxima parser. But
I think the best way is to be interoperable is to work well in Sage
and for maxima and giac to work well in Sage as well.

So, I think I did my part, i.e. integrating sympy in sage (it could
greatly be improved though, but the usual time constrains apply with
me:), and now it's your job (imho) to make giac operable in Sage as
well. Then we can use both packages together.

I am interested in your (or anyone elses) thoughts on this. I would
like to spent my time as efficiently as I could. :)

Ondrej

parisse

unread,
Jun 20, 2008, 10:08:03 AM6/20/08
to sage-devel
> Yes, I am well aware of that. The problem is not in the mrv algorithm
> itself, but in series expansion, which needs to support
> very general series. My original code from a year ago was able to
> handle all the cases you wrote above and it took me about 3 weeks to
> write and debug.
> However, it was built on a little fragile series expansion code.
>
> In SymPy, we were fixing bugs that people discover and need fixed
> urgently, and people don't need these limits often, so that's why we
> were fixing other issues first.
> But it's definitely on my TODO list.
>

And after that, you will have to add support for e.g. sin(x)/x as x-
>inf, or x^n/n! as n->inf, etc. After it's done, you'll have to debug
it, and probably speed it up. Maybe another 2 or 3 months of work.
Same for integration. I didn't look at your arithmetic code (gcd), but
it is most probably very slow compared to maxima or even more to giac.
What about linear algebra, etc. You say you have to write it from
scratch, and people at sage have also to do it. I do of course not
have experience in writing C++/Python interfaces, but how can it be
that it's better to restart from scratch?

> Actually, I think it is easier to write it from scratch than to
> maintain wrappers to maxima/giac/ginac. Remember that I wrote swiginac
> with Ola Skavhaug, so I know what I am talking about. And you can ask
> Sage developers about their opinion on maxima wrappers and why Gary is
> writing symbolics from scratch.
>

Actually I would really like to know why Sage developers prefer to
restart from scratch. I do really believe that they are
underestimating the required work. I have read somewhere that Gary is
an undergraduate. I have nothing against undergraduates, we were all
undegraduates at one time, but assigning this kind of task to *one*
undergraduate is in my opinion a clear sign of an underestimation of
the work/knowledge required to build serious calculus capabilites.

> Well, since I started sympy and I am still active in its development I
> know first hand, that it's very hard to be robust and get all the
> corner cases right.
>
> But the last time I tried giac it didn't built and it required several
> emails between you and me to get things fixed. That's a show stopper.

Why? As soon as after I made the required modifications, it builds
from the source tarball. Building giac with all the optimizations and
libraries is not easy because you must build all the libraries before.
But building giac just with GMP support should not be hard. Did you
try recently?

> > Then I hope you will reconsider making sympy interoperable either with
> > maxima or giac or both.
>
> Yep. In fact, we always wanted sympy to by interoperable, that's why I
> wrote Sage interface code and why we have a simple maxima parser. But
> I think the best way is to be interoperable is to work well in Sage
> and for maxima and giac to work well in Sage as well.
>
> So, I think I did my part, i.e. integrating sympy in sage (it could
> greatly be improved though, but the usual time constrains apply with
> me:), and now it's your job (imho) to make giac operable in Sage as
> well. Then we can use both packages together.
>

I do not consider it to be my job to make giac interoperable with
Sage, it should be a common job that someone in Sage should do
together with me. But it requires first someone within Sage that is
interested to do that work, and it does not seem to be the case right
now. Maybe later, if some of the Sage developers decide that it might
be easier to interface with giac than restart symbolic from scratch
(and even do not want to start with your python project).

root

unread,
Jun 20, 2008, 12:18:12 PM6/20/08
to sage-...@googlegroups.com, sage-...@googlegroups.com
>Actually I would really like to know why Sage developers prefer to
>restart from scratch. I do really believe that they are
>underestimating the required work. I have read somewhere that Gary is
>an undergraduate. I have nothing against undergraduates, we were all
>undegraduates at one time, but assigning this kind of task to *one*
>undergraduate is in my opinion a clear sign of an underestimation of
>the work/knowledge required to build serious calculus capabilites.

I have to second Bernard's comment here. The integration code in Axiom
was written by Davenport, Trager, and Bronstein, all of whom invented
the code as their PhD thesis work. I worked with all three people on
the Axiom project. Axiom represents an estimated 300 man-years of work
over a 23 year period, with funding at an estimated total of $42 million
(back when the dollar was worth something). All three people spent years
working on the project.

The belief that it might be "better" to rewrite this code from scratch
seriously underestimates the time, knowledge, and effort required to
achieve high quality, well tested, trustworthy code.

The code size, time requirements, porting effort and complexity of
making a working interface to systems like Giac, Maxima, or Axiom
is MUCH less than rewriting algebra code from scratch.

I do admit that interfaces lacks the same "street cred" as new algebra
code but Sage would end up with a much higher quality final product.

Tim


Ondrej Certik

unread,
Jun 20, 2008, 11:15:51 AM6/20/08
to sage-...@googlegroups.com
> And after that, you will have to add support for e.g. sin(x)/x as x-
>>inf, or x^n/n! as n->inf, etc. After it's done, you'll have to debug
> it, and probably speed it up. Maybe another 2 or 3 months of work.

Yep.

> Same for integration. I didn't look at your arithmetic code (gcd), but
> it is most probably very slow compared to maxima or even more to giac.

Yep.

> What about linear algebra, etc. You say you have to write it from
> scratch, and people at sage have also to do it. I do of course not
> have experience in writing C++/Python interfaces, but how can it be
> that it's better to restart from scratch?

Because you want to use it using the tools which Sage have chosen,
i.e. Python, C, Cython and you want
it to be maintainable. Also the one who wrote the code usually chooses
the technology, so you should
ask those Sage devs who wrote it, why they didn't chose giac instead.

>
>> Actually, I think it is easier to write it from scratch than to
>> maintain wrappers to maxima/giac/ginac. Remember that I wrote swiginac
>> with Ola Skavhaug, so I know what I am talking about. And you can ask
>> Sage developers about their opinion on maxima wrappers and why Gary is
>> writing symbolics from scratch.
>>
>
> Actually I would really like to know why Sage developers prefer to
> restart from scratch. I do really believe that they are
> underestimating the required work. I have read somewhere that Gary is
> an undergraduate. I have nothing against undergraduates, we were all
> undegraduates at one time, but assigning this kind of task to *one*
> undergraduate is in my opinion a clear sign of an underestimation of
> the work/knowledge required to build serious calculus capabilites.

Other people will join in too. Patches need to be reviewed and I
believe anyone can do solid work. There were high school students
who contributed a very nontrivial fixes to SymPy through google GHOP,
so given that Gary is already undergraduate I don't
see who better should do it. You don't need to understand quantum
field theory to write symbolic manipulation software. :)

>
>> Well, since I started sympy and I am still active in its development I
>> know first hand, that it's very hard to be robust and get all the
>> corner cases right.
>>
>> But the last time I tried giac it didn't built and it required several
>> emails between you and me to get things fixed. That's a show stopper.
>
> Why? As soon as after I made the required modifications, it builds
> from the source tarball. Building giac with all the optimizations and
> libraries is not easy because you must build all the libraries before.
> But building giac just with GMP support should not be hard. Did you
> try recently?

Yes, I tried just now at PMAA08 conference, where they block all
traffic besides port 80 and I was unable to download the code from the
web,
because it is over ftp only
(ftp://ftp-fourier.ujf-grenoble.fr/xcas/giac_unstable.tgz). Well,
that's a show stopper for me. You may criticize me, that I am strict,
but I think I am not. I wanted to use (try) your software right now
and I cannot. So any user who encounters that will immediatelly turn
away.

So I may write you an email to send me the sources in an email, or to
put it somewhere on the web, but that's exactly what I am talking
about -- people
should be able to download it without writing an email to the author. :)

>> > Then I hope you will reconsider making sympy interoperable either with
>> > maxima or giac or both.
>>
>> Yep. In fact, we always wanted sympy to by interoperable, that's why I
>> wrote Sage interface code and why we have a simple maxima parser. But
>> I think the best way is to be interoperable is to work well in Sage
>> and for maxima and giac to work well in Sage as well.
>>
>> So, I think I did my part, i.e. integrating sympy in sage (it could
>> greatly be improved though, but the usual time constrains apply with
>> me:), and now it's your job (imho) to make giac operable in Sage as
>> well. Then we can use both packages together.
>>
>
> I do not consider it to be my job to make giac interoperable with
> Sage, it should be a common job that someone in Sage should do
> together with me. But it requires first someone within Sage that is
> interested to do that work, and it does not seem to be the case right
> now. Maybe later, if some of the Sage developers decide that it might
> be easier to interface with giac than restart symbolic from scratch
> (and even do not want to start with your python project).

Why do you want me to make sympy interoperable with giac if you are
not willing to make giac interoperable with sympy? :)

Just a joke. Well, my experience with Sage developers is that they are
extremely helpful with helping these efforts and answer all questions
I might have.
Did you try to send or do some patch? I am sure Sage devels will help.

On Fri, Jun 20, 2008 at 6:18 PM, root <da...@axiom-developer.org> wrote:
>
>>Actually I would really like to know why Sage developers prefer to
>>restart from scratch. I do really believe that they are
>>underestimating the required work. I have read somewhere that Gary is
>>an undergraduate. I have nothing against undergraduates, we were all
>>undegraduates at one time, but assigning this kind of task to *one*
>>undergraduate is in my opinion a clear sign of an underestimation of
>>the work/knowledge required to build serious calculus capabilites.
>

> I have to second Bernard's comment here. The integration code in Axiom
> was written by Davenport, Trager, and Bronstein, all of whom invented
> the code as their PhD thesis work. I worked with all three people on
> the Axiom project. Axiom represents an estimated 300 man-years of work
> over a 23 year period, with funding at an estimated total of $42 million
> (back when the dollar was worth something). All three people spent years
> working on the project.
>
> The belief that it might be "better" to rewrite this code from scratch
> seriously underestimates the time, knowledge, and effort required to
> achieve high quality, well tested, trustworthy code.
>
> The code size, time requirements, porting effort and complexity of
> making a working interface to systems like Giac, Maxima, or Axiom
> is MUCH less than rewriting algebra code from scratch.
>
> I do admit that interfaces lacks the same "street cred" as new algebra
> code but Sage would end up with a much higher quality final product.

Well, you know what Linus says[1], right. :) If it was that easy as you say,
someone would already did it.

Ondrej

[1] http://lkml.org/lkml/2000/8/25/132

parisse

unread,
Jun 20, 2008, 12:24:06 PM6/20/08
to sage-devel
> > What about linear algebra, etc. You say you have to write it from
> > scratch, and people at sage have also to do it. I do of course not
> > have experience in writing C++/Python interfaces, but how can it be
> > that it's better to restart from scratch?
>
> Because you want to use it using the tools which Sage have chosen,
> i.e. Python, C, Cython and you want
> it to be maintainable.

What makes you believe that a C++ library and an interface are not
maintainable? After all, Sage is relying on C/C++ libraries.


> Other people will join in too. Patches need to be reviewed and I
> believe anyone can do solid work.

I agree. But I believe that developing good code require experience.
And developing code with math algorithm requires a mature
understanding of the math. That's why I don't believe an undergraduate
can develop a CAS from scratch. Maybe I'm wrong, we'll see.

> Yes, I tried just now at PMAA08 conference, where they block all
> traffic besides port 80 and I was unable to download the code from the
> web,
> because it is over ftp only
> (ftp://ftp-fourier.ujf-grenoble.fr/xcas/giac_unstable.tgz). Well,
> that's a show stopper for me. You may criticize me, that I am strict,
> but I think I am not. I wanted to use (try) your software right now
> and I cannot. So any user who encounters that will immediatelly turn
> away.
>

It has nothing to do with the code itself. Binaries are available from
http, if someone is interested, he will make some tests on the
binaries and ask me for the source to be available on http.
It is now available on the web.
http://www-fourier.ujf-grenoble.fr/~parisse/giac/giac_unstable.tgz

> Why do you want me to make sympy interoperable with giac if you are
> not willing to make giac interoperable with sympy? :)
>
> Just a joke.

I never said I would not help you make sympy interoperable with giac.
I have always answered your questions when you had problems to compile
giac. I would be happy to have a python frontend to giac and I'm ready
to help you if you are willing to. Moreover, this is not the same
situation, giac (as maxima or axiom) was here before sympy and sage.

> Well, my experience with Sage developers is that they are
> extremely helpful with helping these efforts and answer all questions
> I might have.
> Did you try to send or do some patch? I am sure Sage devels will help.
>

I won't do anything before someone is really interested. It would be a
waste of time, because I don't know python (and learning python to a
fluent level certainly requires some time), I don't know exactly what
to do and I would not have a reasonable insurance that my library
would be integrated in the sage distribution.

>
> Well, you know what Linus says[1], right. :) If it was that easy as you say,
> someone would already did it.
>

Nobody says it's easy. I just can't see how it could be easier to
redevelop all from scratch.

Ondrej Certik

unread,
Jun 20, 2008, 12:48:05 PM6/20/08
to sage-...@googlegroups.com
On Fri, Jun 20, 2008 at 6:24 PM, parisse
<bernard...@ujf-grenoble.fr> wrote:
>
>> > What about linear algebra, etc. You say you have to write it from
>> > scratch, and people at sage have also to do it. I do of course not
>> > have experience in writing C++/Python interfaces, but how can it be
>> > that it's better to restart from scratch?
>>
>> Because you want to use it using the tools which Sage have chosen,
>> i.e. Python, C, Cython and you want
>> it to be maintainable.
>
> What makes you believe that a C++ library and an interface are not
> maintainable? After all, Sage is relying on C/C++ libraries.

I think C++ is fine too. I think it's just that someone has to be
interested in let's say using giac, and it will happen.
If people are not interested, it will not happen.

>
>
>> Other people will join in too. Patches need to be reviewed and I
>> believe anyone can do solid work.
>
> I agree. But I believe that developing good code require experience.
> And developing code with math algorithm requires a mature
> understanding of the math. That's why I don't believe an undergraduate
> can develop a CAS from scratch. Maybe I'm wrong, we'll see.

Yes, but the limit algorithm is easy to understand. And Gary is
writting the base symbolics, so you don't need some high math to do
that.

>
>> Yes, I tried just now at PMAA08 conference, where they block all
>> traffic besides port 80 and I was unable to download the code from the
>> web,
>> because it is over ftp only
>> (ftp://ftp-fourier.ujf-grenoble.fr/xcas/giac_unstable.tgz). Well,
>> that's a show stopper for me. You may criticize me, that I am strict,
>> but I think I am not. I wanted to use (try) your software right now
>> and I cannot. So any user who encounters that will immediatelly turn
>> away.
>>
>
> It has nothing to do with the code itself. Binaries are available from
> http, if someone is interested, he will make some tests on the
> binaries and ask me for the source to be available on http.
> It is now available on the web.
> http://www-fourier.ujf-grenoble.fr/~parisse/giac/giac_unstable.tgz

Yes I know. But it has something to do with easiness of use. If you
know what I mean.
Managing a project is not just about writing a code, but also making
sure other people can use the code easily.

Anyway I have 5 minutes to try (=make it compile, it's ok if I will
have to wait couple hours, that is unavoidable in some cases, but
without me fixing things), I downloaded it, read README, it said do
"./configure && make && make install" if you are in a hurry, so I did
configure, it said:

Adding link . to giac in src
**** The following problems have been detected by configure.
**** Please check the messages below before running "make".
**** (see the section 'Common Problems' in the INSTALL file)

** The header file for GMP version 2 or above could not be found.

** A test program could not be linked against GMP version 2 or above.


== Enabling debug support

== Disabling gc support

== Disabling semi-classical routines

== GMPXX support not checked (disabled)

deleting cache /dev/null
rm: cannot remove `/dev/null': Permission denied


So I installed libgmp3-dev in Debian, then it configured just fine, so
I did make and it failed immediatelly:

$ make
make all-recursive
make[1]: Entering directory `/home/ondra/ext/giac-0.8.0'
Making all in src
make[2]: Entering directory `/home/ondra/ext/giac-0.8.0/src'
/bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.
-I.. -g -O2 -c sym2poly.cc
mkdir .libs
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I. -I.. -g -O2 -c sym2poly.cc -fPIC
-DPIC -o .libs/sym2poly.lo
In file included from /usr/include/c++/4.3/backward/hash_map:64,
from index.h:27,
from poly.h:26,
from sym2poly.h:24,
from sym2poly.cc:32:
/usr/include/c++/4.3/backward/backward_warning.h:32:2: warning:
#warning This file includes at least one deprecated or antiquated
header which may be removed without further notice at a future date.
Please use a non-deprecated interface with equivalent functionality
instead. For a listing of replacement headers and interfaces, consult
the file backward_warning.h. To disable this warning use
-Wno-deprecated.
In file included from poly.h:26,
from sym2poly.h:24,
from sym2poly.cc:32:
index.h:273: error: expected initializer before '<' token
index.h:275: error: 'hash_index' was not declared in this scope
index.h:275: error: template argument 1 is invalid
index.h:275: error: template argument 2 is invalid
index.h:275: error: invalid type in declaration before ';' token
In file included from poly.h:27,
from sym2poly.h:24,
from sym2poly.cc:32:
monomial.h: In function 'void giac::Mul(typename
std::vector<giac::monomial<T>, std::allocator<giac::monomial<T> >
>::const_iterator&, typename std::vector<giac::monomial<T>,
std::allocator<giac::monomial<T> > >::const_iterator&, typename
std::vector<giac::monomial<T>, std::allocator<giac::monomial<T> >
>::const_iterator&, typename std::vector<giac::monomial<T>,
std::allocator<giac::monomial<T> > >::const_iterator&,
std::vector<giac::monomial<T>, std::allocator<giac::monomial<T> > >&,
std::pointer_to_binary_function<const giac::index_t&, const
giac::index_t&, bool>, std::pointer_to_binary_function<const
giac::monomial<T>&, const giac::monomial<T>&, bool>)':
monomial.h:541: error: expected initializer before '<' token
monomial.h:542: error: 'hash_prod' was not declared in this scope
monomial.h:542: error: expected `;' before 'produit_'
monomial.h:547: error: 'hash_prod' is not a class or namespace
monomial.h:547: error: expected initializer before 'prod_it_'
monomial.h:558: error: 'prod_it_' was not declared in this scope
monomial.h:558: error: 'produit_' was not declared in this scope
monomial.h:565: error: 'prod_it_' was not declared in this scope
monomial.h:565: error: 'produit_' was not declared in this scope
monomial.h:565: error: 'prod_it_end' was not declared in this scope
In file included from sym2poly.h:24,
from sym2poly.cc:32:
poly.h: In function 'int giac::hashdivrem(const
std::vector<giac::T_unsigned<T, U>, std::allocator<giac::T_unsigned<T,
U> > >&, const std::vector<giac::T_unsigned<T, U>,
std::allocator<giac::T_unsigned<T, U> > >&,
std::vector<giac::T_unsigned<T, U>, std::allocator<giac::T_unsigned<T,
U> > >&, std::vector<giac::T_unsigned<T, U>,
std::allocator<giac::T_unsigned<T, U> > >&, const std::vector<U,
std::allocator<_T2> >&, int, double, bool)':
poly.h:87: error: expected initializer before '<' token
poly.h:88: error: 'hash_prod' was not declared in this scope
poly.h:88: error: template argument 1 is invalid
poly.h:88: error: template argument 2 is invalid
poly.h:88: error: invalid type in declaration before '(' token
poly.h:93: error: 'hash_prod' is not a class or namespace
poly.h:93: error: expected initializer before 'prod_it'
poly.h:94: error: 'hashptr' was not declared in this scope
poly.h:109: error: invalid types 'int[int]' for array subscript
poly.h:114: error: 'prod_it' was not declared in this scope
poly.h:114: error: invalid types 'int[int]' for array subscript
poly.h:114: error: 'prod_itend' was not declared in this scope
poly.h:114: error: invalid types 'int[int]' for array subscript
poly.h:161: error: invalid types 'int[int]' for array subscript
poly.h:180: error: invalid types 'int[int]' for array subscript
poly.h:198: error: invalid types 'int[int]' for array subscript
poly.h:202: error: 'prod_it' was not declared in this scope
poly.h:202: error: invalid types 'int[int]' for array subscript
poly.h:202: error: 'prod_itend' was not declared in this scope
poly.h:202: error: invalid types 'int[int]' for array subscript
make[2]: *** [sym2poly.lo] Error 1
make[2]: Leaving directory `/home/ondra/ext/giac-0.8.0/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/ondra/ext/giac-0.8.0'
make: *** [all-recursive-am] Error 2


Now I would have to investigate the first error:

index.h:273: error: expected initializer before '<' token

I.e this line:

typedef HASH_MAP_NAMESPACE::hash_map<
index_t,index_m,hash_function_object > hash_index ;

But I am sorry, my time has run out, I need to go to a conference
dinner now. As you can see, I would have to start fixing the sources.

To repeat again: I am not blaming you, it can well be a problem with
my installation of Debian, but nevertheless this is my (end user)
experience with giac.
If I take Sage or SymPy, on the same installation of Debian, it just works.

>
>> Why do you want me to make sympy interoperable with giac if you are
>> not willing to make giac interoperable with sympy? :)
>>
>> Just a joke.
>
> I never said I would not help you make sympy interoperable with giac.
> I have always answered your questions when you had problems to compile
> giac. I would be happy to have a python frontend to giac and I'm ready
> to help you if you are willing to. Moreover, this is not the same
> situation, giac (as maxima or axiom) was here before sympy and sage.

Yes I know and I thank you for that. GiNaC was there also before SymPy
and actually GiNaC was a reason I started SymPy.

As I said, I don't have time to wrap giac to Sage.

>
>> Well, my experience with Sage developers is that they are
>> extremely helpful with helping these efforts and answer all questions
>> I might have.
>> Did you try to send or do some patch? I am sure Sage devels will help.
>>
>
> I won't do anything before someone is really interested. It would be a
> waste of time, because I don't know python (and learning python to a
> fluent level certainly requires some time), I don't know exactly what
> to do and I would not have a reasonable insurance that my library
> would be integrated in the sage distribution.

Yes, that is the real reason (and it's not your fault). But who better
should do it if not the one who wrote the C++ code?

>
>>
>> Well, you know what Linus says[1], right. :) If it was that easy as you say,
>> someone would already did it.
>>
>
> Nobody says it's easy. I just can't see how it could be easier to
> redevelop all from scratch.

Ok. My point was that the pure fact, that someone wrote the code
already and the code is sitting somewhere (be it in giac, or axiom) is
not enough to be
easily usable by people. Because if it was, people would be using
Axiom and be happy with that. Some people are happy, but a lot of
people aren't, as can be seen by the number of people using Sage.

Ondrej

William Stein

unread,
Jun 20, 2008, 1:54:33 PM6/20/08
to sage-...@googlegroups.com
Hi,

Ondrej, Bernard, and Tim have been sort of arguing in response to
Rob Dodier's nice post... In their discussion they are I think seeing
everything too much in black and white, and missing the shades
of grey. Here's what we actually do in Sage:

1. Identify needed functionality (e.g., compute characteristic
polynomials of matrices, or "symbolic calculus").

2. Find the existing best open source free option that
implements 1, if there is any (e.g., say the pari C library
in the above example, or "maxima" + a very sophisticated
Python interface).

3. Fully integrate 2 into Sage. (Bobby Moretti and I did this
for Calculus, in the above example.)

4. Somebody comes along and points out that 2 is not
optimal and that they can do better. E.g., they have a
new algorithm for computing characteristic
polynomials, or think they can implement a drop in
replacement for symbolic calculus that is in fact much
better.

5. Somebody tries very hard to implement 4. Sometimes they
succeed, and we *switch* over to it, and sometimes they fail,
and the code never goes into Sage. Both happen and that
is fine by me.

This is what is happening with symbolics. In 2005 we identified
Maxima as the best open source system given our constraints.
Bobby Moretti and I spent about 8 months fully integrating Maxima
in as the core of our symbolic calculus functionality in Sage.
Bill Furnish "popped up" and claimed he could do something
much better, and has been working on this for the last 5 months.
If (or when) his code turns out to be clearly better than what is currently
built on top of Maxima in Sage, then it will go into Sage. If not, it won't.

The *only* reason I can see for not going from 4 to 5 in the above
example is that I, or Bobby Moretti, and Maxima authors, or whatever
have big egos and can't stand to see their hard work and code
get thrown away. Well I swallow my frickin' pride and just deal
with it, and have thrown away massive amounts of code I write.
I think that's really the core issue in this whole thread -- some people
are really disturbed by code get thrown away... Well deal with
it. It's much more important to make decisions that are best for the
overall quality of a project and "the community goals" than to
stroke your ego by keeping your own code alive forever.

-- William

Nick Alexander

unread,
Jun 20, 2008, 2:14:08 PM6/20/08
to sage-...@googlegroups.com
> 5. Somebody tries very hard to implement 4. Sometimes they
> succeed, and we *switch* over to it, and sometimes they fail,
> and the code never goes into Sage. Both happen and that
> is fine by me.

+1. It hurts to have your code die -- it has happened to me -- but
sometimes it is best of the project.

Nick

root

unread,
Jun 20, 2008, 4:30:33 PM6/20/08
to sage-...@googlegroups.com, sage-...@googlegroups.com
>I think that's really the core issue in this whole thread -- some people
>are really disturbed by code get thrown away... Well deal with it.

Lets try to avoid ad hominem. Bernard's point is not one of ego. Nor
is mine. Almost all the code I've written in the last 37 years is
gone and I'm thankful for that :-)

In fact, *I* didn't write any of the integration code.
I am not capable of writing Davenport-Trager-Bronstein (DTB) code.

The core issue is, very few people *are* DTB-capable worldwide.
And if you are anywhere near DTB-capable, it would make more sense
to build on top of existing robust, well tested, and high quality
code towers.

>It's much more important to make decisions that are best for the
>overall quality of a project and "the community goals" than to
>stroke your ego by keeping your own code alive forever.

Code *quality* is the key issue. When I see an expert like Paul
Zimmermann involved in the gmp-Sage work, I know from experience
that Paul writes quality code and gmp is well tested. It has been
around a long time and has been widely used. I can make the same
quality argument about Axiom's DTB integration code. Both are
"best of breed".

Bernard's point is that it is much less effort to interface
than it is to rewrite from scratch. "The community" benefits
more from an interface than a rewrite.

But your time is your own.

Tim

parisse

unread,
Jun 20, 2008, 3:11:44 PM6/20/08
to sage-devel
> Ondrej, Bernard, and Tim have been sort of arguing in response to
> Rob Dodier's nice post... In their discussion they are I think seeing
> everything too much in black and white, and missing the shades
> of grey. Here's what we actually do in Sage:
>
> 1. Identify needed functionality (e.g., compute characteristic
> polynomials of matrices, or "symbolic calculus").
>
> 2. Find the existing best open source free option that
> implements 1, if there is any (e.g., say the pari C library
> in the above example, or "maxima" + a very sophisticated
> Python interface).
>

Then there is a natural question arising here: did you really review
all the existing open source CAS at that time and how did you choose?
I don't have an exact picture of the functionnalities of CAS in 2005
but it seems to me that giac/xcas was already in the same class than
maxima (with of course some - and some +) and axiom certainly remains
a leader in symbolic integration.
Then the question is not really "which is the best CAS" because I
believe that the answer will depend on the needs of the user. But I
had the impression that Sage tries to use for each algorithm the best
open-source software. If this is really the objective of Sage, then
you can't have a single answer for CASes. Sometimes it is better to
call axiom, sometimes maxima and sometimes xcas and sometimes maybe
another CAS. Therefore my question: what is the roadmap of Sage for
symbolic computations? Really reimplement from scratch everything,
slowly replacing maxima? Or build interfaces to e.g. axiom or giac or
*put here your favorite open-source CAS* and use the best one
depending on the kind of problem.
If it is the first possibility, then I loose my time here and I'll
have a much better job to speak directly with axiom and maxima
developers if they are interested to discuss with me.

parisse

unread,
Jun 20, 2008, 3:12:01 PM6/20/08
to sage-devel
> Yes, but the limit algorithm is easy to understand. And Gary is
> writting the base symbolics, so you don't need some high math to do
> that.
>

Then who will write the real stuff?

> $ make
> make all-recursive
> make[1]: Entering directory `/home/ondra/ext/giac-0.8.0'
> Making all in src
> make[2]: Entering directory `/home/ondra/ext/giac-0.8.0/src'
> /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.
> -I.. -g -O2 -c sym2poly.cc
> mkdir .libs
> g++ -DHAVE_CONFIG_H -I. -I. -I.. -I. -I.. -g -O2 -c sym2poly.cc -fPIC
> -DPIC -o .libs/sym2poly.lo
> In file included from poly.h:26,
> from sym2poly.h:24,
> from sym2poly.cc:32:
> index.h:273: error: expected initializer before '<' token
> index.h:275: error: 'hash_index' was not declared in this scope
> index.h:275: error: template argument 1 is invalid
> index.h:275: error: template argument 2 is invalid
> Now I would have to investigate the first error:
>
> index.h:273: error: expected initializer before '<' token
>

I guess you are running a version of gcc which is > to 4.2. Someone
else told me about the same kind of error. If this is the case, since
I compile on gcc 4.1 or 4.2 and do not have access to 4.3 or >, it has
to wait. Or you have to compile with gcc 4.1 or 4.2.

> If I take Sage or SymPy, on the same installation of Debian, it just works.

Well, running isympy was not really easy for me. On my laptop, I have
a stable debian distribution from 2005, where python is too old.
Therefore I tried on a server, where python is up to date, but I had a
problem with the output a lot of â for e.g. fraction bars, or nothing
visible for the symbol i you are using for sqrt(-1). I checked with
xterm, uxterm, without luck. Then I got it running with gnome-
terminal.
I believe there is a clear distinction between CAS end-users who
really want binaries with an installer (which I provide for windows,
mac and linux packages so that they don't have install problems) and
developers who should have a little bit of Unix background in order to
solve simple install problems, because their installation might differ
from install where the source has been compiled before. I will of
course do my best so that the compilation process works out of the
box, but I don't think it should be an excuse not to try it further
and collaborate with the author/maintainer to fix the
things.

> > I won't do anything before someone is really interested. It would be a
> > waste of time, because I don't know python (and learning python to a
> > fluent level certainly requires some time), I don't know exactly what
> > to do and I would not have a reasonable insurance that my library
> > would be integrated in the sage distribution.
>
> Yes, that is the real reason (and it's not your fault). But who better
> should do it if not the one who wrote the C++ code?
>

That could be done if there was a document somewhere clearly
explaining how to interact between sage and your library or binary.
Something like the documentation of texmacs for writing plugins. If
something like that exists, I would be glad to have a pointer to it.
Otherwise, I can't do it on my own on a reasonable time schedule.

> Ok. My point was that the pure fact, that someone wrote the code
> already and the code is sitting somewhere (be it in giac, or axiom) is
> not enough to be
> easily usable by people. Because if it was, people would be using
> Axiom and be happy with that. Some people are happy, but a lot of
> people aren't, as can be seen by the number of people using Sage.
>

I do not have exact figures of xcas users, and of course axiom users
or maxima users, but there are definitively many xcas, axiom and
maxima users out there. I agree that xcas lacks developers.

William Stein

unread,
Jun 20, 2008, 3:28:41 PM6/20/08
to sage-...@googlegroups.com
On Fri, Jun 20, 2008 at 12:11 PM, parisse
<bernard...@ujf-grenoble.fr> wrote:
>
>> Ondrej, Bernard, and Tim have been sort of arguing in response to
>> Rob Dodier's nice post... In their discussion they are I think seeing
>> everything too much in black and white, and missing the shades
>> of grey. Here's what we actually do in Sage:
>>
>> 1. Identify needed functionality (e.g., compute characteristic
>> polynomials of matrices, or "symbolic calculus").
>>
>> 2. Find the existing best open source free option that
>> implements 1, if there is any (e.g., say the pari C library
>> in the above example, or "maxima" + a very sophisticated
>> Python interface).
>>
>
> Then there is a natural question arising here: did you really review
> all the existing open source CAS at that time and how did you choose?

We tried.

> I don't have an exact picture of the functionnalities of CAS in 2005
> but it seems to me that giac/xcas was already in the same class than
> maxima (with of course some - and some +) and axiom certainly remains
> a leader in symbolic integration.

Much more than just functionality is important. Number of developers,
users, documentation, build support, "bus factor", popularity (Maxima
is *by far* the most popular open source computer algebra system), etc.

> Then the question is not really "which is the best CAS" because I
> believe that the answer will depend on the needs of the user. But I
> had the impression that Sage tries to use for each algorithm the best
> open-source software. If this is really the objective of Sage, then
> you can't have a single answer for CASes. Sometimes it is better to
> call axiom, sometimes maxima and sometimes xcas and sometimes maybe
> another CAS. Therefore my question: what is the roadmap of Sage for
> symbolic computations? Really reimplement from scratch everything,
> slowly replacing maxima?

Maybe. It depends on what developers actually succeed at doing. Nobody
knows whether or not this will really happen.

> Or build interfaces to e.g. axiom or giac or
> *put here your favorite open-source CAS* and use the best one
> depending on the kind of problem.


Maybe. It depends on what developers actually succeed at doing. Nobody
knows whether or not this will really happen.

> If it is the first possibility, then I loose my time here and I'll
> have a much better job to speak directly with axiom and maxima
> developers if they are interested to discuss with me.

It's certainly a good idea to speak with the axiom and maxima developers.
I love talking with them.

William

root

unread,
Jun 20, 2008, 4:54:58 PM6/20/08
to sage-...@googlegroups.com, sage-...@googlegroups.com
As to the point of "community goals" I have a proposal to make.

Since the stated goal of Sage is to be a viable alternative to
the 4Ms it makes sense to develop a "measure" of how close the
goal is approached.

Maple has a Kamke ordinary differential equation test set.
Maple can do almost all of the ODEs in that set.
How well does Sage do, where is Sage weak, and what needs to be
developed in order to be a Maple alternative?

Bonderenko has a 4000 integral test suite used against Maple and MMA.
How well does Sage do, where is Sage weak, and what needs to be
developed in order to be an MMA alternative?

Axiom has a 619 integral Schaums test suite.
How well does Sage do, where is Sage weak, and what needs to be
developed in order to be a Axiom alternative?

Are there any other major test suite collections available?
Is there one for limits? For finite fields? For linear algebra?
If not, can people be sponsored to collect them?

Perhaps Sage could host a test suite site that shows the results
of running the test suite against the competition. Something like:

Schaums' test suite (619 indefinite integrals)
Axiom: 419 passed,
137 no closed form exists.
60 cannot simplify
2 Schaums typos found
1 Axiom bug found
MMA:
Maple:
Sage:

Kamke test suite
Bonderenko test suite
etc.

Students could be hired to perform the test suite collection and
computation. There can be no question of python-vs-C, ad-hominem,
free-vs-paid, or any other argument.


This is where Sage gets to prove it really is a 4Ms alternative.

Tim

William Stein

unread,
Jun 20, 2008, 3:37:43 PM6/20/08
to sage-...@googlegroups.com
On Fri, Jun 20, 2008 at 12:12 PM, parisse
<bernard...@ujf-grenoble.fr> wrote:
>
>> Yes, but the limit algorithm is easy to understand. And Gary is
>> writting the base symbolics, so you don't need some high math to do
>> that.
>>
>
> Then who will write the real stuff?

There are a lot of Sage developers:
http://lite.sagemath.org/development-map.html

[snip -- weird arguments about whose code is harder to build; this has
nothing to do with sage, and I think should not be discussed here.]

> I believe there is a clear distinction between CAS end-users who
> really want binaries with an installer (which I provide for windows,
> mac and linux packages so that they don't have install problems) and
> developers who should have a little bit of Unix background in order to
> solve simple install problems, because their installation might differ
> from install where the source has been compiled before. I will of
> course do my best so that the compilation process works out of the
> box, but I don't think it should be an excuse not to try it further
> and collaborate with the author/maintainer to fix the
> things.

This belief might be why there aren't very many giac developers.

>> > I won't do anything before someone is really interested. It would be a
>> > waste of time, because I don't know python (and learning python to a
>> > fluent level certainly requires some time), I don't know exactly what
>> > to do and I would not have a reasonable insurance that my library
>> > would be integrated in the sage distribution.
>>
>> Yes, that is the real reason (and it's not your fault). But who better
>> should do it if not the one who wrote the C++ code?
>>
>
> That could be done if there was a document somewhere clearly
> explaining how to interact between sage and your library or binary.
> Something like the documentation of texmacs for writing plugins. If
> something like that exists, I would be glad to have a pointer to it.
> Otherwise, I can't do it on my own on a reasonable time schedule.

This is ridiculous with people telling each other to do something.
Open source is about developers scratching their itch. When somebody
really *wants* to use Giac and Sage, so much that they are willing
to do the work right to make the two work together and maintain it,
then it will hopefully happen. Before then it should not. I don't want
some half-assed interface in Sage from somebody who doesn't care deeply
about *both* giac and sage.

-- William

William Stein

unread,
Jun 20, 2008, 3:52:05 PM6/20/08
to sage-...@googlegroups.com
On Fri, Jun 20, 2008 at 1:54 PM, root <da...@axiom-developer.org> wrote:
> Since the stated goal of Sage is to be a viable alternative to
> the 4Ms it makes sense to develop a "measure" of how close the
> goal is approached.
[specifc test suites]

> This is where Sage gets to prove it really is a 4Ms alternative.

The goal of Sage is to be an alternative to the 4M's in the sense that
it is a viable alternative for *real people* to do what they need to do on
a day to day basis for their research, teaching, and education. This is
best measured by *listening* to real people describe how they
use math software, and specifically what they they really find
lacking in Sage. Pursuing a grand program involving large test
suites is of course very valuable, but it is a much different than
the main goal of the Sage project, and it somewhat ignores the
dynamic nature of real people and their needs.

The mission of the Sage project -- to provide a viable free open
source alternative for every real people to Magma, Maple,
Mathematica, and Matlab -- is not going to change until it
is accomplished.

-- William

root

unread,
Jun 20, 2008, 5:42:48 PM6/20/08
to sage-...@googlegroups.com, sage-...@googlegroups.com

I believe you sidestepped the question. My point is that Sage
makes the claim that it will be a viable alternative to the 4Ms.
In computational mathematics that is a testable claim. So test it.

Or is your claim that *real people* do not care that Sage provides
correct and tested answers to ODEs, integration, limits, etc? Clearly
the 4Ms have shown what they can do. Maple's Kamke test suite answers
give me great confidence that
(a) Maple can handle my ODE needs,
(b) they give correct answers,
(c) they have a much wider range than Axiom and
(d) Axiom gets the right answers for the subset it accepts.
I now know that Axiom needs more extensive ODE algorithms.
If you do ODE work I'd highly recommend Maple over Axiom, at least
until Axiom can prove it is competitiive in ODEs.

It is not a lot of effort. The Kamke test suite took a couple weeks
to test. The Bonderenko suite took about 2 months. The Schaum test
suite took about 2 months (but I had to develop it from scratch).
These are summer tasks for students. They are all in Axiom syntax
but some bright spot could write an Axiom-to-Sage translator and
have the tests running quickly.

I would offer to do it for Sage but I'm busy building a new test
suite for graphics based on the CRC Standard for Curves and Surfaces.
You're welcome to use the test suite when it is complete.

The results would go far toward convincing *real people* who care
about the quality of their computational mathematics software (e.g. me)
that Sage "meets or exceeds" the 4Ms in fundamental areas.

Without some sort of objective measurement (which we ought to expect
from computational mathematicians) the "viable alternative" claim
is just marketing hype. Since I'm confident that Sage is capable of
"meets or exceeds" I think it would benefit the community to test it.

Tim
An occasional "real people", although I have my complex moments.

David Harvey

unread,
Jun 20, 2008, 4:42:07 PM6/20/08
to sage-...@googlegroups.com

On Jun 20, 2008, at 5:42 PM, root wrote:

> I believe you sidestepped the question. My point is that Sage
> makes the claim that it will be a viable alternative to the 4Ms.
> In computational mathematics that is a testable claim. So test it.

<snip>

I think it would be good for someone to test Sage on those suites you
suggest. It's just a question of someone offering to come forward and
do the work!

david

mabshoff

unread,
Jun 20, 2008, 4:47:57 PM6/20/08
to sage-devel
Yes, I did discuss the possibility of sharing test suits with Robert
Dodier while we was at Dev1 and Tim's name also fell since he seems to
have a good overview of what is out there. ODEs and Integration is
currently "farmed" out to Maxima, so any testing of Maxima for now
will improve Sage's performance in that area.

On a general level we in the mathematical community should be willing
to share test suits (even between open and close packages) since
improving the quality of every system out there is a goal worth
pursuing. We might want to open another thread to decouple that
discussion from this thread

> david

Cheers,

Michael

Craig Citro

unread,
Jun 20, 2008, 4:51:41 PM6/20/08
to sage-...@googlegroups.com
>>Pursuing a grand program involving large test
>>suites is of course very valuable, but it is a much different than
>>the main goal of the Sage project, and it somewhat ignores the
>>dynamic nature of real people and their needs.
>>
>> ...

>
> I believe you sidestepped the question. My point is that Sage
> makes the claim that it will be a viable alternative to the 4Ms.
> In computational mathematics that is a testable claim. So test it.
>

I don't think William sidestepped the question. I think he's just
trying to say that having a large test suite is not the *only* measure
for how useful a CAS is. (I'm not trying to say that you're saying
this, either.) Sage has a huge test suite that gets run with every
release, and I'm sure everyone would be *very* excited to see a 700
integrals get added. It would also be nice to have a list of how each
of several CASes do on a large test suite. I think William is just
trying to say that deciding how "good" a CAS is based on how it does
on a specific test suite shouldn't motivate where peoples' energy is
spent.

-cc

root

unread,
Jun 20, 2008, 6:38:42 PM6/20/08
to sage-...@googlegroups.com, sage-...@googlegroups.com
> Sage has a huge test suite that gets run with every release,

Is there an obvious way to collect all of these tests?
I'd like to run them in Axiom

Tim


mabshoff

unread,
Jun 20, 2008, 5:31:00 PM6/20/08
to sage-devel


On Jun 20, 3:38 pm, root <d...@axiom-developer.org> wrote:
> > Sage has a huge test suite that gets run with every release,

I actually run the test suite (which takes about an hour and a half of
CPU time and is about 45,000 input statements) after every patch I
merge.

> Is there an obvious way to collect all of these tests?

I would not say it is obvious how to convert them. There is
infrastructure to extract the tests with their expected results from
the docstrings, but I am no expert on this and somebody else should
fill you in on technical details.

> I'd like to run them in Axiom

On potential possibility would be to improve the Axiom<->Sage
interface and log all the inputs send from Sage. I believe Bill Page
is the author of that code, so maybe he can fill you in how much
functionality of Sage does have the ability to use Axion for its
computation.

> Tim

Cheers,

Michael

parisse

unread,
Jun 21, 2008, 2:27:32 AM6/21/08
to sage-devel

> > I believe there is a clear distinction between CAS end-users who
> > really want binaries with an installer (which I provide for windows,
> > mac and linux packages so that they don't have install problems) and
> > developers who should have a little bit of Unix background in order to
> > solve simple install problems, because their installation might differ
> > from install where the source has been compiled before. I will of
> > course do my best so that the compilation process works out of the
> > box, but I don't think it should be an excuse not to try it further
> > and collaborate with the author/maintainer to fix the
> > things.
>
> This belief might be why there aren't very many giac developers.
>

>
> > That could be done if there was a document somewhere clearly
> > explaining how to interact between sage and your library or binary.
> > Something like the documentation of texmacs for writing plugins. If
> > something like that exists, I would be glad to have a pointer to it.
> > Otherwise, I can't do it on my own on a reasonable time schedule.
>
> This is ridiculous with people telling each other to do something.
> Open source is about developers scratching their itch.

I find this contradictory to the above quote. I expect two levels of
communications:
1/ without having to contact anybdy at sage, something that gives me
an idea where to start, how much work it will require (this is what I
found for building a texmacs plugin)
2/ then I can begin and if I have problems I try to contact for
example this forum (that's what I did with Joris for texmacs).
Same for people who would like to use giac inside one of their
projects; 1/ can be done by testing the binaries capabilites and
getting the source, untar it, see that it should compile with
configure, make, make install. If it doesn't work, he contacts me or
ask a question in the xcas forum.

> When somebody
> really *wants* to use Giac and Sage, so much that they are willing
> to do the work right to make the two work together and maintain it,
> then it will hopefully happen. Before then it should not. I don't want
> some half-assed interface in Sage from somebody who doesn't care deeply
> about *both* giac and sage.

Then I don't see this happen. When I decided to write a plugin for
texmacs, I knew approximatively how much time it would require, and
there was a very positive feedback from the texmacs community, which
was very open to add a plugin for giac. I don't know how much time it
would require for sage, have no guidance, and most importantly, I
don't see any real interest from sage.

Ondrej Certik

unread,
Jun 21, 2008, 5:17:52 AM6/21/08
to sage-...@googlegroups.com
> Then I don't see this happen. When I decided to write a plugin for
> texmacs, I knew approximatively how much time it would require, and
> there was a very positive feedback from the texmacs community, which
> was very open to add a plugin for giac. I don't know how much time it
> would require for sage, have no guidance, and most importantly, I
> don't see any real interest from sage.

But I don't see any real interest from you either, so I don't see any
problem with it.
I am sure that if you decide in the future you really want giac
working in Sage, you will receive feedback and help.

Anyway, I would like to thank all the participants in this long
thread, I enjoyed it and I also learned something new from each of
you.

Let's get back to work.

Ondrej

rjf

unread,
Jun 21, 2008, 12:28:17 PM6/21/08
to sage-devel
Why does anyone rewrite code that apparently already exists?

For myself, I can say this:
Sometimes I don't understand other people's code. It is too
elaborate, too general, uses extra layers of technology, is in a
programming language I am uncomfortable with. Maybe some other
reasons.

Recently I decided to try "skip lists" as a data structure. Using
Lisp. I found several packages. I decided not to use them and wrote
my own 2-page version. I understand my own program. It doesn't do
more than I need.

This apparently happens with other people.

The real problem I see with Sage rewriting is that duplicating the
imported capabilities (or a subset of them) is not progress.
That is, rewriting Maxima in python may be fun, technologically
helpful if you want everything in python, maybe making nice user
interfaces to it .... but is not progress in the sense of expanding
the horizons of what a CAS can compute.

Worse, it is likely to be less capable than Maxima (or ...), since
there may be subtleties that will be missed.

Even worse, in my opinion, it may adopt the same design decisions as
Maxima, including the ERRONEOUS ones, by default.

For example, I have repeatedly pointed out the difficulties of dealing
with assumptions (in Macsyma, Mathematica, Maple).
Duplicating these systems will duplicate the difficulties.

RJF

parisse

unread,
Jun 21, 2008, 12:36:03 PM6/21/08
to sage-devel
> But I don't see any real interest from you either, so I don't see any
> problem with it.

? Why do you think I'm writing here if I really had no interest?

William Stein

unread,
Jun 21, 2008, 1:55:09 PM6/21/08
to sage-...@googlegroups.com

Dear Richard,

I've been thinking about this, and I think I understand your point.
The work on the rewrite of Sage's symbolic calculus code (from full
reliance on Maxima) has until now been a 100% voluntary effort,
and I think people 100% volunteering should get to do as they want
as long as we have ways to keep bad code out.

However, on Monday the people working on this rewrite will instead
be working fulltime for me, and things will change. I will start
by requiring them to create a specification for what they plan
to do -- a "Sage Enhancement Proposal" like this old one:
http://wiki.sagemath.org/CalculusSEP

And we will greatly appreciate your feedback on it.

-- William

Robert Dodier

unread,
Jun 21, 2008, 2:13:50 PM6/21/08
to sage-devel
root wrote:

> Are there any other major test suite collections available?

At present Maxima includes a copy of Michael Wester's test suite
which was the basis for his published review of computer algebra
systems from about 10 years ago. We haven't done anything with it
but I asked for and received permission from him to release it under
terms of GPL and it is now in Maxima CVS.

Wester has test scripts for several programs; Maxima CVS only
contains the Macsyma test scripts.

best

Robert Dodier

root

unread,
Jun 21, 2008, 4:54:06 PM6/21/08
to sage-...@googlegroups.com, sage-...@googlegroups.com, axiom-d...@nongnu.org
>> Are there any other major test suite collections available?
>
>At present Maxima includes a copy of Michael Wester's test suite
>which was the basis for his published review of computer algebra
>systems from about 10 years ago. We haven't done anything with it
>but I asked for and received permission from him to release it under
>terms of GPL and it is now in Maxima CVS.

Yes, I did a set of tests for Michael years ago for the review.
The Axiom version of those tests are in our test suite also.

I'm looking for test suites against "standard" sources (like Schaums,
Zwillinger, Kamke, etc) as well as other large collections of tests
(e.g. Bondarenko). Ideally ALL computer algebra systems should
test against the same published standard sets, a project I call "CATS"
(Computer Algebra Test Suite).

It only makes sense to have a fully vetted version of tests that
people can use against all the systems. These tests should have the
agreed-upon "correct" answers along with commentary about ranges,
branch cuts, etc. Ideally these CATS documents would also present the
algorithms in both mathematical terms and as software implementations.
(I would support Sage's calc rewrites IF they were doing it to present
the algorithms in some literate form for people to reference and
learn. Sadly competition, not science, seems to be the driving
motivation.)

If we can collect such test sets and show that each system generates
equivalent answers (a difficult problem given the zero equivalence
issue), then people can feel SOME confidence that
(a) they are getting reasonable answers
(b) the systems are plug-equivalent

This IS supposed to be computational mathematics and the answers
are testable.

In fact, I believe that NIST should fund such an effort to support
both the quality of computational mathematics and the educational
aspects of showing the "best of breed" computational algorithms.

Tim

Ondrej Certik

unread,
Jun 29, 2008, 7:20:28 PM6/29/08
to sage-...@googlegroups.com
>> If I take Sage or SymPy, on the same installation of Debian, it just works.
>
> Well, running isympy was not really easy for me. On my laptop, I have
> a stable debian distribution from 2005, where python is too old.
> Therefore I tried on a server, where python is up to date, but I had a
> problem with the output a lot of â for e.g. fraction bars, or nothing
> visible for the symbol i you are using for sqrt(-1). I checked with
> xterm, uxterm, without luck. Then I got it running with gnome-
> terminal.

Thanks a lot for the bug report, that's a show stopper indeed, I made it:

http://code.google.com/p/sympy/issues/detail?id=901

Feel free to add any more details to the issue above.

I meant an interest (or having time) in actually doing the job
necessary to get giac in sage.

Ondrej

parisse

unread,
Jun 30, 2008, 4:40:03 AM6/30/08
to sage-devel
> Thanks a lot for the bug report, that's a show stopper indeed, I made it:
>
> http://code.google.com/p/sympy/issues/detail?id=901
>
> Feel free to add any more details to the issue above.
>

BTW, I have also modified giac source, it should now compile with gcc
4.3.1.

> I meant an interest (or having time) in actually doing the job
> necessary to get giac in sage.

As I said earlier, I'm ready to invest time for that, but I can't do
it alone, there must be someone on the python side who has time and
interest to do it with my help.

David Roe

unread,
Jul 1, 2008, 5:51:51 AM7/1/08
to sage-...@googlegroups.com
> BTW, I have also modified giac source, it should now compile with gcc
> 4.3.1.

Excellent!

> As I said earlier, I'm ready to invest time for that, but I can't do
> it alone, there must be someone on the python side who has time and
> interest to do it with my help.

I've seen a lot of acrimonious threads recently about Sage's
relationship with software such as Maxima, Axiom and giac. I think
some of it may result from a misunderstanding about the priorities of
the Sage developers.

Many of us are interested in Sage primarily for computational number
theory, and of those that aren't, only a few are really interested in
working on the kind of symbolic manipulations required for the classic
computer algebra applications of calculus, solving equations, etc.
that are the forte of Maxima and SymPy for example. But when someone
comes along and volunteers to work on making symbolics in Sage better,
we don't tell them no. We let them loose and see what happens. But
there's not a huge developer base within sage working on improving
"symbolics." Currently, it seems to be mostly Gary.

So, where does this leave giac? You're probably no going to find
someone currently involved with Sage who wants to work on it with you.
If you want to further its incorporation into Sage, here's what you
can do. The first step would be making giac an experimental spkg.
Personally, I know very little about the process for doing so: I've
tended to work mostly within the Sage library of Python and Cython
code. But if you log on to the #sage-devel IRC channel you will
likely find someone who can answer questions as they come up. In
particular, I don't think an experimental spkg requires any Python
code.

The second step is to take a look at how Sage interfaces with outside
software. Look through the files in sage.interfaces for examples of
using pexpect to communicate with running instances of other programs
(this is how sage communicates with maxima). Since giac is written in
C++, you can also link to it dynamically and make the functionality
available through Cython. This tends to be significantly more work
than just writing a pexpect interface. Take a look at the wrappers in
sage/libs and the C and C++ code in c_lib for some examples of Sage
using other programs as libraries (eg pari, ntl, mwrank, flint...).

Next, one would make the experimental spkg into an optional one by
making sure that it builds on the platforms Sage supports. You would
also open a trac ticket to incorporate your interface code into the
Sage library. As long as the library code you want to add is well
written and documented, I think we will always welcome the ability to
use more math software from Sage. One of Sage's strength's is the way
it combines many systems, and adding new interfaces always helps with
this. By getting to the optional package stage, you give any user of
Sage the ability to install giac as an optional package and then have
a Python interface to it from Sage.

The final hurdle, getting a package incorporated as standard in Sage,
requires more than just code and effort required of an optional
package. It requires that the proposed package satisfies a number of
requirements, namely (from
http://groups.google.com/group/sage-devel/browse_thread/thread/1c42fb1e4ca32230/7cec80383bd54573?lnk=gst&q=standard+spkg#7cec80383bd54573)
GUIDELINES FOR INCLUSION OF ALL NEW SPKGS IN SAGE

1. GPL version 2 compatible license. (This rule
will be reconsidered in December 2008. I.e., we
might allow GPL v3 only code.)

2. The package must build on our supported architectures:
* Linux x86, x86_64, itanium, ppc
* OS X ppc, intel
* Solaris sparc, x86_64
* MS Windows (or at least a reasonable plan for building in
the near future)

3. Quality: The package should be "better" than anything else (that
passes criteria 1 and 2) 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
* Documentation
* Usability
* Memory leaks
* Maintainable
* Build time
* Size
* Dependencies

4. Interest and Demand:
* JSAGE vote (majority)
* A majority vote on sage-devel.


At every stage of this process, you should be able to find help in
answering questions that come up. Whether you can find someone else
to chip in and contribute to the work depends on who else is excited
about getting giac into Sage. But you should feel free to go ahead
and go through the steps of making giac an optional spkg even if
nobody currently involved in Sage development is enthusiastic enough
to help out. If it's important enough to you to put in the work, go
for it!
David

Ondrej Certik

unread,
Jul 1, 2008, 6:13:46 AM7/1/08
to sage-...@googlegroups.com
> At every stage of this process, you should be able to find help in
> answering questions that come up. Whether you can find someone else
> to chip in and contribute to the work depends on who else is excited
> about getting giac into Sage. But you should feel free to go ahead
> and go through the steps of making giac an optional spkg even if
> nobody currently involved in Sage development is enthusiastic enough
> to help out. If it's important enough to you to put in the work, go
> for it!

Thanks a lot David for writing this up! I can say for myself that I am
interested in having giac in Sage, as it can do some things and do it
fast and it's just good to have different approaches to the same
thing, e.g. giac, maxima, sympy, Gary's symbolics. So that we can get
all of them to equal footing and then see which approach is the most
viable.

I don't have time to do giac.spkg though, but I will test it and
report bugs if you do.

Ondrej

parisse

unread,
Jul 1, 2008, 8:13:48 AM7/1/08
to sage-devel

> So, where does this leave giac?  You're probably no going to find
> someone currently involved with Sage who wants to work on it with you.
>  If you want to further its incorporation into Sage, here's what you
> can do. The first step would be making giac an experimental spkg.
> Personally, I know very little about the process for doing so: I've
> tended to work mostly within the Sage library of Python and Cython
> code.  But if you log on to the #sage-devel IRC channel you will
> likely find someone who can answer questions as they come up.  In
> particular, I don't think an experimental spkg requires any Python
> code.
>

I just tried to compile the latest source of giac on
sage.math.washington.edu with what seems to be the standard method
sage -sh
./configure --prefix="$SAGE_LOCAL" --disable-gui
It works. What is now required to make an experimental spkg? What
should I do with a spkg?

> The second step is to take a look at how Sage interfaces with outside
> software.  Look through the files in sage.interfaces for examples of
> using pexpect to communicate with running instances of other programs
> (this is how sage communicates with maxima).  Since giac is written in
> C++, you can also link to it dynamically and make the functionality
> available through Cython.  This tends to be significantly more work
> than just writing a pexpect interface.  Take a look at the wrappers in
> sage/libs and the C and C++ code in c_lib for some examples of Sage
> using other programs as libraries (eg pari, ntl, mwrank, flint...).
>

That is the part where someone who knows about sage and/or python is
most probably required.

> Next, one would make the experimental spkg into an optional one by
> making sure that it builds on the platforms Sage supports.

Then the natural question is how do I get access to a platform where
it would not build in order to fix things?

> 2. The package must build on our supported architectures:
>    * Linux x86, x86_64, itanium, ppc
>    * OS X ppc, intel
>    * Solaris sparc, x86_64
>    * MS Windows (or at least a reasonable plan for building in
>      the near future)
>

> At every stage of this process, you should be able to find help in
> answering questions that come up.  Whether you can find someone else
> to chip in and contribute to the work depends on who else is excited
> about getting giac into Sage.  But you should feel free to go ahead
> and go through the steps of making giac an optional spkg even if
> nobody currently involved in Sage development is enthusiastic enough
> to help out.  If it's important enough to you to put in the work, go
> for it!
> David

Thanks for your message!
Reply all
Reply to author
Forward
0 new messages