Re: [eigen] Small documentation optimizations (tiny test patch)

[ Thread Index | Date Index | More Archives ]

2011/6/21 Douglas Bates <bates@xxxxxxxxxxxxx>:
> On Jun 20, 2011 11:38 PM, "Tim Holy" <holy@xxxxxxxxx> wrote:
>> Hi Gael/all,
>> On Monday, June 20, 2011 02:07:23 pm Gael Guennebaud wrote:
>> > thanks for the patch. Looking forward for the next ones.
>> OK, here's a more complete patch. I'm submitting here because it contains
>> changes that I expect to be non-controversial. Most pages were barely
>> touched,
>> though I couldn't stop myself from getting a bit carried away on the
>> Sparse
>> tutorial page (BTW there's a chance that bug #9 could be closed).
>> I've also submitted my first documentation "bug" report (#300), this one
>> without a patch. Currently my main use of Eigen is in C++ functions called
>> from Matlab (MEX functions), and so I am quite interested in the Map class
>> to
>> wrap Matlab arrays. I think there should be a tutorial page titled
>> something
>> like "Interfacing with external libraries: the Map class." However, I've
>> noticed some funny behavior from Map; before writing the tutorial page, I
>> thought I'd ask whether these inconsistencies are intended or not. (I'm
>> also
>> curious for the purposes of moving forward on my own code...)
> I'm working on a similar interface between R and Eigen using the Rcpp C++
> template package for interfacing R and C++.  Currently the RcppEigen package
> passes its tests on Linux but not on Windows. After I fix the Windows glich
> it will be available as The
> sources and development version are on the R-forge site for the Rcpp
> project.
> One of our comparisons is on the speed of fitting a linear model (and also
> simplicity of code, which should not be underestimated). R uses a
> rank-revealing QR decomposition and Eigen is one of the few high-level
> linear algebra packages that also provide this so that we can obtain the
> results we want in the rank-deficient case. I'm pleased to say that Eigen
> performs very well, twice as fast as the current R code and faster than an
> implementation using Amarillo, which is not rank-revealing. The fastest code
> by far uses the LDLT decomposition. I feel that it should be rank-revealing
> but that is not part of the interface. Should it be possible to check for
> rank-deficiency according to the ratio of the elements of the diagonal, D,
> to its largest element or am I missing something here?

We had this conversation a few times in the distant past and the
conclusion was that LDLT is not rank-revealing.

The pivoting one does in LDLT is akin to partial (columns-only)
pivoting in LU, whereas only full-pivoting LU is rank-revealing. In
concrete terms, if you have a big coefficient in the bottom-left
corner of the matrix, there's nothing in LDLT that will bring it into
the diagonal.


Mail converted by MHonArc 2.6.19+