> Even at 10 minutes with no optimization > that seriously tests my patience. And 72 minutes with > optimization is real deal breaker. >
! > > (c) Did you first look at the giac.info page? > > I don't know what that is. However, I expect to be able > to cd to the source directory, start looking around, and make > progress. I was very pleasantly surprised by how well > this worked with ginac, which certainly passes that test. > info documentation can be accessed with the info program or inside an emacs session (Ctrh-H I if the info file is installed or Ctrt-U Ctrl-H I otherwise). giac.info is also available as HTML from my webpage. It is not up to date but it gives an introduction that will greatly help everyone who wants to program with giac. I strongly recommend to look at it before looking at the source code. > > > (e) Perhaps. From my own experience, it is not easy to enter into a > > large library (e.g. cocoa, pari, etc.). > > I don't know what you mean here. Pari is also a fairly unpleasant > library to work with. Ginac is one of the better ones I've seen, similar > maybe to NTL which is also quite good as far as usability goes. > PARI is terrible to use as a library. > I didn't find NTL that easy to use. Perhaps it depends on the code style of the reader and writer. I had a look at singular 2 years ago, and I did not find it easy at all (and it was not available as a library anyway). I didn't look at ginac recently, but I did 8 years ago when I started giac. At the beginning giac was based over ginac, I first wrote a polynomial library extension with ginac since it had (and still does not have stable) factorization code. Then I decided to abandon ginac, since I didn't like to use cln and I could not access easily to the underlying symbolic representation for the conversions. Maybe it's because I do not really master C++, but I find much easier to have union and explicit type information in a structure like giac::gen. > > (a) is not recevable since I could relicense it to GPL v2. Anyway, it > > is highly improbable that you could take code slices without taking > > almost all of the library. Higher level code depends on the low level > > routines and data structures (e.g. rational fraction integration from > > multivariate polynoms) + many parts are interconnected (e.g. > > integration requires linear algebra) which BTW makes modularization > > difficult. > > This nicely illustrates issues with using giac for sage. Again, it is > not to say that giac is "bad"; just that it isn't suitable for my purposes. > I believe it will take time to really modularize a CAS library in independant components. Of course it's cleaner. You will end up requiring the same amount of code. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
