BUG: I used cell-arrays in the underlying functions, bad!
I cannot understand why restarting Matlab result sometimes into more verbose error messages that help me to actually solve problems. Now I am trying to find a command that makes Matlab showing as much information as possible. For example the below index-exceed-dimension error is totally useless with my recursive algorithm -- this is the specific algorithm where Matlab have once revealed the specific line but now for some reason only telling the vacuously the name of the algorithm
Index exceeds matrix dimensions.
Error in Dij (line 65)
Dij_=Dij(ii,jj,[II,k],[r,q_(k)]);
where you can see that I am running the algorithm Dij failing on the line running the algorithm Dij again.
How can I get more information about the error? Or how can I get inside any point in the recursive algorithm? -Linebreak and trying to get inside that point just fires the error.
Add a try catch block on your recursive algorithm, print the information you think it would be valid and then rethrow an error that will terminate your other callbacks silently.
You may use the keyboard matlab function to check the matlab workspace as the recursive function goes on. You can choose to add it just before your error message, so it will be called every time it goes deeper in the recursive level, so that you can check what is going on, or you can add it when the error occurs (on the catch).
This is just a draft, it may contain errors, adapt it into your needs:
try
% recursive routine
catch ext
if strcmp(ext.identifier,'MyPackage:MyRecursiveRoutine:TerminateSilently'))
% Do nothing
else
% Display useful information, you edit it to add information you think would be valid, i.e.:
disp(ext.getReport)
disp(yourVariable)
% get dbstack size, to see how many recursive functions, i.e:
theStack = dbstack;
recursiveCalls=sum(strcmp({theStack.name},'MyRecursiveFcnName'))
% You may even add the keyboard function here, so that you can inspect your workspace:
keyboard
throw(MExcept('MyPackage:MyRecursiveRoutine:TerminateSilently',''));
end
end
Run dbstop if error before running your code to drop to the debugger exactly at the point of error. From there you can inspect the variables, including whatever variable you've carried along to ID the level. You can also run dbstack to see the full call stack.
It is not evident in the description where the bug is because it does not show with which tools I programmed the underlying functions: I used cellarrays and for some reason Matlab returns far worse error messages with cellarrays than with Matrices so:
my genuine recommendation is avoid cellarrays and use matrices -- and if you need to play with a lot of zero cases, use the ready sparse functionalities because they have far better debugging verbosity!
Instead of wasting too much time to debugging, choose the right tools and Matlab is excellent with Matrices and you can see it in the quality of error messages.
Related
I am using MATLAB's fitgmdist ("fit a guassian mixture to data", from the Statistics and Machine Learning Toolbox) with some success. Is there a way to make it run in a verbose mode, e.g., tell me what iteration it is on, or show convergence stats during the process, so I know how well it is progressing?
Related, is there a way after the function has run and delivered the gmdistribution object, to determine how many iterations actually ran or how close the convergence came? (It would be useful to know these things so I could better set the options parameters up front.)
Simply put: no and yes.
You can try to access the actual .m-file (e.g. open(fitgmdist)) to copy it and then edit it to your purposes (copy it so you won't overwrite the build-in function), but there is no straight-forward implemented way to obtain the verbosity you want. The name-value pair which comes closest to what you want is display, iter:
iter: Display iterative output to the Command Window for some functions; otherwise display the final output.
I am not quite sure about this part, since I can't run a test, but the final number of iterations should be available in the gmdistribution structure under gmdistribution.NumIterations. The docs state that this is only for objects constructed with fitgmdist.
I am doing parameter estimation in matlab using lsqnonlin function.
In my work, I need to plot a graph to show the error in terms of lsqnonlin iteration. So, I need to know which iteration is running at each point of time in lsqnonlin. Could anybody help me how I can extract the iteration number while lsqnonlin is running?
Thanks,
You want to pass it an options parameter setting 'display' to either 'iter' or 'iter-detailed'
http://www.mathworks.com/help/optim/ug/lsqnonlin.html#f265106
Never used it myself, but looking at the help of lsqnonlin, it seems that there is an option to set a custom output function, which gets called during every iteration of the solver. Looking at the specification, it seems that the values optimValues.iteration and optimValues.fval get passed into the function, which is probably the things you are interested in.
You should thus define your own function with the right signature, and depending on your wishes, this function prints it on the command line, makes a plot, saves the intermediate results in a vector, etc. Finally, you need to pass this function as a function handle to the solver: lsqnonlin(..., 'OutputFcn', #your_outputfun).
The simple way to do this would be:
Start with a low number of (maximum) iterations
Get the result
Increase the number of iterations
Get the result
If the maximum iterations is used Go to step 3
This is what I would recommend in most cases when performance is not a big issue.
However, if you cannot afford to do it like this, try edit lsqnonlin and go digging untill you find the point where the number of iterations is found. Then change the function to make sure you store the results you need at that point. (don't forget to change it back afterwards).
The good news is that all relevant files seem to be editable, the bad news is that it is not so clear where you can find the current number of iterations. A quick search led me to fminbnd, but I did not manage to confirm that this is actually used by lsqnonlin.
I am solving a stiff PDE in MATLAB using ode15, and it often freezes depending on the initial conditions. I never actually get an error, it just won't finish even after 10 hours when it should take around 30 seconds to run. I am experimenting with different spatial and time node intervals, but it is hard, because I don't get feedback.
Is there some sort of equivalent to diagnostic for fsolve? stats is not useful because it only displays an output after fsolve is finished.
Check out the documentation on odeset, and specifically the stats option. I think you basically just want to set stats to on and you will get some feedback.
Also, depending on your ODE, you may need a different solver. About half way down the page on this page there is a list of most of the solvers available in MATLAB. Depending on whether your function is stiff or non-stiff, and how accurate you need to get, one of those might work better for you. Sometimes I just code them all in and comment out all but one until I find the one that runs the best for me, but check out the documentation on each if you want to find the "right" one for your application.
Your question is confusing because you refer to both ode15s and fsolve locking up. These are two completely different functions. One does numerical integration and the other solves for roots. Also, fsolve has no option called 'Stats' (see doc fsolve). If you want continuous output from fsolve use:
options = optimist('Display','iter');
[x,fval,exitflag] = fsolve(myfun,x0,options)
This will display the iteration count, number of function evaluations, the function value, and other stuff depending on what algorithm you use (the alorithm can be adjusted via the 'Algorithm' option). Again see doc fsolve for full details.
As far as the 'Stats' option with ode15s goes, it's not going to give you very much information. I doubt that it will you figure out why your system is halting (if it even is ode15s that you have a problem with). What you can try is using an output function via the 'OutputFcn' option of odeset. You can try the simple odeprint first:
options = odeset('OutputFcn',#odeprint)
which will print your state after each integration step. Type edit odeprint to see the code and how you might write your own output function if you need to do more.
I would like to run a program called QuantiSNP that used Matlab in its code. I am not familiar with Matlab at all. I got the below error message and no output. Any idea how to fix it? FYI, I don't have access to source code of the program....
??? Error using ==> chol Matrix must be positive definite.
MATLAB:posdef
Highly appreciate your help
Jean
It's very hard trying to answer your question without seeing any code but here is some general info about the problem you are facing:
What you see is a Matlab error message. I assume QuantiSNP is a compiled Matlab program so you probably can't debug it. In short it says that at some point the program is trying to calculate the Cholesky factorization using chol() function, but the matrix inside is not positive definite. Most of the time the problem happens because the matrix is actually zero, which in turn is [potentially] caused by an invalid input parameter
Check to see if the parameters you are using (1) are valid and (2) match your environment. If there is an input CSV or TXT file, make sure the path is correct. Make sure numbers make sense. Are there any zeros or extra lines somewhere that should not be there?
Depending on which version of QuantiSNP you have, you may have access to the --verbose switch. Add --verbose to the end of your command (for example quantisnp2.exe firstparam secondparam --verbose) to see some messages on the screen as the program runs through the data. See if you can figure out where it's failing and if it's related to your input parameters.
Take a look the QuantiSNP how-to page to make sure you understand the required parameters and the formatting of the input file.
I have a problem with ode45. I've defined a function and trying to solve it by ode, but when i run it, it takes so long. I tried to display the "t" input in my function and it showed time step was 10^-8 ! [I do not get any error from ode45]
So i put a breakpoint at the end of my function, and after I Step once, it goes to sym.m file and calls Function delet(h)
function dxr=Dynfun(t,x)
...
dxr=[A;B]
after Step it goes to
function delete(h)
if builtin('numel',h)==1 && inmem('-isloaded','mupadmex') && builtin('numel',h.s)==1 && ~isa(h.s,'maplesym')
mupadmex(h.s,1);
end
end
and that's what makes it too long, because it goes in a loop in there.
what's the problem?! Thanks
Sounds like it's a "stiff" problem to me. I would recommend using a solver that is designed for stiff problems. I would also recommend trying a fixed step solver at a small step size ~ 0.001 and see what the output looks like. If you are breaking in sym.m, sounds like you've some some symbolic logic going on in there. Is there a way you could take your symbolic expression and convert it to a matlab script?
As indicated by macduff, your problem could be stiff. Try ode15s (which is designed for stiff problems) and see if the stepsize still decreases to unacceptably low values.
If that is indeed the case, then your problem might contain a singularity for the initial values you give it. If your problem has dimensions lower than 3, you can define a small event function to get insight into the values at each step, and plot them to see if there is indeed something problematic going on.
Then -- do you really need symbolic math? The philosophy behind that is that it's easier to read for humans, which makes it terrible to deal with for computers :) If you can transform it into something non-symbolic, please do -- this will noticeably increase performance.
Also, more a word of advice, delete is also Matlab builtin function. It is generally a bad idea to name your functions after Matlab buitins -- it's confusing, and can cause a lot of overhead while Matlab is deciding which one to use.