Hello all,
Are any of you doing scientific computing on Pharo? I have some seriously old Numerical Recipes code that I altered and compiled, and more recently have used the GNU Scientific Library. All of that is connected to Dolphin, and it will take some time to adapt it to Pharo. Even more recently, I found reason to exceed GSL's feature list, and Octave might be able to do the job. The first thing would be do the minimum work to get some data into Octave and see how it does. Ideally, I would want to pipe data into Octave, get results from it, and then do some post-processing in Pharo. In GSL (dll/so) terms, the idea is to do all of the memory management and algorithm level work in Smalltalk, and the tight loops via the external code, and hopefully to do all of that w/o littering the drive with temporary files. Any experience, good or bad, in those directions? Bill _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Hi Bill,
I tried to port Smallapack - a Smalltalk interface to Lapack - into squeak but never finished it... google it if you have time to loose. It works on VW and Dolphin yet. In squeak, I have chosen to use FFI, but maybe it would have been more secure to generate a VM plugin... As you may know, Lapack is a very stable robust and public domain algebra library used for example in Matlab, Octave, Scilab, etc... It is my number one choice far above gsl. Now the idea to go thru octave interpreter might work as well. You may however loose some time in interpreting inputs/outputs back and forth... Depends on the volume of I/O you are planning. I presume there is also an access possible to an octave engine doable via plugin/FFI, passing directly Octave objects to Octave functions... Nicolas 2009/7/24 Schwab,Wilhelm K <[hidden email]>: > Hello all, > > Are any of you doing scientific computing on Pharo? I have some seriously old Numerical Recipes code that I altered and compiled, and more recently have used the GNU Scientific Library. All of that is connected to Dolphin, and it will take some time to adapt it to Pharo. Even more recently, I found reason to exceed GSL's feature list, and Octave might be able to do the job. > > The first thing would be do the minimum work to get some data into Octave and see how it does. Ideally, I would want to pipe data into Octave, get results from it, and then do some post-processing in Pharo. In GSL (dll/so) terms, the idea is to do all of the memory management and algorithm level work in Smalltalk, and the tight loops via the external code, and hopefully to do all of that w/o littering the drive with temporary files. > > Any experience, good or bad, in those directions? > > Bill > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Nicolas,
Thanks for your reply. I am aware of lapack, and will give it some more consideration. However, I am mostly interested in FFTs, wavelets, and least squares fits; GSL is a nice entry point. Do you have a better recommendation? Recent work leads me to something that could (I think) be expressed as a non-linear least squares fit on complex valued functions. Options include finding something that can crunch the problem as-is, which Octave might be able to do, and doing a lot of algebra to reduce everything (which I again _think_ is possible) to real-valued functions and then turn GSL's Levenberg-Marquardt algorithm loose on it. Mapping GSL into Dolphin was not a small job and is not by any means complete, though I was able to automate parts of it. The result is nice, because the I/O, memory management and algorithms can be done in Smalltalk, and compiled C/C++ does the tight loops that would be slow in Smalltalk. Presumably, Octave would offer a similar mix of fast basic routines and a relatively slow interpreter making the calls. The snag is that suddenly everything degrades from the usual benefits of Smalltalk. Driving the Octave interpreter is a possibility, but I wonder whether it would turn into an exercise in writing Octave scripts. My preference (at the risk of repeating myself) is to do the I/O and logic in Smalltalk and leave the number crunching stepss to something called from Smalltalk. An example would be f := SampledFunction loadFrom:'file.name'. fft := f copy fourierTransformForward. "do something to the transform" ^fft copy fourierTransformBackward. Of coruse, exactly what/when to copy and when to modify in place depends on the algorithm and goals. Any ideas on whether such a thing would be possible with the octave interpreter? I fear it would all turn into programming in Octave vs. programming in Smalltalk. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Nicolas Cellier Sent: Monday, July 27, 2009 4:52 PM To: [hidden email] Subject: Re: [Pharo-project] Anyone mixing Matlab/Octave and Pharo? Hi Bill, I tried to port Smallapack - a Smalltalk interface to Lapack - into squeak but never finished it... google it if you have time to loose. It works on VW and Dolphin yet. In squeak, I have chosen to use FFI, but maybe it would have been more secure to generate a VM plugin... As you may know, Lapack is a very stable robust and public domain algebra library used for example in Matlab, Octave, Scilab, etc... It is my number one choice far above gsl. Now the idea to go thru octave interpreter might work as well. You may however loose some time in interpreting inputs/outputs back and forth... Depends on the volume of I/O you are planning. I presume there is also an access possible to an octave engine doable via plugin/FFI, passing directly Octave objects to Octave functions... Nicolas 2009/7/24 Schwab,Wilhelm K <[hidden email]>: > Hello all, > > Are any of you doing scientific computing on Pharo? I have some seriously old Numerical Recipes code that I altered and compiled, and more recently have used the GNU Scientific Library. All of that is connected to Dolphin, and it will take some time to adapt it to Pharo. Even more recently, I found reason to exceed GSL's feature list, and Octave might be able to do the job. > > The first thing would be do the minimum work to get some data into Octave and see how it does. Ideally, I would want to pipe data into Octave, get results from it, and then do some post-processing in Pharo. In GSL (dll/so) terms, the idea is to do all of the memory management and algorithm level work in Smalltalk, and the tight loops via the external code, and hopefully to do all of that w/o littering the drive with temporary files. > > Any experience, good or bad, in those directions? > > Bill > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |