Didier,
I would go along with "clearly" with the code in Smalltalk; I do not have enough experience with Java to pronounce it too slow to do the job. Nor can I claim to understand what is involved in a continental weather forecast. When it comes to transforming 500,000 sample time series, I have a little more sense of it. There the problem is not so much the cost of processing one of them, it's that I have many of them to analyze and summarize.
It might be that you do not address the expensive things that I use. For things like non-linear regression with modest numbers of points, the speed penalty of even Smalltalk might indeed not be a deterrent.
In terms of my GPL/GSL struggle, the code most likely to be put at risk by GPL is what is needed to do least squares, root finding, and regression; it is also (however indirectly) connected to the more poorly designed parts of GSL. The transforms are relatively clean, and would be almost directly accessible with only modest improvements to Pharo. The few vector operations that I have used from BLAS can be clean-roomed with little effort. This could work out nicely.
I'm not sure I agree that communication with external libraries is "unstable." I have done a lot of it for a long time with good results. It is true that our current FFI is not as good as Dolphin's, but it does work as far as it goes. It can be readily modified to provide diagnostic information that is suppressed by default and that helps a lot in getting things to work. NativeBoost and/or Alien will hopefully address callbacks and get closer to Dolphin's handling of structure field types.
Bill
________________________________________
From: Didier Besset [
[hidden email]]
Sent: Friday, October 15, 2010 11:09 AM
To: Schwab,Wilhelm K
Subject: Re: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license
You just have to see what is good for you.
Clearly, you won't compute the weather forecast each day for whole
Europe in ST or Java. However, I found that making least-square fits
within the time required to refresh a screen perfecttly acceptable
compared to the unstability of cross language communication.
Cheers,
Didier
On 14/10/2010 22:36, Schwab,Wilhelm K wrote:
> That is wonderful news!
>
> Didier, There is a natural question that arises: what are the performance implications of Smalltalk or Java? Why not C with a Smalltalk wrapper? I have not tried number crunching with Cog or NativeBoost doing some of the expensive lifting, but absent those advantages, the benefit from coding tight loops in C has been nothing short of eerie. I have never tried Java for it. If there is a speed boost to be had, would a port offend you? I am a pragmatist, so it would begin one function at a time, chosen by the type of work I do and driven by when the machine grunts.
>
> Thanks,
>
> Bill
>
>
>
> ________________________________________
> From:
[hidden email] [
[hidden email]] On Behalf Of Stéphane Ducasse [
[hidden email]]
> Sent: Thursday, October 14, 2010 4:02 PM
> To: Pharo Development; The general-purpose Squeak developers list; ESUG Mailing list
> Cc: Didier H. Besset
> Subject: [Pharo-project] Object Oriented Implementation of Numerical Methods" under the MIT license
>
> I want to thanks didier for releasing the code of his book under MIT.
> Thanks!
>
>
> Begin forwarded message:
>
>> From: Didier Besset<
[hidden email]>
>> Date: October 14, 2010 8:06:52 PM GMT+02:00
>> To: Stéphane Ducasse<
[hidden email]>
>> Subject: Disclaimer
>>
>> I hereby release the code of my book "Object Oriented Implementation of Numerical Methods" under the MIT license.
>>
>> Didier Besset
>
> _______________________________________________
> 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
Locked
