Thanks Scott. My gut reaction is that it is absurd for pure j svd to out-perform lapack. On a brief look, it seems the j lapack addon does not calculate an optimized workspace size but just calculates a sufficiently large one. I'll try and get back later. On Aug 14, 2014 9:34 AM, "Scott Locklin" <[email protected]> wrote:
> Bill: > > The SVD operation returns the values: > 'u s v' =. svd trn > > The J version returns the diagonal, which is what you want. The lapack > version for some reason returns the whole array with all the 0's. So, to > match them up: > > 'ul sl vl' =. gesvd_jlapack_ trn > > +/ s=(<0 1)&|: sl > > In this case, you get all 30 singular values matching up. > > I guess allocating a 10000, 30 array to return 30 numbers is wasteful, but > I'm pretty sure the slow down is some other problem. I can fiddle with the > build on my end, since I'm probably responsible for the shared object, but > the ultimate fix will probably involve calling dgesdd, hopefully from the > new lapacke wrappers. > > Meanwhile, kudos to whoever wrote math/misc/svd, as it works really well, > even on very large problems. > > -SL > > "bill lam-2": > >Both svd and gesvd return a 3 element box vector, but the shapes of array > >inside box are different. Do their results agree with each other? > >I'll take a look at the bug in j lapack. > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
