Does it make sense to define a class like RegressionGlobalFitStatistics? It
would look like:
public class RegressionGlobalFitStatistics{
... private constructors
public double getRsquared(){
return _rsq;
}
public double getAdjRsquared(){
return _adjrsq;
}
I was not aware of the versioning document. Thank you. A few more things
make sense now. It is still a bit bittersweet. In my opinion the interface
is a programmer's most terrific tool. It keeps him honest as well. I
understand your point though.
-Greg
On Wed, Jul 13, 2011 at 11:42 PM, Phil Steit
On 7/13/11 9:05 PM, Greg Sterijevski wrote:
> Phil,
>
> "Fortunately for users, maybe less fortunately for developers, we
> can't really "evolve" our API rapidly This is why we
> favor abstract classes over interfaces."
>
> Just so that I am sure I understand, let me restate the objection to
Phil,
"Fortunately for users, maybe less fortunately for developers, we
can't really "evolve" our API rapidly This is why we
favor abstract classes over interfaces."
Just so that I am sure I understand, let me restate the objection to an
interface. An interface approach is more likely to be
On 7/13/11 7:14 PM, Greg Sterijevski wrote:
> Phil,
>
> "How exactly do interfaces make the hierarchy flatter in this case?
> I agree we should aim for as simple a structure as possible. The
> question is, what is that structure?"
>
> They may or may not make the structure different. Any design we
Sorry, sent the previous email without finishing (aparently gmail is not
idiot proof...)
So,
public class ConstrainedRegressionResults. extends RegressionResults{
private double[] lagrangian;
private double[] varcov;
public ConstrainedRegressionResults( double[] lagrangian, double[]
var
Phil,
"How exactly do interfaces make the hierarchy flatter in this case?
I agree we should aim for as simple a structure as possible. The
question is, what is that structure?"
They may or may not make the structure different. Any design we come up with
today is likely to be outmoded in 6 months
On 7/13/11 5:15 PM, Greg Sterijevski wrote:
> Hello All,
>
> Sorry for being a bit slow on the uptake... I am still in the wilds of
> numerical imprecision with the longley data. I am getting close to figuring
> out where the error is being accumulated.
>
> I agree that interfaces impose rigidity i
Hello All,
Sorry for being a bit slow on the uptake... I am still in the wilds of
numerical imprecision with the longley data. I am getting close to figuring
out where the error is being accumulated.
I agree that interfaces impose rigidity in the design. However, there are
broad similarities in l
On 7/13/11 12:45 PM, Ted Dunning wrote:
> +1 to the overall thrust here. This is a good thing.
>
> One item that I would like to add is that we should agree on the general
> direction before getting bogged down in debates on the details.
> Establishing some momentum in the direction of agreement
+1 to the overall thrust here. This is a good thing.
One item that I would like to add is that we should agree on the general
direction before getting bogged down in debates on the details.
Establishing some momentum in the direction of agreement might help shorten
the ensuing spelling discussio
Interfaces are not a great idea in a changing API.
On Wed, Jul 13, 2011 at 12:35 PM, Phil Steitz wrote:
> We can also talk about getting
> rid of the interfaces entirely and just have LinearRegression and
> its immediate children abstract classes with all abstract methods.
> Or maybe others have
To effectively integrate Greg's contributions on updating
regression, we really should refactor the multiple regression
hierarchy so that we have consistency in results reporting and data
definition. Here are some initial ideas. Better ideas and/or
patches welcome.
0. Deprecate MultipleLinearReg
13 matches
Mail list logo
