@Kitonum So it looks like I do have to roll my own, and thanks much for providing an example of how to do it. It's a bit more complicated than I expected it to be, mostly because you are doing it more general so it works for the sine example you provide (and also for my E vectors). Nice.

I do take a slight exception about the correctness of my original code-snippets. I do not know whether you actually edited my post; I just copied the code from my own post into Maple and found it to behave as expected (which is correct for any numerical N I cared to try it for).

No argument about using the inert Sum rather than sum; for a procedure that is necessary.

Thanks much,

M.D.

@Rouben Rostamian  and others: It is sorta off topic, but 2D input has its uses, e.g. when you want to write course materials or other documentation in Maple. The red 1D input becomes too garish, and the tty kind of font with no Greek letters does not cut it. Here 2D input shines, and I believe this is what it is meant for. It may be specialized, but when you want it it becomes a critically important feature.

For working in Maple: 1D is the way to go.

M.D.

@Joe Riel Actually, it works on Emacs 22.1 as well (I was mistaken, on this machine I run 22.1 only). Emacs 24.x produces a complaint that "abbrevlist is obsolete," but it seems to run (abbrevlist.el is provided).

I did find that within nested multiline comments, name:=proc() causes name to be set in blue which it should not be.

M.D.

@Joe Riel Excellent, thanks much.

M.D.

Others already provided answers, but I do wonder why not consider evaluating the differentials?

diff(f(x,y,z),x);

will give you the "sensitivity" to x; you can evaluate it at any point (x,y,z) you want to:

eval(diff(f(x,y,z),x),{x=x0,y=y0,z=z0});

You can plot the results directly and get a plot of the "sensitivities" rather than just function values.Do note that these are first-order sensitivites, so the results will differ from evaluations of the function at different points like you asked above.

Ask again, if you need more details.

M.D.

@Thomas Dean Look, there is nothing wrong per se with using procedures or functions as long as you are aware of what you are doing. Maple is intelligent enough to keep parameters separate from variables:

f:=(t) -> t+t^2+...; # here t is a parameter and not the (global) variable t

xpr:=t+t^2+...; # here t is a variable (a name in Maple parlance).

To evaluate f for some variable x you need to call f(x). To evaluate f for the >variable< t you need to call f(t). Note that f(t) can have other names used internally; these are then used like global variables. This can get confusing quickly and is one reason why using an expression may be clearer.

M.D.

@roman_pearce I disagree. I find it much more ridiculous trying to plot something that goes beyond 10^300. Not even cosmologists need such scales.

Plotting is slow enough as it is. Making it use arbitrary-precision floats would just slow it down further.

M.D.

@ecterrab Does Physics:-Assume also work outside of the Physics Package (i.e. when/if I am doing something not loading the package)? (I am not near a machine with a recent version of Maple so I can't check myself).

M.D.

@acer 0et al.,

It is correct that ArrayTools:-RandomArray poduces an array rather than a Vector or Matrix. In many cases the difference will be irrelevant; in some cases not.

The 2-d vs 1-d case is easily fixed:

Rarry:=ArrayTools:-RandomArray(Ndata,1,distribution=uniform)[..,1]

produces a 1-d object that, e.g., I can directly throw into DiscreteTransforms:-FourierTransform(). I forgot whether it is an Array or a Vector, but FourierTransform will work with either (per the docs).  This is actually used in one of my codes with arrays of significant lengths (many millions). At the time I experimented quite bit to speed this up and esp. limit memory usage and came up with this scheme as the most efficient (on Maple 15 and 17). IIRC, the [..,1] index to reduce the dimension did not incur a significant memory penalty (my biggest concern at the time).

It is clearly not the only way; but it is a credible contender.

M.D.

@ecterrab I think "assume" is evil! Everytime I tried using it I would lose track of what variable is what, with or without the tilde, eventually having to backtrack a significant amount or just outright start over. I use "assuming" when needed, and that works in general (for me). This all without even considering interferences with the Physics package...

assume (if it is even really needed) is in my view one of the constructs in Maple in need of an overhaul. Use it at your own peril.

M.D.

PS: There are obviously people here on MaplePrimes who understand "assume" and what it does, can do, how to use it and the pitfalls to watch out for. But for the uninitiated soul, and even someone like me who has by now a good number of years of working experience with Maple, I assert that "assume" is a cesspool of confusion.

@ It is great and inspiring (as Edgardo said) to hear from users "in the trenches" how Maple enabled them to tackle problems sucessfully that might otherwise not have been tackled.
 I would like to add to this the enormous potential Maple has as a teaching tool. We all know about Robert Lopez' work and many of us have gained insight from his posts, webinars etc. I myself used Maple as a the teaching tool in a course on accelerator physics I held last year, with good enough success that I get to do it again next year. While there is room for improvement in the course (as it always is), I have evidence that several of my students kept using Maple in their work afterwards drawing success as well as pleasure from using it. Class was always lively and engaged. What a difference compared to the standard white-board way of teaching!

Now, that being all good, we should actually reflect on where we want Maple to go. As a commercial enterprise with bottom lines to meet, Maplesoft has to obviously cater to their users while working hard to recruit new ones. What are the features most lacking form Maple? I cannot answer for the majority, obviously, but what about image processing? Here I am thinking less about Photoshop but along the lines of ImageJ. I have analysed complete experiments with Maple and since Maple's image processing capabilities are inadequate, I used ImageJ to extract the info from the gathered images (our raw data) and then read the results into Maple. This could be easier. On the other hand, is this what Maple should do, or should Maple stick to its roots as mathematical software? Matlab seems to shine in this area (I am not a Matlab user but I see what others are doing with it) so do we need another one like this? On the other hand, the combination of mathematics with numerical work makes a lot of Maple's worth. Speaking of Matlab, a limitation I consider serious (for my own work) is Maple's inability to import most Matlab's data constructs (everything beyong simple arrays is ignored, for the most part).

Personally I benefit a lot from Maple's ability to combine mathematics with numerical work, so any development in that area will benefit my work. But then, others needs may differ. And, of course here on MaplePrimes we do not reach new users.

I do a bit disagree on Alan's assessment of the use of spreadsheets. I use them all the time for information best conveyed in tabular form (like machine settings or what have you). I even use them for quick plots (usually when I do not have Maple around). They are of enourmous value even in engineering and science; although, to be sure, if you use Excel to solve diff. equations you are grossly abusing it for a purpose it was never meant to do. I have never ever used the "Solver" facility of it (which is a kind-of least-squares minimizer, I think).

Anyway, my thanks to Alan and all the follow-on posters for a great and inspiring thread.

Mac Dude

(Needless to say, but I am not affiliated with Maplesoft either, just a satisfied user).

@Carl Love 

Carl, Preben and Markiyan,

Thanks much for yor suggestions. The reason why my output differs from the one Markiyan shows is simply because I had an interleaving simplify() applied to it; which I forgot to paste into the input window of MaplePrimes. The output from f@@2 is identical to the Maple 2015 output.

I like the eval[recurse] command, but alas, that is Maple 18 and newer. I have Maple 17 and like to be compatible with Maple 15 since I have that on some older machines that cannot run later Maple versions, so no eval[recurse] for me for the time being.

The seq trick I still need to explore. In my application the whole thing is actually wrapped into a much larger context so I have to assess whether it works in that context.

Thanks,

M.D.

@acer For the record, yes, your 2nd sheet "inlined1501.mw" works for me, too (Maple 15.01 on Mac OS X).

Don't know why "inlinedmathtable.mw" did not work, but it isn't really important (for me) right now.

M.D.

@acer While this is very cool, it does not appear to work in Maple 15 (which is what I have open at this very minute). I'll try Maple 17 later.

M.D.

@mathnoob1 You create a worksheet in "Document mode". In this sheet you toggle between Plain Text for writing your text and 2D Input for code. It is a bit finicky, I often end up having to select a piece of prose and explicitly convert it to Plain Text (Format:Convert to…). Maple code meant to be  evaluated has to be on its own line; you cannot do what you seem to want to do (include the Maple command in the text and have Maple evaluate it).

M.D.