Almost all of the items on the list are in B or C.
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.
Here's what I would put as the only items required for 3.0:
- 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.
- Dense solving API refactoring complete; docs updated (i.e. qr().solve(...))
- New SVD API stable, documented.
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. Same with any performance stuff which doesn't break the API.
Keir
On Mon, Nov 9, 2009 at 7:20 PM, Benoit Jacob
<jacob.benoit.1@xxxxxxxxx> wrote:
Hi,
I started a page there:
http://eigen.tuxfamily.org/index.php?title=Todo_for_3.0
Feel free to say if something is stupid. I just started something so
at least things get moving and dumped some random ideas, that's all.
Also i hope you can think of more stuff. Note how there are 2
sections, one for blockers and one for non-blockers.
Let's also start vaguely discussing 3.0. People are starting to ask
when it will be there, or at least when a reasonable beta will be
there. I have started answering them to expect a beta in Spring 2010,
i hope that is OK with you guys. I think it'd be nice if you could
agree at least on a beta goal. So here's a proposal, tell me what you
think about this: let's plan to make a "reasonable" beta stable API in
the springtime (say in april or may) of 2010. By "reasonable" i mean
that traditional features of a linear algebra library (including
various decompositions) are, say, 95% feature-complete and 99% API
stable. The 99% API stability is important and anyway, the earlier we
think hard about it, the earlier it will happen. This 99% API
stability requirement is the main reason why i don't see us releasing
a beta before april, perhaps march, but not earlier. Exotic features
wouldn't have to be 99% API stable in that beta, only the big
traditional features.
I hope this makes sense :) if not, well, you know what to do.
*puts on flame-proof suit*
Benoit