[Gsll-devel] Problems with SVD through gsll on OS X 10.5 with SBCL

[Liam Healy]

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
Mahendran<nimalan.mahendran at 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
> Mahendran<nimalan.mahendran at 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-Decomposition.html,
>> 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 at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
>