gsll-devel

gsll-devel@common-lisp.net

246 discussions

Re: [Gsll-devel] practical differences between native CL array and the GSLL marray type?
by Malcolm Reynolds 30 Apr '09

30 Apr '09

Thanks for adding this so quick Thomas! Just pulled down the new version and it looks good. The specialisation for gsll-marrays looks like it should be quite easy, I might even tackle it myself if Liam has no objections.. One thing that would also be useful to me in my current work is to compare matrices for some degree of approximate equality - eg if Y is the pseudoinverse of the matrix X, then the properties XYX = X and YXY = Y should hold, but there is likely to be some numerical aberrations. I thought about a function for numerical-approximately-equal, with a tolerance parameter, but now I think probably the best way to handle this is to pass in a custom :test function. Would you agree? Malcolm On Wed, Apr 15, 2009 at 5:02 AM, Thomas M. Hermann <tmh.public(a)gmail.com> wrote: > The NUMERICAL-EQUAL function has been implemented as a generic function > in LISP-UNIT. It is specialized for the system classes NUMBER, LIST, > VECTOR and ARRAY. It has been lightly tested. The documentation has not > been updated. Please note that when you specialize it for your data > type, a congruent argument list is (RESULT1 RESULT2 &KEY TEST). This > will be clear when the documentation is updated. > > Also note that the versions specialized for the CL system classes are > for RESULT1 and RESULT2 of the same class, so, for example > > (NUMERICAL-EQUAL LIST ARRAY) ; Not defined => an error > > will throw an error. I'll get around to defining the mixed class > versions later. Sooner if there is a real need for them. > > Please feel free to email me bugs and further suggestions. > > Cheers, > > Tom > > Liam Healy wrote: >> I haven't defined such a predicate, but I think it's a good idea. As >> you have seen, in order to do tests on marrays, I turn all the marrays >> into CL arrays and do the comparisons on the result. I don't know if >> it's the best possible way to do it, but it works. You get an error >> from assert-numerical-equal because it uses #'numerical-equal as a >> test, and that does not handle marrays. Your suggestion spurred me >> to take a look at the lisp-unit source; what I'm thinking about is >> changing #'numerical-equal to a generic function with some methods >> pre-defined for CL classes; this would permit applications like GSLL >> to add methods for their own objects. >> >> I've cc'ed Tom Hermann on this email; he is behind the modified >> version of lisp-unit more so than I am. >> Tom: what do you think of this idea? >> >> Liam >> >> >> On Mon, Apr 13, 2009 at 11:05 AM, Malcolm Reynolds >> <malcolm.reynolds(a)gmail.com> wrote: >>> On a related point, I'm writing some unit tests using your modified >>> version of lisp-unit (the one from repo.or.cz) and I haven't as yet >>> been able to figure out a good way to compare two matrices for >>> equality. In the automatically generated tests in the GSLL code it >>> appears you do (cl-array ...) to convert the matrices back to native >>> form. Is this the best way possible, or is there some numerical >>> equality predicate in the gsll library that I've missed? It would seem >>> to be ideal to be able to >>> define a test by (assert-numerical-equal <marray 1> <marray 2>) but I >>> get an error message when I try this... >>> >>> Malcolm >>> >>> On Mon, Apr 13, 2009 at 2:24 PM, Malcolm Reynolds >>> <malcolm.reynolds(a)gmail.com> wrote: >>>> Hi Liam, thanks for your response. >>>> >>>> Glad to hear that marrays are recommended, and especially that they >>>> are implemented well on SBCL as that is what I'm using. >>>> >>>> As for the million element square matrices then yes, clearly on >>>> reflection that won't work. Some of the matrices I'm using will be >>>> sparse, but some will not be sparse at all - without wanting to get >>>> bogged down in details, I'm going to need to represent the Graph >>>> Laplacian, which is a matrix that is equal to the degree matrix minus >>>> the adjacency matrix (and so in a fairly sparse graph this matrix is >>>> sparse) but I will also need the graph Kernel, which is the >>>> pseudoinverse of the Laplacian. This will not be sparse at all, so >>>> clearly a direct representation of it isn't possible. I know of >>>> someone in my university's department who has a fast method for this >>>> kind of situation which means that calculating the full kernel matrix >>>> is unnecessary, so I guess I can look into that if and when I find >>>> that performance is a limiting factor. >>>> >>>> Anyway thanks again for your response, and for your hard work on GSLL. >>>> I'm pretty new to lisp and I'm continuously impressed by the quality >>>> of the libraries! >>>> >>>> Malcolm >>>> >>>> On Sat, Apr 11, 2009 at 3:46 PM, Liam Healy <lhealy(a)common-lisp.net> wrote: >>>>> Yes, it is definitely my recommendation to use marrays >>>>> everywhere. I am starting to get in the habit of doing so >>>>> myself. One of my ideas is to extend CL array operations to >>>>> marrays so that you need not convert back and forth. It is >>>>> also my intent that other math software libraries would also >>>>> use marrays (or an extension of them), so that they become a >>>>> standard way to interchange data between libraries. >>>>> >>>>> There is more overhead for marrays than plain arrays, but on >>>>> SBCL where the native arrays are used in GSL directly, there >>>>> is very little, and there is no copying. I recommend that >>>>> you build it with marray and then see if you have >>>>> performance problems. However, if you are talking matrices >>>>> of 1000000x1000000, I think you will have problems in any >>>>> representation on almost any kind of hardware. For single >>>>> floats, one such matrix is 4TB. In that case, I recommend >>>>> you rethink the problem structure. If these are sparse >>>>> matrices, you should use a sparse matrix representation. >>>>> GSL doesn't have such a representation, but others have been >>>>> interested in having it so it might be worth posting >>>>> something to the GSL mailing list -- perhaps someone has >>>>> written a GSL-compatible sparse array representation. >>>>> >>>>> Liam >>>>> >>>>> >>>>> >>>>> On Sat, Apr 11, 2009 at 8:12 AM, Malcolm Reynolds >>>>> <malcolm.reynolds(a)gmail.com> wrote: >>>>>> Hi all, hope this is the right place for this kind of request. >>>>>> >>>>>> I'm writing a program which will be doing Machine Learning over graph >>>>>> data structures. In it I'm going to be needing to represent a bunch of >>>>>> matrices, some sparse, some definitely not sparse, and do fairly basic >>>>>> operations on these matrices (add/ subtract/multiply, pseudoinverse, >>>>>> probably some others). I've started a basic prototype using the >>>>>> standard CL arrays but I always knew I would need GSLL to calculate a >>>>>> pseudo inverse. >>>>>> >>>>>> My question is, would it be a reasonably sensible decision to just use >>>>>> marrays for the whole program rather than worrying >>>>>> about converting to/ from CL-type arrays all the time? Are there any >>>>>> places where CL-arrays beat marrays either in terms of memory usage, >>>>>> access speed, or anything else? I might be needing to scale this >>>>>> system up be dealing with N*N square matrices where N is on the order >>>>>> of hundreds of thousands or even millions, if that makes any >>>>>> difference to the recommendation. >>>>>> >>>>>> Thanks in advance for any help! >>>>>> >>>>>> Malcolm Reynolds >> > > -- > === Thomas M. Hermann === >

2 9

[Gsll-devel] Extracting sub-matrices and sub-vectors?
by Malcolm Reynolds 30 Apr '09

30 Apr '09

Hi guys, I've been out of the country for a while but I'm getting back to work on my project. Something else I've been wondering about for GSLL is whether there is a way to quickly extract sub-matrices and especially sub-vectors from a matrix. Something with power equivalent to the matlab indexing using a colon to express ranges would be amazing but I guess probably quite nasty to implement efficiently. However, what would help me even more right now is a way to extract rows / columns from a matrix, without copying. I currently use a do-loop to run through the indices I want, but since the internals of the storage appear to be row major, is there a way to get a "pointer" (not sure if this is preferred lisp terminology, sorry) to an individual row? To clarify, if I do (defvar x (make-marray 'double-float :initial-contents '((1 2 3) (4 5 6) (7 8 9)))) is there any efficient way (ie don't need to copy element by element to a new object) thatI can get a reference to the row (4 5 6) of that, either as a gsll::matrix or gsll::vector object? If structure was shared between the matrix and the vector that would be no problem, it would be ideal in fact. Regards Malcolm Malcolm

2 2

[Gsll-devel] practical differences between native CL array and the GSLL marray type?
by Malcolm Reynolds 14 Apr '09

14 Apr '09

Hi all, hope this is the right place for this kind of request. I'm writing a program which will be doing Machine Learning over graph data structures. In it I'm going to be needing to represent a bunch of matrices, some sparse, some definitely not sparse, and do fairly basic operations on these matrices (add/ subtract/multiply, pseudoinverse, probably some others). I've started a basic prototype using the standard CL arrays but I always knew I would need GSLL to calculate a pseudo inverse. My question is, would it be a reasonably sensible decision to just use marrays for the whole program rather than worrying about converting to/ from CL-type arrays all the time? Are there any places where CL-arrays beat marrays either in terms of memory usage, access speed, or anything else? I might be needing to scale this system up be dealing with N*N square matrices where N is on the order of hundreds of thousands or even millions, if that makes any difference to the recommendation. Thanks in advance for any help! Malcolm Reynolds

2 4

[Gsll-devel] bugreport: matrix operations after garbage collection on sbcl
by Norman Werner 04 Apr '09

04 Apr '09

Hello, The following code reproducably yields a wrong result: (progn (setf a (parse-gsl-array " [1 1 1 ; 1 1 1]")) (setf b (parse-gsl-array " [1 1 1 ; 1 1 1]")) (sb-ext:gc) ;;without gc everything is fine (gsll:elt+ a b)) I have no ideo what is going on here especially since my knowledge of garbage collection is quite limited. This is on sbcl (1.0.18 from debian stable). Regards Norman -- Norman Werner Im Sommerwind 1a 70563 Stuttgart

1 1

[Gsll-devel] Functions passed with function designators only
by Liam Healy 01 Apr '09

01 Apr '09

I have made a change to how functions ("callbacks") are passed to GSL. Previously, it was necessary to write the function(s) as separate defun(s) and then define make-callback on them. Now, you simply pass a function designator (function object or symbol representing a function object). For example, to integrate sine from 0 to pi, (integration-qng 'sin 0.0d0 pi) or to integrate the sine of the square root of x, (integration-qng (lambda (x) (sin (sqrt x))) 0.0d0 pi) This goes for all functions and mobjects that pass functions to GSL. Many functions that took lists of functions (such as function, df, fdf) now take the functions separately. The argument 'scalarsp is present in many mobject creators; if set to T, your function(s) will be passed array arguments as separate elements, and should return multiple values of elements in proper order for any returned array(s). If you are using any of these definitions, you will need to remove your make-callback forms and update the calling after you pull the new master branch. Liam

1 0

[Gsll-devel] contrib: using iterate with gsll
by Norman Werner 31 Mar '09

31 Mar '09

Hello As it was a little bit cloudy I used this sunday to find a way to use iterate (http://common-lisp.net/project/iterate/) with gsll. The following code does not rely on any other libraries than gsll and iterate, it "should work" - however it was not heavily testet. As an example try: (setf m1 (gsll:make-marray 'double-float :initial-contents '((1 2 3) (0 6 8)))) (iterate:iterate (iterate:for e ELEMENT-IN-GSLL-MATRIX m1) (format t "~A " e)) (iterate:iterate (iterate:for (row column) INDEXES-IN-GSLL-MATRIX m1) (format t "~A " (gsll:maref m1 row column))) ===========CODE STARTS HERE =============== (iterate:defclause-sequence iterate::ROW-IN-GSLL-MATRIX iterate::ROW-INDEX-OF-GSLL-MATRIX :access-fn (lambda (marray index) (typecase marray (gsll::matrix (gsll:row marray index)) (gsll::vector (error "iterating over the rows in a vector is not supported. You may want iterate over its elements instead")) (t (error "only iterating over rows of an gsll:matrix is supported")))) :size-fn (lambda (marray) (typecase marray (gsll::matrix (elt (gsll:dimensions marray) 0)) (gsll::vector (error "iterating over the rows in a vector is not supported. You may want iterate over its elements instead")) (t (error "only iterating over rows of an gsll:matrix is supported")))) :element-type t :sequence-type t :element-doc-string "(copied) rows of a gsll matrix" :index-doc-string "index of the rows in a gsll matrix") (iterate:defclause-sequence iterate::COLUMN-IN-GSLL-MATRIX COLUMN-INDEX-OF-GSLL-MATRIX :access-fn (lambda (marray index) (typecase marray (gsll::matrix (gsll:column marray index)) (gsll::vector (error "iterating over the columns in a vector is not supported. You may want iterate over its elements instead")) (t (error "only iterating over columns of an gsll:matrix is supported")))) :size-fn (lambda (marray) (typecase marray (gsll::matrix (elt (gsll:dimensions marray) 1)) (gsll::vector (error "iterating over the columns in a vector is not supported. You may want iterate over its elements instead")) (t (error "only iterating over columns of an gsll:matrix is supported")))) :element-type t :sequence-type t :element-doc-string "(copied) columns of a gsll matrix" :index-doc-string "index of the columns in a gsll matrix") (iterate:defclause-sequence iterate::ELEMENT-IN-GSLL-VECTOR iterate::INDEX-OF-GSLL-VECTOR :access-fn (lambda (vector index) (typecase vector (gsll::mvector (gsll:maref vector index)) (t (error "only iterating over elements of an gsll:vector is supported")))) :size-fn (lambda (vector) (typecase vector (gsll::mvector (elt (gsll:dimensions vector) 0)) (t (error "only iterating over elements of an gsll:vector is supported")))) :element-type t :sequence-type t :element-doc-string "(copied) elements of a gsll vector" :index-doc-string "index of elements in a gsll vector") (iterate:defmacro-driver (iterate:FOR element iterate::ELEMENT-IN-GSLL-MATRIX matrix) "Iterates over all (copied) Elements in matrix" (let ((row-index (gensym "row-index")) (col-index (gensym "col-index")) (row-size (gensym "row-size")) (col-size (gensym "col-size")) (m (gensym "m"))) (when iterate::generate (error "not yet implemented a generate clause for iterate::ELEMENT-IN-GSLL-MATRIX")) `(progn (iterate:with ,m = ,matrix) (iterate:with ,row-index = 0) (iterate:with ,col-index = 0) (iterate:with ,row-size = (elt (gsll:dimensions ,m) 0)) (iterate:with ,col-size = (elt (gsll:dimensions ,m) 1)) (iterate::for ,element iterate::next (if (>= ,row-index ,row-size) (iterate::terminate) (if (>= ,col-index ,col-size) (progn (setf ,col-index 0) (incf ,row-index) (if (>= ,row-index ,row-size) (iterate::terminate) (gsll:maref ,m ,row-index ,col-index))) (prog1 (gsll:maref ,m ,row-index ,col-index) (incf ,col-index)))))))) (iterate:defmacro-driver (iterate:FOR indexes iterate::INDEXES-IN-GSLL-MATRIX matrix) "Iterates over the indexes in matrix. indexes is a list like (row-index-name column-index-name) " (let ((row-index (gensym "row-index")) (col-index (gensym "col-index")) (row-size (gensym "row-size")) (col-size (gensym "col-size")) (m (gensym "m"))) (when iterate::generate (error "not yet implemented a generate clause for iterate::INDEXES-IN-GSLL-MATRIX")) `(progn (iterate:with ,m = ,matrix) (iterate:with ,row-index = 0) (iterate:with ,col-index = 0) (iterate:with ,row-size = (elt (gsll:dimensions ,m) 0)) (iterate:with ,col-size = (elt (gsll:dimensions ,m) 1)) (iterate::for ,indexes iterate::next (if (>= ,row-index ,row-size) (iterate::terminate) (if (>= ,col-index ,col-size) (progn (setf ,col-index 0) (incf ,row-index) (if (>= ,row-index ,row-size) (iterate::terminate) (list ,row-index ,col-index))) (prog1 (list ,row-index ,col-index) (incf ,col-index)))))))) ============ Code ENDS HERE =============== If you think this could be usefull for others just include it into the distribution (be aware that it adds a dependency on iterate) or just add some paragraphs to the documentation. Regards Norman -- Norman Werner Im Sommerwind 1a 70563 Stuttgart

2 1

Re: [Gsll-devel] SVD problem
by Liam Healy 16 Mar '09

16 Mar '09

Viktor, I've pushed to master a new version that I hope solves your problem, as well as the other mysterious SBCL problems reported here. When I run your (test 1000) there is no error and it looks reasonable. Please pull it, try again, and post your results. Liam On Sun, Mar 15, 2009 at 11:15 AM, Viktor Leis <viktor.leis(a)googlemail.com> wrote: > Great! Thanks for the effort. > > Viktor > > On Sun, Mar 15, 2009 at 3:55 PM, Liam Healy <lhealy(a)common-lisp.net> wrote: >> After a conversation with Paul Khuong on #lisp, I think we have figured out what >> is causing this problem. I need to change the way the array pointers >> are used in SBCL. >> I don't think it's too complicated a fix, but I am in the midst of >> something else so I can't >> get to it right away. >> >> Liam >> >> On Mon, Mar 9, 2009 at 5:26 AM, Viktor Leis <viktor.leis(a)googlemail.com> wrote: >>> I'm using SBCL 1.0.25 on AMD64 and SBCL 1.0.17 on a 32-bit box. >>> By nonsense results I mean wrong results: the second return value >>> contains only zeros. >>> When SBCL crashes I either get a SB-SYS:MEMORY-FAULT-ERROR or "fatal >>> error encountered in SBCL pid 31660(tid 140110828128592): no scavenge >>> function for object 0x79109fe4 (widetag 0xe4)". This definitely looks >>> like an SBCL bug. >>> >>> Viktor >>> >>> On Mon, Mar 9, 2009 at 12:27 AM, Liam Healy <lhealy(a)common-lisp.net> wrote: >>>> Viktor, >>>> >>>> What version of SBCL are you running, and what do you mean by >>>> "nonsense results"? >>>> When I run sbcl 1.0.18.debian, I get an error from (test 1000) which >>>> looks like it's in >>>> the printing routine as it tries to return the answer matrix: >>>> debugger invoked on a SB-SYS:MEMORY-FAULT-ERROR in thread #<THREAD >>>> "initial thread" RUNNING {10039ADBF1}>: >>>> Unhandled memory fault at #x0. >>>> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. >>>> restarts (invokable by number or by possibly-abbreviated name): >>>> 0: [ABORT] Exit debugger, returning to top level. >>>> (SB-SYS:MEMORY-FAULT-ERROR) >>>> 0] >>>> WARNING: Starting a select without a timeout while interrupts are disabled. >>>> :ba >>>> 0: (SB-SYS:MEMORY-FAULT-ERROR) >>>> 1: (SB-SYS:MEMORY-FAULT-ERROR)[:EXTERNAL] >>>> 2: ("foreign function: #x41EAA2") >>>> 3: ("foreign function: #x41EB70") >>>> 4: ("foreign function: #x40D53D") >>>> 5: ("foreign function: #x41CA5C") >>>> 6: (SB-KERNEL::COLLECT-GARBAGE 0) >>>> 7: ((FLET SB-THREAD::WITH-MUTEX-THUNK)) >>>> 8: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-MUTEX]477)) >>>> 9: ((FLET #:WITHOUT-INTERRUPTS-BODY-[SUB-GC]60)) >>>> 10: (SB-KERNEL:SUB-GC)[:EXTERNAL] >>>> 11: ("foreign function: #x41EAA2") >>>> 12: ("foreign function: #x40D435") >>>> 13: ("foreign function: #x4116C3") >>>> 14: (SB-BIGNUM:MULTIPLY-BIGNUM-AND-FIXNUM >>>> #<unavailable argument> >>>> #<unavailable argument>) >>>> 15: (SB-IMPL::FLONUM-TO-DIGITS >>>> 0.006426902231453881d0 >>>> #<unavailable argument> >>>> NIL) >>>> 16: (SB-IMPL::OUTPUT-FLOAT-AUX >>>> 0.006426902231453881d0 >>>> #<SB-PRETTY:PRETTY-STREAM {100631AE51}> >>>> -3 >>>> 8) >>>> 17: (SB-PRETTY:OUTPUT-PRETTY-OBJECT >>>> 0.006426902231453881d0 >>>> #<SB-PRETTY:PRETTY-STREAM {100631AE51}>) >>>> 18: ((FLET #:WITH-PRETTY-STREAM-2825) #<SB-PRETTY:PRETTY-STREAM {100631AE51}>) >>>> 19: ((LABELS SB-PRETTY::OUTPUT-GUTS) >>>> #<SB-PRETTY:PRETTY-STREAM {100631AE51}> >>>> 0 >>>> (1000)) >>>> 20: ((FLET #:WITH-PRETTY-STREAM-2825) #<SB-PRETTY:PRETTY-STREAM {100631AE51}>) >>>> 21: ((LABELS SB-PRETTY::OUTPUT-GUTS) >>>> #<SB-PRETTY:PRETTY-STREAM {100631AE51}> >>>> 0 >>>> (1000 1000)) >>>> 22: (SB-PRETTY:OUTPUT-PRETTY-OBJECT >>>> #2A((-0.03152179146033235d0 -0.0064356015982750805d0 >>>> 0.031318650821186636d0 0.021215786371980315d0 0.003314355400406193d0 >>>> 0.0033404976598180773d0 -0.024914202255263d0 0.022145320720119623d0 >>>> -0.023703547290539858d0 0.010257175021330184d0 >>>> ... >>>> 23: (PRINC >>>> #2A((-0.03152179146033235d0 -0.0064356015982750805d0 >>>> 0.031318650821186636d0 0.021215786371980315d0 0.003314355400406193d0 >>>> ... >>>> >>>> I didn't try (test 3000). >>>> By the way, I tried Clozure CL 1.2 on the same platform (Debian >>>> amd64) with both >>>> (test 1000) and (test 3000), and both run to completion and look >>>> reasonable, so I >>>> think at least what I'm seeing is a problem with SBCL. >>>> >>>> Liam >>>> >>>> On Sun, Mar 8, 2009 at 8:11 AM, Viktor Leis <viktor.leis(a)googlemail.com> wrote: >>>>> Hi, >>>>> >>>>> I've got a problem with singular value decomposition: Big matrices >>>>> (e.g. 3000x3000) crash SBCL. With a matrix of 1000x1000 it doesn't >>>>> crash but instead I usually get nonsense results. With a small matrix >>>>> (e.g. 500x500) it works perfectly fine. I get the same behavior on 32 >>>>> and 64 bit Linux. >>>>> >>>>> (defun test (n) >>>>> (let ((a (make-marray 'double-float :dimensions (list n n))) >>>>> (s (make-marray 'double-float :dimensions n)) >>>>> (v (make-marray 'double-float :dimensions (list n n)))) >>>>> (dotimes (i n) >>>>> (dotimes (j n) >>>>> (setf (maref a i j) (random 1.0d0)))) >>>>> (multiple-value-list (sv-decomposition a s v)))) >>>>> >>>>> Viktor Leis >>>> >>> >> >

2 1

Re: [Gsll-devel] Strange behaviour on REPL
by Liam Healy 16 Mar '09

16 Mar '09

ozgur, If you haven't been following the "SVD problem" thread from Viktor, I have fixed a problem with the way SBCL handles arrays. I have a feeling that what you are seeing is a symptom of the same problem. Pull the latest version, try again, and post your results. Thanks. Liam On Sun, Mar 15, 2009 at 3:01 PM, ozgur <ozgurican(a)gmail.com> wrote: > I was able to reproduce similar erroneous behaviour on my other Ubuntu 8.04 > box on Emacs 21-X + Slime and SBCL 1.0.11.debian binary version. Even though > max-index and min-index behaved correctly after i've computed standard > deviation on the vector,max-index started to behave incorrectly after some > interactive commands in REPL. I should also note that max-index had behaved > correctly when i started this session. Here it is:

1 0

[Gsll-devel] Strange behaviour on REPL
by ozgur 13 Mar '09

13 Mar '09

Hi to all; During a Slime REPL i ' ve run into this weird situation: min-index(or max-index) function returns a false index after computing standard deviation on the vector. Even the more strange thing is; it happens some times in REPL even if i do not make any computations on GSL vector. It also happens in some other stuff like "dot" function in REPL. My environment is: - Emacs 22.2.1 GTK+ version - SBCL 1.0.18 Debian and latest Slime + GSLL Is there anyone who has an idea? =========================== MAIN> z (14251 86635 60784 78558 53917 48603 84066 72312 84507 69247 53053 91973 116426 46241 59753 72637 96668 74113 87682 55315 61885 80976 75919 78000 73473 68500 90708 72015 76385 82901 84680 61214 121564 54791 79807 65935 59139 75268 81570 81243 65808 98473 57104 72086 53659 40330 68685 65409 59822 58165 465

1 0

[Gsll-devel] SVD problem
by Viktor Leis 09 Mar '09

09 Mar '09

Hi, I've got a problem with singular value decomposition: Big matrices (e.g. 3000x3000) crash SBCL. With a matrix of 1000x1000 it doesn't crash but instead I usually get nonsense results. With a small matrix (e.g. 500x500) it works perfectly fine. I get the same behavior on 32 and 64 bit Linux. (defun test (n) (let ((a (make-marray 'double-float :dimensions (list n n))) (s (make-marray 'double-float :dimensions n)) (v (make-marray 'double-float :dimensions (list n n)))) (dotimes (i n) (dotimes (j n) (setf (maref a i j) (random 1.0d0)))) (multiple-value-list (sv-decomposition a s v)))) Viktor Leis

2 2

← Newer
1
...
16
17
18
19
20
21
22
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

gsll-devel