Scientific Computing
Les Tyrrell
tyrrell at canis.uiuc.edu
Tue Sep 1 18:55:23 UTC 1998
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, batchstyle
processing applications where the emphasis is on getting numerical
results to be postprocessed 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 vectorstyle computation for many routine engineering applications.
I would not expect to be able to have good performance for highend stuff
such as Direct Numerical Simulation of the NavierStokes 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 objectoriented. My impression is that
straightforward implementations of numerical algorithms are easier in
a nonOO 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
More information about the Squeakdev
mailing list
