Numerical Computing in Java?

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?"

Comments

No Operator Overloading is a BAD THING

[digerata]

I always thought that Sun's decision to leave operator overloading out of java was a huge mistake. IIRC, Their argument being that it could lead to confusing code if programmers change the meaning of operators like + is really -. If you ask me that argument is ridiculous. A programmer could just as easily create a method called add() and have it perform like subtract.

All it does is make us have to type more and take a few hundred milliseconds more time to look at a line of code like

CrazyObjectNumber a = new CrazyObjectNumber(...);
CrazyObjectNumber b = new CrazyObjectNumber(...);
CrazyObjectNumber c = (a * b) + 53;

Which line 3 ends up being:
CrazyObjectNumber c = ((a = a.multiply(b)).add(53)).clone();

Which one is easier to read?

Re:No Operator Overloading is a BAD THING

[cft_128]

On top of that, someone could come along and change the code and forget to update the comment to reflect the change. Then you simply have more obfuscated code.

And that is why I never, ever comment my code.

Use the right tools for the right job...

[Chilles]

Sure it might be easier on the administration side to use just one tool. But in the end a language is just that, a tool. You don't see carpenters throwing away all their tools except the hammer just to keep their tool-shed clean...

These are not the languages you are looking for

[Anonymous Coward]

Step away from the "one language fits all" mentality. The type of problem you're trying to solve has already been solved, so you can forget about Java and C++.

Go get Matlab (or Mathematica or Mathcad/Maple). Matlab has a powerful scripting language that does exactly what you need, and you can download thousands of functions written for it. Or just hire me and I'll write a translator from Matlab to your favorite language. Oh wait: translators already exist, so nevermind.

Also, why are you trying to confuse yourself (and future maintainers) with operator overloading in C++? It's just a Bad Idea (TM). Don't do it.

Jython

[FullMetalAlchemist]

You might want to try Jython and the Numerical Python for Jython.
I have not used either for a long time, but use plain Python and Numerical Python a lot; sure beats Matlab and Mathematica for most things. Right now for solving optimization problems with 10k+ s.t. constraints.

Re:Can you elaborate?

[Anonymous Coward]

how about
a = sqrt(abs((b + c) * (d / e)));
vs
a = Math.sqrt(Math.abs((b.add(c).multiply(d.divide(e)) ));

for the small cases (such as this one) it doesn't make as much difference, but for complex equations it adds up quickly.

Interfaces

[GlobalEcho]

[Disclaimer: Until recently I was a quant, and among other things was responsible for the coding quality of Bank One's quantitative libraries. I am no longer there, and do not speak for JPMorgan, who now owns the business.]

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.

Operator Overloading is evil, evil, evil

[melquiades]

Agreed that, for the single purpose of numerical computing, in certain well-controlled circumstances, operator overloading gives an arguable benefit in readability.

But dude, have you ever programmed in C++? Used STL? Blech! Blech^2! I know there are people who love these things, but the readability is unforgivable. Only a Perl code could make it look good. Operator overloading brings out the worst in developers, encourages them to be waaaay to clever for anybody's good. In C++, the evil started with

cout << "Hello world!";

(what the hell were they thinking?!) and went downhill from there. Once you open the door to crap like that, the crap will come.

Years ago, I was at a forum with Josh Bloch and Gilad Bracha where a Java numerics guy berated them for not having overloading and asked them to add it. Bracha basically said "over my cold, dead body." I'm with him on that. The greater cause of readable Java trumps the minor benefits of overloading.

Use Nice!

[bonniot]

You could use Nice, which has operator overloading, generates Java bytecode, and allows you to give a syntactically pleasing interface to existing libraries. For instance, supposing there is Matrix.times(Matrix) method in the Jama package, you could declare in Nice:

import Jama.*;

Matrix `*`(Matrix, Matrix) = native Matrix.times(Matrix);

Then you can write m1 * m2 and that will call the times method.

You can also use Eclipse, JUnit and Ant with Nice. Don't hesitate to ask for help on the nice-info mailing list.