Ali Mohammad Razeghi

I'm pleased to see real progress in this author's work. Its not what I'd describe as perfect, but I can't always say that about my own codes either.

As I read through this code, I see error checks on the variables to help the user. I see an H1 line. There is good help (more on this later.) Use of the symbolic toolbox is documented. The internal comments are well done.

A couple of somewhat minor points - the help is spread throughout the code. So for help on the 5 argument version of this code, you must look down inside the code. You don't see that part using help. You must edit the code.

Next, I don't see why it is necessary to use dblquad or triplequad to do the integration for the 2-d or 3-d cases. They are adaptive numerical tools, as such are quite CPU intensive, especially for the 3-d case.

Finally, I'm not entirely sure about the use of the phrase "area normalization", even though I myself suggested it as an alternative. As applied to a possibly complex function, "area" seems not entirely appropriate to me, but a better word escapes me at the moment.

So as a whole, while not perfect, this is a good effort by the author. I hope & expect to see continued improvement from this author.

My thanks to Richard Brown for his accurate review. Most of my comments would just mirror his. This submission indeed needs very much improvement.

The help is poor, consistently so for this author. (I'm disappointed that this author has not improved his coding style given the many poor reviews.) While there are short descriptions of the parameters, they are woefully inadequate. For example, es is described as a stopping criterion. But what test is applied, we don't have any idea. maxit is the maximum number of iterations, but what is iterating? How many iterations is a reasonable number?

Worse, while the many parameters have default values, we don't have any idea what those defaults are. Worse yet, these defaults are poorly implemented. If you wish to set only the last variable to something other than its default value, you must set all the other variables too. And, since we don't know what the defaults for the other variables are, this is a real problem. This goes against the standard matlab paradigm for defaults.

I also agree with Richard's comments about the methods used, and am not at all impressed with the Gauss-Seidel method chosen. The algorithm itself is a bit suspect, not converging to any requested tolerances in my tests.

Poor programming styles are used throughout. For example, a Vandemonde matrix is generated using a doubly nested loop. Why not use the existing vander function? Even better, since this was created using the current release, use bsxfun to generate that matrix in one line, with NO loops at all.

Other loops are used for no good reason, where a simple vectorized statement is entirely appropriate.

The code is not terribly readable, lacking whitespace. While it does have many internal comments (a GOOD thing!), they are not always useful. Many comments merely name the loop variable, something that is usually clear anyway. Far more valuable would be a useful explanation of the method used, something that is totally lacking.

Other examples of poor coding style are the use of poor variable names. Use of a lower case "L" is a bad idea, as it makes your code virtually impossible to read. l looks too much like the number 1.

Even the name of the function is a poor, un-mnemonic choice. Why call a root finding code "interpolat"? If the next homework assignment by this author is truly an interpolation code, I might expect to see it called rootfind.m?

Next, this function lacks an H1 line. Its a necessary tool to enable the lookfor command. And since the name of this function is so un-memorable, one would think lookfor is a valuable thing.

Finally, mlint flags fully 15 different lines in this code. Many of those flags are problems worthwhile resolving.

As I said, this code needs vast improvement before I would even consider calling it fair. This is not to say the code is terrible, as I've seen far worse submissions on the FEX. While part of me wanted to rate this as "poor", it has barely enough redeeming characteristics to call it "needs improvement". But there are other codes I would recommend before this one.