53 views

Skip to first unread message

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

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

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...
> 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:

>

>

> 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
> 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.

>

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.

>

maxima or giac or both.

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

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-
> 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.

>

>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.

>

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.

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.

>

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).

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.

>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

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.

>>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

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
> > 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.

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.

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.

>

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 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.

>

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.

>

redevelop all from scratch.

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.

<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

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

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.

> 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

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.

>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

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
> 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).

>

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.

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?
> writting the base symbolics, so you don't need some high math to do

> that.

>

> $ 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

> 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
>

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

>

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.

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?

>

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.

>

or maxima users, but there are definitively many xcas, axiom and

maxima users out there. I agree that xcas lacks developers.

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?

<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

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

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?

<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

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]> 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.

> 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

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.

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

Jun 20, 2008, 4:47:57 PM6/20/08

to sage-devel

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

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.

>>

>> ...>>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

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

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,

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?

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

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

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
> > 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.

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.

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.

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.

> 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

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

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

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?> problem with it.

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

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
> Are there any other major test suite collections available?

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

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.

>

>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

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.

>

> 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

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
>

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

>

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

>

4.3.1.

> I meant an interest (or having time) in actually doing the job

> necessary to get giac in sage.

it alone, there must be someone on the python side who has time and

interest to do it with my help.

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.

> 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

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!

> 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

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.

>

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...).

>

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.

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!> 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

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu