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 at canis.uiuc.edu>
To: squeak at cs.uiuc.edu <squeak at 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
>
>
>
>
>