Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion - Standardizing Regression function inputs #9

Open
Beakerboy opened this issue Jul 21, 2016 · 0 comments
Open

Discussion - Standardizing Regression function inputs #9

Beakerboy opened this issue Jul 21, 2016 · 0 comments

Comments

@Beakerboy
Copy link
Contributor

Beakerboy commented Jul 21, 2016

Let's discuss how we want the input parameters to be designed for ultimate flexibility. I have my library set up to accept two arrays, one a set of independent variables [[v1,w1,x1],[v2,w2,x2],[v3,w3,x3],...] and the other the dependent array [y1,y2,y3,...]. I like this approach because, although in simple linear regression, the points are defined as (x,y), in three-space, where points are (x,y,z) would z be the dependent variable?...and if this is the case, should we change the name in the Regression class so it's not xs and ys? Would we have to explicitly state "dependent variable is always the last element in each data array"? It seems less cumbersome to do "new LinearRegression(array $ys, array $xs)"...but maybe it's all my years working with Excel biasing me.

Alternatively, we could have Regression define a default, and the children could have their own specialty constructors if need be:

class Regression{
  __construct(...$params){
      if (count($params) == 1) // set it up to use an array of points
        foreach($params as &$point){  // pop the last element off of each point into a new array.
           $ys[] = array_pop($point);  
      }
      else if (count($params) == 2) //use an array of ys and an array of xs.
        //do nothing
  }
}

Similarly, $xs could be an array [1,2,3,4,5,4,...], or a simple "Matrix" [[1],[2],[3],[4],[5],...] and the constructor could manage it. I was planning on putting this type of logic in my Regression class, and then calling $this->compute(), which would be a method that each child of Regression would implement.I see the advantage of "$this->compute()" is that each child wouldn't have to be set up like:

 class Linear extends Regression{
  function __construct(...$params){
    parent::__construct();
     [least squares code or whatever]
  }
}

if they wanted to handle class inputs in the default manner. Separating the more universal housekeeping/set-up code from the specialized optimization code.

Similar discussion needs to happen on the input parameters for [RegressionTypes]->evaluate();

@Beakerboy Beakerboy changed the title Standardizing Regression function inputs Discussion - Standardizing Regression function inputs Jul 21, 2016
markrogoyski pushed a commit that referenced this issue Aug 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants