My first thought is to use a debugger to check for division by zero, or something close enough to zero to be a problem. It usually a good idea to explicitly code a check on the divisor to see it is not zero before doing the division. The same concepts apply to other functions that might bomb because the arguments are out of range or domain.
Using the debugger, does it bomb on the very first iteration, or on one of the other values after that?
Do you validate your data? Edit: It may be quicker to write code to validate the data, rather than tediously debugging your way backwards through the code. Validation is really important, one should always do it.
Some other things that may help, having looked at the code from your other topic:
* Make use of version control programs like git. One can either use it from the shell, or there is integration with IDE's. I say this because your code had a lot of stuff commented out;
* If you have functions with lots of parameters, put each one on it's own line, rather than one giant line of code, as in.
void aapx(const Eigen::Ref<const Eigen::MatrixXcd>& uh,
const Eigen::Ref<const Eigen::MatrixXcd>& vh,
This helps with display, especially on this site, the window for the code is fairly narrow. Also, if I am looking at the code in shell, it's easier if it doesn't word wrap.
* really try not to have giant functions (including main) it can be a real nightmare trying to break them up after the fact. Remember a function should only do one thing, if it's more than say 20 LOC, it's getting too big. I you are worried about passing lot's of variables about, consider putting them and their functions into a class or struct, so the functions can have direct access to the member variables
There are advantages in doing this. An object doesn't exist until it's constructor is completed. I like the class to inherit (with protected) a Validation class, whose functions I call from the constructor of the class in question. One can alos publicly inherit an Interface class, which has all the interface function in it and avoids cluttering the object's class.One can also throw exceptions. The downside of all this is that you may not want to have to learn all this other stuff;
* put a few lines of comments says what a function does;
* put a comment on the declaration of variables to say what they are. This is really helpful for others;
* if there is a link to documentation that explains what process you are following (wiki say) put it in a comment;
* Try not to use variables
or anything else that looks too similar. It will bite you one day when you get the order wrong. I prefer to use
if that is what they are;
* Do try to put your own code into it's own namespace. This will also save you when you inadvertently use an identifier that already exists in a library that you use, including the STL;
* one can use a namespace alias, as in this for example:
namespace ed = Eigen::Dense;
then qualify anything in
This allows one to use whatever abbreviation that suits for a namespace. This is a very common practice in the boost library;
I have an interest in this code, I am a Engineering and Mining Surveyor, and I am applying for a job doing data processing for geophysical surveys (Magnetic, Gravimetric and Spectral). It will be good for me to understand some of what goes on behind the scenes in the code. So I was wondering what application/purpose your code has in the spectral realm? I have been doing some study - mainly ruminating the wiki pages.