Re: [eigen] Usage of Eigen2 in a closed source application |

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] Usage of Eigen2 in a closed source application*From*: "Benoit Jacob" <jacob.benoit.1@xxxxxxxxx>*Date*: Sun, 14 Dec 2008 17:50:51 +0100*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=aGbEYZuYthuHDd8iSTdbBcD0+euunwvdWoOheXYg2X0=; b=XyS3cZzOpHhv+9VTMU1rqVo0z0WByXH7X6B8q8o3RTM5VXJEGZCiNz/+gPON2EI6fC JA/692FSmshfsiKXh2wVHDhedeVo16mYz6eNKvJPRgrSys9AY5/3axl94G2ZptT6BosO 1OBedVa2MBrrNAN7dgbq0CCUP79ZwkKwV6JdQ=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=d717wj4gWQ4qvzK+SU9PNDFIm0RM2rYwJWCAPMR0ReJL9nLGL0j4nIzq4uQ//swprL PY0Uhksslm3YOkASnKs5oM6byB3OH7BzTyv4CFGD+kpRokJh+cW2OqTdyfIrdgaBRcFd 1sg63kGlc7nE5tBWx8TmEEWPRqPW/mRodxEgM=

2008/12/14 Keir Mierle <mierle@xxxxxxxxx>: > I have looked at it, and started sketching some interfaces, but didn't end > up with anything. I read the relevant parts of the Golub book. Actually > implementing the SVD is not hard; the tricky part is to make the API > reusable. The SVD algorithm breaks down into a few clear parts which would > almost certainly be useful outside of the SVD itself. I see, that's interesting. > > I am not sure about the following things: > > Should we maintain the current API for the SVD and just change under the > covers? No, we don't have to maintain the current API. When I say that the current SVD is experimental it means that we don't make API stability guarantees for now. > If so, then it is not obvious to me how to break the algorithm into > smaller reusable pieces, because the SVD object owns the matrix with the > results. In particular, should the bidiagonalization also be a > Bidiagonalization object? Should it own the result matrices? Whatever makes most sense technically (haven't yet looked at it), we don't have to preserve any existing API for the sake of it. > Householder matrices are used in several parts of the code; it would be nice > to have a simple mechanism for accumulating householder transforms (without > actually applying them) to reuse throughout. I see. > I don't understand how lazy evaluation would work with the SVD; does it even > make sense? Don't worry about it. Lazy evaluation is for expressions, but in decompositions such as LU and QR we compute the decomposition right away, in the constructor of the decomposition class. SVD should be no different. Decompositions aren't lazy. > My template-metaprogramming-fu is not strong. Not that you should need much of it, but just in case you're interested, this can help you learn how stuff works: http://eigen.tuxfamily.org/api/InsideEigenExample.html > I am not sure how to evaluate the numerical precision of the resulting SVD > algorithm, which is important for many applications (however this is an > entire other can of worms). AFAIK there are at least three different SVD algorithms, each representing a different compromise between speed and numerical stability. My suggestion is that we first reimplement the generic SVD (for dynamic-size matrices) using the most stable SVD. Then when we do fixed-size specializations, we'll use a faster, less stable SVD as fixed-size is only for small sizes anyway. Numerical stability is extremely important. For dynamic-size we want to cover sizes up to 1000x1000. For the LU decomposition and matrix inversion, I initially experimented with the usual LU (partial pivoting) as it is faster and is what most libraries do, but numerical stability was not good enough for sizes like 200x200 and bigger: matrix inversion simply failed and returned a really wrong result. Problem solved with a full-pivoting LU. I want the same in SVD so we can be confident in the results returned by Eigen. This is easy to test in unit-tests, i.e. compute the SVD, reconstruct the original matrix and compare. Gael went further and made unit-tests that will compare precision with other libraries to check that we're doing as well as them. Cheers, Benoit ---

**References**:**[eigen] Usage of Eigen2 in a closed source application***From:*FMDSPAM

**Re: [eigen] Usage of Eigen2 in a closed source application***From:*Keir Mierle

**Re: [eigen] Usage of Eigen2 in a closed source application***From:*Benoit Jacob

**Re: [eigen] Usage of Eigen2 in a closed source application***From:*Keir Mierle

**Messages sorted by:**[ date | thread ]- Prev by Date:
**Re: [eigen] Usage of Eigen2 in a closed source application** - Next by Date:
**Re: [eigen] patch for tridiagonal matrices in eigen** - Previous by thread:
**Re: [eigen] Usage of Eigen2 in a closed source application** - Next by thread:
**Re: [eigen] Usage of Eigen2 in a closed source application**

Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |