In addition to what Edgardo says be aware that for e^(x) you'd want to write exp(x).

M.D.

This is very useful info. However, I do wonder about the recommendation to use the functional form rather than the uneval quotes as it does not apply to functions of more than one argument.

Uneval quotes, on the other hand, work with functions of more than one argument as well (assuming all arguments have been properly assigned).

Mac Dude

Robert,

I like reading your posts expanding on MaplePrimes questions and answers very much. I do suggest, however, that you name the interns who you mention are writing (or contributing to) the answers under your guidance. While it is unlikely that we know them they should be able to see their name on the board (unless they object, of course) and be able to show their work to their peers. I work with summer students (which are not interns, but still) and I make sure they are named and acknowledged appropriately.

I do like your content as it exposes aspects of Maple I may have missed and I am less familiar about.

Mac Dude

@Carl Love Hmm, I had not thought about using subs on a proc, but I can see that that might be possible.

However, even if the inner proc is defined first (say, upstream of the other executable code) it can presumably still be modified by a subs, and called afterwards. But the subs statement would then create a new (modified) instance of the proc---at least if subs is used in the normal way---at which time it is again a known entity. Even if the result of the subs is assigned to the original name a new instance is created (by necessity before the call to the inner proc) so logically it would be possible (and in fact it does not really matter where the inner proc is located within the code of the outer proc). Basically, I don't think Maple does true in-place substitution (some weird commands may, but subs does not).

It does actually indicate the possibility of doing "run-time editing" of code. A technique sometimes used in assembler (machine-language) coding when people did that. Highly efficient and hellish to debug. I should play with that...

Be that as it may, it is what it is. Right now I don't have time for too deep an exploration of this subject as I need to get some results.

Thanks,

M.D.

@acer Ah, I forgot about ModuleApply, I shall try that. Also thanks for the hint that the order in which the code is arranged is important... I actually thought about that but decided that it should not be that way, assuming that Maple is using some kind-of two-pass system when parsing the code. So I guess I was wrong about that.

Your point about the overhead from a local proc within a proc is important. I'll have to decide how relevant it is for my specific implementation... in general, Track may not get called all that often, but trackElement does get called a lot (could be millions of times in a run) so the primary objective is to make trackElement efficient. I can however see how making this a module gets around the instantiation overhead.

Thanks much,

Mac Dude

Example please.

M.D.

@tomleslie Really no argument with you approach here, staying close to the OP's attempt. I do remember however the frustrations I had before I fully understood the rather bewildering plethora of Maple indexed variables (lists, Vectors, Matrices, arrays, Tables and what have you) so I wanted to point out what it is that is being generated and what one can and cannot do with the result (just try to convert a subset of the table into a Matrix so you can use LinearAlgebra).

M.D.

PS: I do like your final version with the same uneasiness  about gamma and gamma[]. In addition, non-indexed gamma in Maple is Euler's constant and cannot even be set without a two-step process unprotecting it and removing it from the list of Maple constants. But that could have been the intention of the OP.

@tomleslie You are correct. wrt. D being local to the OP's proc. In fact, I think your and my replies crossed as I do not remember having seen yours before writing mine.

Be that as it may; your eqTqble.mw works (of coursse).

I do have two comments:

First: the table produced does not behave like a true 3-d array. An expression like

eval(DD[1]);

does not evaluate. The OP may, however, declare DD as an Arrary like this:

global DD:=Array(1..n,1..n,1..n); # just add the Array assignment to the original declaration
              
after which (s)he can e.g. evaluate one slice of the array:

eval(DD[1]);

or make this a Matrix or whatever.

Secondly; in larger projects the use of global variables should be discouraged as endless pain and suffering will occur when variables change value seemingly randomly and initiated in different procedures or modules. Better to either return the Array or table from the proc, or wrap the thing in a module and use exports. For a single proc this is obviously not a grave concern, but the OP should be aware of this.

Mac Dude.

@acer Ok, I stand corrected. i have never used that option so it escaped me.

M.D.

@TomM what does " carefully setting the Server to be the same as the first worksheet" mean?

In Maple, you pick whether to use a common server for all worksheets or separate servers in the preferences. And I would not be surprised if you needed to restart the complete Maple system (i.e. quit and relaunch) to make a change effective (but I have not tried this so cannot tell for sure). The worksheets will indicate the server on the lower right status line. But it not that you need to "pick the right server". (On the other hand, if you did this successfully in Maple 18 you maybe know all this, in which case I apologize for the lecture.)

I'd define some simple  variable in worksheet 1, execute worksheet 1 and then see if worksheet 2 picks that one up. Also, there is the question what happens is worksheet 2 begins with a restart (as we have all learned to do). I betcha that that restart hoses everything.

Mac Dude

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