Here's my take on how to do serious number crunching tasks within a Squeak environment -- whether it be celestial mechanics, matrix math, or statistical computing. I should point out that I am a C++ developer by day, a Schemer (until recently) and Squeaker (wannabe) by night. I already have written a (commercial) C++ library for celestial mechanics, and have previously developed a Scheme-like environment (in C++) for writing apps that call this library. Now I'm thinking about making the existing C++ code a part of a dedicated Squeak VM, with specialized primitives that take care of all the serious number crunching in C++. Not too different from Siren, in terms of concept and architecture. (Too bad I can't make a living doing that sort of thing :-)
Kyle Pierce
P.S. Thanks to STP for the new Siren, which I hope to play with soon
-----Original Message----- From: Les Tyrrell tyrrell@canis.uiuc.edu To: squeak@cs.uiuc.edu squeak@cs.uiuc.edu Date: Tuesday, September 01, 1998 12:57 PM Subject: Re: Scientific Computing
Short answer: Smalltalk, which Squeak is based upon, is not intended for the sorts of serious number crunching commonly found in engineering applications. These are typically large, monolithic, batch-style processing applications where the emphasis is on getting numerical results to be post-processed for later review after the computation is over, whereas Smalltalk is well suited for highly interactive
exploration
of abstract models.
HOWEVER.
Squeak is open, a bit of a new situation in the Smalltalk world. VM's can be changed. Provision for this is explicitly included in the Squeak system. One can easily imagine installing FloatArrays like objects, much as we currently have with CharacterArrays, or for that matter FloatMatrices.
I believe you would be able to get rather good numerical performance for vector-style computation for many routine engineering applications. I would not expect to be able to have good performance for high-end stuff such as Direct Numerical Simulation of the Navier-Stokes equation over arbitrarily shaped complex three dimensional bodies, but then if you are trying to do that sort of thing you have bigger worries anyway.
A bigger issue in my opinion is the extent to which the OO model fits the way engineers typically think of numerical problems... mathematics has a highly imperative, operational point of view, much more process ( or procedural ) oriented than object-oriented. My impression is that straightforward implementations of numerical algorithms are easier in a non-OO language ( ie, a "kinder, gentler" variant of FORTRAN ) and that the problems we have using things such as FORTRAN are more due to its ancient, archaic roots than the fact that it is a procedural language.
I know that there are folks out there doing Math in Squeak- I'd be interested in seeing how they approach this, and hearing whether they feel if this is an issue or not. For myself, one of my first Smalltalk projects was an attempt to build an unstructured Euler flow solver so I am not at all opposed to this sort of thing. Actually, I felt that the interactive side of things had been neglected for far too long in engineering computations. Perhaps now I would be able to see the problem more easily from an OO perspective, but then it was hard to ignore the procedural character of the algorithms I was trying to implement ( actaully, I did implement, but I didn't have the computational power to run and debug them ).
les
squeak-dev@lists.squeakfoundation.org