Numerical Computing in Java? 196
Nightshade queries: "I work for a department in a big financial company that uses equal amounts of C++ and Java. For a variety of reasons, we've decided that Java is the future of the group because of all the benefits of the language (it's so easy to use compared to C++, we can use Eclipse, Ant, jUnit, etc). The problem is that we do a lot of numerical computing and Java has no operator overloading! Languages like C# have operator overloading and because of this company's like CenterSpace have popped up with some nice looking numerical libraries. Try to find numerical packages for Java and it'll be pretty tough. What have people done in terms of numerical computing in Java? We currently use the Jama and Colt libraries for matrices and complex numbers, but these have awkward interfaces without operator overloading and are incomplete (no support for things like symmetric matrices) so we're looking for better solutions. So should we bite the bullet and switch to C#? Should we use a pre-processor like JFront? What have other people done?"
Java Hurt (Score:3, Interesting)
Read "How JAVA's Floating-Point Hurts Everyone Everywhere".
http://www.cs.berkeley.edu/~wkahan/
For speed, Fortran is still best. Most enginering codes are in Fortran.
Jython (Score:5, Interesting)
I have not used either for a long time, but use plain Python [python.org] and Numerical Python a lot [pfdubois.com]; sure beats Matlab [mathworks.com] and Mathematica [wolfram.com] for most things. Right now for solving optimization problems with 10k+ s.t. constraints.
Do BOTH! (Score:2, Interesting)
The dev teams working with java are used to the quirks of the language, thus should be very familiar with how to use the library, even though it might not be the best it could be.
However, If you are looking to provide a tool for companies to use for development, I would recommend both. There is a need for this in both Java AND
Perhaps looking into a way to use the same code base, but compile it in both Java, and Java.NET would be the best option here, and give more choice to the customers!
Re:Java Hurt (Score:4, Interesting)
That does not compute, logically - erm
Anyway, from the very paper you pointed to, C9x does complex math better than Fortran. Interesting - I wish there were some detail to it though.
Re:These are not the languages you are looking for (Score:4, Interesting)
One step further along that road: consider using Python to glue together old pieces.
If Java was a step toward elegant simple expression away from C++, the Python is yet another wonderful step in that direction [mindview.net]. The URL is for Bruce Eckel's site: he of the Thinking in {C++,Java} book series fame.
You can glue together all those highly efficient numerical kernels written in FORTRAN, C or C++ with a nice object oriented scripting language. No need to go through more off-road stress testing of a new Java implementation of SomeOldAlgorithm with all the quirky corner cases that people have already hit using the crust old code in languages no one wants to learn anymore.
Interfaces (Score:5, Interesting)
There are two main considerations you have with respect to libraries of numerical routines:
(1) Having access to quick, accurate, and reliable numerical analytic routines such as singular value decompositions, FFTs, and optimizers.
(2) Having convenient and standard ways within your organization of defining vectors and matrices, as well as simple operations (e.g. dot products) on them.
To address the first problem, I think you have to look first to the quality of the numerical routines you plan to use. Paying attention to their native language or available interfaces is foolish. Would you really trust a 5-year-old SVD written in Java over something from LAPACK or NAG? I sure wouldn't, and I would never guarantee a model calibration based on it!
Thus, your numerical analytic routines will come in some hoary library, and you will have to interface to it as best you can. In many cases you could use JNI or, if that makes you nervous, have the Java portion communicate with the library wrapped in a separate process using sockets or something. But the point is, quality is more important than interface here.
The other issue is standardization of vector and matrix encapsulations etc. Here I am less opinionated, but my thoughts are roughly as follows: there are probably lots of vector/matrix implementations out there, some of which must be good. You might as well just choose one with an API and implementation you are impressed with...it's not as though you will be expecting it to do your numerical math. Sure you won't get operator overloading (if you're in Java) but having done financial mathematics in C, C++ and MatLab, I can say with a fair degree of certainty that you will use overloading far less often than you might think.
You now have a convenient standard for manipulating objects, and a quality library. Write the glue and you're done.
Oh, and for those people recommending MatLab/Octave/Mathematica etc., let me just say that most of us in finance know about them and many use them for prototyping. Python, and (ugh) VB too. But ultimately one is often asked to create a library that gets handed off to internal developers for use in one or more custom apps, which are then distributed to anywhere from 5 to a couple hundred users, and run on portfolios of thousands of securities. Even if, say, your MatLab routine didn't need licensing for each workstation and took just a couple milliseconds to run, you're still looking at perceptible delays before the user sees results.
Modern financial applications are one of those few remaining arenas in which computers are Not Yet Fast Enough.
Use Fortran 95 (Score:2, Interesting)
list (Score:1, Interesting)
But don't expect much. Usually you'll have to convert your c++ or whatever code to java yourself. That's what I do. We build our own Java numerical library and use others as well. We use numerics for air flow simulations not finance so our old code is in fortran. I'd suspect there are more commercial java packages directed at finance.
Use Nice! (Score:5, Interesting)
You can also use Eclipse, JUnit and Ant with Nice. Don't hesitate to ask for help on the nice-info mailing list.
Re:These are not the languages you are looking for (Score:3, Interesting)
That said Matlabs main strength is the near infinite libraries (generally all numerical mathematical and engineering research is done in Matlab, so basically anything you can ever want is available) and prototyping speed. The m-files are interpreted at runtime and you can also "code" in interactive mode much like with Python (but Matlab is more complete in this area than the Python interactive stuff).
Matlab isn't for realtime stuff though (which I assume is what you mean, because if you are just simulating ms intervals aren't that bad). Typically you'd use Matlab to prototype and then either translate to C/Fortran or just redo based on the Matlab files. Since Matlab is a numerical system it's easy to make statistical checks on your data in order to ensure correctness. And that should be a major part of the development phase, I have tried to "just do the code first" a number of times and it seldom saves you time.
Screw the language wars ... (Score:2, Interesting)
Jakarta's Commons Math library (http://jakarta.apache.org/commons/math/ [apache.org]) has some interesting classes (including handling of complex numbers and lots of statistical stuff). I haven't used it in anger and hence do not know the extent of their support for the features you are looking for, but it is a good start. It is also designed to be a lot faster than Sun's math APIs.
And yes, they're all objects and there is no operator overloading. And I reflect sentiment earlier about how this is a Good Thing in general.