http://www.mapleprimes.com/posts/128489-10-Tips-For-Writing-Fast-Mathematica-Code en-us 2026 Maplesoft, A Division of Waterloo Maple Inc. Maplesoft Document System Fri, 12 Jun 2026 21:57:37 GMT Fri, 12 Jun 2026 21:57:37 GMT The latest comments added to the Post, 10 Tips for writing fast Mathematica code http://www.mapleprimes.com/images/mapleprimeswhite.jpg http://www.mapleprimes.com/posts/128489-10-Tips-For-Writing-Fast-Mathematica-Code http://www.mapleprimes.com/posts/128489-10-Tips-For-Writing-Fast-Mathematica-Code?ref=Feed:MaplePrimes:10 Tips for writing fast Mathematica code:Comments#comment128493 <p>In 9, what do you mean by a 'let ... in' statement?</p> The latest comments added to the Post, 10 Tips for writing fast Mathematica code 128493 Thu, 08 Dec 2011 12:52:14 Z Joe Riel Joe Riel http://www.mapleprimes.com/posts/128489-10-Tips-For-Writing-Fast-Mathematica-Code?ref=Feed:MaplePrimes:10 Tips for writing fast Mathematica code:Comments#comment128495 <p>A number of languages have a statement that looks like</p> <p><code>let x = computation in expression</code></p> <p>This x is an abbreviation for the result of the computation, it is not a 'variable', in the sense that it cannot be assigned to.&nbsp; Such an x is <em>immutable</em>.&nbsp; Immutable variables can be implemented much more efficiently than mutable variables; even better, they are thread-safe.</p> <p>If you look at a lot of Maple programs, you'll notice that quite a lot of the assignments are in fact done only once, so that if they were done via a 'let', this would allow the interpreter to deal with them more efficiently.</p> The latest comments added to the Post, 10 Tips for writing fast Mathematica code 128495 Thu, 08 Dec 2011 18:00:04 Z JacquesC JacquesC http://www.mapleprimes.com/posts/128489-10-Tips-For-Writing-Fast-Mathematica-Code?ref=Feed:MaplePrimes:10 Tips for writing fast Mathematica code:Comments#comment128536 <p><a href="http://www.mapleprimes.com/posts/128489-10-Tips-For-Writing-Fast-Mathematica-Code#comment128495">@JacquesC</a> Thanks.&nbsp; I'm familiar with the <strong>let</strong> function from lisp (emacs-lisp, actually) and would welcome a similar construct in Maple. Lisp's let binding is not immutable and I cannot comment on any efficiency advantages, but as a user I find it exceptionally convenient to be able to locally declare variables. It's not clear, though, that a let-expression would be as useful (programming-wise) if the bound variables were immutable, particularly in a mainly imperative language (which Maple is).</p> The latest comments added to the Post, 10 Tips for writing fast Mathematica code 128536 Fri, 09 Dec 2011 06:18:52 Z Joe Riel Joe Riel http://www.mapleprimes.com/posts/128489-10-Tips-For-Writing-Fast-Mathematica-Code?ref=Feed:MaplePrimes:10 Tips for writing fast Mathematica code:Comments#comment128540 <p>1) My advice in Maple on this would be to keep the floats and the exact symbolics separate. Use exact symbolics alone, for whatever part of the task demands it. And if at any point you switch over to float-numerics, then try to switch over entirely for that subtask. Keep the mixed float &amp; exact symbolics separate where possible, and if it seems like you have to then... re-think the code.</p> <p>2) Jacques' comment isn't quite fair. It's not the same to say, "if you're doing numerics, then try to compile" and "you better compile". And Maple is behind Mathematica in areas like auto-compiling for plotting and numeric solving. Mathematica has been doing that to various degrees, invisibly and behind the scenes, since v.2.2 I think. Maple's only doing it broadly with the much less fast evalhf interpreter, and only specifically auto-compiling inside dsolve/numeric. Even in the case that the Maple user Compile's the function, there is still a signifcant portion of avoidable overhead when using that to plot, fsolve, Minimize, etc. (This deserves a blog, for plotting. And another, for external wrapper topics.)</p> <p>3) As Jacques says, documentation is key here. But not just nitty-gritty details in existing help-pages. There's a big need for more take-a-step-back-what's-your-goal-big-picture documentation.</p> <p>4) The revised <a href="http://www.maplesoft.com/support/help/Maple/view.aspx?path=ProgrammingGuide">Maple 15 Programming Manual</a> is a bit more coordinated that its predecessors, with respect to start-to-finish programming. I mean, the <a href="http://www.maplesoft.com/support/help/Maple/view.aspx?path=ProgrammingGuide/Chapter15">chapter</a> on debugging and profiling and (new, heavens!) testing code fits together more. It still needs to be at least four times as long, but that's natural. It says a lot, I think, that the long debugger section of that chapter is (without mentioning it much) based on the commandline interface. Which is good because the popup graphical debugger that launches from the Standard GUI is almost devoid of virtue. The primary reason that profiling and debugging are not commonplace is that <em>programming</em> itself has become a bit of a dirty word in the Maplesoft corporate mindset. This (IMHO) is a rather North American manner of marketing: to show that new item A is good it is necessary to behave as if any alternative B is bad. So "clickable math" gets marketed by supressing programming, even though programming is Maple's <em>greatest strength</em>.</p> <p>5) I agree that remembering values requires understanding of the mechanisms, but disagree that it always requires expert knowledge. As member PatrickT suggested, if you remember to remember then don't forget to forget. If it were so important to not remember too much, then why (after decades) are there so few tools for finding and clearing such internal tables? Also, how much of Jacques' comment about greater slowdown with greater memory allocation is relevant more to Maple's stop-dead-to-mark-and-sweep style of memory manager?</p> <p>6) Maple's own Library is mostly not thread-safe. So this restricts one to entirely user-defined + kernel builtins. The Task model is more convenient. But memory management needs work, for this to be in Maple's top-20.</p> <p>7) I've always been fascinated that Mma makes so much of Reap and Sow, while in Maple it seems that you'd pretty much have to cobble together your own, and they might not be that useful to you. Jacques' take on this seems to relate to computational complexity of data-building, but Maple's top-10 should include this more generally. O(n^2) vs O(n) for list/set building, sure. But also for computation. This might be the #1 item.</p> <p>Jacques writes, "..why do the designers make it so darned easy to write bad code?" One partial answer is that it is misplaced subservience to users' "wishes for convenience". People sometimes want something easier than `seq`, and are given `$` whose difference they often don't understand and get into difficulty. The same for `||` vs `cat`. Even `unapply` is merely a powerful convenience, which gets abused when it is treated like candy. That's why code like this gets written, and used in some deeply nested loop,</p> <pre> proc(x,y) unapply(F(x,y),[a,b]); end proc </pre> <p>It's why Components have associated code sections without a well-considered evaluation model. It's why the triple-exclamation-mark button exists, so that people don't so easily get the performance benefits of procedures' evaluation model. It's why <a href="http://www.maplesoft.com/support/help/Maple/view.aspx?path=DocumentTools%2fRunWorksheet">RunWorksheet</a> and <a href="http://www.maplesoft.com/support/help/Maple/view.aspx?path=DocumentTools%2fRetrieve">Retrieve</a> exist.</p> <p>Another partial answer is the misplaced notion that users cannot handle the truth, which is deemed too complicated or scary. This is why only `sum` (and not `Sum` or `add`) appears on the Expression palette. Why there is no good, honest, do-this-not-that programming practices guide. It's why help-pages don't use uneval quotes around unprotected names as optional parameter keywords. It's why help-pages use the form package[routine] instead of package:-routine even though <a href="http://www.maplesoft.com/support/help/search.aspx?term=colondash">?colondash</a> makes package[':-routime'] tragicomic.</p> <p>In a Maple with only `sum` on the Expression palette people are far more likely to try things like,</p> <pre>CodeTools:-Usage( plot(sum( a^(3^i)-a^(2^i), i=1..infinity), a=0..0.1) );</pre> <p>instead of,</p> <pre>CodeTools:-Usage( plot(Sum( a^(3^i)-a^(2^i), i=1..infinity), a=0..0.1) );</pre> <p>8) See 7).</p> <p>9) Jacques is being a little unfair to Mathematica here, I think. Mma's pattern matching is a strength: powerful and useful. It doesn't disparage that functionlity to say don't eat it like candy. The same is true of bits of Maple, eg. `unapply`. If the rule were more like, "don't do steps that you can't justify or don't understand at all" then people might do this less often,</p> <pre> ... deep in some loop ... f := unapply(expr,x); G( f(x),... ); # where `f` is used nowhere else. </pre> <!--break--> <p>10) If this were Maple's top-10 list then it'd be easier to find at least ten good suggestions. For pure numerics, I'd also suggest&nbsp;<em>try to act in-place on Matrices/Vectors/Arrays.</em> Which brings me to,&nbsp;<em>save on memory management time by producing less transient, collectible garbage</em>, which is applicable to both numerics and symbolics. Time and time again those principles have brought me great savings when trying to tune code.</p> <p>acer</p> The latest comments added to the Post, 10 Tips for writing fast Mathematica code 128540 Fri, 09 Dec 2011 12:34:25 Z acer acer http://www.mapleprimes.com/posts/128489-10-Tips-For-Writing-Fast-Mathematica-Code?ref=Feed:MaplePrimes:10 Tips for writing fast Mathematica code:Comments#comment128570 <p><a href="http://www.mapleprimes.com/posts/128489-10-Tips-For-Writing-Fast-Mathematica-Code#comment128536">@Joe Riel</a> : I think I like the idea of a 'let ... in ...' statement and I'd probably use it frequently. It would potentially lead to very high levels of nesting, I imagine, which would be an issue for aesthetical reasons - I would probably request to have your maplev-mode not indent the blocks inside these statements. I wonder whether the memory manager could be made to take advantage of the immutability of these guys. Maybe it would also be nice to have a way to close multiple let... in... scopes at once. (It's interesting to note the difference with the <a href="http://www.maplesoft.com/support/help/view.aspx?path=use">?use</a> statement, by the way, which creates only a temporary binding (not even a real name) for an expression - it doesn't evaluate the expression at the beginning of the statement, but does so every time it is referenced.)</p> <p>On the whole I agree with Jacques' comments regarding option remember. I think we now have a slightly better approach with <a href="http://www.maplesoft.com/support/help/view.aspx?path=CacheOption">?option/cache</a> in that it can't grow arbitrarily out of control as easily in terms of memory <em>usage</em> overhead, but it can still be tricky in terms of memory <em>access</em> overhead (and other overhead, and considerations such as mutable data structures and side effects).</p> <p>Erik.</p> The latest comments added to the Post, 10 Tips for writing fast Mathematica code 128570 Sat, 10 Dec 2011 00:20:15 Z epostma epostma http://www.mapleprimes.com/posts/128489-10-Tips-For-Writing-Fast-Mathematica-Code?ref=Feed:MaplePrimes:10 Tips for writing fast Mathematica code:Comments#comment128572 <p>acer's comments are really thoughtful.&nbsp; I generally agree with them, even where they seem to contradict what I said; this can easily be explained: my own comments were a little too brief to appropriately deal with the true complexity of the situation in a number of cases (think of some of my comments as a caricature of the situation, based largely on truth, but also containing obvious inaccuracies, largely put there for effect).</p> <p>I will only comment on a few points, where it seems valuable.&nbsp; If I don't comment, it is because I agree (including point #2 above where acer says I am being unfair to Mathematica!).&nbsp; In some places, I agree <strong>wholeheartedly</strong>, in particular his point #4.&nbsp;</p> <p>Point #5: there are few tools for 'forgetting' because the modern way to remember (option Cache) handles this very well already.</p> <p>Point #7: Mathematica seems to 'get' functional programming (which is what Reap and Sow really are, they are basic combinators from functional programming) better than Maple, which can't quite seem to shake its procedural heritage, even though it has seq/map and a few other similar primitives.&nbsp; If you teach people the 'right' primitives and downplay to procedural ones, better code would be written.&nbsp; It made a certain amount of sense (in 1980!) to have the Maple language be Algol/Pascal-like, since those were the prevalent ideas at the time.&nbsp; But in 2011, procedural is really no longer the prevalent paradigm; in fact, even OO is slowly declining.&nbsp; Functional and model-based are in high ascendancy.&nbsp; Maple is actually very well placed to 'play' in both of these arenas (unlike OO, where the few features that were added to Maple to make it more OO friendly luckily never really took off).&nbsp; Of course, MapleSim is as model-based as it gets (good!).&nbsp; In fact, and this is quite amusing to me, the underlying denotational semantics of MapleSim, as I learned recently, are <em>relational</em> rather than functional [think Prolog].&nbsp; At the model-based level, this makes a lot of sense.&nbsp; At the 'programming' level, one generally wants more control (because of predictability).</p> <p>The comment about "misplaced subservience to users' wishes for convenience" is very interesting.&nbsp; In my own work, I have been thinking about this very hard.&nbsp; A few of those thoughts have been published in the paper <a href="http://imps.mcmaster.ca/doc/hlt.pdf">High Level Theories</a> with Bill Farmer.&nbsp; (There are slides of talks, some by Bill, some by myself, which I should also put up which expand on this theme.) The basic idea is to create a layered system, with the lowest layers being 100% aimed at highly trained, expert developers, and the highest layer being 100% aimed at a non-programmer user, with intermediate layers serving as compromises in between.&nbsp; The error that acer points out is to pervert the low-level language for user convenience, as well as to pervert the user-interface with programming concepts.&nbsp; I do not believe that there exists a palatable compromise that serves both audiences well, so it is better to not try.</p> <p>Regarding #9 (pattern matching): completely agree.&nbsp; The problem here is that there is a huge disconnect between the marketing of the feature and the reality of what you get when you <em>program</em> with it.&nbsp; Because the innards of how pattern-matching are not known or documented, it is impossible to predict how such programs will work.&nbsp; And it is very well known that pattern-matching based programs (in general, this is not specific to Mathematica, but is true of all term-rewriting) are extremely hard to control/predict/etc.&nbsp; And it does generalize to other areas where the actual cost of the routine (like unapply) is not well understood.</p> <p>Regarging #10 and <span>&nbsp;<em>save on memory management time by producing less transient, collectible garbage</em></span>: I would love to know how to do this.&nbsp; I currently don't really know how to do this.&nbsp; The theory that I know about this requires features (like 'let ... in ...' !) which Maple does not (yet?) have.&nbsp; </p> The latest comments added to the Post, 10 Tips for writing fast Mathematica code 128572 Sat, 10 Dec 2011 00:35:07 Z JacquesC JacquesC