@Christopher2222 I really don't know enough of Mma to judge its capabilities,  but the picture in the Apollo example clearly was convolved "on earth" and then deconvolved in Mma, presumably in both cases with a Gaussian kernel. As such, there is no noise introduced to the convolved image which makes deconvolution possible to a very high degree, even if a relatively straightforward approach is taken. Real-life cases are a lot more difficult to deconvolve as anyone who has tried it will know and appreciate. Often, algorithms like wavelet deconvolution or minimum-entropy methods will achieve better results than straightforward deconvolution, but they are all limited by the noise added to the convolved image as that noise is amplified in the process.

Having said that; personally I find Maple's image-processing abilities lacking at least until Maple 17, the last one I am actively using. Even though ImageTools has a lot of members, I can find no advanced tools like FFT/inverse FFT; wavelet decomposition, deconvolution (using any algorithm) or others. Likewise there is not so much there as far as scientific image processing is concerned, i.e. to extract data from images.

There are some advanced functions (like ImageTools:-Entropy) that seem to be useful. But overall it seems to me the user of Maple is on his/her own as far as image processing is concerned. The example worksheet for ImageTools exemplifies it by having only some rather simple examples. Given the importance of image processing thse days this lack is arguably not working in favor of Maple.

Needless to say, maple has sufficient capability for the knowledgeable user to write his/her own routines.

Mac Dude

@shoeless I second your unhappiness with the way Maple deals with units. In fact; I have more-or-less given up on the units. It is quite a bit easier to do the dimensioning "by hand" or "by head", esp. if you adhere to certain "standards" from the get-go (like using SI units throughout and avoid using multipliers like "milli" or "kilo"). Can lead to some funny numbers but at least you get there without too much of a fight.

Maple's value lies in the combination of algebraics and numerics. Treatment of units is not a strength of Maple. It would be useful is MapleSoft could address this, but I suspect it would require significant R&D work to even find out how to get it right, let alone implementation.

My $0.02

Mac Dude

Markiyan, it may be helpful to explain the point you want to get across. And, what do Kaspersky and AbbyLingvo have to do with this?

Mac Dude

I have not tried your work, but why do you use unapply with indexed parameters (the p[x] etc)? I am not sure whether that even works; but I certainly do see what sense it makes. Use regular names for the parameters and put in array elements for the arguments of P if that is what you want to use.

And I cannot figure out whether the line beginning with (Y1,Y2,...) ->...  is input or output.

M.D.

@Carl Love That looks very interesting. I'll be sure to check it out.

Many thanks,

M.D.

@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.