Hi Bernard, etc.:

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
<[EMAIL PROTECTED]> 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

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

Reply via email to