Estimators and Residuals interfaces. I'd never thought of that. I like it!
I have read your draft proposal and I will make some comments over there,
shortly.
On Mon, Apr 1, 2019 at 5:33 PM Ben Nguyen <bennguye...@gmail.com> wrote:
> Hello,
> With the regression library restructuring, am I correct to assume that a
> priority is to structure it such that appendage of new tools after the port
> of current linear regression (OLS, GLS, SimpleRegression) is as painless as
> possible?
>
> I’ve seen this approach elsewhere and want to know what you think:
> an approach which separates key regression features by implementing for
> e.g an Estimators and Residuals parent abstract/interface (others as
> needed) which is extended by for ex: OLSEstimators and OLSResiduals…. Then
> have a central handler ex: OLSRegression…. All of which are in the package
> regression-linear-ols? What do you think of this preliminary idea?
> I would think that appending say the LogisticRegression (and other types)
> would be more straightforward as a result, having different regression
> types each having defined behavior and in separate packages with minimal
> dependencies as well of course.
>
> Thank you
> -Ben
>
> From: Eric Barnhill
> Sent: Monday, April 1, 2019 11:02 AM
> To: Commons Developers List
> Subject: [commons-statistics] STATISTICS-7 discussion
>
> Our ongoing discussion with potential mentees is being moved here as
> suggested by Gilles.
>
> Gilles commented on STATISTICS-7:
> ---------------------------------
>
> current "math-linear" will be ported to "Commons Linear" in the future?
>
>
> Perhaps; we'd need expert advice on how to design a modern implementation
> of matrix algebra (?).
>
> In the meantime, it may be worth exploring the implications of having a
> very focused {{commons-numbers-matrix}} module in "Commons Numbers".
>
> I also recommend checking out the EJML, which appears to be well
> maintained, and probably has more expertise behind it than we would be able
> to bring here. Like JTransforms its performance appears to be best in class
> and it is appealingly encapsulated with no mission creep.
>
>
>
> > just use the current library temporarily for now
>
>
> I'd rather not, as it will perpetuate the impression that "Commons Math" is
> still supported. A new major version of CM should be released (with
> "legacy" codes) that will depend on "Commons Statistics".
>
> I agree, we do not want these libraries depending on commons-math.
>
>
> "math-util"
>
>
> Anything in there that is still useful is a candidate for "Commons
> Numbers". Did you have a look at what's there already?
>
>
> It is worth continuing the discussion about these Utils and utils-type
> classes. They are often antipatterns that are falling between the stools of
> object encapsulation and functional programming. MathUtils in particular
> does nothing to describe the random functionalities in that class, all of
> which probably have a better home somewhere else.
>
> Someone else in our discussion mentioned MathArrays; most of this
> functionality should be handled by streams now for example, and the current
> algorithmic approach of most of MathArrays should be discouraged.
>
>
