What you show will work for anything that naturally appears in Maple output (so includes int, diff, sum, etc, which can appear unevaluated). However, for any routine in Maple which has a meaning (and a symbolic representation) in mathematics but does NOT return unevaluated in Maple, then your trick will not work! [In fact, many Maple commands do not work on raw input]. The problem is that many commands are written to understand those things that are ``values'' in Maple, but pretty much none are written to understand ``commands''. Now, in everyday use, since just about everything is a value, this is not a big deal. But you'll notice that some things that are ``the same'' typeset differently. For example, sum typesets, add does not. So sum(i^2,i=1..10) will typeset, add(i^2,i=1..10) will not. This is an endless source of weird bugs. If you try to apply context-sensitive menus to general maple terms (i.e. those that never appear in output), you'll rapidly see what I mean.

Robert is quite right -- it is almost always more efficient to use builtins whenever possible, and to resort to ``programming'' when there are no builtins to perform the task. This is especially true of any kind of looping constructs -- which is why map and add are faster here. Another reason is that the for-loop version is in the wrong complexity class! It is quadratic instead of linear (in memory, thus in time too). The one exception to using builtins is when a builtin happens to use a sub-optimal algorithm, then it is possible to beat it via Maple code. While fairly rare, it does happen [and Roman showed one such example recently].

This is clearly a bug in the pretty-printer. It is worthwhile noting that Classic does not suffer from this bug, that this is a bug introduced in Standard.

Any function that converts reals to integers (that made sense) would have done. The main point is that your function was a function from the integers, and plot is from the reals. For plotting a function over a finite range (as someone else pointed out), doing it via a point plot by explicit sampling is the most obvious thing. When faced with an infinity plot, you need to get more creative -- thus the floor function.

Any function that converts reals to integers (that made sense) would have done. The main point is that your function was a function from the integers, and plot is from the reals. For plotting a function over a finite range (as someone else pointed out), doing it via a point plot by explicit sampling is the most obvious thing. When faced with an infinity plot, you need to get more creative -- thus the floor function.

Thanks for spotting that, I have fixed it now.

Thanks for spotting that, I have fixed it now.

In my opinion, it is always a bad idea to illustrate a concept via a bad Maple idiom -- in this case, adding one element at a time to an expression sequence. While in small programs, this is OK, it does not scale, and simply causes many people to write programs which fail in weird ways later. The better way to do this is P:=[seq(plot(BSplineCurve(tListList[1..i],v),v=1..10),i=4..nops(tListList))]; display( P, insequence=true ); As a bonus, it's shorter!

In my opinion, it is always a bad idea to illustrate a concept via a bad Maple idiom -- in this case, adding one element at a time to an expression sequence. While in small programs, this is OK, it does not scale, and simply causes many people to write programs which fail in weird ways later. The better way to do this is P:=[seq(plot(BSplineCurve(tListList[1..i],v),v=1..10),i=4..nops(tListList))]; display( P, insequence=true ); As a bonus, it's shorter!

As far as I know, this functionality is implemented via Maple itself -- which clearly has access to its own pretty-printer.

Very weird -- in the "Recent comments" column, the title of my latest post has verbatim &lt; show up in it, but the title in the page view has a < instead. Why is the behaviour different in different contexts?

I tend to use the <code> tag for in-line stuff, and reserve <pre> for cut-and-paste of longer chunks of Maple, especially when there is output present (to preserve spacing). That said, the 2D printer should know about all of Maple, no? Apparently, small expressions are OK, but larger chunks of 'meaty' Maple are out-of-scope for the 2D printer. That doesn't sound right, does it?

It should also explicitly state that that means that Maple's own $ command is thus unusable in MapleTA, and that seq should be used instead. Also, it might be nice to change the Maple documentation for $ to state that if the user is using MapleTA, that this command is disabled.

It should also explicitly state that that means that Maple's own $ command is thus unusable in MapleTA, and that seq should be used instead. Also, it might be nice to change the Maple documentation for $ to state that if the user is using MapleTA, that this command is disabled.

As I am sure you have observed, in Maple 11, converting to piecewise on e does not work anymore (even when using the assumptions you gave). It can convert to piecewise based on s though. Let's assume that your piecewise above is called 'p'. Then one gets that convert(p, piecewise, r) assuming r>0; and convert(p, piecewise, r) assuming r<=0; both produce very small answers, which perhaps was what you were looking for? Unfortunately, for multivariate non-linear piecewise expressions, I do not know of any recipe. It seems that experimentation is where the state of the art is at!