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/
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.
3. Are you the only Giac/XCas developer? If so, why? (I was the only
Sage developer for a long time...)
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).
5. Why does the OS X binary of Giac/XCas not link in PARI?
6. How much time can you send on Giac/XCas development? (I.e., is
it your full time research? Your hobby? etc.)
7. Is there any connection between Giac/Xcas and Mathemagix, which
is another French project with perhaps similar goals and strategies?
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
9. When did the xcas/giac project start? How long has it been under
development?
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.
(b) Create a pexpect interace to the command line Giac. This is fairly
straightforward (and is perhaps similar to making Giac usable from
texmacs).
(c) Create some sort of C/C++ library interface. This is very
very difficult.
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. 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 (see
http://trac.sagemath.org/sage_trac/ticket/10).
To do (b) is actually quite easy in comparison. It also doesn't
require (a), since it
could be done via working with your binaries (just like texmacs).
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.
William
On Sat, Apr 12, 2008 at 12:44 PM, parisse
<bernard...@ujf-grenoble.fr> wrote:
>
> >
> > Nope, it isn't. After initially switching to GPL V3+ we have decided
> > to remain at GPL V2+ for now. Since we have discussed this quite
> > extensively in the past here is no need to rehash this here. I don't
> > need another drawn out licensing discussion.
> >
>
> Well, I don't see why it is a concern since giac can be relicensed to
> version 2.
>
>
> > > I do so that I can fix bug myself using gdb. Sometimes
> > > in the future, I'll certainly have to make some documentation for
> > > programmers, but I'll move it as a priority only if I'm sure active
> > > developers are using giac.
> >
> > This is certainly a chicken/egg problem. I did revisit risch.[cc|h]
> > and vecteur.[cc|h] and rish.cc was better commented than I did
> > remember. But what I am missing is doxygen style documentation of
> > input and output parameters.
> >
>
> This is the developer doc I plan to write someday, but it is currently
> not a main priority.
>
>
> >
> > Yes, we agree here, too, but we are only interested in factorization
> > here at the moment. Otherwise everything else seems to be covered by
> > other components in Sage.
> >
>
> I believed that you would appreciate to see other developers focus on
> the aspects you do not want to develop themselves, like integration
> which BTW is far more than just implementing the Risch algorithm. If
> you don't see any interest on integrating giac in sage, fine, as I
> said earlier I do not *need* sage, of course I would appreciate
> feedback from their users, but I can continue my way expanding giac
> and integrating the same libraries into giac (as sage does) and
> certainly I will not loose anymore time justifying me here when I read
> the ton of some of your next comments, like:
>
>
> > We are interested in only a small part of the functionality
> > and giac has been looked at in the past [that discuss has happened
> > face to face at Sage Days or in IRC] and we never came to the
> > conclusion that it was worth the effort [i.e. the cost was not worth
> > the effort]:
> >
>
>
> >giac has potential problems [please correct me if I am wrong]:
> >
> > * a low busfactor, i.e. few if not one active developer
> > * no really visible developer community
> > * no public CVS or version control system
>
> Integration into sage would certainly help!
>
> > * unsatisfying documentation
>
> The focus in on xcas user documentation
>
> > * unkown build issues:
>
> of course, since they are unknown. Note however that it is ported to
> mac os and win and arm linux and wince.
>
>
> > * unknown memory leak issues [Did you ever run valgrind? If not I
> > would highly recommend it]
>
> yes
>
>
> > * unknown portability issues: Sun Forte, MSVC, alignment problems,
> > endianess issues,
>
> see arm port. I never cared about sun or msvc.
>
>
> > * small test suite: it seems that there are only the files in $GIAC/
> > check to do some testing. It is only a handful of files compared to
> > 52,000 doctests in Sage.
>
> You would be surprised by the number of bugs that are caught by
> definite integration. Giac is certainly not bugfree but it can be and
> begins to be used as an alternative to maple.
>
>
> >I am sure all of the issues
> > above can be overcame [in case they do exist], but I am not going to
> > work on any of this unless factorization becomes more important than
> > the ports. And I don't see that happening because certain institutions
> > are paying me to port to Solaris and Windows. And if one pays for the
> > band that person decides what music is played.
> >
> > So: What should you do? Start with an optional or experimental spkg
> > and prove me wrong. ;)
> >
>
> That is not the way I see collaboration. I will not do all the work
> myself.
>
>
> >If
> > factorization could be broken out from giac in a reasonably small
> > package (like factory in Singular) we might have something to discuss,
> > but as a whole I do not see this as a good fit.
> >
>
> Obviously factorization depends on all the basic algorithms like gcd,
> polynomials etc. and it can not be isolated easily. And if it's the
> only thing you would be interested in giac, then there is indeed no
> need to continue this discussion :-)
>
>
>
> >
>
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
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:
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
Hi,
parisse wrote:
|> (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.
If your code is heavy on templates, I suggest to try out
Boost.Python[1]. You just need a decent C++ compiler to use it (no
external tools), I use it for my project and it is really a blessing. As
far as I can tell, performance is indistinguishable from C++.
Best regards,
~ Francesco.
[1] http://www.boost.org/doc/libs/release/libs/python/doc/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgDLs0ACgkQFCtI0YdDCEs0kACgv2MtXfUOCNG+Eme0K6fscozk
l10AnRvyCut47zTvS+YLebw/j6C3xQkp
=1uWd
-----END PGP SIGNATURE-----
Which libraries does it check for that a standard system won't have?
I guess I'll find out.
On OS X my build fails with:
In file included from gen.h:39,
from sym2poly.h:25,
from sym2poly.cc:32:
vecteur.h:25:28: error: gsl/gsl_vector.h: No such file or directory
vecteur.h:26:28: error: gsl/gsl_matrix.h: No such file or directory
vecteur.h:27:33: error: gsl/gsl_permutation.h: No such file or directory
In file included from sym2poly.cc:36:
In file included from sym2poly.cc:36:
modpoly.h:27:30: error: NTL/ZZXFactoring.h: No such file or directory
modpoly.h:28:20: error: NTL/ZZ.h: No such file or directory
modpoly.h:29:22: error: NTL/GF2X.h: No such file or directory
modpoly.h:30:32: error: NTL/pair_GF2X_long.h: No such file or directory
modpoly.h:31:31: error: NTL/GF2XFactoring.h: No such file or directory
I guess this is Giac not finding GSL, NT, etc. Your autoconf
seems to have options to enable/disable GSL, NTL, etc., but I can't
tell wout to specify exactly *where* those libraries are installed
on the system (for Sage, they are in $SAGE_LOCAL).
On one Linux machine that I tried the buld *does* work, perhaps
because so much is installed system-wide on that machine.
The spkg I made is here:
http://sage.math.washington.edu/home/was/tmp/giac-0.7.4.spkg
this is really a tar bz2 file, so you can extract it with
tar jxvf giac-0.7.4.spkg
It took 31 minutes to build giac/xcas, and the build appears to work:
sage: !giac
Help file aide_cas not found
// Unable to find keyword file doc/en/keywords
Added 0 synonyms
Welcome to giac readline interface
(c) 2001,2007 B. Parisse & others
Homepage http://www-fourier.ujf-grenoble.fr/~parisse/giac.html
Released under the GPL license 2.0 or above
See http://www.gnu.org for license details
-------------------------------------------------
Press CTRL and D simultaneously to finish session
Type ?commandname for help
0>> 2+3
5
// Time 0
> You might have an error doing make install if latex2html is not
> installed. If you don't want to install latex2html, an easy fix is to
You're right, we definitely can't assume that latex2html is installed.
(Note: latex2html has a non-GPL-compatible license; we also
use it for the sage docs, since Python did, but I regret this dependency.)
> comment the recursion in Makefile.am from the doc subdirectory, the
> first two lines should look like
> doc/Makefile.am
> #SUBDIRS
> #DIST_SUBDIRS
> then run
> automake
> in the giac directory and then
> ./configure --prefix="$SAGE_LOCAL" --disable-gui
> Another way to fix this is to run make install from the src
> subdirectory only.
> Or maybe add a fake latex2html command somewhere in your path. I don't
> know what the sage build process can handle best. Any suggestion?
Best is probably only running make install from the src subdirectory.
That's what I've done in the above spkg.
Very good.
Do you have any mirror sites of the complete giac/xcas webpage?
-- William
I got past the above OS X problems by setting CXXFLAGS, CFLAGS,
and LDFLAGS as you suggest. But then the build bombs out with this:
...
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I. -I..
-I/Users/was/build/sage-3.0.alpha1/local/include -c global.cc -o
global.o
global.cc: In function 'bool giac::my_isnan(double)':
global.cc:2245: error: '__isnand' was not declared in this scope
global.cc: In function 'bool giac::my_isinf(double)':
global.cc:2249: error: '__isinfd' was not declared in this scope
make: *** [global.lo] Error 1
Error building GIAC/XCAS
real 1m32.451s
...
I can get you an account on an OS X box if you want to help with
porting Giac/Xcas to OS X. Or, if you have os x you could try
to install the spkg below, then fix things until it works.
The latest spkg with the above path changes is at
http://sage.math.washington.edu/home/was/tmp/giac-0.7.4.spkg
It builds on linux but not os x.
>
>
> > On one Linux machine that I tried the buld *does* work, perhaps
> > because so much is installed system-wide on that machine.
> >
> > The spkg I made is here:
> >
> > http://sage.math.washington.edu/home/was/tmp/giac-0.7.4.spkg
> >
> > this is really a tar bz2 file, so you can extract it with
> >
> > tar jxvf giac-0.7.4.spkg
> >
> > It took 31 minutes to build giac/xcas, and the build appears to work:
> >
> > sage: !giac
> > Help file aide_cas not found
>
> That means the short help file has not been installed or in an non-
> standard place. Hence ?keyword will not work. Standard place is
> $PREFIX/share/giac/ where $PREFIX is usually /usr/local but may be
> modified at ./configure time. Giac should detect be able to detect it
> from the full path binary name (but I've not tested non standard
> installation path).
>
Yep, that's all because I only do make; make install inside
the src/ subdirectory (not the docs). This is to avoid the
latex2html dependency that you warned me about.
>
> > // Unable to find keyword file doc/en/keywords
>
> This is the same kind of error, this time for localized synonyms of
> commandnames. That should not affect English users.
>
>
> > > comment the recursion in Makefile.am from the doc subdirectory, the
> > > first two lines should look like
> > > doc/Makefile.am
> > > #SUBDIRS
> > > #DIST_SUBDIRS
> > > then run
> > > automake
> > > in the giac directory and then
> > > ./configure --prefix="$SAGE_LOCAL" --disable-gui
> > > Another way to fix this is to run make install from the src
> > > subdirectory only.
> > > Or maybe add a fake latex2html command somewhere in your path. I don't
> > > know what the sage build process can handle best. Any suggestion?
> >
> > Best is probably only running make install from the src subdirectory.
> > That's what I've done in the above spkg.
> >
>
> Ok, I'll try to find a way to install the short help file when running
> make install from the src directory.
>
>
> >
> > Do you have any mirror sites of the complete giac/xcas webpage?
> >
>
> Not currently.
>
Would you like to have one on sage.math.washington.edu?
If nothing else, giving you some server space/bandwidth on
the other side of the world would be a good way for our
projects to work together...
-- William