http://www.mapleprimes.com/posts/36818-Axiom-Vs-Maple en-us 2026 Maplesoft, A Division of Waterloo Maple Inc. Maplesoft Document System Wed, 10 Jun 2026 22:18:15 GMT Wed, 10 Jun 2026 22:18:15 GMT The latest comments added to the Post, Axiom vs Maple http://www.mapleprimes.com/images/mapleprimeswhite.jpg http://www.mapleprimes.com/posts/36818-Axiom-Vs-Maple http://www.mapleprimes.com/posts/36818-Axiom-Vs-Maple?ref=Feed:MaplePrimes:Axiom vs Maple:Comments#comment63886 <p>I have seen this, and I will post something real -- later.</p> The latest comments added to the Post, Axiom vs Maple 63886 Wed, 26 Aug 2009 18:27:13 Z JacquesC JacquesC http://www.mapleprimes.com/posts/36818-Axiom-Vs-Maple?ref=Feed:MaplePrimes:Axiom vs Maple:Comments#comment63887 <p>I don't have such a comparative review, but as far design ideas for future development,<a href="http://www.cas.mcmaster.ca/~carette/publications/JLM_May29_09.pdf"> I have plenty</a>.&nbsp; And they are based on my knowledge of the history of CASes.&nbsp; I have 2 Master's students polishing their (defended, accepted) theses who have worked on implementing parts of that, I should be able to post a link to their work soon.</p> <p>As far as weak/strong types go, with so many years of experience behind us, the answer is turns out to be rather simple: strong types work realy well when you know what you're doing (i.e. there is strong theory underpinning your work), and are a huge hindrance when you don't.&nbsp; In practice, this means that logic, algebra and functional programming can all be strongly typed, but analysis, geometry and imperative programming can't (yet).&nbsp; Don't get me wrong: the abstract theory of analysis, geometry and even imperative programming are well established; the gap is that the theory of 'computation' over specific objects isn't.&nbsp; In other words, Calculus is well-founded, but doing calculus-like computations on representations of functions (i.e. expressions) isn't.&nbsp; There is no adequante 'denotational semantics' for calculus. </p> <p>As far as writing a comprehensive comparison of these two systems, it's a good idea, but not something I&nbsp; am likely to do 'soon'.&nbsp; I have a non-trivial backlog of work that I've done that I still have to write up properly, and so I have tried quite hard to not start too many new projects before a few of the old ones are written up.</p> <p>Thanks for the reminder about types and properties.&nbsp; It's triggered a link in my head with stuff I am currently looking at.&nbsp; My colleague Bill Farmer coined some good terminology to do with partial functions: they have an 'apparent domain' as well as an 'effective domain'.&nbsp; When you say, for example, that the domain of (x:numeric) -&gt; 1/x is 'the reals', you are really describing the apparent domain, since 0 is not in fact in the 'effective domain' (of real-valued functions).&nbsp; But can, fruitfully, use 'type' for the 'apparent domain' and 'property' for 'effective domain'!&nbsp; The principal reason for making a difference between them is that we can thus have a decidable type system but an undecidable property system, and still keep everyone happy.</p> The latest comments added to the Post, Axiom vs Maple 63887 Thu, 27 Aug 2009 17:52:17 Z JacquesC JacquesC http://www.mapleprimes.com/posts/36818-Axiom-Vs-Maple?ref=Feed:MaplePrimes:Axiom vs Maple:Comments#comment63888 <p>No, I did not mean whether you have a review, or will write it shortly, but just&nbsp; when fit, hopefully before 30 years...<br /> <br /> I could catch only part of the material in those slides because of the CS<br /> jargon, but I was a bit surprised by the historical link Maple -&gt; Sage as I<br /> had thought that the main influence on Sage came from some other CAS.<br /> <br /> The way you put the issue of weak vs strong types sounds a bit funny to me. By<br /> those terms, in Physics research it is not know what is being done: at<br /> exploring new ground, most likely, a strong underpinning mathematical theory<br /> is missing.<br /> <br /> And, as Physics deals mainly with analysis and geometry, it sounds that a<br /> strong types will become, most frequently, a hindrance. Something like the<br /> less typed the better.<br /> <br /> This issue might help also to explain why I find Axiom so hard to understand<br /> and make something useful with it, as it was developed by (and fits well into)<br /> minds more familiar with fields like logic or algebra. I.e. &quot;strong typed minds&quot;.<br /> <br /> In this regard I have seen that a (qualitative/semiquantitative?) measure of the<br /> &quot;degree of typing&quot; was sometimes posed, as in these articles (<a href="http://www.tcl.tk/doc/scripting.html#921216">ref1</a>, <a href="http://en.wikipedia.org/wiki/Programming_language#Typed_versus_untyped_languages">ref2</a>).<br /> <br /> And here and there I have seen that CAS were sorted after such a magnitude. E.g. <a href="http://lists.nongnu.org/archive/html/axiom-developer/2005-09/msg00211.html">this post </a>suggests the following order:<br /> <br /> <b>Maple &lt; Mupad &lt; Axiom<br /> <br /> </b>If this order makes any sense, I wonder where other systems lay. Indeed I<br /> was a bit surprised at reading in the Wikipedia article <a href="http://en.wikipedia.org/wiki/Comparison_of_programming_languages">Comparison of programming languages</a> that Mathematica has a strong<br /> type strength (and no mention of Maple, by the way).<br /> <br /> I cannot get you wrong as. I have no idea of what the abstract theories of<br /> analysis, geometry and imperative programming are. Most likely, whatever I<br /> have ever done are computations with specific objects.<br /> <br /> I do not understand either when you talk about 'denotational semantics'. If you<br /> mean something like stated in <a href="http://en.wikipedia.org/wiki/Denotational_semantics">this article</a>, I am perplexed. I read:</p> <blockquote><i> Broadly speaking, denotational semantics is concerned with finding mathematical objects that represent what programs do. </i></blockquote> <p>Al least for a mathematical system like Maple, this issue seems to me<br /> upside-down. What I want is a computational representation of (some)<br /> Mathematics (and as faithful as possible). What is the point of inventing a<br /> mathematical representation of a routine for calculus that outputs<br /> mathematical nonsense? (like several ones in Maple do).<br /> <br /> I guess that what you say about a &quot;decidable type system&quot; is related to these<br /> two articles (<a href="http://en.wikipedia.org/wiki/Decidability_(logic)">ref3</a>, <a href="http://en.wikipedia.org/wiki/List_of_undecidable_problems#Problems_in_analysis">ref4</a>). But I do not see why that 'apparent domain' is decidable while the 'effective domain' is not. Is there a proof for that?</p> <p>&nbsp;</p> The latest comments added to the Post, Axiom vs Maple 63888 Sat, 12 Sep 2009 08:48:34 Z jakubi jakubi http://www.mapleprimes.com/posts/36818-Axiom-Vs-Maple?ref=Feed:MaplePrimes:Axiom vs Maple:Comments#comment63889 <p>Take a look at Sage's syntax and its leveraging of Python -- that is very Maple-like.&nbsp; The fundamentals of the language (Python + Sage extensions) are quite close to Maple's, as is the paradigm of using an interpreted language to 'script' a set of fast base functions.&nbsp; While the Sage developers may now be influenced by other systems, their basic system is essentially a copy (at the design level) of Maple, whether they like it or not.&nbsp; Personally, I find this very disappointing, since we've learned a lot about how to build CA software in the last 25 years!</p> <p>Current research in parts of Physics does strike me very much as weakly typed.&nbsp; This certainly allows you to experiment a lot more, since you don't need to be concerned with small stuff like &quot;making sense&quot;...&nbsp; </p> <p>Over the years, I have seen the benefits of both certainty (through solid foundations) and free-for-all experiments.&nbsp; I am interested in building something which allows both.&nbsp; And, by the way, the only 'solid foundations' systems (as far as I am concerned) that are 'real' are <a href="http://coq.inria.fr/">Coq </a>and <a href="http://www.cl.cam.ac.uk/research/hvg/Isabelle/">Isabelle</a>; there are a number of smaller systems with solid foundations, but their libraries are too small to be interesting.&nbsp; Of course, both those systems are notoriously hard to use as well as being quite slow for doing computations.</p> <p>The <a href="http://www.tcl.tk/doc/scripting.html#921216">degree of typing</a> picture you refer to is quite good.&nbsp; To be more precise, at 'static' typing, which means typing at 'compile time'.&nbsp; The languages I like these days (Haskell and O'Caml) would fit best in the extreme upper right corner (although, to be fair, <a href="http://wiki.portal.chalmers.se/agda/">Agda 2</a> would be even further out).&nbsp; Maple would fit right in between Tcl/Perl and VB, fairly high up [not always a good thing].&nbsp; That Mupad is more typed than Maple and Axiom further still is indeed true.&nbsp; Mathematica is essentially the same as Maple, as is Macsyma on the 'types' scale.&nbsp; The Wikipedia article is very misleading because it does not differentiate between static and dynamic typing!&nbsp; On the dynamic typing scale, Maple is extremely strongly typed -- its type system is Turing-complete!</p> <p>As far as denotational semantics is concerned, you are correct, it does seem backwards!&nbsp; But that is the fundamental issue with symbolic computation -- it is all about <a href="http://en.wikipedia.org/wiki/Intensional_statement">intensional statements</a> being interpreted as if they were actually <a href="http://en.wikipedia.org/wiki/Extension_(semantics)">extensional</a>.&nbsp; People use Maple as if it were about actual mathematical objects, while what Maple really does is 'symbol shuffling'.&nbsp; You need strong reflection theorems to show that these coincide.&nbsp; And we know that these indeed coincide for first-order logic and algebra, and these theorems are 'unknown' for analysis and geometry (even though lots of counter-examples are well-known to naive reflection theorems).</p> The latest comments added to the Post, Axiom vs Maple 63889 Tue, 15 Sep 2009 05:51:03 Z JacquesC JacquesC http://www.mapleprimes.com/posts/36818-Axiom-Vs-Maple?ref=Feed:MaplePrimes:Axiom vs Maple:Comments#comment63890 <p>This phrase &quot;<i>'static' typing, which means typing at 'compile time</i>'&quot; makes me wonder how does this concept apply to Maple non-compiled usage. I see also <a href="http://en.wikipedia.org/wiki/Type_system#Static_typing">this sentence</a>:</p> <blockquote><i> In static typing, types are associated with variables not values. </i></blockquote> <p>As I am not aware of any documentation on this subject, some guesses follow, by interpretation of these statements.</p> <p>The kernel routines are compiled, and <b>?type</b> states:</p> <blockquote><i> The simplest types are the surface types. These are generally defined in the Maple kernel, and represent superficial or top-level properties of expressions. </i></blockquote> <p>and <b>?type/surface</b> states:</p> <blockquote><i> Most of the system types are surface types since these are encoded in the top node of the expression tree. </i><i>Thus <br /> type({ .. }, set); </i><br /> <i>type([a] + [b,c], algebraic); <br /> Both return true regardless of the types of the components of the set in the first case, and regardless of the types of the terms of the sum in the second. </i></blockquote> <p>So, it sounds like surface types are static.</p> <p>And may be that this concept of static types could be stretched to some types defined in the standard library. E.g. container types like <b>type/Matrix</b>, independent of the values asigned to the objects they contain.</p> <p>Now, names are not declared a static type, and their types will depend on what was assigned to them. However, protected names, in particular system ones, have a fixed value as long as the protection holds. Can their types also be labeled as static?</p> <p>So, something like the rest would be purely dynamic types. But I do not understand what do you mean by the statement that their system is Turing-complete. Something like a universal Turing machine can be simulated by Maple type routines alone?</p> <p>And I wonder about the actual comparison method that allows saying that A is more strongly typed than B.</p> The latest comments added to the Post, Axiom vs Maple 63890 Tue, 29 Sep 2009 04:34:03 Z jakubi jakubi http://www.mapleprimes.com/posts/36818-Axiom-Vs-Maple?ref=Feed:MaplePrimes:Axiom vs Maple:Comments#comment63891 <p>Where you mention the &quot;container&quot; type 'Matrix', you might mean 'rtable' (which, unlike 'Matrix', is in the kernel as a constructor). Consider,</p> <pre> &gt; b := Array(1..2,1..2,[[1,2],[3,4]]); [1 2] b := [ ] [3 4] &gt; b.b; # elementwise [1 4] [ ] [9 16] &gt; rtable_options(b,subtype='Matrix'); # change its type &gt; b.b; [ 7 10] [ ] [15 22] &gt; rtable_options(b,subtype='Array'); &gt; b.b; [1 4] [ ] [9 16] </pre> <p>acer</p> The latest comments added to the Post, Axiom vs Maple 63891 Tue, 29 Sep 2009 17:55:56 Z acer acer