Well, the error I found is fixed.
Great! The pseudo-solution I suggested didn't work so well, but the new test is passing with your code. I just wasn't sure if it was a complete solution as the bug report is still open (https://gna.org/bugs/?23186).
Maybe there is a need, to also test for 2 field data.
That might be useful for sanity purposes, just to make sure relax is behaving correctly for all dispersion parameter categories.
The code ordinary_least_squares() is not used yet, as I still going back and forth about argumentation for which one to use. Depending on the statistic book I read, I change my meaning.
Maybe just dump both side-by-side in a new relax library module (i.e. restore the old one that was deleted). Then you could compare performance. The differences are often due to edge cases, which in this case may not even be an issue. Note that statistics books, and statisticians themselves, have strong opinions and biases based on their speciality. So you need to be objective and test for yourself. So if you dump both into the library, you can use them as you wish, or forget about them. You work on the auto-analysis will then be decoupled from this code, as the linear regression code will be separated, isolated, independent, and fixed. This is the entire purpose of the library and why I created it :) (see http://article.gmane.org/gmane.science.nmr.relax.devel/3789). If a function can operate by itself, having only simple data input and output and is not reliant on the relax data store, then the aim should be to shift it into the library to isolate it. This has the effect of simplifying the auto-analyses by minimising the amount of code there. It also simplifies the pipe_control package, as these modules should only check arguments and manipulate the relax data store. Migration of functions to the library is still an ongoing process, but already since relax 3.0.0 (http://wiki.nmr-relax.com/Relax_3.0.0) the auto_analyses, data_store, pipe_control, prompt, specific_analyses, and target_functions packages have been hugely simplified. This decoupling is also a great aid for the debugging process due to the isolation and code simplification. Cheers, Edward