Re: [eigen] eigen and API stability

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


Nicolas,

On Thu, Sep 5, 2013 at 10:08 AM, Nicolas Limare <nicolas.limare@xxxxxxxxxxxxxxxxxx> wrote:

We are discussing the opportunity to add Eigen to this list of allowed
libraries. Eigen seems quite portable, as stated in the "Compiler
Support" section of the website main page[3]. I see no statement about
the OS, so I suppose Eigen is OS-agnostic.

I'm glad your are considering Eigen as one of the few libraries allowed by IPOL. Eigen uses non standard features (intrinsics, aligned memory allocation, alloca, etc.) only when the compiler, OS and platform have been well identified. So in theory Eigen should indeed be OS-agnostic. Only compilers with C++ support issues are not supported like XLC or sun studio. In practice it is well tested on Linux, OSX, Windowss with GCC, clang, ICC and MSVC and known to work on many other platforms.
 
Is there a project policy regarding this API stability? Do you require
that any code written for Eigen 3.n is usable without changes with
Eigen 3.m for any m>=n? I understand there are some unit tests, but
are are all tests written for 3.n versions kept unchanged for future
3.m versions?

Yes, in Eigen we have an explicit policy on keeping both API and ABI stability along the 3.x branch. This is why we pay a strong attention to the public API and that some features take time to be officially supported.  Of course this only concerns the set of officially supported modules that are in the Eigen/ folder. The unsupported/Eigen folder contains WIP modules. 
 
What is the current development plan for Eigen, how long do you expect
to stay on the 3.x branch (which, I suppose, implies a major API version)?
And if/when Eigen moves to a 4.x branch, will the 3.x branch still be
maintained, especially fixed to be compilable with the latest compilers?
 
There is currently no plan to move to a 4.x branch, so we'll certainly stay with 3.x branch for at least two years. If we start a 4.x series, then we'll sure maintain the last 3.x version for a few years (just like we did for the 2.x branch). Anyways, I currently cannot imagine major API changes, I can only envision minor changes that would most likely affect corner cases only, like advanced user code extending Eigen. The API for "normal" usages is pretty solid.
 
For example, I like this statement by GSL people: "GSL is a mature
library with a stable API. The main emphasis is on ensuring the
stability of the existing functions, tidying up and fixing any bugs
that are reported."[4] If the same thing can not be written for Eigen
(or can it?), which API policy statement could be written instead?

Eigen development is still quite active and not limited to maintenance. We are still consolidating, optimizing, and extending the set of features while keeping a stable API.

I hope this answer your questions?

Best,

gael


 

All the best,

[1]http://www.ipol.im
[2]https://tools.ipol.im/wiki/ref/software_guidelines/#external-libraries
[3]http://eigen.tuxfamily.org/#Compiler_support
[4]http://www.gnu.org/software/gsl/#development

--
Nicolas LIMARE - CMLA - ENS Cachan         http://limare.perso.math.cnrs.fr/
IPOL journal                                             http://www.ipol.im/
-> image processing, reproducible research, open science



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/