[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Release plan
- From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
- Date: Tue, 16 Aug 2011 08:55:36 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ID1Lbb7m5RGIs2WLauzrWYSYu22ADNd9VRrBx20RuyA=; b=lWzogyT2POCjdWnvGv4pW+GLVGZ/Eu8jcCGmcy+8fLT0FUKwRsIj0Z4csjX/72gAj1 wa2v0tRS/mgKo3KAQuIEGlD9/RRxJsLbnEmxwH3ERKd9oqiH0NTRx0N55edNGcU6m5Wz G6aWuNbkE7o51svqyCrFnHYl6qslnJSIehS0I=
On Thu, Aug 11, 2011 at 2:45 AM, Andrea Arteaga <yo.eres@xxxxxxxxx> wrote:
> Thank you, Benoit!
> If I have some time I could give an helping hand with the lapack
> implementation, if you need some.
> Regadring the BTL, I'm planning a "completely" new one; i.e. rethink
> it from scratch. For example, the current one has some limitation that
> do not allow a straightforward distributed-memory benchmark for some
> libraries (PBLAS, ScaLAPACK, ...). It's not always "fair", too: every
> library receives different input matrices and vectors when doing the
> same action -- this is not a problem in many cases, but it's a crucial
> problem in some other cases (think of the conjugate gradient method,
> where the number of iterations strongly depends on the input data...).
sounds nice, I'm looking forward;)
> Andrea Arteaga
> 2011/8/9 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
>> 2011/8/3 Andrea Arteaga <yo.eres@xxxxxxxxx>:
>>> Hello all.
>>> Just a few questions to organize some packaging work: is there a plan
>>> for the next release? Will the version be 3.0.2 or something else?
>>> When would it come out? Will the lapack module be ready?
>> Thanks to Gael and Thomas there is already a good number of fixes in
>> the 3.0 branch since 3.0.1, so I think that a 3.0.2 release soon would
>> make sense. Maybe in a few weeks?
>> The 3.0 branch is only for bugfixes so in principle I wouldn't expect
>> new features in it. Incomplete modules stay incomplete.
>> The development branch will eventually give us a 3.1 release, but that
>> is probably still some distance away, as our main objective for it,
>> bug 99, is still far from done. Of course if needed we can reconsider
>> and make a 3.1 release without it.
>>> A last question: who is responsible for the BTL benchmarking suite
>> It's always been Gael. I'm sure he'll be glad if you send your patches
>> to this list!