On Mon, Aug 25, 2008 at 7:42 PM, William Stein <[EMAIL PROTECTED]> wrote: > On Mon, Aug 25, 2008 at 3:08 PM, David Philp <[EMAIL PROTECTED]> wrote: >> On 26/08/2008, at 2:50 AM, William Stein wrote: >> > Burcin -- I did actually mostly implement pattern matching in Pynac. >> >> Is there documentation? A bit of google turned up nothing. > > (1) Let me clarify -- I *wrapped* the pattern matching already in Pynac. > (2) I made up the name pynac about 3 days ago, and released the first version > 15 hours ago. This is code that will be included in Sage. There was > a long sage-devel post about this last night. So I doubt Google will > find anything. Incidentally, Pynac = Ginac + Python - CLN, and you > can read about Ginac at the Ginac website: http://www.ginac.de/ > >> >> sage: sin(1+sin(x)).subs(sin(w0)==cos(w0)) >> cos(cos(x) + 1) >> >> In Mathematica, the result would be cos(sin(x) + 1), since having matched >> the outer expression, the replacement algorithm moves on rather than in. >> One would obtain cos(cos(x) + 1) by making the substitution rule sin==cos. >> Can you do that? Can you evaluate code during the matching of your >> patterns? Can you nest patterns? I think these are highly desirable, even >> if they are suitably carefully hidden from the casual user. > > I didn't implement the pattern matching. I wrapped the pattern matching > that is provided by GiNaC. It is certainly not identical to the pattern > matching in Mathematica, at present. I'm glad you're pointing out some > of the differences between what is in Mathematica and what is in Ginac. > Thanks! > >> We already have a pretty good "symbolic engine" in Sage, maxima does >> quite a good job of solving integrals, limits, etc. The main problem >> with Maxima is that we cannot extend it. >> >> Is "not extending of Maxima" a concrete policy? > > Maxima is definitely not the future of symbolic manipulation *in Sage*: > > (1) Maxima cannot manipulate native Python objects (e.g., real interval > field elements, number field elements, finite field elements); both > Pynac and sympy can. > > (2) Maxima is written in Lisp. This is a total show stopper for most > Sage developers, including me. > > Both apply to Axiom, too, by the way.
Tim Daly just wrote to me off list about this remark: "Users [of axiom] never see Lisp code. I realize you don't like Axiom and don't plan to use it in Sage. But I would ask you to at least keep your facts straight when criticizing Axiom in public. -- Tim" (a) I'm not criticizing Axiom. I'm saying that it doesn't have two properties that are relevant to it being used for a certain aspect of symbolic manipulation in Sage itself, since the original poster seemed to not understand what the issues are. I do not think this makes Axiom (or Maxima) in any way bad -- it's just that they aren't the right tool to solve a certain problem. (b) I do not dislike Axiom. In fact, I really like a wide range of software, including Axiom. (c) I made two claims above which you seem to dispute: (1) Axiom cannot manipulate native Python objects. [[I think this is true]] (2) Axiom is written in Lisp. [[I think there is some truth to this.]] In (2) I didn't say that users use Lisp to work with Axiom, just like they don't use Lisp to program Maxima. But the discussion is about extending the core functionality of the system rather than just writing user-level code, so I thought that was justified. -- William --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
