On March 26, 2007 6:07 PM Ondrej Certik wrote; >... > Bill Page wrote: > > Yes, isn't that the way things go in computer algebra - > > everyone seems to write their own? :-( That's a pity. If what > > you really want to do is physics, then it's a trap that many > > people have fallen into. It took me a long time to get over > > that stage. > > Well, it depends. You cannot stay at that, you need to get some > real results, otherwise it's of course nonsense to create anything > from scratch. But SymPy, besides fun (which is very important) > also allows me to play with the differential geometry already. > And I like it. I like to play with ideas, so I think it was not > a lost time. >
I am not against you having fun. As an end in itself and as a by-product of something else, that is fine. But even if you do get some novel results after building a new tool, I would argue that in almost every case you would be further ahead if you had invested the same amount of time in learning to properly use (and perhaps extend) some existing system. > > To sum it up: It would be nice to have an open source alternative > to Maple/Mathematica, that is reasonably fast (maybe written in > C++), could be easily extended with your own ideas, would be > callable from python and could be used in real world problems > (as Maple/Mathematica can). Such open source alternatives already exist, e.g. Axiom and Maxima. They are both written in Lisp and modern Lisp implementations are certainly "reasonably fast", arguably perhaps as fast as C++. And the Sage project demonstrates that these can be made callable from python: http://www.sagemath.org At the SymPy website http://code.google.com/p/sympy you quote the GiNaC developers: > ... > Why not use CAS with its own language (like Maple / Mathematica / > Maxima) is best described by: http://www.ginac.de/FAQ.html#whynotmaple >> Q: What was the problem with Maple? >> >> A: First of all: Maple is a wonderful product. Yes, it is. >> However, when you start writing large-scale applications you >> are doomed to run into trouble with it unless you are extremely >> careful and know exactly what you are doing. This is true of any large application in any programming language. If you want to argue that it is a matter of degree, then I think you are splitting hairs. Compared to advances in computer hardware, software technology lags very far behind. It is the constraint in any large project no matter what tools you choose. >> One important problem with Maple (and any other CAS) is the >> lack of a standardized up-to-date language. For instance, the >> concept of Object Oriented design is not present. Quite >> generally, facilities for encapsulation are poorly developed. That is simply not true. Most standardization in programming languages occurs by de facto adoption despite efforts by various standards organizations. Maple has permitted coding in an object oriented manner since release 9 (see Maple modules). It could be easily argued that Axiom (alias ScratchPad) applied the concepts of object-oriented design and polymorphic type systems almost two decades before these were even recognized as interesting programming paradigms by the rest of the computer science and mathematics communities. So up-to-date is largely a matter of perspective or else Axiom was and still remains ahead of it's time. >> Maple's language is dynamically scoped and from time to time >> you find that Maple's developers messed up with that by not >> properly declaring variables to be local resulting in obscure >> (history-dependent) bugs. How are we supposed to write >> scientific software with the language even the Maple developers >> have problems to handle? Mathematica and Macsyma face the same >> problem, by the way. Yet this is exactly the kind of problems that the designers of Axiom were trying to avoid. >> >> Rather than pointing out a number of Maple's linguistical >> and structural weaknesses let us ponder about one simple >> fact. The purpose of symbolic computation is to "simplify" >> mathematical expressions so that we can more easily understand >> their structure or code them more efficiently for numerical >> evaluation by a computing machine. I *very* strongly disagree with this statement as the main purpose of symbolic computation. At best it is only one possible purpose. Simplification is too ambiguous and subjective a concept. What is simple and easy to understand by one person may not be simple or easy to another. As far as I am concerned the purpose of symbolic computation is to accurately and correctly do by computer some of what mathematicians do when they manipulate mathematical objects. In a very real sense all computation done by modern digital computers is symbolic. The only distinction that I can make between symbolic computations and numeric computation is that the former is almost always concerned with exact results while the later is usually concerned with approximate results. >> Most beginners simply use their Computer Algebra tool by >> typing in some expression and then tell the system to "simplify" >> it, usually by a command with that name. This is fine, so far. >> However, when several people embark on a large-scale project >> that relies considerably on symbolic computation, it is >> unacceptable. This is because whenever somebody codes simplify >> (expression) somewhere, this is a demonstration of his inability >> to understand what's going on. This is very unclear. It seems to me that the main reason that beginners are so interested in simplification is usually because they wish to show (or even prove) that some presumably unintuitive equality holds. They rely on the expression manipulation performed by the simplification routines to be exact in the sense of preserving the mathematical correctness of the result while reducing these expressions to some sort of canonical form. The problem is that it can be shown that this problem is undecidable in general and can be carried out effectively only in certain well defined domains. >> Does he really want to "simplify" a rational function by >> cancelling a greatest common divisor from numerator and >> denominator? Or maybe he really only wants to expand an >> expression and later collect for some variable? When the CAS >> manufacturer ships the next release of his product, such calls >> to "simplify" are doomed to break. Sure, CAS do an amazing >> job at simplifying results. But since nobody ever defined >> what "simple" really means the next release might come up >> with different (though still hopefully correct) results. This >> frequently leads to subtle errors that are very hard to debug. >> When you start a large-scale program involving Computer Algebra, >> it is a good idea to memorize this: "simplify" is evil. Actually Axiom takes exactly this philosophy. As a result it's "simplify" operation is comparatively "weak" in comparison to most other general purpose computer algebra systems. Instead Axiom goes to considerable length to represent in detail what is meant by a "domain" of computation. Equality is one of the operations exported by particular domains. More on this later. > ... > What surprises me, that there are not already some examples > of such usage of Axiom, as I think those are things that > everybody wants to play with at the beginning. > There is quite a large literature about Axiom. See the bibliography and some collected articles here: http://portal.axiom-developer.org/refs > > But I do hope that it will be possible to build new systems > > based on past experience and previous investments rather > > than repeating past mistakes and re-inventing the wheel. > > What I can say from my own experience - the time I spent > implementing some particular algorithms (limits, series > expansion, gcd or square free decomposition of polynomials) was > completely negligible compared to time spent inventing and > designing the interface. I took GiNaC as a starting point, but > I improved things that I didn't like on it (removed unnecessary > classes etc). From Axiom I can just learn how to do some > particular symbolic algorithm, but as I said - this is not a > problem, as what SymPy does so far is very trivial from the > mathematical point of view. I am not sure what you mean by "From Axiom I can just learn how to do some particular symbolic algorithm.". Specific algorithms are only a part of the problem. Axiom goes very much beyond that. > > What is not trivial is how to actually represent everything, and > that is an area, where no one actually knows how to do it. In fact that is exactly the point that is being addressed by Axiom. Axiom does provide (at least in principle) the means to represent everything. I disagree that no one knows how to do it. I think the Axiom designers showed very clearly how many areas of advanced and abstract mathematics could be coded and represented in a computer in addition to the more pedestrian concerns of data structures and algorithms. > So even if the only contribution of SymPy is that we actually > showed that the CAS can be done this way, it will be good. What do you think is novel about the way that SymPy implements computer algebra? > > I learned however how not to do things - I am in no way trying > to reinvent some new (better) language, even if that language was > actually better than Python. Actually, all the languages turned > out to be worse (Maple/Mathematica/Maxima). I think the concept of better and worse are too vague and subjective. You need to state clearly the objectives and find a way to quantify the differences between languages. I think this is a very difficult problem. > Maybe Aldor will turn out to be better, but currently, from the > technical point of view it isn't (many bugs, almost nonexistent > user base, not open source, etc.). Aldor is the 2nd generation Axiom library compiler language but it is not quite yet available as open source, although many people do have to it by individual request to aldor.org. SPAD is the first generation language and it is available with Axiom. Over 1300 mathematical domains are currently implemented in SPAD so I think there is good reason to believe that it is suitable for very large scale projects. Aldor improves on SPAD in several ways and the aldor.org website promises that Aldor will be available as open source very soon now. > Your argument is, that it is not important the language is not > widespread, but rather that it is the best option for a CAS. I think SPAD and Aldor are much better suited to describing mathematics for the purposes of computer algebra than any other programming language now in common use. Since the accurate representation of mathematical objects and the efficient coding of mathematical algorithms is central to the goals of computer algebra, I do think they are the best option for a CAS. > But then you are immediately creating an obstacle for newcomers. > It has it's advantages, I understand that, but it also has a > lot of disadvantages. > That is true. But one thing to note that at least in general form, i.e. syntax and data structures, SPAD and Aldor and the Axiom library are actually very similar to Python and were implemented as much as 20 years earlier than Python and similar languages. > SymPy is going to be a library in a standard widespread language. > We chose Python. So I think we are not reinventing a wheel. What "wheel" are we talking about? The programming language or the computer algebra system? Much of what you are trying to do with SymPy does indeed look like re-invention to me. > We are just trying to bring the CAS to masses, if I can use > this expression. :) > No, I doubt very much if this is possible, at least not any more than it is possible to bring advanced abstract mathematics to the masses. It takes years to appreciate the value of doing certain things certain ways and at least part of this is based on often unstated cultural and historical biases. Regards, Bill Page. _______________________________________________ Axiom-mail mailing list Axiom-mail@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-mail
