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

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?

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...

I hate overloading

[Anonymous Coward]

I hate operator overloading because if hides what's actually happening - a function call. When you are actually debugging code its difficult to see what is going on.

I also dislike "virtual" inheritance for the same reason.

I just don't think OO programming is the greatest thing since sliced bread. That's a very unpopular view.

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.

Re:No Operator Overloading is a BAD THING

[Anonymous Coward]

Why are you adding extra complexity?

c = (a.multiply(b)).add(53);

As long as you're writing methods, might as well have them return sensible objects.

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.

Re:Java Hurt

[Anonymous Coward]

C9X supports is detailed in some paper there if I remember correctly. It has better support for setting rounding metods etc, IIRC.
Fortran do not have that, but many manufacturers have libraries or own compiler directives to do that. Well, well, I have used vendor library calls.

For speed of Fortran..
There are many things speed is depending on.
I work with "supercomputers" vectorcomputers down to clusters, and Fortran compilers are superior simply because they have been around longer. Ok, generalisation, there are no 100% answers. It is depending on code, machine, librarys, compiler, the weather of the day and if you are wearing your lucky shirt...

Many engineeringcodes were started with Fortran and therefor there are a lot of library support for Matrixes etc.

90% of the code I work with is Fortran. 10% C.
We actually got a benchmark using Java. Was a good laugh..

But sure, use whatever language float your boat.

Just make sure to program with accuracy in mind (Kahan) and with performance in mind (use librarys, constructs that the compiler can optimize. Unfortunatly is the nice objectoriented hiding hampering the compilers.. )

Re:Jython

[anonymous cowherd (m]

Why use Jython when you could use regular Python? The only advantage Jython has (and I'll admit, this might be a big advantage depending on the size of the codebase) is that it compiles to Java bytecodes and allows you to access Java classes from Python.

Other than that, I can't think of any reason why I'd use it, especially for numeric computation. Why be 2 versions behind in the language when you can have some very useful and elegant features like generator expressions now?

Re:java is the future

[GuyverDH]

If C / C++ is so last week, and Java is the future, then how can it be that Java wouldn't exist without C.

From Java's perspective, the two are tied together.

You (currently) can't have Java without C, while you can have C, without Java.

It's safe to assume that until another language comes around that can do things as well as C/C++, that Java will continue to be written in C.

So to say that Java is the future, while condemning C/C++ to the past is short-sighted at best, and ignorant at worst.

Where would all your lovely new "Java" versions come from, if not from dedicated, hard working C/C++ programmers?

Horses for courses

[barries]

When choosing a language, choose one that does what you need. Don't choose a language because it's easy or pretty if it doesn't do what you need. Moreover, if you really are limited to a single language, you are forgoing the huge swaths of comp. sci. goodness whatever language you're limiting yourself to doesn't support.

Any competent group generally needs to be able to handle a mix of languages, from C/C++/Java, Perl/Python/Ruby/etc, and the myriad of narrow languages (SQL, templating, shell & batch, HTML, lua, etc., etc.).

Perhaps you should use C, C++ or FORTRAN for the numerical portions and native Java for the general purpose portions.

- Barrie

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.

Try JNI

[miyako]

Since you've said that your department has experience with both C++ and Java, have you thought about using the Java Native Interface. JNI basically allows you to use some native methods that you can write in C++ in your java application. Sun has some good good articles on their website about it, and after spending a couple hours with it, it's pretty easy.
This will allow you to make use of a lot of pre-existing C++ code, and to write code in C++ when it turns out to be better at a particular problem, while still using Java for the majority of your application.
I've used JNI extensively for graphics applications (which are heavy on math), where it's either much faster in C++ (yes yes, java is much faster than it used to be, but sometimes much faster still isn't quite fast enough), or just much easier to solve a given problem in C++, even though Java is the best choice for most of the application.

Re:No Operator Overloading is a BAD THING

[TheLink]

Think of it as something like CRC. If the code isn't consistent with the comments then you know you're supposed to fix something. Either the comment is broken or the code is.

Sure it may not be easy to figure out which is broken but that's better than figuring whether the 10 lines of Java are correct or not (and which 10 lines to focus on) (if they're wrong you don't have a quick "checksum").

No religion wars, please

[insac]

Could we please try lo list why "operator overloading" is such a troublesome feature?

The statement "since it is so easy to misuse" doesn't count: I'd like to know WHY it is so easy to misuses.

The statement "you'd better use other languages for mathematical calculus" doesn't apply either: I'm in a financial project and we use Java, and there are some pretty complicate expression even in economics.

The statement "I used it in C++ and it was a mess" is also not appropriate as an answer to my question: if Java will ever consider this feature, there's no reason why it should copy the C++ style.

On the other side (the operator overloading fans):
the statement "I'm not going to" doesn't apply; your colleague could do and you would kill him after tracing a bug

The statement "The expressive power of this feature is more important than the possible misuses" doesn't apply either: Java tries to avoid misuses by forcing programmers to behave properly and we should respect this philosophy (not meaning I'm against the feature.. only I'd like to have it without the major cons)

My opinion:
"Why it is so easy to misuse and mantain?"

1) At first glance you could not realize if the symbol "+" is a simple primitive "sum" or a more elaborate object operator

2) sometimes the notation is simply "out of this world" (ehm... meaning "not natural" :-)

Example: (let me write in pseudo-Java)
Vector v1=new Vector();
Vector v2=new Vector();
Vector v3=v1+v2; //ok, concatenation of the 2 vectors
Vector v4=v2-v1; //what the hell does that mean?

3) if we choose a C++-like implementation we could have a "operator+" (-/*) method that has its own implementation (possibly different from add() or any other method in the class)

4) if we choose a C++-like implementation we wouldn't have just one place to look at to understand the meaning of operators (they could be overloaded twice or more times in the class hierarchy)

Any other reason in your opinion?
Then when we have all the reasons listed we could consider if there could be a way (compatible with "Java guidelines") to add this feature without incurring in all this misuse problems.

If we (or Sun :-) can't find such a way, or is not justified by the advantages (cleaner syntax in economics and mathematical expression) then we would not ask for it...

Last thing:
you can vote for this feature (or stand against it ) at this URL (registration needed) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id =4905919 [sun.com]

No, operator overloading is a GOOD THING!

[Anonymous Brave Guy]

Here are a few reasons not to do it.

• Developer productivity, in terms of finished lines of code produced per day, is remarkably consistent across programming languages. If you insist that a trivial expression be written as five lines of crap, you just reduced your developer productivity to 20% of what it was. (Before anybody flames, please read the research. Google is your friend.)
• Replacing a simple and transparent expression with five lines of crap makes the code vastly harder to read. There is far more scope for introducing no-brainer bugs, and it will be far harder for anyone reviewing the code to identify and remove them.
• In many languages, using a consistent syntax to represent the same logical operations allows you to write generic code that can work on all types supporting that syntax. In most parts of the programming world, we call addition "+" and multiplication "*". Pointless diversity just hinders code reuse in one of the few areas where it actually is more than just a buzzphrase.

We use high level languages instead of assembler because they let us work at varying levels of abstraction, keeping what we're doing relatively simple at each level and delegating the details to the levels below. That makes for more readable, less error-prone code. What you're advocating is the very antithesis of this approach; if you're going to be that clumsy, you might as well write in assembler. In fact, on reflection, that would be neater...

cout << "Design error";

[Anonymous Brave Guy]

The problem with using << for C++ I/O streams isn't really the use of operator overloading, it's the fact that it puts into code what should be data: the order of the terms to be output. As anyone who's worked with internationalised code much can tell you, that's a "D'oh!" mistake.

As for readability, I write serious maths software using C++. We already use complex matrix multiplication expressions and the like, which are hard enough to read already when you're constrained to a textual representation. From a numerical programmer's perspective, you can have my overloaded (and highly readable) operators over my code, dead body.

Re:Okay, mom....

[wirde]

C is *not* a functional language
http://www.google.com/search?hl=en&lr=&ie=UTF-8&oi =defmore&q=define:functional+language [google.com]

Re:No Operator Overloading is a BAD THING

[gnovos]

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.

That was moderated as funny, but in reality it is an excellent idea. People still have to understand what your code does, so if you write you code in such a way that it is perfectly clear what you are doing, and with variable, class and method names that clearly indicate thier function, there is absolutly no reason to comment code and every reason not to.

Comments can very easily grow out of date but the code itself NEVER can. That is the nature of code, after all.

not just operator overloading

[jeif1k]

In addition to the lack of operator overloading, there are other problems with Java for numerical computing. For example, it doesn't have "complex" and similar data types, and it has no means by which you can define them yourself efficiently either. Also, Java does not have true multidimensional arrays.

The C# language is considerably better for numerical computing than Java. However, C# implementations are still a bit behind Java implementations (although they seem to be catching up fast).

I would recommend sticking with C++ for now and waiting another year to switch to something else. C# will probably mature to the point where it is a reasonable choice.

I disagree completely with this statement

[fenris_23]

From a mathematical point of view, the prefix notation represented by a function with arguments makes much more sense than the infix notation represented by operator overloading.

Operator overloading only makes sense in a small number of cases where the class you are developing only provides binary and unary operations. There are many more cases where a function should be tertiary or more. In these cases, you have to abandon operator overloading and use the same functional notation anyway. Also, sometimes operator overloading doesn't even make sense. E.g. How do I overload the * operator for vectors?

In the end, when developing a library like that using operator overloading is going to have to use inconsistent representation for operations - which is just ugly - imo.