> > This is the developer doc I plan to write someday, but it is currently > > not a main priority. > > Sure, I understand that and since it is your time it is your call how > you allocate your resources. But it would make it much easier for us > to wrap the library if documentation existed. >
That's why I plan to do it if I have a reasonable hope that people will use it. > > For use integration == Risch and limits == Grunt, they are not to be > taken literally. > Ok, but in fact the Risch algorithm is for most input never called, because other heuristics give much faster and more usable output. And definite integration adds other code. > Well, that reflects my personal opinion and around here we prefer to > be honest. After discussing GIAC in IRC right after your original post > I waited a while for somebody else to jump into the discussion and/or > volunteer to do some work. That didn't happen, so instead of just > ignoring you I wrote my honest opinion on things. Email certainly > isn't the best medium for discussion between people who don't know > each other and I had no intention of offending you personally or say > bad things about your code. > Ok, let's forget about that. > > William did look at GIAC way back before he selected Maxima for Sage > years ago. One of the issues was build support. Another one was that > it didn't seem to have a large community. Not much seems to have > changed in that regard. On the developer side that's correct, but it's slowly changing on the user side (I mean people using giac under xcas). > So if you start providing things like a devel > mailing list, a public svn/hg/git it would give people a chance to > become involved. There are plenty of people around here who lurk and > might have taken a look at GIAC as a consequence of this discussion. > There is a phpbb2 forum for giac/xcas (mainly used for xcas today) and a svn at sourceforge. The svn is currently used only as a backup. > > > * unknown memory leak issues [Did you ever run valgrind? If not I > > > would highly recommend it] > > > yes > > Good. > As an answer to your next post, I used valgrind a few times and it helped me correct a few bugs, but I have no idea how to handle the kind of output you copied. About the linkage of the static binaries (using a provided libstdc++), it is the result of user problems installing xcas_root.tgz: the current binaries have the advantage of being usable on almost every Linux PC. Debian and Ubuntu users may install a common debian package which is dynamically linked with the libstdc++, but again for the user's convenience, all the additionnal libraries (like NTL, pari, cocoa, etc.) are statically linked in. Xcas users are *not* expert Linux users (well most of xcas users are not Linux users at all). > > > * unknown portability issues: Sun Forte, MSVC, alignment problems, > > > endianess issues, > > > see arm port. I never cared about sun or msvc. > > Well, hear I would have really preferred to hear something like "I am > glad to integrate changes you might provide". > Maybe my sentence was not clear (English is not my mother language...) I thought it was obvious that I would make any reasonable change in the source code to make giac compatible with other compilers, but that I would not take care myself of other compilers than gcc. > > 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. > > Sure, but with any complex system changes on one end can cause > potential issues in other places. I'm well aware of that, but in my experience, many of them will interact with the integration code and will therefore be caught by testintegrate (testlimit is also a good checker). >I am not > implying your code is buggy, I am just saying that I would prefer a > large test suite because that is how we caught numerous build issues > in for example eclib. > I fully agree, giac needs more tests. It's just that I do not have much time, I have to choose what I do. > Sure, the idea behind Sage is collaboration, but somebody has to get > the ball rolling. And that is usually the developer behind the code or > a Sage person who is interested in the functionality. Since nobody has > stepped up so far [that might change] the ball is in your court. > I hope someone will be interested, since I don't have time to do that alone myself, and it would most probably be a loss of time if nobody is interested. But of course I'm ready to work together with someone who knows what to do on the sage side. > I know that, but as Singular shows with libfactory it can be done. I > don't consider this discussion to be not worth your time. If you > consider that certain other features of GIAC are better than anything > else in Sage we need to know about them. It is your code, so you > should be able to tell us what to look at. I.e. a solver of non-linear > systems would also be interesting. I do not pretend that feature xyz of giac is better than anything else in the open-source world, it's just that giac provides *today* many interlinked features that one expects in a CAS (by "one", I mean a typical math user, not someone doing research in a very specialized computer algebra topic), and that it seems some sage ressources are/ will be devoted to write code for features that are already available in giac. Hence I asked me why don't they link against giac to focus on new functionnalities? That of course does not mean sage should not write their own code for such features, but it's not that urgent and it could be done in such a way that both sage and xcas could benefit. Bye, Bernard --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
