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

[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 http://cran.R-project.org/web/packages/RcppEigen 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?

> More "bug" reports will follow, with patches implementing proposed fixes for
> more complex documentation issues. Due to other duties, these may filter in
> more slowly.
>
> Best,
> --Tim