On Sun, Apr 13, 2008 at 9:23 AM, parisse <[EMAIL PROTECTED]> wrote: > Hi! > > I have a couple of questions about Giac/XCas and also you. They are all > over > > the map. Answer what you want and ignore the other questions. > > > > 1. Is this the public svn development server for Giac/Xcas? > > > > http://xcas.svn.sourceforge.net/viewvc/xcas/ > > > > Yes. But it is currently used only as a backup for the source files > and it would require someone with knowledge about autotools to make it > compilable.
OK. > > > 2. Is this the only mailing list for Giac/XCas? > > > > http://sourceforge.net/mailarchive/forum.php?forum_name=xcas-devel > > > > It seems to have only 5 posts in the last 2 years, so maybe it isn't > > the right list. > > > > No, the right list is the Xcas forum > http://pcm1.e.ujf-grenoble.fr/XCAS > It is currently mostly used by some French Xcas users. Thanks. That looks much better. I've added it to my list of math software mailing lists: http://wiki.wstein.org/lists > > 3. Are you the only Giac/XCas developer? If so, why? (I was the only > > Sage developer for a long time...) > > > > I'm currently the only C++ coder. Wow, you have written a huge amount of code for one person. > Renée is writing the documentation > and doing all kinds of tests. There is also Jean-Pierre Branchard who > is working on the online version of giac and other projects using CAS > (like a spreadsheet from a browser). I'm interested in his "spreadsheet from a browser" project, since we plan to do something similar with Sage at some point, probably. Does he intend to embed giac like functionality as formulas in the cells? Does "from a browser" mean an "AJAX application"? > > 4. What exactly is the goal of Giac/XCas? I have looked at your web page > > a lot and slides, etc., but I don't get it. My guess is that you like > > me decided > > to take the amazing range of open source software available -- PARI, > > NTL, GSL, etc., and put them together, then fill in all the > > gaps motivated by a goal to create an alternative to certain > > commercial software. In your case, I'm guessing > > the commercial software that motivated you is Maple, Mupad and the TI-89. > > In my case it was primarily Magma (and perhaps Mathematica later). > > > > The goal is indeed to be an alternative to Maple and also TI > calculators. That's why there is a syntax compatibility mode. You can > for example open maple V.5 worksheets inside xcas, and for common > undergraduate commands, there is even a chance that they will run > without modification. Very interesting. I don't know anything about the structure of Maple worksheets or how to parse them, etc. > This goal is perhaps one of the reason I'm isolated on the coding > side, people simply do not believe that xcas can be an alternative to > maple and people in the CA research field are not interested to "fill > the gap" in areas that are essential to be usable in the education > market. I so understand! I think *now* that there are a lot of talented people who strongly believe that an open source system based on GMP/Pari/etc. *can* be an alternative to maple. I think you're likely right that 'people in the CA research field are not interested to "fill the gap" in areas that are essential to be usable in the education market."' Fortunately there are a lot of people doing work on math software these days who are not in the CA research field. The goal of Sage is to create a free open source viable alternative to Maple, Mathematica, Magma, and Matlab. This means (1) genuinely being an "alternative to Maple" (etc.), and (2) filling the gap in "areas that are essential to be usable in the education market". The goals of Sage are thus very very similar to your goals. And the problem you've faced with lack of interest and support from "the CA research field" have been addressed in the Sage project by simply ignoring that field and getting support from other areas (undergrads, grad students, retired tech workers, researchers not in CA, etc.). I think some people in CA research will come around eventually, though if they don't it won't stop us. > > > > 5. Why does the OS X binary of Giac/XCas not link in PARI? > > > > I had no idea and lacked time to analyse. The fact is that when I > tried to link with pari, I get some strange errors even when working > with integers. Since my current user basis does not require the > advanced arithmetic functions of pari, it's not a priority. I understand. > > > > 6. How much time can you send on Giac/XCas development? (I.e., is > > it your full time research? Your hobby? etc.) > > > > I work on giac/xcas almost full time (that is outside the time I'm > teaching). But a part of my teaching is done with my students using > Xcas, where I get feedback and collect bugs (novice users are some of > the best users for bugs because they try many inputs that expert users > would never try). Same here. I'm very lucky since I'm teaching a course on Sage this quarter: http://wiki.wstein.org/2008/480a > > 7. Is there any connection between Giac/Xcas and Mathemagix, which > > is another French project with perhaps similar goals and strategies? > > > > No connection. I don't know how actively Joris is developping > mathemagix, I have the feeling he has not much time, because of > texmacs. Makes sense; the mathemagix project seems to be going very slowly. > > 8. If I want to build Giac from source, do I need *all* of these libraries > > to be installed first? (Your web page describes these as *both* required > > and recommended in the same line, which is _very_ confusing): > > * GMP > > * MPFR > > * NTL > > * PARI 2.3 > > * CoCoA 0.99 > > * GSL > > * FLTK > > > > No, the only mandatory library is GMP. I recommend you to use the > giac_unstable.tgz source file. I'll check the website... Thanks. > > 9. When did the xcas/giac project start? How long has it been under > > development? > > > > It started about 8 years ago. The first usable binaries were available > around 2 years later. A major rewrite of the xcas user interface began > in 2005. There are today more than 1000 downloads per month on my main > site, mainly from French speaking countries. I hope to get more users > worldwide, now that the user doc is (partially) available in English. > The version number is still < 1, before releasing version 1, I want to > 1/ finish the transition to thread-safe code (with a context pointer > for all functions that require information from the context) > 2/ have enough CAS capabilities to be an alternative at the > undergraduate level (for example I'm currently working on definite > integration and summation). > My target for version 1 is around 2010. <joke> Wow. I hope to be completely done with Sage by then :-). </joke> > > > > 10. The first steps in improving Sage/Giac integration would be: > > (a) create an optional Giac package that doesn't build any of the > FLTK/X11 > > Xcas stuff. It's best if this can build from source easily > > into an existing > > Sage install. > > this should already the case if you configure with --disable-gui. > Since I don't know how to do conditionals in a Makefile.am it will > compile a fake xcas which does just show an error message. The > readline version will of course be functional, except that you won't > be able to display a plot. OK. The way Sage optional packages work is as follows. Image that you install *all* the components of Sage into a single self-contained local directory on your laptop. Then imagine trying to install giac/xcas *into* that local directory. The latter is what we need to be able to do in order to make a giac optional spkg. You could make this vastly easier for us if you (1) installed Sage on a computer from source (2) installed giac into that Sage install by typing ./sage -sh # to set some environ variables and paths then in your giac source directory ./configure --prefix="$SAGE_LOCAL" make make install and *fix* all the problems that come up. Then tell us what steps are needed to build giac into your Sage install. With that info, we could easily make a giac spkg. > > (b) Create a pexpect interace to the command line Giac. This is fairly > > straightforward (and is perhaps similar to making Giac usable > from > > texmacs). > > Since I did it for texmacs, it is certainly easy to do it for icas.cc, > I can add a --sage flag, I just need to know what is the equivalent of > texmacs escape character sequences, like > #define TEXMACS_DATA_BEGIN ((char) 2) > #define TEXMACS_DATA_END ((char) 5) > #define TEXMACS_DATA_ESCAPE ((char) 27) > #define TEXMACS_DATA_COMMAND ((char) 16) Yes, this is exactly the sort of thing that makes this easier. Thanks. > > (c) Create some sort of C/C++ library interface. This is very > > very difficult. > > > > I had some hope that swig could help do the bridge between the C++ > giac library and python, but I never tried. Indeed using swig, etc., could make this easier, but there are serious performance and other issues with using swig for low-level math software. We use Cython instead: http://cython.org/ But yes, there are a lot of tools for making C++ usable from Python. > > > > Just (a), (b) would make it very easy for any Sage user to install giac on > > their system and use it from within Sage to try things out. > > > > To do (a) though requires making it very clear how to build giac from > > source without X support, and also very much clarifying exactly what > > the dependencies of giac really are (exact versions, which are needed, > etc.). > > For any dependency not already in Sage (e.g., cocoa), that dependency would > > have to be removed from giac or added to Sage. > > I'm pretty sure that the required version of GMP for example is > already in Sage. Cocoa is not required, giac configure should build > giac without cocoa support if it is not present. > > > > Getting anything as > > complicated as Giac to build robustly as a Sage spkg (on all the platforms > > Sage supports) is potentially a several week project for somebody working > > full time. It's similar to getting something into Debian, say. Anyway, > that's > > maybe optimistic, since I suspect that Macaulay2 is similar in many ways > > including complexity to Giac, and we *still* do *not* have building > Macaulay > > 2 up to snuff in Sage yet, which is really frustrating > (seehttp://trac.sagemath.org/sage_trac/ticket/10). > > > > I don't know sage, so obvioulsy I can't say how long it would take. > But as explained above, only GMP is required to build giac. Most > optional libraries are in sage and should be compatible with giac. X > support can be disabled, which makes me think that maybe your first > estimate is a little bit pessimistic. Excellent. > > > > > > > Anyway, if I understand much better what the point of Giac/Xcas is about, > > it would help me see whether there is any way in which you can help the > > Sage project and the Sage project can help you and Giac/Xcas. That's what > > the above questions are motivated by. > > > > Thanks for the opportunity to clarify to the sage community. > > Bernard Thanks for answering all of my questions. After reading your answers, here is what I hope will happen: (1) you will spend some time building Sage from source and figure out how to install giac "into" the Sage build directory. This is by far easier for you than for us, probably, since you know the giac build system and code base more than anybody. (2) You'll post an email to sage-devel about (1), and we'll make an optional giac spkg, so that any Sage users can easily install Giac from source by typing "sage -i giac". (3) We'll create a pseudo-tty/pexpect interface to giac, so that giac is usable from the Sage notebook, and experimenting with giac from within Sage is easy. (4) I hope you will continue watching sage-devel and post whenever you have any thoughts or experiences about things we're discussing. Given your goals and background developing giac, it is inevitable that you'll have a lot to offer in regard to experience, etc. Even if there turns out to be no real code sharing between the giac and Sage projects, there are certainly a lot of common problems and solutions ("patterns") which can be shared. At the Enthought/Sage Days in Austin Texas in February, there were a surprisingly large number of discussions about common problems the Enthought/Scipy project faces and the Sage project faces, where no code would or could be shared, but where we benefited a lot from discussing our solutions together. (5) I hope you'll come to a Sage Days workshop sometime. You can see a list of upcoming workshops here: http://wiki.sagemath.org/ Notice that one is in Nancy, France in October. Coming to a Sage Days is by far the best way to find out who "the Sage developers" really are, which is just a bunch of people all over who just want to create awesome free open source mathematical software. - 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 -~----------~----~----~----~------~----~------~--~---
