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

Re: No, Operator Overloading is a BAD THING

[Anonymous Coward]

In your example, you say that "CrazyObjectNumber c = (a * b) + 53;" should be replaced with : "CrazyObjectNumber c = ((a = a.multiply(b)).add(53)).clone();". Either you went out of your way to make a bogus example, or you don't understand when/how to use C++'s OO mechanisms.

Consider the following:

#if 0
typedef CrazyObjectNumber crazy;
crazy crazy_add_int( const crazy& lhs, int rhs ) { ... };
crazy crazy_mul( const crazy& lhs, const crazy& rhs ) { ... };
#endif

c = crazy_add_int( crazy_mul( a, b ), 53 );

Now when you s/crazy_mul/operator*/ and s/crazy_add_int/operator+/, you can simply type:

c = a * b + 53;

Guess what happens in the background when you use operator overloading? It turns back into the equivalent of crazy_add_int and crazy_mul! So when you use operator overloading, all you buy yourself is a false sense of confidence in some operators that are commonly understood to have no side effects. However, in your f**k'd up example, you show us why C++ is dangerous: we end up with people using class specific overloads to do braindead things like mutating the object in place (why else would you feel the need to specify clone()?).

multiple options

[BeerMilkshake]

1. try to do everything in one environment

This seems like low short-term risk because you reduce the number of technologies that have to work together, but you incur more long-term risk because of technology churn.

2. Combine libraries

A library implemented in Java/.NET can call a library implemented in .NET/Java using bytecode-IL translators such as IKVM.

Another way is to develop bindings, like we used to do to call C++ libraries from Ada, and such.

3. 'On the wire' integration

This is similar to (2) except that you have more processes.

Using something like CORBA, you can implement a service in, say FORTRAN, that calls the FORTRAN libraries. You can then implement your client in whatever (Java, PERL, C/C++, .NET, ...).

There are CORBA/.NET solutions, both OS and commercial, available (Borland Janeva, IIOP.NET, ...)

Re: No, Operator Overloading is a BAD THING

[digerata]

This was marked as insightful?

My f**k'd up example was in Java not C++. The problems you bring up aren't present in Java. We are discussing Java, not C++. You do not seem to be knowledgable in Java, hence your statement, '...do braindead things like mutating objects in place...need to specify clone()'. Clone does not mutate any object. The need for it is to make a copy so that c won't be modified when someone modifies a.

I'm not going to get into another religious debate over something that has been argued since the dawn of time.

here's a thought

[Anonymous Coward]

Operator over loading is a redherring. I would think using a math markup language to handle the User interface part would be a nice way to go. Then you can simply write a parser to convert the markup to execution code. that way, you can easily change the parser to generate more optimized code. just a thought. then it wouldn't matter if the actual library is written in C/C++/Java/C# or some other language.

Re:Can you elaborate?

[Anonymous Coward]

a = Math.sqrt (
Math.abs ( b . add ( c )
. multiply ( d . divide ( e ) )
)
);

Is bulkier. But you can see exactly what is happening... Contrast with:

a = sqrt(abs((b + c) * (d / e)));

And try to figure out why FOO::BAR::BAZ(char*) is being invoked with a const string.

Also: You may want your add/multiply routines to modify the object rather than creating unnecessary new objects. To avoid unnecessary replication costs when each object is measured in megabytes...

a . copy ( b )
. add ( c )
. multiply ( d )
. divide ( e )
. abs ( )
. sqrt ( );

Which works provided each method returns the current object.

Re: No, Operator Overloading is a BAD THING

[Anonymous Coward]

Actually, it would seem that YOU'RE the one that doesn't know about Java. The operations you perform with A mutates A, and after the mutations, you clone it. In your example, you'll end up with

c.equals(a) == true

presuming that you have implemented equals correctly, of course

Jakarta Commons Math & other stuff

[andyverbunt]

First, you might be interested in Jakarta Commons Math, which is about to release version 1.0 : http://jakarta.apache.org/commons/math/index.html [apache.org]

Secondly, I'd probably consider isolating all the formulas and then put them aside somewhere (XML, database, ...) in a human-readable format.
Then make a parser that can read that format (i.e. using the libraries you mentioned), substitute variables, and calculate a result. The advantages that I see:
1) you centralize all numerical stuff
2) in a readable format
3) so operator overloading (or the lack of) will only bother you in the parser
4) it will be easy to change or add formulas without having to recompile everything
5) easy to write tests (junit)
6) easier to change underlying math-libraries without affecting the rest of your code.