#59 Enhancement to linear least squares regression

open
nobody
None
5
2010-12-17
2010-12-17
Slava Mazur
No

The idea behind proposed enhancement is application of the current linear least squares regression to a wider range of containers. Currently the input data must be in std::vector<double>. However, in my particular case for example, i need to perform linear least squares on the data in boost::circular_buffer<double> and it is highly undesirable to create vector copies of the original data just to satisfy rather rigid requirements of the current linear least squares design. A proposed patch relaxes such a requirement and at the same time preserves backward compatibility. A correspondent test case is added to the test_suite.

Discussion

  • Enhancing the flexibilty of the class LinearLeastSquaresRegression is a good idea. Just a design question: instead of adding more classes would it be better for the "end user" to stay with one LinearLeastSquaresRegression class but add two "templatized" constructors to this class? These constructors would allow e.g. boost::circular_buffer<double> to be used as input parameters.

     
  • Slava Mazur
    Slava Mazur
    2010-12-20

    I agree, but the reason for the proposed design was the current design of the LinearRegression class, which handles both 1d and multi-dimensional regressions. In addition to generalize wrt input data type, my goal was to optimize the existing solution, since currently LinearRegression class treats a one-dimensional regression as being a multi-dimensional one, which introduces although small, but an overhead in 1d case. Such an overhead may become significant if LinearRegression is used repeatedly in a loop. If the LinearRegression class were a template instead, things would be much simpler, but this would break the backward compatibility.

     
  • Slava Mazur
    Slava Mazur
    2010-12-24

    With a little help from mpl i managed to simplify design significantly (see the attached). A template argument "ArgumentType" apparently becomes redundant (perhaps as well as the whole class LinearLeastSquaresRegression), but they left unchanged for backward compatibility. It is recommended to remove them in due time though - this will simplify design even further (for example, an ugly cast in swap method will go away).

     
  • Good solution! I have submitted your last version (with a small change from my side) to the SVN head. IMO the original intention for two classes - LinearLeastSquaresRegression and LinearRegression - was that LinearLeastSquaresRegression is the generic class that can take a list of functions used for the regression whereas LinearRegression takes only linear functions. WIth the second constructor in the current version
    template <class xContainer, class yContainer, class vContainer>
    LinearRegression(const xContainer& x,
    const yContainer& y, const vContainer &v);
    LinearRegression now becomes a swiss jackknife. IMHO I'd either remove this constructor or - as you already mentioned - remove the class LinearLeastSquaresRegression completely (leaving a stub for backward compatibility)

    I've removed the second usage of the swap method already and I think we can remove the other swap invocation as well if LinearFcts becomes a list of functions.

     
  • I have removed the swap method. Please find the recent version in the SVN head. Even though it breaks backward compatibility I would now also remove the ArgumentType as it is redundant. Or should we introduce a backward compatibility stub, Luigi?

     
  • Luigi Ballabio
    Luigi Ballabio
    2010-12-29

    Let's keep backward compatibility.