>root wrote: >> You let the enemy use your own strength against you. The Axiom front >> end is the same as the Axiom back end. It's all "of a piece" so that >> viewing the documentation and the code are all a single thing. When >> you read the documentation like a book (ala Knuth or Queinnec) you >> learn the whole system. The 3Ms cannot do this. And Axiom equations >> need to carry the type because that's where the meaning is. Thus >> mathml isn't a reasonable transfer mechanism and cannot be trojaned.
Arthur wrote: >I found your Sun Tsu analysis interesting. I have been thinking that >I would eventually write a content mathml package for Axiom partly >because of discussions I've seen here. However I have also wondered >"why bother, i.e. why not just let Axiom handle the semantics?" Now >you've added a new (for me) slant. Do you think content mathml would >amount to a Trojan horse? I think that content mathml is a very difficult problem where a lot of effort goes to die. Consider what it might mean to take the semantics of an expression in Axiom, box it up, export it, import it into nM, re-export it to content mathml, and then re-import it into Axiom, whole and intact. Expressions like E=MC^2 are icons. They have no meaning of themselves and are just pictures to remind us of the meaning. All of the meaning exists in the surrounding paragraphs. Most systems manipulate these icons thinking they are doing mathematics. Axiom captures the semantics of an expression (or tries to) in the type information. Think of the type as the "paragraphs surrounding the icon containing the meaning". Is 3 an integer or a number from primeField(7)? nM, and almost every other system, has no way to represent the meaning. Content mathml tries to create these kinds of meaning using external libraries. Unfortunately these get lost once the expression is imported since the internals have no way to carry the information around or keep it accurate. At best I can see content mathml as a storage mechanism but I can more easily do that in Axiom by writing out the lisp data structures. Mike Dewar has done a lot of work in this area and might have more well thought out opinions. Tim _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer