Hello everyone,
I'm trying to see whether I could use SBCL (or whatever CL implementation) as an alternative for Matlab in machine learning research. I have gsll running, but I saw that gsll's SVD, (sv-decomposition u s v) is converging to the wrong answers for the identity matrix.
M = [1 0 0; 0 1 0; 0 0 1]
but Matlab's SVD works fine.
Here's what happens in gsll/SBCL:
(setf M1 (MAKE-MARRAY '(UNSIGNED-BYTE 32) :INITIAL-CONTENTS '((1 0 0) (0 1 0) (0 0 1)))) (setf u (copy m1)) (setf s (make-marray 'vector-unsigned-byte-32 :dimensions 3)) (setf v (make-marray 'matrix-unsigned-byte-32 :dimensions '(3 3))) (sv-decomposition u s v)
GSL> u #<MATRIX-UNSIGNED-BYTE-32 #2A((0 0 0) (2147483648 0 3220176896) (0 2147483648 0))> GSL> s #<VECTOR-UNSIGNED-BYTE-32 #(268809831 296241371 268543215)> GSL> v #<MATRIX-UNSIGNED-BYTE-32 #2A((2083159301 2991920483 0) (2147483648 0 1072693248) (0 3220176896 0))> GSL>
The answers are definitely not right.. I don't think the right memory addresses are even being accessed.
I noticed in the definition of SV-decomposition in svd.lisp, the :outputs parameter is (A S V), but according to the GSL documentation at http://www.gnu.org/software/gsl/manual/html_node/Singular-Value-Decompositio..., maybe it should be (A V S)? I'm not sure how these parameters to defmfun actually work or what they mean (although I am familiar with cffi..). I was getting the same numbers even when I did SVD on this matrix:
M = [1 0 0; 0 2 0; 0 0 3]
so a memory access error seems likely to me.
Would someone mind helping me fix this?
Thanks!
Hi,
Sorry, I made a stupid/obvious mistake - (unsigned-byte 32) instead of some kind of floating-point number :P It would be nice to have an error message though..
Thanks for gsll, it's been pretty useful so far.
On Fri, Jun 19, 2009 at 12:54 AM, Nimalan Mahendrannimalan.mahendran@gmail.com wrote:
Hello everyone,
I'm trying to see whether I could use SBCL (or whatever CL implementation) as an alternative for Matlab in machine learning research. I have gsll running, but I saw that gsll's SVD, (sv-decomposition u s v) is converging to the wrong answers for the identity matrix.
M = [1 0 0; 0 1 0; 0 0 1]
but Matlab's SVD works fine.
Here's what happens in gsll/SBCL:
(setf M1 (MAKE-MARRAY '(UNSIGNED-BYTE 32) :INITIAL-CONTENTS '((1 0 0) (0 1 0) (0 0 1)))) (setf u (copy m1)) (setf s (make-marray 'vector-unsigned-byte-32 :dimensions 3)) (setf v (make-marray 'matrix-unsigned-byte-32 :dimensions '(3 3))) (sv-decomposition u s v)
GSL> u #<MATRIX-UNSIGNED-BYTE-32 #2A((0 0 0) (2147483648 0 3220176896) (0 2147483648 0))> GSL> s #<VECTOR-UNSIGNED-BYTE-32 #(268809831 296241371 268543215)> GSL> v #<MATRIX-UNSIGNED-BYTE-32 #2A((2083159301 2991920483 0) (2147483648 0 1072693248) (0 3220176896 0))> GSL>
The answers are definitely not right.. I don't think the right memory addresses are even being accessed.
I noticed in the definition of SV-decomposition in svd.lisp, the :outputs parameter is (A S V), but according to the GSL documentation at http://www.gnu.org/software/gsl/manual/html_node/Singular-Value-Decompositio..., maybe it should be (A V S)? I'm not sure how these parameters to defmfun actually work or what they mean (although I am familiar with cffi..). I was getting the same numbers even when I did SVD on this matrix:
M = [1 0 0; 0 2 0; 0 0 3]
so a memory access error seems likely to me.
Would someone mind helping me fix this?
Thanks!
Nimalan Mahendran
I kind of agree there should be a more explicit error, but I have mixed feelings on this, and to the request I received recently to auto-coerce scalars that aren't double-floats into double-floats which is the predominant scalar type in GSL. The fact of life is the vast majority of GSLL functions take double-floats (or marrays of double-floats), and that's it. The BLAS functions are an exception in that they usually have single-float and complex forms (4 in total), and some of the math functions take all element types. In these cases the functions are defined as generic functions so if incorrect arguments are supplied, a "no method" error will be signalled, which is fine.
For everything else, well, on the one hand, I, like everyone else, wants a matlaby-type of interactive system where I pound out my problem, hit enter, and get an answer. I don't want an overly fussy rejection because I typed "2" instead of "2.0d0" etc. On the other hand, I don't see check-type or coerce used very often as routine filtering of input for lisp functions. I think this is a small clash of cultures. Traditional programming (batch-style edit, compile, link, run) one is expected to match types correctly. A "desk calculator" (e.g, Matlab) style of interactive use permits sloppiness. I imagine people use CL and GSLL for both styles. For people who are writing programs, there's a small cost to the repeated check-type or coerce and good style suggests that the programmer should simply stick with double-float.
Something of this sort is on my to-do list, but it's not likely to happen soon, due to other things on my list. I'll need to think about what form this should take. I'm happy to hear people's thoughts on this.
In the meantime Nimalan, the lesson to be learned for GSL/GSLL is "(almost) always use double-float".
Liam
On Sat, Jun 20, 2009 at 10:31 AM, Nimalan Mahendrannimalan.mahendran@gmail.com wrote:
Hi,
Sorry, I made a stupid/obvious mistake - (unsigned-byte 32) instead of some kind of floating-point number :P It would be nice to have an error message though..
Thanks for gsll, it's been pretty useful so far.
On Fri, Jun 19, 2009 at 12:54 AM, Nimalan Mahendrannimalan.mahendran@gmail.com wrote:
Hello everyone,
I'm trying to see whether I could use SBCL (or whatever CL implementation) as an alternative for Matlab in machine learning research. I have gsll running, but I saw that gsll's SVD, (sv-decomposition u s v) is converging to the wrong answers for the identity matrix.
M = [1 0 0; 0 1 0; 0 0 1]
but Matlab's SVD works fine.
Here's what happens in gsll/SBCL:
(setf M1 (MAKE-MARRAY '(UNSIGNED-BYTE 32) :INITIAL-CONTENTS '((1 0 0) (0 1 0) (0 0 1)))) (setf u (copy m1)) (setf s (make-marray 'vector-unsigned-byte-32 :dimensions 3)) (setf v (make-marray 'matrix-unsigned-byte-32 :dimensions '(3 3))) (sv-decomposition u s v)
GSL> u #<MATRIX-UNSIGNED-BYTE-32 #2A((0 0 0) (2147483648 0 3220176896) (0 2147483648 0))> GSL> s #<VECTOR-UNSIGNED-BYTE-32 #(268809831 296241371 268543215)> GSL> v #<MATRIX-UNSIGNED-BYTE-32 #2A((2083159301 2991920483 0) (2147483648 0 1072693248) (0 3220176896 0))> GSL>
The answers are definitely not right.. I don't think the right memory addresses are even being accessed.
I noticed in the definition of SV-decomposition in svd.lisp, the :outputs parameter is (A S V), but according to the GSL documentation at http://www.gnu.org/software/gsl/manual/html_node/Singular-Value-Decompositio..., maybe it should be (A V S)? I'm not sure how these parameters to defmfun actually work or what they mean (although I am familiar with cffi..). I was getting the same numbers even when I did SVD on this matrix:
M = [1 0 0; 0 2 0; 0 0 3]
so a memory access error seems likely to me.
Would someone mind helping me fix this?
Thanks!
Nimalan Mahendran
-- Nimalan Mahendran
Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
-
Liam Healy -
Nimalan Mahendran