incresearch

Finds the intervals that function sign changes

Description

Derives number of dimensions ( variables ) of given function then
Finds brackets of x that contain sign changes value of
function on an interval (in this interval if the function
would be continiues we have a root) then finds roots of function with using
sectioning method in the interval [ xmin , xmax ]. It is a one dimensional root finder
that finds all the roots.

Clarification: It is not realy a root finder. It shows you the intervals
that the function has roots. Then the user can use any fast root finder
in that intervals.

• Required Products: Symbolic Math Toolbox
• MATLAB release: MATLAB 7.2 (R2006a)

[John D'Errico]

I don't truly dislike this code. But it needs improvement. What could be done better?

In general, its hard to read. The author could learn to use whitespace. Blank lines hurt nothing. But they make your code easier to read. And easy to read code is better when it comes time to find some nasty bug in your code.

I also would suggest not using the lower case letter (l) as a variable. Its hard to distinguish from the number 1. The line "for i = 1:l" took me a few seconds to read, as I wondered why the author was looping exactly once.

A few other things I'd like to see are an H1 line. This enables the lookfor command on your code. Its just a one line descriptor of your function, placed immediately after the function header. Include all major keywords that someone might search for in that line.

I'd like to see error checking. Make your code friendly. Help your users.

The author provides defaults for the variables. This is nice, but they are poorly implemented. The author checks to see if there are < 6 inputs, in which case the assumption is that argument 6 was not supplied. But what if I want to change the default for arguments 3 and 6? I then need to supply values for arguments 4 and 5. A better programming style (and one that is fairly standard in Matlab) is to allow the user to supply [] as a placeholder. So then your tests should look like:

if (nargin<6) || isempty(maxit)
maxit = 50;
end
if (nargin<5) || isempty(es)
es = .001;
end

etc.

A better solution when you have so many arguments that are defaulted is to use property/value pairs. This allows the user to supply only the arguments that are changed from their defaults, and you can supply them in any order.

I'd also like to see better descriptions for the inputs. For example, "es" is a poorly named variable, apparently a stopping criterion. What test is done with es? How are we to know? What is the default value for es?

This brings up another point. When you have defaults for your variables, the help should tell the user what is that default value.

The help could be improved in many other ways. For example, what exactly is returned? If my function has multiple roots, will all of them be returned that are found? Or will it stop at the first root found? How about the function itself? Is this a 1-d root finder? If so, then why should the user not just use fzero? After all, fzero should be faster than this code.

The code itself is not very well vectorized, using nested loops to operate, and break statements to exit them. Its hard to follow the code.

It appears that the author might have done a better job of reusing old function evaluations. For example, when he finds a sign change across some interval, there is no reason to RE-EVALUATE the function at the end points of that sub-interval.

The author uses an approach of first evaluating the function at a sequence of steps, linearly placed over the entire domain. Then this set is searched for sign changes. But its not obvious to me that if it turns out that there are additional sign changes that turn up after this point, will they be identified and resolved?

I also note that mlint flagged many lines in tis code - 13 of them in all. Some are significant issues that are worth investigating.

What do I like about this code? It has lots of internal comments. The input arguments do have defaults, though as I said, not well implemented. There is help, although not particularly well done.

Over all, this code is not what I'd call poor. But it has many flaws, and very much "needs improvement" before other users find it to be of value.

[Duane Hanselman]

Is this any improvement over FZERO that ships with MATLAB? I note that this submission is poorly written.