Re: [eigen] SimpliciaLDLT::analyzePattern_preordered

[ Thread Index | Date Index | More Archives ]

We should release a 3.2.2 release soon as numerous fixes are hanging in the 3.2 branch.

I guess that backporting this small changeset to the 3.2 branch is harmless, so we could ship it with that release. Any objections from others?


On Sat, Aug 2, 2014 at 1:55 AM, Sameer Agarwal <sameeragarwal@xxxxxxxxxx> wrote:
Is there an eta for a new release for Eigen in which this code will be released?
Without this, there is a significant performance regression in Ceres.


On Sun, Jul 20, 2014 at 7:49 AM, Sameer Agarwal <sameeragarwal@xxxxxxxxxx> wrote:
Thank you Gael. Much appreciated. 

On Sun, Jul 20, 2014 at 5:24 AM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

On Sun, Jul 20, 2014 at 12:11 AM, Sameer Agarwal <sameeragarwal@xxxxxxxxxx> wrote:
Hi Gael,

The NaturalOrdering template parameter will do just fine. Since my matrix is generally speaking already permuted.


On Sat, Jul 19, 2014 at 1:31 PM, Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:

we should rather add a third template parameter to let the user choose the ordering method, currently :AMDOrdering<> or NaturalOrdering<> as in SparseQR and SparseLU. Perhaps we could also add a "PredefinedOrdering<>" class to ease the use of a custom precomputed ordering. Meanwhile, it's probably ok to use this undocumented method as a temporary workaround.


On Fri, Jul 18, 2014 at 4:56 PM, Sameer Agarwal <sameeragarwal@xxxxxxxxxx> wrote:

Is there a reason why analyzePattern_preordered is not documented in the public API for SimplicialLDLT?

There are situations in which, an ordering is computed via some indirect means or the natural ordering of the matrix is good enough that we do not want to spend time finding an ordering all over again. In such cases, this is a very useful method to have.

Is it okay to depend on this method in user code?


Mail converted by MHonArc 2.6.19+