I have not reached the conclusion but would like to give some status report.
My test case is simple:
------------------- a := LapackDGEMatrix rows: #(#(3 2 4) #(2 -5 -1) #(1 -2 2)). b := LapackDGEMatrix rows: #(#(1) (2) (3)). c := LapackLeastSquareProblem matrix: a rhsMatrix: b.
c solution. -------------------
If I evaluate this, the external call for 'dgesvd_' in CLapackDLibrary>>xgesvdWithjobu:jobvt:m:n:a:lda:s:u:ldu:vt:ldvt:work:lwork:info: fails.
But if I fix it by rewriting the cdecl line to:
<cdecl: long 'dgesvd_'( char * char * long * long * double * long * double * double * long * double * long * double * long * long * ) module: 'libLAPACK'>
from
<cdecl: long 'dgesvd_'( char * char * long * long * double * long * double * double * long * double * long * double * long * long * )>
it passes.
However, the value that gets stored in the 's' instance variable of LapackSVDecomposition is a LapackDGEMatrix, and when the resulting value is used in the #defaultTolerance, I get DNU for '*".
On Tue, Aug 9, 2016 at 3:26 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Correction: (sorry)
In a 64 bit image, TestCBlas runs fine but the ones listed above fails in a 32-bit image.
On Tue, Aug 9, 2016 at 3:12 PM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Thanks!
I am trying this from a vanilla 5.0 image and I see that ConfigurationOfSmallapack-nice.18 is loaded. Now, however, the following tests from Smallapack-SUnitTests category fail:
#('TestCBlas>>#testCsscal' 'TestCBlas>>#testSaxpy' 'TestCBlas>>#testSgemv' 'TestCBlas>>#testSgemvTrans' 'TestCBlas>>#testSger' 'TestCBlas>>#testSscal' 'TestCBlas>>#testStrsm' 'TestLapackMatrix>>#testMatrixProduct' 'TestLapackMatrix>>#testSum' 'TestRandMatrix>>#testOperationTiming')
As I wrote, TestCBlas used to be all green. I'll check what has changed since -nice.16...
On Sat, Aug 6, 2016 at 4:56 PM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
This should be fixed in ConfigurationOfSmallapack-nice.18 BTW, I think you can provide the absolute path to the .dylib instead of copying in local repository...
2016-08-06 23:29 GMT+02:00 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
Hi Yoshiki, thanks for reporting, I'll try better...
2016-08-01 0:48 GMT+02:00 Yoshiki Ohshima Yoshiki.Ohshima@acm.org:
I see you have some changes but it appears that evaluating the Installer do it goes into an infinite loop of #moduleName and #masOsxModuleName.
(Thanks again!)
On Sat, Jul 30, 2016 at 8:23 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
But some of TestLapackMatrix tests fail. A few external functions cannot be found, it looks like.
On Sat, Jul 30, 2016 at 7:55 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote: > Great! > > Before (I got into a meeting and then entered the "Friday mode", I was > going down the path of trying to call the Framework functions but > copying files anyway was a simpler solution for now. > > Yes, I got all tests green. Thank you! > > On Fri, Jul 29, 2016 at 3:24 PM, Nicolas Cellier > nicolas.cellier.aka.nice@gmail.com wrote: >> OK, what I did on my Mac: >> >> 1) look under the Squeak app and edit the Contents/Info.plist >> 2) change value of SqueakPluginsBuiltInOrLocalOnly to "No" >> otherwise library loading is restricted to the Squeak app bundle >> 3) copy the veclib framework library files (dylib) in same directory >> as >> squeak image >> 4) launch Squeak >> 5) install Smallapack >> follow instruction from >> >> https://github.com/nicolas-cellier-aka-nice/smallapack/wiki/SmallapackSqueak >> 6) change CBlasLibrary class>>moduleName 'libcblas.dylib' -> >> 'libBlas.dylib' >> nowadays, cblas and blas are in the same dylib... >> 7) change CLapackLibrary class>>moduleName 'libclapack.dylib' -> >> 'libLapack.dylib' >> idem >> 8) re-initialize the cache (I know, I know, there are too many...) >> CBlasLibrary install. CLapackLibrary install. LapackMatrix >> resetBlasInterfaces; resetLapackInterfaces. >> 9) run the TestCBlas suite >> >> It should be green >> I will commit the changes later, and will probably implement >> moduleNames as >> a Preference (pragma oriented). >> No need to override code anymore :) >> >> I think step 3) is necessary because of ioLoadModuleRaw() in >> platforms/iOS/vm/OSX/sqMacUnixExternalPrims.m >> >> https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/iOS/vm/... >> It would only look those frameworks: >> >> static char *frameworks[]= >> { >> "", >> "/CoreServices.framework/Frameworks", >> "/ApplicationServices.framework/Frameworks", >> "/Carbon.framework/Frameworks", >> 0 >> }; >> >> But I did step 3) before I tried 1) + 2), adn did not retry, so maybe >> I'm >> wrong... >> Scanning all the frameworks is not a solution. And what if we want a >> specific version? >> It would be far better to be able to specify the path to the library >> from >> within the image like VW... >> >> >> 2016-07-29 19:41 GMT+02:00 Nicolas Cellier >> nicolas.cellier.aka.nice@gmail.com: >>> >>> >>> >>> 2016-07-29 19:28 GMT+02:00 Nicolas Cellier >>> nicolas.cellier.aka.nice@gmail.com: >>>> >>>> >>>> >>>> 2016-07-29 19:02 GMT+02:00 Yoshiki Ohshima >>>> Yoshiki.Ohshima@acm.org: >>>>> >>>>> First question: >>>>> >>>>> The Mac OS comes with Accelerate.Framework and that contains BLAS. >>>>> But probably I still should compile those libraries, right? >>>>> >>>> >>>> No, it's better to link to accelerated library. >>>> I don't have a Mac handy here to verify how to link to it though. >>>> I'll be able to check latter in the evening >>>> >>> >>> >>> I've downloaded the code, and I see it now: the library names are >>> hardcoded (see implementors of moduleName). >>> For Mac it is libblas.dylib and libcblas.dylib >>> Also note that there is a preference for switching to cblas (blas >>> functions with C interface). >>> This should be faster because we pass some parameters by value >>> rather than >>> allocating them and pass reference... >>> >>> Module names could also be replaced by Preferences eventually, but >>> by now, >>> you'll have to override... >>> >>>>> >>>>> >>>>> On Thu, Jul 28, 2016 at 4:11 PM, Yoshiki Ohshima >>>>> Yoshiki.Ohshima@acm.org wrote: >>>>> > Thanks! >>>>> > >>>>> > On Thu, Jul 28, 2016 at 4:04 PM, Nicolas Cellier >>>>> > nicolas.cellier.aka.nice@gmail.com wrote: >>>>> >> Hi Yoshiki, >>>>> >> >>>>> >> Thanks for inquiring about Smallapack. >>>>> >> >>>>> >> This problem has been solved in 2011 as the post tells. >>>>> >> Moreover, it was about alignment of squeak objects that was on >>>>> >> multiple of 4 >>>>> >> on SqueakV3 memory. >>>>> >> Spur is 8 byte aligned, so the problem would have also vanished >>>>> >> without any >>>>> >> patch for those being patient :) >>>>> >> >>>>> >> For the 15 arguments limit, Smallapack comes with it's own >>>>> >> compiler, >>>>> >> so it's >>>>> >> a non issue. >>>>> >> Maybe I should make the documentation more clear on >>>>> >> >>>>> >> >>>>> >> https://github.com/nicolas-cellier-aka-nice/smallapack/wiki/SmallapackSqueak >>>>> >> ? >>>>> >> >>>>> >> Unfortunately, there's no Sparse Matrix representation in >>>>> >> Lapack. >>>>> >> If you know of a good package for that, it could be integrated. >>>>> >> >>>>> >> If you have other questions, don't hesitate to ask. >>>>> >> >>>>> >> cheers >>>>> >> >>>>> >> Nicolas >>>>> >> >>>>> >> 2016-07-29 0:22 GMT+02:00 Yoshiki Ohshima >>>>> >> Yoshiki.Ohshima@acm.org: >>>>> >>> >>>>> >>> I am trying to do a bit of linear algebra stuff that involves >>>>> >>> to >>>>> >>> solve >>>>> >>> a sparse 2D matrix (for a variation of doing least square >>>>> >>> fit). >>>>> >>> >>>>> >>> There was a message from Nicolas: >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2011-August/161113.ht... >>>>> >>> >>>>> >>> Is this where it stands today, too? It looks like that arg >>>>> >>> count >>>>> >>> problem is still there in 5.0, but is it in a way non-issue as >>>>> >>> it is >>>>> >>> still FFI based? >>>>> >>> >>>>> >>> Thanks! >>>>> >>> >>>>> >>> -- >>>>> >>> -- Yoshiki >>>>> >>> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > -- Yoshiki >>>>> >>>>> >>>>> >>>>> -- >>>>> -- Yoshiki >>>>> >>>> >>> >> >> >> >> > > > > -- > -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki
-- -- Yoshiki