Re: [eigen] Including Spectra within Eigen 3.4

[ Thread Index | Date Index | More Archives ]

Dear Xixuan,

Am 23.02.2017 um 02:45 schrieb Yixuan Qiu:

To partly answer Bill's question on the "smallest"/"largest" option, I want to say that both ways are workable, with their own pros and cons.

I would actually vote for Bill's suggestion, the my previous email.

Reasons for template parameter:
1. For most cases the selection rule, that is, requesting the smallest or largest eigenvalues, is predefined for a specific problem. For example in matrix approximation and PCA (principal component analysis), it is already known
that largest eigenvalues are needed.
2. According to Gael's plan, proper solvers will be automatically deduced for different selection rules. This means that we need to store different types of matrix operators in the class according to the selection rules, and hence
we need that information at compile time.

I agree that this is an advantage.
3. Template parameter brings some performance gain. Fewer if-else conditions are evaluated.

The selection itself shouldn't be cost relevant.

Reasons for run-time option:
1. It allows for control in the run time.
2. Compatible with other ARPACK wrappers.
3. Smaller object file size and faster compilation. If users need to frequently switch between different selection rules, they only need to compile one solver class.

A class based selection would allow for more flexibility and use cases we currently do not think of.

Concerning to the implementation in spectra, since I have no experience with the shift methods, could they be implemented via a preconditioner?,
i.e. provide via an extra class to unify the approaches? Template specialization would still allow to choose between implementations.
E.g. in the Davidon type methods one can use the identity as preconditioner and  obtains a method that is formally equlivalent
to plain  Lanczos/Krylov.

Best regards,

Mail converted by MHonArc 2.6.19+