Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 72065 invoked from network); 21 May 2006 23:06:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 21 May 2006 23:06:48 -0000 Received: (qmail 5973 invoked by uid 500); 21 May 2006 23:06:46 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 5900 invoked by uid 500); 21 May 2006 23:06:46 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 5889 invoked by uid 99); 21 May 2006 23:06:46 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 21 May 2006 16:06:46 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [193.252.22.31] (HELO smtp11.wanadoo.fr) (193.252.22.31) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 21 May 2006 16:06:44 -0700 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1112.wanadoo.fr (SMTP Server) with ESMTP id 2525C1C0008D for ; Mon, 22 May 2006 01:06:22 +0200 (CEST) Received: from lehrin.spaceroots.local (AToulouse-152-1-4-21.w82-125.abo.wanadoo.fr [82.125.2.21]) by mwinf1112.wanadoo.fr (SMTP Server) with ESMTP id 004151C0008C for ; Mon, 22 May 2006 01:06:22 +0200 (CEST) X-ME-UUID: 20060521230622113.004151C0008C@mwinf1112.wanadoo.fr Received: from localhost (localhost.localdomain [127.0.0.1]) by lehrin.spaceroots.local (Postfix) with ESMTP id 9995F4E2CC for ; Mon, 22 May 2006 01:06:23 +0200 (CEST) Received: from lehrin.spaceroots.local ([127.0.0.1]) by localhost (lehrin.spaceroots.local [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30622-02 for ; Mon, 22 May 2006 01:06:16 +0200 (CEST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by lehrin.spaceroots.local (Postfix) with ESMTP id 8BD104E2CB for ; Mon, 22 May 2006 01:06:16 +0200 (CEST) Message-ID: <4470F268.8090805@free.fr> Date: Mon, 22 May 2006 01:06:16 +0200 From: Luc Maisonobe User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: fr, en MIME-Version: 1.0 To: Jakarta Commons Developers List Subject: Re: [math] Q-R -decomposition References: <238221690603290914y3b6b6f25n92109b43ff0956c9@mail.gmail.com> <8a81b4af0603291436v71641423y155281c6efdebccf@mail.gmail.com> <238221690603312338h759b284fve47f22be32675209@mail.gmail.com> <8a81b4af0604011119r48e65a62l8abeace01e36dd85@mail.gmail.com> <238221690605080253y2d44f995q658f3e85cf897313@mail.gmail.com> <8a81b4af0605142042s1194870al6d97d57ad63f9249@mail.gmail.com> <238221690605201026g5398c0e8g3bf05b645f912929@mail.gmail.com> <8a81b4af0605201447x1c051cd8j5bc99eb4be932d0c@mail.gmail.com> <238221690605210454r6535e0eoebad8912bf347ccf@mail.gmail.com> <35b94d690605211233o6e90ef91lb32ab780038c42bc@mail.gmail.com> In-Reply-To: <35b94d690605211233o6e90ef91lb32ab780038c42bc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N >> > Beyond what is available in the API (Q and R), what exactly does the >> > QR Decomp "know" that makes solving easier? foreword : what is stated below is oriented only for least squares problems, it is not a general discussion about decomposition algorithms. When using QR decomposition in least squares problems, you NEVER really compute Q explicitely, and if you don't retrieve Q, you don't retrieve R either. The decomposition algorithm keeps some information about Q (the Householder vectors, but also some coefficients and permutation indices if you want to support rank-deficient problems) and you use this information to compute transpose(Q).Q.V for some vector V without computing Q itself, and it uses R internally also to provide some higher level result, not Q and R to let you compute something with them. Q is a huge matrix, much larger than the Householder vectors it can be deduced from. This is especially true when the problem as a few parameters but a lot of measurements (in orbit determination problems, for example, you often have less than 10 parameters in the model and several tens of thousands of measurements). What makes least squares solving easier is not the QR decomposition itself, but the way it is used in the surrounding algorithm (Levenberg-Marquardt for example). In this case, you do NOT compute the normal equations (i.e. transpose(J).J where J is the jacobian matrix) and decompose the resulting square matrix like you would do in a Gauss-Newton solver. You decompose the jacobian matrix itself (this is the reason for the transpose(Q).Q.V part of the solver). Both decomposition are therefore not used the same way. The QR way is more accurate because there are situations where the squaring of the jacobian matrix involved in the normal equations computation leads to cancellation of some tiny values (epsilon -> epsilon^2). For difficult problems, this is really important. On the other hand, using LU has other benefits. First, you may build the normal equations iteratively (i.e. build Jt.J by updating a matrix as measurements are considered one after the other) and second, the matrix size is small (mXm where m is the number of parameters of the model), which is smaller than the nXm matrix appearing in the QR decomposition (but beware, nobody really computes the nXn Q matrix). QR decomposition involves about twice the number of operations the LU decomposition. So the choice is size versus accuracy for simple problems, and you may only choose accuracy for difficult problems, as the other way alternative simply fails. For optimization problems, the Levenberg-Marquardt algorithm (which uses a QR decomposition as one of the many parts of the algorithm) is the method of choice you will find in many applications. It works really well and few people bother studying really what is the better alternative. In any case, for least squares problems, the decomposition used is an implementation choice and the user doesn't really need to see the intermediate steps (building J or not, decomposing Jt.J using LU or J using QR, applying residuals, updating the parameters). He chooses one method or the other and get the final result. Luc --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org