[sage-devel] Re: presentation about Maxima at Sage developer days
> 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! --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
> 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
> 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-deve
[sage-devel] Re: presentation about Maxima at Sage developer days
> 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. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
>> 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. On Sat, Jun 21, 2008 at 6:36 PM, parisse <[EMAIL PROTECTED]> wrote: > >> 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? I meant an interest (or having time) in actually doing the job necessary to get giac in sage. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
> 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? --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
> 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
> > 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. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
On Jun 20, 3:38 pm, root <[EMAIL PROTECTED]> 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
> 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
>>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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
On Jun 20, 1:42 pm, David Harvey <[EMAIL PROTECTED]> wrote: > 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. > > > > 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! 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
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. 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
>> 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. 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. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
On Fri, Jun 20, 2008 at 1:54 PM, root <[EMAIL PROTECTED]> 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
On Fri, Jun 20, 2008 at 12:12 PM, parisse <[EMAIL PROTECTED]> 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
On Fri, Jun 20, 2008 at 12:11 PM, parisse <[EMAIL PROTECTED]> 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
> 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. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
> 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. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
>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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
> 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
On Fri, Jun 20, 2008 at 6:24 PM, parisse <[EMAIL PROTECTED]> 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, std::allocator > >::const_iterator&, typename std::vector, std::allocator > >::const_iterator&, typename std::vector, std::allocator > >::const_iterator&, typename std::vector, std::allocator > >:
[sage-devel] Re: presentation about Maxima at Sage developer days
> > 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. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
> 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 <[EMAIL PROTECTED]> wrote: > >>Actually I would really like to know why Sage developers prefer
[sage-devel] Re: presentation about Maxima at Sage developer days
>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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
> 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). --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
On Fri, Jun 20, 2008 at 12:45 PM, parisse <[EMAIL PROTECTED]> wrote: > >> 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) 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 t
[sage-devel] Re: presentation about Maxima at Sage developer days
> 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. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: presentation about Maxima at Sage developer days
On Wed, Jun 18, 2008 at 4:56 PM, Robert Dodier <[EMAIL PROTECTED]> wrote: > > 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. 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
