Re: problem with solve-sv
Yann LeCun <[email protected]>
| Newsgroups | gmane.lisp.lush.devel |
|---|---|
| Message-ID | <[email protected]> |
There were no less than three problems with solve-sv:
1 - the code for checking the size compatibility was wrong
2 - the solution was supposed to be returned, not copied into b
(which has a different size)
3 - the GSL function gsl_linalg_SV_decomp does not handle
the case M<N for an MxN matrix.
I fixed problems 1 and 2 and updated the CVS.
Problem 3 requires a completely different implementation.
[email protected] wrote:
> I also encounter problems when attempting solve-lu instead, using a 4x4
> matrix A bombs; 3x3, 2x2 work.
solve-lu works fine for all sizes. It generates an error
message (rightfully so) when the matrix is not invertible.
-- Yann
On Thursday 25 August 2005 07:58 am, Thomas Knudsen wrote:
> I have some problems getting solve-sv in lush version 1.1
> to run properly. I am, however, a Lisp/lush newbie
> (at time of writing having written a total of approximately
> 30 lines of lush code), so due to cluelessness, I may do
> something obvious wrong. This is my code for testing the
> least squares solver:
>
> .......................................................................
> svdetc.lsh
> .......................................................................
>
> (libload "libnum/linalgebra")
>
> ; generate toy problem
> (setq A [[1 3 2][4 5 6][7 8 9][10 12 11]])
> (setq x [1 2 3])
> (setq b (idx-m2dotm1 A x ))
>
> ; check dimensions of A and b
> (printf "A: %d %d (%d)\n" (idx-dim A 0) (idx-dim A 1) (idx-ndim A))
> (printf "b:") (idx-bloop ((ii b)) (printf "%f " (ii))) (printf "\n")
>
>
> (solve-sv A b)
> (printf "b:") (idx-bloop ((ii b)) (printf "%f " (ii))) (printf "\n")
>
> .......................................................................
> This is the response from lush:
> .......................................................................
>
> ? (load "svdetc.lsh")
> A: 4 3 (2)
> b:13 32 50 67
>
>
> *** lisp_c runtime error: incompatible vector/matrix sizes for SVD
> solver
> ** in: C_solve_sv
>
> *** solve-sv : Run-time error in compiled code
> Debug toplevel [y/N] ?
> .......................................................................
>
> (apropos "solve-sv") replies:
> ------------------------------------------------------------------------
> (solve-sv <a> <b>)
> [DH](packages/libnum/linalgebra.lsh)
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> [adapted from the GSL manual]: This function solves the linear system
> A*x=b using singular value decomposition. the result is put in b on
> output. Matrix a is also destroyed in the process. Only non-zero
> singular values are used in computing the solution. The parts of the
> solution corresponding to singular values of zero are ignored. In the
> over-determined case where A has more rows than columns the system is
> solved in the least squares sense , returning the solution x which
> minimizes the square norm of (A*x-b).
> .......................................................................
>
>
> Since A has 4 rows, b has 4 elements, this seems to be OK
>
> Doing (solve-sv A (transpose b)) instead, results in:
>
> *** solve-sv : (lisp_c) INDEX has wrong number of dimensions :
> ::INDEX2:<1x4>
>
> Doing a rather pointless thing: (solve-sv A x) actually satisfies
> the lush level bounds checking, but results in gsl aborting the
> process, i.e. bombing lush, returning me to the shell prompt:
>
> .......................................................................
> gsl: svd.c:371: ERROR: first dimension of matrix U must size of vector
> b
> Default GSL error handler invoked.
> Aborted
> .......................................................................
>
> To me, this indicates
>
> (1) a bug in the lush dimension check and
> (2) that lush should register its own error handler
> with the gsl error handling code
>
> But (as already mentioned) I am a lisp/lush newbie, I may be very
> wrong, so ANY comments/suggestions are much appreciated!
>
> Thomas
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf