I think this toolbox is well done but when i'm using it i don't understand what i get.
If i'm right, when q=0 these functions are simply the harmonic functions, that is, we could use them as DFT eigenfunctions. Nevertheless, i see this is only true if i take only the first term of the expansion series of Mathieu functions. When i take more terms of the expansion i get a completely different result from that of the DFT.
I'd appreciate much if anyone could help me with this issue.
Thank you.
Pretty good. A useful set of tools, at least if you work with these functions. A few things the author should consider improving.
1. There are no H1 lines. For example, in the help for Ypm, the first two lines of the help are:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% RADIAL MATHIEU FUNCTION OF THE SECOND KIND
Note that the SECOND line of the help was a nice, one line description of the function. It would do very nicely for an H1 line, except it is the SECOND line. Why is an H1 line valuable? Suppose you want to remember the name of this function next year, and your memory is slipping like mine does at times. You might try the lookfor utility. You might type this in MATLAB:
lookfor mathieu
It would return nothing, since the author failed to provide H1 lines for these tools.
Delete that meaningless line of all % symbols, and this code would be more useful.
2. It is a good idea to use mlint on your code. It points out the failure by the author to preallocate some variables, then growing them dynamically in the code. This is inefficient.
3. There are no error checks on the variables. Be friendly to your users. If the argument q must be positive (see the help for Ypm) then test for that property. If this test fails, then return an error that indicates what failed and why. Similarly, if KF can take on only one of the values {1, 2, 3, 4}, then test for that fact. Don't just crap out with some random error, or return a garbage result. Be friendly to those who use your code.
4. Internal comments are valuable, both to those who read your code as well as yourself as the author. Next year when you need to fix a bug in your code, those comments would have been helpful. Learn to comment your code. A great goal to look towards is one line of comment for every line of code. I'll consider you a success if you do half that.
5. The help could be a bit more friendly. For example, Cpm is described as no more than "Correlation factor". Correlation of what?
There were some things I really did like. I found a very useful .pdf file. Well done there. I found examples of the use of these functions, and useful comments in the examples.
I wanted to rate this submission as 3.5 stars. Some might choose to round that up to a 4, others might see those flaws I've pointed out as more important and round it down to a 3. With many misgivings, I've chosen to round this one up to a 4.
