Re: [eigen] 3.3-alpha1 for mid november?

Hello,

Those features look very nice. Thanks for all the hard work.

Any chance of the dreaded issue 622 being resolved for 3.3?

Toby

From: Gael Guennebaud <gael.guennebaud@xxxxxxxxx>
Sent: 16 June 2015 22:15
To: eigen
Subject: Re: [eigen] 3.3-alpha1 for mid november?

Hi,

we should really make that release. The previous blockers (877 and 876) have been fixed a long time ago. We can easily fix 1017 before making the alpha. I'll also see if I can fix MKL support easily.

I've also drafted a summary of changes on the wiki: http://eigen.tuxfamily.org/index.php?title=3.3. Any one is welcome to help making this summary more comprehensive and feel free to add any features that I've forgotten.

gael

On Wed, Dec 3, 2014 at 3:13 PM, Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

On 02.12.2014 22:54, Gael Guennebaud wrote:

On Mon, Dec 1, 2014 at 4:16 PM, Christoph Hertzberg <
chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Regarding evaluators, I would appreciate, if we can make the tests compile
on <2GB machines again (but no need to block alpha1 for that). Gael, you
said memory requirements should decrease after some clean-up?

Did I? If so, I'd not be so affirmative anymore. We'll see. Am I correct
that they currently concern the *SVD unit tests and a few matrix-function
unit tests? Perhaps we could try to split them.

I looked up the message. Indeed, you only said that you hoped that a clean-up will reduce memory requirements:
http://article.gmane.org/gmane.comp.lib.eigen/4848

Glancing through the code, I found some indirections, like evaluator_traits_base, evaluator_base which you marked as "probably not needed anymore". Removing those might already reduce the number of template instantiations significantly.
But I'm still far away from understanding the entire evaluator architecture enough to know at what points things could be simplified.

For alpha1, we also have to fix the remaining compilation/runtime issues,
and it would also be nice to have:
- 877

I would consider this a compilation issue and I'm working on this at the moment.

- 876 (at least a workaround)

Yes, we can definitely remove the atanh2 here (I don't know why the quoted source used that. Probably, to avoid that people implementing this "optimize away" the log1p).

Regarding log1p we need to detect systems where this is defined already. Unfortunately, sometimes it exists but not in std:: namespace (e.g. POSIX provides log1p and log1pf in global namespace).
But the actual problem are systems which claim to be C++11, but don't provide it.

Regarding feature requests, I would already defer the following ones to 3.4:
- 751 (numerically robust AMD)
- 707 (inplace decomposition)
- 612 (inplace triangular product/inverse)
- 231 (STL iterators)
- 166 (private allocator)
- 68 (blocked column pivoting QR)

I agree, none of them are critical.

The following twos would be very nice to have, but I'd rather release 3.3
without them and have a 3.4 a very few months later with these two features
"only":
- 437 (reshape)
- 329 (indexed views)

Yes, both of them would be very nice. At least the later was requested a lot of times.

--
----------------------------------------------
Dipl.-Inf., Dipl.-Math. Christoph Hertzberg
Cartesium 0.049
Universität Bremen
Enrique-Schmidt-Straße 5
28359 Bremen

Tel: +49 (421) 218-64252
----------------------------------------------