My First Attempt

Please go through the enclosed README file for more details.

Description

The user has to modify the function to be integrated in a file named eval1.m enclosed in the same directory & invoke romberg() from MATLAB terminal.
The output is in the form of two values :
1. Approximate Integration Value.
2. Error from the actual value supplied by user.

Initially, the user can give known functions & through error can check for correctness & accuracy limits. Then with few modifications can use the function to evaluate integration of various functions, numerically.

I DON'T CLAIM ANY COPYRIGHT ABOUT THE METHOD OR THE PROGRAM SUBMITTED HERE.

• MATLAB release: MATLAB 7.7 (R2008b)

[John D'Errico]

Argh. I spent an hour writing an extensive review of this submission, but then it disappeared when I tried to add a new comment! Sigh. This will teach me to be more careful. I'll take another stab at it.

Don't rate your own submissions. That defeats the purpose of the file exchange review system, which is to provide peer reviews for your work. In fact, this submission is not worth three stars. Not even close. I'll do my best to explain why it is not.

I do like that there was a ReadMe file provided. This tells a user what to expect and how to use your submission. At the same time, don't leave trash around in your work. Why leave the README~ and trapezoidal.m~ files in this directory when you submit it? These are temporary backups the editor generates, but they are simply trash for the rest of the world. Dump them first. Be nice to those who download your work. It shows you to be professional, instead of a novice.

Next, there is NO help in any of these submissions. Look at the functions that the MathWorks supplies. See that there is a block of contiguous comments at the beginning of EVERY function. That is what help uses when you ask for help on a function.

There are no H1 lines in your code. This is the very first line of the help block. It is what lookfor uses, to help find your functions next month, or next year. An H1 line should be a SINGLE line of comment, that explains what the function is, as well as having a set of useful, logical keywords to search on.

There are no error checks in your work. Error checking is a friendly thing to do when you allow others to use your tools. Error checks allow you to be friendly to a user who makes a mistake. It helps them to understand what they did wrong. Write friendly errors that explain how to repair their mistake.

Lets look at some of your code itself. How about eval1? This is the function that each of your tools calls to integrate. By hard coding the function, instead of allowing them to supply an anonymous function or function handle or a general m-file that feval could use, you force a user to edit your code just to use it. This makes it likely that they will make mistakes, create bugs of their own.

==================================
function fval = eval1( x )

 fval = 1 / ( 1 + x * x );

 return;
==================================

Better would be to allow them to give you a function in the form of

fofx = @(x) 1 ./ ( 1 + x .* x );

See here that this is a function that quad, quadl, or quadgk could accept. Look at those tools to understand how you might pass in a function. Very importantly, it uses the .* and ./ operators, so that it is vectorized. It can accept a list of points to evaluate, and return a vector of function values in one call. As such it will be for more efficient. Learn to use the power of matlab to best advantage. I'll talk about this more later.

Next, look at another of your functions. Here is trapezoidal.m.

==================================
function SUM = trapezoidal( a, b, n )

 SUM = 0;
 H = (b - a) / n;
 prev = eval1( a );

 for i = 1 : n
  curr = eval1( a + i * H );
  SUM = SUM + 0.5 * ( prev + curr ) * H;
  prev = curr;
 end

 return;
==================================

Again, there are no comments, but also no internal comments. An internal comment helps you next year when there is a bug in your code. It helps your successor if this is code you wrote for a real job. Perhaps you get run over by the crosstown bus. How will they read your code to understand it, to maintain it? A good goal is to write ONE line of comment for every substantial line of code. That goal is especially important for vectorized code, which this is not. But explain what you are doing, and why you did it that way! If you made a choice, then say why you did it. MATLAB does not charge for comment lines. Your employer will appreciate them for the reasons I listed above. So will your teacher when they must read the mess you submit as homework.

What else is wrong with trapezoidal.m? Use good, intelligent, mnemonic names for your variables. SUM is a very poor choice, as it risk confusion with the function sum - a VERY valuable tool in matlab. Don't use variable names that overload good, useful functions, even if you do use all caps.

Next, name the other variables with good names. Again, matlab does not reward frugality of typing. You don't get a break on your license fee if you use short names. Well named variables make your code self documenting. Admittedly, here H, a, b are all names that are found in textbooks on integration. I might have chosen alternative names for H like delta, stepSize, increment. But even if you do use H, when you do define the variable, do something like this:

% H is the (uniform) step size for the integration rule
% between successive function evaluations.
 H = (b - a) / n;

Next, the entire function trapezoidal.m function could have been written in not much more than one line of code in a vectorized form, perhaps several if you are feeling frivolous. Learn to use vectorized forms in matlab. They will be more efficient.

I do like that you used white space in your code, in your expressions. White space makes code more readable.

In conclusion when you submit your work to a place like the file exchange, there should be a good reason for it. The fact that you got an A on your homework assignment does not make it worthwhile to give to the world. That just makes it something to hang on the refrigerator with a magnet. A FEX submission should be either something that will be useful to other users of MATLAB, or it should be something they can learn from. This submission will be useful to nobody as a tool. It will teach them only how to write poor code. However, don't take my criticism here as harsh. Take it constructively. Use these comments to learn to write better code in the future.

[John D'Errico]

 

[John D'Errico]

Comment added - don't name your submission "My first Attmept". This tells nothing about what it does, merely that this is your homework assignment.