On 7/13/11 9:34 PM, Greg Sterijevski wrote:
> All,
>
> I am working on some additions to the regression package and have run into a
> bit of difficulty.
>
> The statistical R Squared is equal to 1.0 
> SumOfSquaredError/SumOfSquaresTotal. Say that I run my regression two
> different ways. The first manner I tell the regression technique to include
> a constant, so the SumOfSquaresTotal = Summation of ( Y  Mean(Y) ) ^2. In
> the next run, I tell the regression technique not to include a constant, but
> I do include one in the data I supply ( one rhs variable is always set to
> one). The models are identical, but the R Squared may not be consistent,
> since in the second run I will assume Mean(Y) = 0.0.
The models are not identical, because in the second case, the
unitary column is a (zero variance) regressor. I would say whoever
supplied the data did not understand the API and the reported
Rsquare is meaningless. This is why we indicate in the javadoc
that the data should *not* include unitary columns, but the
hasIntercept property should be used instead to indicate that the
model should include an intercept term.
>
> The question to the list is what is the proper course of action? Ignore it
> and leave the obvious inconsistency? Force a mean? (That's not exactly a
> good solution). Empirically test the data as it comes in? If an independent
> variable exhibits zero variance, then it must be the constant. I then set
> the flag for it, and get the correct result?
It is never a good idea to try to "fix" API abuses / data anomalies
/ bad specifications, other than to throw exceptions on easily
discernible precondition violations. In this case, for example,
zero variance regressors may actually occur in data and our decision
to change the model specification may be not at all what the user
wants. Our contract with users is that we clearly document how the
API works, preconditions, algorithms, etc. and compute what we say
we compute. I would say don't do anything special in this case.
Phil
>
> Thoughts?
>
> Greg
>

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
