Recent comments have suggested that Java may not be suitable for numerical computation (a view that I do not share)
Well, I think this should be put into context. Let's examine some approaches to numerical computation: 1. A cleanly designed library of commonly used, somewhat low level functionality, like [math]. While it is relatively easy to build solutions for complex problems, this approach suffers from lots of temporary object creation and data copying. This is hard to avoid in Java without giving up data encapsulation and providing ample opportunity to users for shooting themselves in the foot. See the constructor of CubicSplineFunction for an example. 2. Provide solutions to higher level problems. Inline the code for the lower level functionality, do memory allocation less dynamically and weight the usage of abstractions carefully against possible object proliferation. For example in a ray tracer, use the vector components explicitely instead of using vector objects. This is, in general, noticably faster than approach 1, and an increase of *two* orders of magnitude is possible, although not necessarily common. Profiled and well optimized Java code run on a HotSpot JVM can be on par with average C code with regards to performance. 3. Get a highly optimized C/C++/FORTRAN library (possibly including a compiler), which takes processor architecture, cache size and organization and whatnot into account. A performance improvement of another order of magnitude compared to approach 2 is not unheard of. I tried an EMF simulator two years ago, and when built on a generic Java library, very similar to RealMatrixImpl, a 1000x1000x1000 data point simulation run all night. Switching to approach 2 brought it down to roughly 5min, barely enough to fetch a coffee. The real good stuff, using C and tricky algorithms specifically designed for EMF simulations, is nearly interactive, in the 5..10s range.
Summary: whether Java programs can be used for tackling numerical problems depends on the problem, the problem size, how you want to solve it, and the tradeoffs you are willing to consider.
some design/refactoring decisions made some time ago that moved things more in the "framework" direction in commons math.
Hm. There are reasons that there are usually a bunch of different algorithms for solving seemingly the same problem. Which specific algorithm should be used can heavily depend on the higher level problem, and a good choice can be a really huge win. And yes, unsuspecting users are regularly bitten by stock textbook solutions which are either much too slow or fail unexpectedly.
J.Pietschmann
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
