Re: [eigen] 3.0 planning

[ Thread Index | Date Index | More Archives ]

2009/11/10 Keir Mierle <mierle@xxxxxxxxx>:
> Nice! However, there is an enormous amount of work implied on that list. I
> think priorities should be rearranged into three categories: A. Breaking API
> changes. B. API additions. C. Enhancements.
> Almost all of the items on the list are in B or C.

Well, as far as i'm concerned, i'm only assigning to myself as much as
i think i can do in that time span. I think we can make it. We are on
the good side of the big refactorings now and it seems as if we can
get back to normal coding instead of the crazy abstract discussion
threads we had.

> I argue that only A and some of B is necessary to release 3.0 beta, and that
> it's more important to release something that's API complete soon than it is
> to have all the items in C. In my opinion, there should be a 3.0 which has
> all the API changes, and a 3.1 which has speed enhancements, and then a 3.2
> which has the LAPACK precision testing.

LAPACK precision testing is listed as priority 2, so we agree with you.

> Sparse - API stability for basics features. Very important! Many people want
> to use sparse. Sparse is a killer feature; more important that basically all
> the other items on the list.
> Sparse - Stable API for preconditioners and external linear solvers. Have
> ONE of the solvers implemented with the API (COLAMD + LDL? CHOLMOD?)
> Sparse - Example and docs for at least one preconditioned sparse solver.

---> More stuff for Gael to do. Hopefully someone can help him as
indeed the Sparse module is a pretty huge amount of work!

> Dense solving API refactoring complete; docs updated (i.e. qr().solve(...))

This is done and as far as I can see, the documentation is updated, right?

> New SVD API stable, documented.

Indeed, I am editing the wiki page to add that.

> The reason I added sparse as a high-priority item is that having stable
> sparse support opens the door for many users to Eigen; more than any other
> addition. It's not critical that all API additions are finished, but the
> basics should be considered stable. Preconditioners and solvers must be
> included.
> Everything else can be added later. The other items will make eigen nicer to
> use, but aren't blockers to having people use the newer API. Consider the
> LAPACK / BLAS precision testing stuff -- Great to have, but can be added
> later while users who are happy with the existing tests can start working
> with 3.0 right away.

Yes, again this is priority 2 so not blocking the release.

> Same with any performance stuff which doesn't break the
> API.

Yes, you won't see such stuff with blocking priority.
I'll just add block-householder with blocking priority (no pun
intended) because it "feels" dangerous to assume that one can just do
that at a later date.


Mail converted by MHonArc 2.6.19+