|Re: [eigen] backporting the vectorized quaternion product to 2.0 ?|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] backporting the vectorized quaternion product to 2.0 ?
- From: Rohit Garg <rpg.314@xxxxxxxxx>
- Date: Wed, 23 Sep 2009 21:01:56 +0530
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=H26S1Dky32q6qibgaf2dQtD09kxtAoIHFldklqjl04E=; b=ppy70IrNkNGShq69f2acfBFgzPKsxXNU3bibbcBI5l5lspQGjh0PI6aniaKVkPPIPf zyhspOYfTRR9xEHTs6clzw73Kf5wWD/pmQvDsIn6UoFlDIIIAmLT4qqVjwUUJqdI2wDm qVFVu5D+Umst+I9M0SsoHfiEQnYOm78qLFowI=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=GH9YX4rvumN5DUE1Yg5ESueDm4XNN8ZvQScryDURVA3OtSuHYqvXh/kOqejiwbXAxp 3uAD7MljTdzsOw37+WobjFWD/8lZj/FsEbItvb5+5gIDhX0lhA+tJCz5Cu9Vrj36YUm8 apaowU/Z9ubrRrWabQJgSnuTFkLihohQWCgQA=
On Tue, Sep 22, 2009 at 10:11 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> (Gael, feel free to disagree with the very idea of 3.0. Just because
> we started discussing that doesn't mean it's too late to oppose it.)
> 2009/9/22 Rohit Garg <rpg.314@xxxxxxxxx>:
>> 3.0 sounds better. Apart from API, what else do you plan to put in 3.0?
> The "ideal world" answer:
> If we can just get the API right, that's enough for 3.0 as
> features/optimizations can got into 3.x.
> The "real world" answer:
> Getting the API right is only possible if we have spent enough time
> implementing optimized algorithms. Take the Householder module:
> currently there is a risk that we have to completely change the API
> when we implement blocked Householder, which in itself is just used as
> an optimization.
Fair enough, but let's lock down the parts which will be there in 3.0,
so that we can focus on which API to optimize and we know the priority
order of stuff to be done.
> So the answer is that in addition to finalizing the API we have to do
> well-chosen optimized algorithm that are likely to trigger API
> improvements elsewhere.
>>> We are well on our way already, and I think it's realistic to aim for
>>> a beta in 3 or 4 months, with a near-finalized API, and final release
>>> in Q2 2010.
>> I think it is important to setup the features spec for 3.0 now and
>> stick to it. Otherwise we'll suffer from feature creep. Since the gap
>> has been long, I suggest that we keep the API changes for 3.0. We
>> don't need to make 3.0 block for sparse module since it wasn't in 2.0.
>> Also, it is unlikely that we'll get the sparse API right the first
>> time, so let's not throw the entire kitchen sink of sparse module at
> Yes, it's OK to keep Sparse as experimental in 3.0.
> On the other hand, I would like to have all Dense modules finalized in
> 3.0, otherwise there's no point in releasing something.
> If needed, we can make Householder and PlanarRotation into internal
> things, so we don't have to worry about their API.
> Let's start a wiki page on 3.0 goals.
Department of Physics
Indian Institute of Technology