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

[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:No Operator Overloading is a BAD THING

[FedeTXF]

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?

This one is

// c = (a * b) + 53;
CrazyObjectNumber c = ((a = a.multiply(b)).add(53)).clone();

Re:No Operator Overloading is a BAD THING

[jilles]

why not do

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

or (using static methods)

CrazyObjectNumber i = CrazyObjectNumber.multiply(a,b)
CrazyObjectNumber c = CrazyObjectNumber.add(i, 53);

Nobody forces you to put things on one line in Java. Inlining happens automatically when it makes sense. Code completion and refactoring will help you avoid most of the typing.

Re:No Operator Overloading is a BAD THING

[fatmonkeyboy]

So, adding "c = (a * b) + 53" as a comment makes the no-overloaded-operator one more readable?

That exact string "c = (a * b) + 53" appears as the last line in the version with operator overloading. As an added bonus, no comment is needed and (therefore) the programmer doesn't need to worry about keeping the comment in sync with the code in case of changes.

I'll agree that people get crazy with it and define operators that aren't clear. I saw such an example of exactly this earlier today - I had to pick up from context clues what the operator did. If I was actually going to use that code, I would have had to look up its implementation to make sure.

Maybe this one fact is even worth denying the ability to use operator overloading in Java. I don't think it is, but I could buy an argument along those lines.

But if you're going to claim that it's easier to read even in simple cases like the one above, you'll need to provide me with a bit more explanation. I'm too stupid to figure out how your code + comment is easier to read than code that reads...as is...like the comment you used to explain it.

Re:No Operator Overloading is a BAD THING

[digerata]

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.

Re:No Operator Overloading is a BAD THING

[digerata]

why not do

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

For one, it would have to be:

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

Whether or not you break it up into multiple lines, its still a pain in the ass to type code so verbatim. c * b is just simpler than c.multiply(b).

Re:No Operator Overloading is a BAD THING

[fm6]

To a math geek, an simple algebraic expression is the easiest thing to read. It has nothing to do putting everything in one line. It's just what they read with the least mental effort.

Re:No Operator Overloading is a BAD THING

[toxis]

Well you're line 3 would end up like this since you don't want "a" to be modified and assuming your methods return new instances:

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

That's okay, I think. With Java 5 this works with autoboxing/-unboxing. But only with predefined classes:

Integer a = 12;
Integer b = 23;
Integer c = a * b + 53;

The last line is internally converted to:

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

And there is operator overloading for class String:

String a = "fu"; // equals new String("fu");
String b = a + "bar"; // equals a.append("bar");

Re:No Operator Overloading is a BAD THING

[gdchinacat]

actually...."fu" and "bar" are constants, there is no 'new String("fu")'. String's do not have an append() method, but StringBuffer does. String concatenation done with the "+" operator always uses an implicit StringBuffer object.

user@foo:~/tmp$ cat Foo.java
public class Foo {

public static void main(String[] args) {
String a = "fu";
String b = a + "bar";
}
}
user@foo:~/tmp$ javac Foo.java
user@foo:~/tmp$ javap -c Foo.class
// compiler version: 46.0

@source "Foo.java"
public class Foo extends java.lang.Object {

/**
* <init>
*
* stack 1
* locals 1
*/
@signature "()V"
public void <init>() {
@line 2
@aload 0
@invokespecial void java.lang.Object.<init>()
@return
}

/**
* main
*
* stack 2
* locals 3
*/
@signature "([Ljava/lang/String;)V"
public static void main(java.lang.String[]) {
@line 5
@const "fu"
@astore 1
@line 6
@new java.lang.StringBuffer
@dup
@invokespecial void java.lang.StringBuffer.<init>()
@aload 1
@invokevirtual java.lang.StringBuffer java.lang.StringBuffer.append(java.lang.String)
@const "bar"
@invokevirtual java.lang.StringBuffer java.lang.StringBuffer.append(java.lang.String)
@invokevirtual java.lang.String java.lang.StringBuffer.toString()
@astore 2
@line 7
@return
}
}

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.

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

Re:No Operator Overloading is a BAD THING

[TheLink]

Just because there's more to read doesn't make things more readable.

In fact often it makes it harder at least for some people anyway - people who prefer to stare at one page and figure it out, rather jump from page to page.

Re:No Operator Overloading is a BAD THING

[Fallen Andy]

Thanks. That's a real simple example. Even pre 8.a.m
with a hangover I can see it feels better.

It's just that if you let some peverse little sick
almost script kiddie lose with operator overloading
you will feel very great pain. You're a disciple of
pain right?

Oh No. No way. Back to that Pascal or even Java compiler you go. If Yannis the Questidis grows up
and writes code *he* understands I'll let him stroke that bad dog called Python (with op overloads). But not C++ (shudders).

Serious answer - it's not the notation "+". That's
the good thing. It's the *SIDE EFFECTS* man. How
do you *know* it was overloaded 10 million lines of code away.

Re:No Operator Overloading is a BAD THING

[RedWizzard]

CrazyObjectNumber c = (a * b) + 53;

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

Which one is easier to read?

Operator overloading is perfect for number classes, obviously. But how often do you write number classes?

The problem with operator overloading is not just confusion over the meaning of the operator, it also that operators have an additional attribute that needs to be remembered and accounted for: precedence. Say you've got a String class that has append() and replicate() methods. You do:

String s = "<";
s.append(">");
s.replicate(3);

The meaning is clear. You'll end up with s = "".
If you overload + to mean append and * to mean replicate you'll be tempted to do:

String s = "<" + ">" * 3;

You'll get s = ">>", assuming you're language converts string literals to Strings automatically. And this stupid example of overloading is really obvious, far more obvious than many real world uses.

The bottom line is that operator overloading can both clarify and obfuscate code. It's nice to have the option in a language, but the argument against it is not a meritless one.

Re:No Operator Overloading is a BAD THING

[stoborrobots]

Why? It lookst to me like the parent's code modifies the object 'c' by multiplying it by 'b' - no assignment needed...

I read that just like I read

str1.append(str2)

which also doesn't need an assignment...

That said, I'm not really sure whether I like operator overloading... I understand the utility, but I've never felt compelled to use it...

Re:No Operator Overloading is a BAD THING

[stoborrobots]

I'm sure you meant

You'll end up with s = "<><><>"

and

You'll get s = "<>>>",

Re:No Operator Overloading is a BAD THING

[Anonymous Coward]

No, unit tests are like a CRC for code. You run your test suite and if something fails, you know either the code is wrong, or the unit test is wrong.

The problem with using comments for this purpose is that comments can't be automatically verified against the code. You can run your unit tests in a few seconds, but it takes way, way longer than that to check comments.

Re:No Operator Overloading is a BAD THING

[zakalwe]

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

Um, only if you don't know what you are doing.

If you do know what you are doing and have a sensibly developed library that is using immutable objects it ends up being:

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

Looks pretty clear to me.

Re:No Operator Overloading is a BAD THING

[Anonymous Brave Guy]

Serious answer - it's not the notation "+". That's the good thing. It's the *SIDE EFFECTS* man. How do you *know* it was overloaded 10 million lines of code away.

How do you know what any function call you make is going to do in detail in a project that size?

The answer is: you don't.

But then again, you shouldn't need to. You trust that the function is going to do the job its interface says it will, and anything that doesn't is a bug. Of course, the same is true of any other function you call you make anywhere in high level code.

Re:No Operator Overloading is a BAD THING

[iroberts]

If you overload + to mean append and * to mean replicate you'll be tempted to do:

String s = "<" + ">" * 3;

You'll get s = ">>", assuming you're language converts string literals to Strings automatically.

This isn't all that different from tempting programmers to write

int i = 1 + 2 * 3;

and expect i to be 9 instead of 7.

Re:No Operator Overloading is a BAD THING

[Anonymous Coward]

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

Huh? If you design your CrazyObjectNumber class correctly it's:

CrazyObjectNumber c = a.mul(b).add(53);

How hard is THAT to read?

Re:No Operator Overloading is a BAD THING

[pfafrich]

Note the .clone() in the above example. In other words a new object is created, which is generally not what you want for a speed efficent numerical routines. Especially if your dealing with 100*100 matricies.

Now do you know whether the overloading of + for some third party number objects is actually going to cause a clone to take place or not?

The method I always use for similar problems is to pre define all my object and uses methods where one of the arguments (say the first) is the result object.

Matrix m1 = new Matrix();
Matrix m2 = new Matrix();
Matrix res = new Matrix();
multiply(res,m1,m2);
// or
res.multiply(m1,m1); // set res to be product of these matricies

To my mind heavy numerics is precisely where you wish to avoid using a complicated mechanism like overloading.

Re:No Operator Overloading is a BAD THING

[RedWizzard]

This isn't all that different from tempting programmers to write

int i = 1 + 2 * 3;

and expect i to be 9 instead of 7.

Except that people expect to deal with precedence when doing arithmetic. They don't expect to deal with precedence simply because a particular symbol is being used to represent a function name.

Re:No Operator Overloading is a BAD THING

[RedWizzard]

Yes, oops. Thanks.

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.

Re:No Operator Overloading is a BAD THING

[Fallen Andy]

I hate to give you the bad news. I nod and enjoy
your wonderful engineering thought. But then again
I live in the *real* world. (I can handle + being
overloaded for string ops, because it's not awfully
surprising. Heck I love Python. So you know I'm not
the CEO or the guy with pointy hair.

But, I still have nightmares about how *this* sort
of code could have bad surprises....

a = b + c

(universe explodes)

Ouch. I really thought it was adding two numbers.
Sorry. I hate to think of my evil twin (of two
decades less ancientness) George deciding that
yes "+" means do some demonic thing with a matrix
I wouldn't consider fun on a a good day .

I'm going to take out my old friend the chain saw
and persuade him of the (chuckle) lack of wisdom
there...

Damn good engineering tool. I was looking for an
excuse to use it.

Re:No Operator Overloading is a BAD THING

[Anonymous Coward]

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.

But the names of types and functions are a kind of comment, and those CAN grow out of date.

Your variable names might clearly indicate their function now. Will they in a year? Two? Ten? Because as soon as they don't, your code is "out of date" as far as I'm concerned, because what the compiler knows it means is not what it says it means.

That's why comments are good. When you change an implementation, it's obvious that you need to change comments, and doing so is easy and safe. But most people don't use refactoring IDEs yet, so for most people changing a type name is a nasty task that might involve a manual search and replace over dozens of files...

Re:No Operator Overloading is a BAD THING

[lscoughlin]

I have exactly one class for you, that i did not write, in which i would absolutely fucking love to have operator overloading.

BigDecimal

take that.

mutter.

Re:No Operator Overloading is a BAD THING

[RedWizzard]

I agree, operator overloading is a huge plus for numeric classes. But it's not without it's problems for other types of classes.

In the case of Java, one problem I have with it is the distinction between primitive types and objects. There doesn't seem to be a lot of reason for it and while they've seen the light to a degree with the auto-boxing stuff in the latest version, they should have done it properly in the first place. If all types behaved like real objects then they could have had a superclass for all numeric classes and they could have allow operator overloading on numeric classes only. That way operator overloading could have been used where it most makes sense, without allowing it for general classes.

Re:No Operator Overloading is a BAD THING

[lbolla]

I've been using C++ for numerical computing for years now, and it has some advantages over the languages I've used before:

1. it's more powerful than Fortran for everything else it's not math. so, if you have to write a program with a numerical core and a graphical interface, I prefer to write everything in C++ rather than fighting with the linker trying to "glue" the Fortran mathematical core and the C++ graphical interface.

2. it's as fast as Fortran, with the new compilers (say G++ 3.4 or icc 8.0)

3. it's OO, and C is not. In my opinion, if used wisely, OO is a _huge_ advantage. Suppose, for example, you have to write some sort of operator that needs lots of internal and temporary stuff, needs to remember its status and other things like that: it's better to put everything (data and functions) inside a class, rather than scatter functions all around the code, naming them to remember who they belong to.

4. template programming rocks! you can write ONE library and use it for float, double, int and whatever type you define.

5. there is _a_lot_ of good numerical software. See Boost::uBlas Library www.boost.org

Re:No Operator Overloading is a BAD THING

[Anonymous Coward]

There is a lot of whining when it comes to operators.

Those who are against will very often use examples where operator notation doesn't make sense and use that as an explanation of why not to use operators.

I just don't see the logic of that type of reasoning. Just because you have the ability to use someting that is available for you, doesn't mean you should always use it.

There are tons of ways to write bad/malicious code without operators that is error prone and hard to understand.

Just don't use operators unless it is very clear of what it is they are doing. But the same reasoning goes to methods as well. Name methods according to what their purpose and what it is they do.

The plus operator ('+') in Java for strings is a perfect example why you want to have operator overloading. They are convenient and when properly applied they are much easier to read.

Case rested.

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

Re:Use the right tools for the right job...

[Anonymous Coward]

granted, as someone who knows over 10 computer languages (and still struggling with english as my 'first language') my current employer will have a hard time replacing me.

not too many coldfusion programmers know perl.
mix it java and php used for a couple of other odds and ends around the office and i have the code to prove my job security.

as an office policy to stick to 'the hammer' it makes hiring replacements that much easier. you only need to look for a new hammerman rather then a full blown carpenter.

Re:Use the right tools for the right job...

[Clover_Kicker]

>as an office policy to stick to 'the hammer' it makes hiring
>replacements that much easier. you only need to look for a new
>hammerman rather then a full blown carpenter.

It makes sense until the office-full of hammerheads wastes days bashing at a problem that could be solved by a screwdriver in 15 minutes.

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.

Re:I hate overloading

[FedeTXF]

What is "Virtual inheritance"?

If you mean inheriting vitual methods (plain methods in Java) thenyou have your views biased towards more static way of solving problems. Dynamic method dispatching it great to abstract and reduce code complexity.
Unless you come from the Fortran camp.

Re:I hate overloading

[Anonymous Coward]

I hate function calls, because they hide what's really going on -- registers being pushed to stack, a branch-to-subroutine instruction, to be later followed by a return instruction. ;)

Re:I hate overloading

[aminorex]

No, operator overloading does not imply a function call. In fact, overloading could be added to Java in such a way as to PROHIBIT function calls. Don't use C++ as your mental model of overloading. Consider instead, Fortran 2003.

But Gosling hates complex numbers. The view he expressed to me was, in effect, that they open the
door to quaternions, and (me genoito) cayley numbers. It's a slippery slope, dontcha know. I think he'd rather not allow floating point at all,
since it could lead to Dedekind cuts, or something.

Re:I hate overloading

[Anonymous Coward]

> Consider instead, Fortran 2003

I think I speak for many when I say: WHAT. THE. FUCK.

Re:I hate overloading

[angel'o'sphere]

This is bull shit.

When you are debugging, your debugger steps into an operator just like it steps into a function. Guess why? Its the same.

Complex add(Complex& lhs, Complex& rhs) { // do the adding
}

and

Complex operator+(Complex& rhs) { // do something
}

Both are the same code. Your debugger steps you right int the "function/operator".

Unfortunatly, your post is neither insightfull nor does operator overloading have to do anything with OO, erm .. sliced bread.

In fact only Eiffel and C++ offer operator overloading (hm, not sure about Ada), and C++ is not considered an OO language but a hybrid language.

Finally the topic is about Java and MATH, probably you can enlighten us there a bit more?

Regards,
angel'o'sphere

Re:I hate overloading

[stoborrobots]

except in many languages, they don't hide the return; instruction...

Re:I hate overloading

[godglike]

Agreed, functional programming is much better but most of those languages have overloading.

The reasoning for the ban is well founded but actually undermined by aString + anotherString. In reality it was probably the limitations of the typing system that prevented them from doing it. Since there seems to be a move on to fix that, overloading might become possible.

Re:I hate overloading

[Pieroxy]

Well, and yet, if you are a Java programmer, you use one everyday: "a" + "b" gives you "ab".

Well, well, well... I would not trade that for a bulky "new StringBuffer("a").append("b").toString()" for mere sake of clarity.

Think about that one for a while.

Java Hurt

[Anonymous Coward]

Check out the writings of Dr William Kahan. One of the men behind the IEEE floating-point standard.
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.

Re:Java Hurt

[Too Much Noise]

For speed, Fortran is still best. Most enginering codes are in Fortran.

That does not compute, logically - erm ... maybe only if you meant development speed (not arguing program speed one way or another).

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: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:Java Hurt

[Fallen Andy]

Yes, but the real reason for Fortran is lost on most
programmers. They think that Physicists, Chemists et
al really are too dumb to switch to *insert favourite
language*.

No sir. If you know *anything* about numerical computations you know they are evil. Boundary errors (chuckles) . The NAG routines are perhaps the most
debugged code on the planet. No way do I want to ever
touch them . Numerics in Java (ouch). Sorry, even
if it runs fast enough you can guess that I'll bite
the bullet and stick with subroutine F96XX29.
Hey, I'm really a coward. Just not an anonymous one.

Re:Java Hurt

[zakalwe]

Check out the writings of Dr William Kahan. One of the men behind the IEEE floating-point standard.
Read "How JAVA's Floating-Point Hurts Everyone Everywhere".

http://www.cs.berkeley.edu/~wkahan/

This paper was written on July 30, 1998, and a lot has changed in Java since. Perhaps it is time to reevaluate what you know, just like Dr Kahan thinks everybody should do with regards to what they learned from textbooks about floating point maths?

For speed, Fortran is still best. Most enginering codes are in Fortran.

Although not related to speed, I find it interesting how Dr Kahan all the way through his paper picks faults with the way that Fortran does things, and saying that Java shouldn't have adopted the same way of doing it.

Here is what Dr Kahan writes in the paper on what should be done to fix Java floating point problems:

"The first step with the least cost and biggest payoff is to abandon Fortran-like bottom-up floating-point semantics, and adopt Kernighan-Ritchie C floating-point semantics."

So first you say to go have a look at what is wrong with Java, and then you say that the best language to use the one that your own reference says is broken. Way to go!

Re:Java Hurt

[Freedryk]

Fortran speed is totally overrated. I run ocean climate models--some of the most time-intensive computing in the world. An average model run takes 2-4 weeks to complete. However, typically the set-up time is 2-4 weeks as well! It takes forever to set up the initial conditions, do small modifications to the code to configure it the way we want it, etc. Fortran vs, say, C or C++ is a 10-20% speed increase at best, and usually the gap is actually much less. At best, you save a day of compute time with Fortran, but you have so much less choice!

There is currently no viable open source F95 compiler--gcc 4.0 will have one, but as of now, we don't. So you have to buy a compiler package if you want to program. Most comp sci grads never touch Fortran--so everyone coming into the compuational sciences has to learn a new programming language, which slows development further. And, where java and C and C++ and python have a huge amount of APIs and such to bolt onto your program so you don't have to re-code the wheel, Fortran has very little that isn't pure numerical codes.

Fortran is undeniably the best for speed. But speed isn't what matters anymore. Hell, Numerical Python can usually get within a factor of 3 of Fortran speed--and considering how fast you can write Python code, the cross-platform portability, and the fact that it costs nothing to use, Python wins hands down for me, every time. I can just use the extra time the python code takes to make a lovely little GUI for my app that everyone in my department can use--which will help the progress of science far more than a halving of the model runtime.

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:These are not the languages you are looking for

[Bob Zer Fish]

Perhaps the reason behind this is because matlab is slow in comparison to C/C++. If you're doing stock modelling which changes by the ms or less, then matlab just isn't quick enough.

Re:These are not the languages you are looking for

[4of12]

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

Re:These are not the languages you are looking for

[Sara Chan]

I agree with the parent comment. Additionally, note that Maple tends to have more reliable numerics than Mathematica. (I know little about Matlab, and so cannot compare it.) You can easily call Java from Maple and Maple from Java.

You say that you work for a large financial company. You might check with the company's research group: they likely already use one of Maple/Mathematica/Matlab; so you could potentially be best off using what they use.

Re:These are not the languages you are looking for

[Camel Pilot]

Or go get Octave which is an open source Matlab like languange...

Re:These are not the languages you are looking for

[Hast]

I've only used Matlab and Maple, well a smattering playing in Mathematica, but not much. Anyways, of Matlab and Maple, Matlab is the champ when it comes so numerical stuff. It is just a lot better at anything that has to do with numbers, it seems like all image processing and computer vision research is done in Matlab from my experience. Needless to say there is a ton of premade stuff.

Maple is the king when it comes to algebraic stuff though. I have sometimes worked out the problem in Maple and then calculated it in Matlab. (Nowadays Maple has a competent numerical library, but it's still not as advanced or complete as Matlab.)

I think that there are some other big programs for statistical stuff (though Matlab is competent in this area). Though I believe a lot of those other programs are mainly used by people who come from a non-engineering background.

Re:These are not the languages you are looking for

[Hast]

Matlab m-files can be transformed into both Fortran or C and compiled if you need more speed. Naturally it is also possible to use compiled libraries directly from Matlab.

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.

Re:These are not the languages you are looking for

[jeif1k]

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.

And this from a guy who recommends Matlab? Matlab is all about "operator overloading".

And do you really think that "x.times(q.over(s.times(s)+Math.PI))" is easier to read and maintain than "x * q/(s*s+pi)"?

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.

Matlab and those other packages are expensive. And Matlab is not the kinds of system you want to write production or end-user code in. It's also kind of flaky when you try to do anything other than numerical computing in it.

Re:These are not the languages you are looking for

[Anonymous Coward]

Another option is Groovy, which has nice number handling. It's also easier to transition from Java to Groovy than to learn Python/Jython.

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

Do BOTH!

[cwensley]

What I'd suggest is BOTH. I am a huge C# fan, and am very inexperienced when it comes to Java. I never got into Java because the code seemed very akward and cumbersome to me (event handling, etc).

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 .NET, since each dev house will use their platform of choice. If you write a .NET version, then it can be used by any lanugage supported by .NET (C#,VB,C++,Java.NET,Cobol,Python, etc). But it will not be usable from native Java.

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:Do BOTH!

[aminorex]

I'd love to do all my coding in C#, if only it ran on a JVM.

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()?).

Try Java on .NET...

[jungd]

On Windows, you can use either MS Visual J# to compile Java for .NET and then use the numeric libraries, or on Linux (and Windows) you can use ikvm ( http://www.ivm.net ) to statically compile java bytes-codes into MSIL code and run it (with .NET on windows, or mono ( http://www.mono-project.com ) on Linux & Windows).

Re:Try Java on .NET...

[ADRA]

So, are you telling the poster to abandon JVM's and use the .NET CLR which may or may not break third party tools just to simplify a seemingly small part of their entire development process?

If you REALLY must use .NET based libraries, why not just write a JNI wrapper for the sub-system using operator overloading? Seem rediculous? I do, but its better than changing the entire environment.

Re:Try Java on .NET...

[jungd]

So, are you telling the poster to abandon JVM's and use the .NET CLR which may or may not break third party tools just to simplify a seemingly small part of their entire development process?

a) most Java apps have little direct contact with java bytecodes (i.e. only those apps that dynamically generate them for whatever reason)

b) the application environment is identical - you can use you usual java compiler to produce bytescodes and them translate them into MSIL codes. The usual Java library API is still available, including class loading & jar file resources, reflection etc. The added bonus is that you can use the enture .NET library API too (by prefixing cli. to the namespaces/packages). Not to mention the many other CLS languages that will seamlessly interoperate with your java code.

I'm using this route and it works fine. I've cross compiled many large java libraries and components and am using them from C#. For example, many of the apache libs - Xalan, Xerces, Ant, JUnit, commons stuff; IBM's eclipse.org rich-client framework - including SWT which uses JNI (x-compiles to P/invoke calls); the entire biojava.org suite; jython; swingwt; and others.

Some are even faster! (under Linux anyway - haven't tested under Windows)

If you REALLY must use .NET based libraries, why not just write a JNI wrapper for the sub-system using operator overloading? Seem rediculous? I do, but its better than changing the entire environment.

Maybe. JNI is for calling native apps though - not sure how you'd easiy arrange calling .NET code (you'd have to embed an IL code VM)

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.

Isn't floating point implementation broken in Java

[Anonymous Coward]

As somebody said, there's the "famous" paper by dr. Kahan.
But Sun pulled out of the JCP regarding IEEE fp, didn't it?
One of the authors of the "Java Floating Point's Hurt Everyone" paper now works for Sun and says (in http://servlet.java.sun.com/javaone/resources/cont ent/sf2002/conf/sessions/pdfs/1079.pdf)
that "Java's floating point follow rules, just not the rules you are used to!:-)"
It's all confusing. Apparently, the information just isn't out there in the open and hasn't been ventilated enough. A lot of Java programmers apparently have never even *heard* of the issue.
Makes me shiver to know some banks use Java...!
My take: do *not* use Java for numerical computation, as "Java Specification Request for Floating-Point Extensions has been withdrawn due to difficulties in setting up an expert group" (from http://math.nist.gov/javanumerics/ ).

Re:java is the future

[Anonymous Coward]

Hopefully there might be a better future, after Java. Despite the many popular features (garbage collection first and foremost), Java is widely regarded as a half-baked language.

Re:java is the future

[GuyverDH]

Hmmmm..

And without C, where would Java be?

Nowhere!

Pathetic

[kaffiene]

That's really sad. You have all the functionality you want but can't progress because your favourite syntactical sugar isn't there?

That's pathetic.

That's like saying, I've got this *great* idea but I can't code it up because I'm using C and it has brackets and not "BEGIN ... END" and I just can't live without them.

It's a different language - get used to it.

Re:Pathetic

[k4_pacific]

#define BEGIN {
#define END }

So there.

Re:Pathetic

[kaffiene]

Hey! I had to read code that some Pascal-head wrote in C, and he'd done just that.

Re:Pathetic

[augustw]

Steve Bourne did this when he wrote the Bourne Shell

Re:Pathetic

[lkaos]

That's really sad. You have all the functionality you want but can't progress because your favourite syntactical sugar isn't there?

Well, let's just do everything in Lambda calculus then.. it has all the same functionality.

Syntactic sugar is the purpose of programming languages. It's to make writing algorithms as easy, natural, and efficient as possible. We're so engrained in these procedure based languages that we seem to have accepted the fact that add(a, b) is the natural way to do things.

It's not. Learning complex procedural libraries is just as terribly complicated as learning a new language (if not worse assuming the new language would offer a more natural means of expressing ideas). I think the real point for the poster is that Java is obviously not the right tool for the job here. Eclipse has a C/C++ plugin (CDT) coupled with the GNU toolchain gives you an equivalent environment for C/C++ as for Java with just as much (if not more) freeness.

Doing something because "it's the thing of the future" is sort of silly. Who had thought Java would be more than a web-developers language 5 years ago? Who's to say we'll even be talking about Java in another 5 years...

Things change rapidly in our industry. Don't chase the future because by the time you get there you're going to be stuck in the past.

Re:Pathetic

[stoborrobots]

Who had thought Java would be more than a web-developers language 5 years ago?

the people who designed it to run on toasters?

Re:Pathetic

[Profound]

The "Syntactical sugar" allows the programmer to customise the language so that they can program closer to the problem domain.

Hiding the complexity of operations behind "sugar" allows the programmer to recognise mathematical conventions of relationships and operators and thus more quickly understand the code or to write it.

It is possible to write it without the sugar (heck, you could write it in assembly) it just takes more effort to do so and far more difficult to verify correctness. On large, difficult projects like the poster described, program complexity and the limited size of the human mind becomes a real problem, and anything you can do to reduce confusion and work at a higher level helps a lot.

Read a Java book from the 90s and you will see them laughing at C++ and how useless, dangerous and misguided templates are. The Java containers perform all kinds of convoluted tricks to make do without them, and now, with Java 1.5 they finally admit that templates have a use.

They did all along. Java needs them now, and they needed them then.

Re:Pathetic

[kaffiene]

We're so engrained in these procedure based languages that we seem to have accepted the fact that add(a, b) is the natural way to do things.

I'd say just the same to you. It's people who are pedantic about everything looking like maths that *must* have stuff written as:

a = b + c;

Personally I find that no more or less readable than:

a.equals(b.plus(c));

or:

(setq a (+ b c))

In fact, in many ways I think that the LISP approach is infinitely superior to overloaded operators in that there is never the issue of figuring out prescedence since it always follows the prefix operator pattern.

I don't see any good reason to assume that having code that looks like maths notation is superior to code which doesn't. For a start - all code is read by coders, not neccessarily by mathematicians. In addition, having one style of applying operations in your code clearly makes code which is more consistent (therefore maintainable) than code that implements many styles.

You're so engrained in mathematical notation that you seem to have accepted the fact that a = b + c is the natural way to do things.

Re:Pathetic

[lkaos]

You're so engrained in mathematical notation that you seem to have accepted the fact that a = b + c is the natural way to do things.

Excellent point! I think I mislead a little with my post. I don't advocate everything look exactly like mathematical notation, but rather that languages be flexible enough to adapt to whatever their user is most comfortable with. I believe strongly in DSLs and have been on-again off-again doing research in the area.

There are certainly lots of people that find things very readable that I find absolutely opaque and vice versa.

Re:Can you elaborate?

[sfjoe]

Even for simple case such as yours, I'd avoid trying to pack it all on one line. Misplaced parentheses are easy mistakes to make and extemely difficult to debug.

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

Matlab may be slower than C++...

[AuraSeer]

Matlab may be slower than C++, but then so is Java, and Java is what the original question is asking about.

I've never seen a side-by-side comparison of Java to Matlab, but if forced to guess I'd definitely really Java to be faster. However, Java is definitely not designed for any kind of mathematical work, so coding and maintenance would end up being a pain. (Trust me, I've been there.)

If you want ease of coding for mathematics, do what this post's grandparent said, and get yourself a dedicated mathematical package. If you want raw execution speed, write in C++ or C or assembler, depending on how much you value speed over maintainability.

Don't get me wrong, I like Java, but in this situation it's the wrong compromise. It doesn't have enough coder-friendliness (for math applications) to make up for its lack of speed, nor enough speed to make it worth the trouble.

Re:Matlab may be slower than C++...

[Anonymous Coward]

"Don't get me wrong, I like Java, but in this situation it's the wrong compromise. It doesn't have enough coder-friendliness (for math applications) to make up for its lack of speed, nor enough speed to make it worth the trouble."

Actually, java has the potential (and I think in many cases this potential is already realized) to be just as fast as equivalent C++ programs. Combine this with the ease of using java and the large user base and the argument against using java is weakened.

Re:Matlab may be slower than C++...

[Hast]

As I mentioned before the main benefit of Matlab is that it is designed for this type of work. Numerical analysis is /easy/ in Matab. It typically turns out to be a major pain in any language for non-trivial programs.

In the end you end up prototyping and testing in Matlab and then redoing (using the Matlab system to compare results against) in another language.

The question is however if not Matlab is "fast enough", particularly if you spend some time optimising by compiling libraries and even some parts of your system.

And even if I like Java I have to say that math code in Java (or any other language for that matter) tend to be absolutely horrid. Both a debugging and maintanence nightmare.

Re:Matlab may be slower than C++...

[AuraSeer]

Actually, java has the potential (and I think in many cases this potential is already realized) to be just as fast as equivalent C++ programs.

For math-intensive applications? Um... not to be a jerk or anything, but can you prove that?

My experience with Java math shows it to be 20-50% slower than the C++ equivalent. I'm willing to be proven wrong, though, if you can show me a benchmark in which Java comes out ahead.

(Of course you can make Java much faster by writing native code, or maybe by using deep Java mojo that I'm not aware of, but then you're increasing programmer workload again...)

Re:Matlab may be slower than C++...

[Anonymous Coward]

Um... not to be a jerk or anything, but can you prove that?

Of course he can't. This claim comes up in every article about Java, and nobody ever links to any convincing benchmarks. The only possible conclusion is that there aren't any and the claim is false.

Re:Matlab may be slower than C++...

[Anonymous Coward]

If by "proof" you mean "can supply credible evidence that you can verify," then yes.

http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html/

The writers of the this article have done the hard Work of "proving" that java's performance on numerical code Is at least comparable to C++.

Also, it seems to me that numerical programs (or at least a large class of numerical programs) are especially suited to dynamic compilation since a small piece of code is executed repeatedly (a hotspot). The compiler can focus on optimizing this hotspot once it's detected.

Re:Matlab may be slower than C++...

[Anonymous Coward]

"nobody ever links to any convincing benchmarks"

http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html/

Re:java is the future

[aled]

And that proves what?

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?

Re:Can you elaborate?

[AuraSeer]

That's kind of the point, isn't it? Interpreting a line that looks like an actual equation, where all the parentheses are mathematically meaningful, is easy.

When all the operations are turned into function calls, it gets much harder to debug. That's partly because of all the extra parens, and also partly because your brain has to interpret mathematics and English words at the same time. (That kind of thing tends to be harder than working with one or the other.) If you then split the equation out onto multiple lines it gets a little easier, but is still not as straightforward as the plain-looking math.

Of course there may be behind-the-scenes problems either way, because "a + b" or a.add(b) can represent a function of arbitrary complexity. But if your operators are hiding really complicated stuff, or especially if they have side effects, that's a strong sign that your design needs to be reworked.

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.

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.

Re:Interfaces

[the_womble]

We need a moderation option on the lines of "poster actually knows something about the subject". I am not a quant but I know enough about it to know that someone is talking sense.

That said the poster of the parent has been luckier than me - when I post on something in my field I usually do not get modded up.

I am very curious about what someone who was a quant till recently would be doing now.

Re:Interfaces

[GlobalEcho]

To satify your curiosity -- I work for a hedge fund now. Rather than modeling exotic derivatives or making fancy portfolio risk measurements, I'll be attempting to come up with trading strategies.

Models remain involved so I guess you might still call me a quant. But there will be a lot less variety, and the mathematics will be even more trivial.

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

Re:Horses for courses

[cerberusss]

Any competent group generally needs to be able to handle a mix of languages

I find that statement a bit strong. In my experience, most people are fluent (i.e. practiced, experienced) with only one or maybe two programming languages. Getting to know a language and its assorted libraries can take quite some time, and the knowledge quickly gets old. Coding in both Java and C++ is probably already too much for most people.

Re:Horses for courses

[pthisis]

Any competent group generally needs to be able to handle a mix of languages

I find that statement a bit strong. In my experience, most people are fluent (i.e. practiced, experienced) with only one or maybe two programming languages

1. The group needs to be able to handle a mix of languages. That doesn't mean everyone in the group needs to know every language.
2. I haven't yet worked with a reasonably competent programmer who didn't know more than 2 languages well (and I'd classify 90% of the programmers I work with as reasonably competent--the ones who only knew 1 language weren't very good in that 1).
3. I find that selecting the right language for the job has worked out incredibly well in practice, even when we wound up with heterogenous systems written in 5 different languages. All the straw man arguments about "people won't be able to work together in different languages" or "Joe can't read C++ code" or "we won't be able to find people to maintain it" turn out not to be issues in real life projects.

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?

[sfjoe]

I have just the opposite opinion. Interpreting a line (or multiple lines) with method calls is no more or less difficult than interpreting lines with overloaded operators. I think the OP has the opposite opinion and I was trying to understand why they felt that way.

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.

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.

Re:Operator Overloading is evil, evil, evil

[iroberts]

In C++, the evil started with

cout << "Hello world!";

(what the hell were they thinking?!) and went downhill from there.

While there are certainly legitimate complaints about overloading the left-shift operator, it is definitely preferable to most of the alternatives. The old printf-family is a set of errors waiting to happen:

printf("Take 20% off\n"); // oops
printf("Hello %s\n"); // oops
printf("You owe $%.2f\n", amount); // Lets hope amount is a float.

It would of course be possible to avoid this without overloading by requiring calls like:

out.printString("Hello, ");
out.printString(wordString);
out.printString ("\n");
out.printString("You owe $");
out.printFloat(amount, 0, 2);
out.printString("\n");

But that is definitely going to cut down on productivity, both in writing and reading code.

By contrast, the streams approach taken in c++ is type-safe, extensible, and easy to use. Perfect? No. Better than most alternatives? Absolutely.

Re:Operator Overloading is evil, evil, evil

[CountBrass]

Compare this to some equivalent Java code:

System.out.println("Ohh look " + " how hard " + " it is to get it right without messing with operator overloading. Gratuitous int: " + anInt);

Note: no bizarre operating overloading and only one line of code.

Re:Operator Overloading is evil, evil, evil

[Anonymous Coward]

ummm...'+' is an operator overload for Strings in Java...which just proves that overloading is useful!

Re:Operator Overloading is evil, evil, evil

[dkf]

By contrast, the streams approach taken in c++ is type-safe, extensible, and easy to use.

There are three things wrong with C++ streams.

• They are anti-i18n. (Look up XPG3 format specifiers and the java.text package for reasons why both C and Java are ahead of C++ in this area.)
• They are really much more verbose when you want to do complex formats (if you only ever use the %f, %d and %s formats in C like that, you're missing the strength of printf().)
• Irrespective of everything else, operator overloading is evil because it is a facility that too many people insist on abusing.

  <RANT>
  If I'm about to do a function/method call, I'd lilke to know goddamnit, because it matters when you're trying to analyze the system performance. (Yes, Java's overloading of + for Strings is bad too, and that leads to a lot of awful code too.) Overloading looks great and can be used to great effect; it just doesn't work out that way in the real world. :^(
  </RANT>

To me, C++ streams feel very noddy and do not seem to be tools fit for high quality production code. No doubt some weenie will disagree...

Re:Operator Overloading is evil, evil, evil

[lscoughlin]

you missed an Integer( int ).toString() in you're little box oh example.

You're snippet just went boom.

Re:Operator Overloading is evil, evil, evil

[Anonymous Coward]

>>you missed an Integer( int ).toString() in you're little box oh example.

No he didn't - there's no need for a manual conversion. Java's String objects handle that automatically. (Of course, the fact that doing so is *itself* an example of operator overloading is counter to the poster's actual point... but that's another story.)

Re:Operator Overloading is evil, evil, evil

[Anonymous Coward]

Oh, but is that '+' thing you are using???

Re:Operator Overloading is evil, evil, evil

[nebaz]

Ironically, no he isn't. This is the one example of operator overloading Java allows.

(int) + (String) results in String.valueOf(int).concat(String)

Re:Can you elaborate?

[DrEasy]

I think his problem is elsewhere: without overloading he would end up with something like:

a = Math.sqrt(Math.abs((b + c)multiply((d/e)) ))

That is, a mix of "native" operators and adhoc methods. With overloading you would be able to forget about the type of the variable or the return value and let the VM figure it all out.

My new hammer is so easy to use

[DrSkwid]

but it won't drill holes, what do I have to do to my hammer to make it drill holes?

---

object-oriented design is the roman numerals of computing.

-- Rob Pike

other witicisms

Use Fortran 95

[beliavsky]

I am a quant who uses Fortran 95 for the things you mentioned -- it has built-in multidimensional arrays, including arrays with complex elements and operator overloading, and it's cross-platform if you write standard Fortran 95 and have compilers for needed platforms. You can compile code to DLLs for use in Excel etc.

Re:Use Fortran 95

[CaptainPinko]

and how does this tie in with Java? you know of any good Fortran -> .class compilers out there? These would have to be fairly top notch since this is a buisness...

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.

yup!

[DrEasy]

I agree with AC! Another benefit would be that you'd be separating data from processing, which would allow easy formula manipulation without needing a programmer (assuming that you'd have some sort of nice formula editor that can spit out the XML for you).

list

[Anonymous Coward]

There is a list of several packages here: http://math.nist.gov/javanumerics

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.

J.A.D.E

[Knetzar]

Take a look at J.A.D.E. Java Addition to Default Environment.
It seems to have some nice math and physics packages.

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.

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

MOD PARENT DOWN

[Anonymous Coward]

Gee, I wish you had logged in. You need some negative mod points.

You didn't realize FOO::BAR::BAZ(char*) will never be called unless you attempt a *unary* math operation on a string of const char*. (Why would you implement that??!?!?)

Also, C++ operator overloading can modify objects instead of returning new ones -- (How pre-increment, etc)?? Also, if you return by reference, a decent compiler should be smart enough to figure out what is going on....

Re:MOD PARENT DOWN

[Anonymous Coward]

Gee, I wish you had logged in too...

Ever deal with arbitrary precision integers or fixed decimal with a custom internal representation? Representing a number as a char array of decimal digit characters may not be efficient, but it's quick to write. And it does happen.

Ever deal with silent auto-promotion of types to customized classes as temporaries? You know, where you say "int(1)" in C++, and the compiler creates an object of type FOO, initializing it with int(1), as a temporary...

I've seen some really badly written code -- they don't call me in to support the stuff that works -- doing some really weird things. Gets even worse when you try to trace it through inlined headers.

And y'all want to make thing worse! Do you really want an operator+() that changes the object's state? So that:

This Works: a = sqrt(abs((b + c) * (d / e)));
This Dies: a = sqrt(abs((d + c) * (d / e)));

God knows I have enough problems with the idiots who implement both operator+() functions and methods. Sometimes one. Sometimes the other. Then patch it together with casting operators.

And, oh yeah, they break commutativity to boot. So that: a+b != b+a.

Frick'en newbies.

Operator overloading is only half the story

[Anonymous Coward]

and templates (generics) are the other half.
Every modern C++ financial library employs templates. Not only do they save time in writing code - the high quality C++ optimizing compilers these days crunch that template code down into very small and fast code. I don't think Java generics are mature enough to provide the same quality code. To my knowledge there are no financial libraries that make use of Java generics either. I'd wait a couple of years before embracing Java for heavy math crunching.

Re:Operator overloading is only half the story

[E_elven]

All Java Generics do is preprocess the generic definitions into their respective Java representations. So (excuse the syntax) for an object

MyVector[int] vec = new MyVector[int]

All calls like this

int value = vec.find(x)

are replaced with

int value = (int) vec.find(x)

C++ templates are much more versatile.

Re:Operator overloading is only half the story

[Anonymous Coward]

true, except your example is wrong.

int value = vec.find(x)

is actually replaced with

int value = ((Integer)vec.find(x)).intValue();

Java's generics don't work for primitives, so boxing/unboxing come into play.

Re:Operator overloading is only half the story

[CountBrass]

"bloated" isn't spelled "versatile".

Re: virtual inheritance

[Anonymous Coward]

In C++, virtual inheritance is a special form of multiple inheritance in which two or more base are allowed to share the same base data. Example follows:

#include <assert.h>

class x { public: int data; };
class a : public x { };
class b : public x { };
class c : public a, public b { };
class a2 : virtual public x { };
class b2 : virtual public x { };
class d : public a2, public b2 { };

int main(void)
{
c C;
assert ((&((a*)&C)->data) != &(((b*)&C)->data)); /* separate copies of x */
d D;
assert ((&((a*)&D)->data) == &(((b*)&D)->data)); /* one copy of x */
return 0;
};

Lame ascii follows:

.x...x. ...x...
.|...|. ../.\..
.a...b. .a2.b2.
..\./.. ..\./..
...c... ...d...

c is standard multiple inheritance.
d is 'virtual' multiple inheritance.

But what about creation of temporaries

[ufnoise]

You might be better off with.

CrazyObjectNumber c=a;
c*=b;
c+=53;

This reduces the number of temporaries required. I use c++ and I hate object overloading because people hijack operators to mean silly things. For example, operator~ means surface integration and operator! means volume integration in this code I work in.

Re: Bad coders are a BAD THING

[E_elven]

If something is commonly expected not to produce side-effects, then the coder should write it so that it will not produce side-effects.

How hard is that?

MathML + library + code generator

[angel'o'sphere]

We use MathML.

You can use editors in most Word processing environments to write formulars in MathML. E.g google for "MathType".

We then use a generator to map MathML on java methods. If methods are mising we write them.

For a MathML equation like: quotient := a/b; a method with name quotient and parameters a and b is created. If the term a/b gets more complicated like a sum or a integral, it is mapped to library functions.

As I said above, if such a function is missing a programmer writes it.

angel'o'sphere

Re: virtual inheritance

[E_elven]

If you find yourself doing MI where the same base class gets inherited there's a very good chance you're doing something wrong.

Okay, mom....

[Tim]

What you describe is a classic example of "mommy" thinking -- absolutely preventing the use of a feature which might be immensely valuable (or essential!) 10% of the time, because there is a chance that someone, somewhere will misuse it. It's the computational equivalent of forcing everyone to use safety scissors -- after all, someone might hurt themselves!

I do program in C++, and I know that it's one of the most flexible, expressive, and efficient programming languages that you'll ever find. It is a language for professional programmers who do not wish to be told how they must do something, in favor of being allowed to just do whatever it is that they're trying to do. So-called "ugly" languages (like Perl) share this philosophy. It's part of the reason that they're so widely used.

Coding in Java is a bit like trying to go through your life wearing nothing on your hands but Big Fluffy Mittens. There's nothing wrong with Big Fluffy Mittens, per se, and Big Fluffy Mittens are undeniably wonderful when you're making a snowman. Still, they kind of suck for brain surgery.

Re:Okay, mom....

[CountBrass]

C++ is an abomination plain and simple. It's a Frankenstein's monster of a functional language (C) that's had OO constructs bolted and stitched onto it.

C gave you a pistol and allowed you to shoot yourself in the foot. C++ gave you a machine with the trigger and the safety catch switched around and came with an instruction manual that encouraged you to shoot yourself in the foot (a previous posters cout C still has a place: writing low level, fast and efficient stuff. C++ is just a willy-wavers' ("ooh look girls I can de-reference a pointer") language.

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

Re:Okay, mom....

[melquiades]

Well, my own take on your griping about "mommy" thinking is that, when people share code, they all have to live with a language together, and decisions about what to leave out of the language are at least as important as decisions about what to put in. People who are eager to use tons of language features and be super-clever with syntax are a pain in the ass to share code with, and a liability on a team; that's why Perl is widely used by recreational hackers and open source projects, but almost unheard of in the world of large commercial projects with shared teams -- and it's why C++ is rapidly losing market share in that world.

I personally ran screaming from C++ to Java after years of having worked in the former. It was as if somebody had read my mind about what went wrong with C++ and invented the language I'd been wanting to use that whole time. When I code in Java, the code is an elegant realization of my object model. When I code in C++, the code is an awkward approximation of it.

I guess we just value different things in a language. De gustibus non disputandum est.

Re:Okay, mom....

[Anonymous Coward]

You've never written a line of code in your life. Come on, just admit it.

Re:Okay, mom....

[ArbitraryConstant]

"I do program in C++, and I know that it's one of the most flexible, expressive, and efficient programming languages that you'll ever find."

Efficient? That should say "the inefficiency is explicit".

"It is a language for professional programmers who do not wish to be told how they must do something, in favor of being allowed to just do whatever it is that they're trying to do. So-called "ugly" languages (like Perl) share this philosophy. It's part of the reason that they're so widely used."

Perl and C++ aren't popular because they have any merit as languages. The property they share is that they were the only alternatives when they came out. Now that there are alternatives for both of them, both of them are correctly losing programmers and projects.

Python is a lot more restrictive than Perl, but it's cleaner. If you were correct, Python wouldn't be gaining ground like it is. C# and Java are both more restrictive than C++, but C++ is also losing ground (more quickly in this case).

"Coding in Java is a bit like trying to go through your life wearing nothing on your hands but Big Fluffy Mittens. There's nothing wrong with Big Fluffy Mittens, per se, and Big Fluffy Mittens are undeniably wonderful when you're making a snowman. Still, they kind of suck for brain surgery."

You would be correct if it were true that programmers that use Java can only use Java. I agree there are some things that Java isn't good for. That would be why I use other languages.

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

Here's a general idea

[Estanislao Mart�nez]

Try to use some other language that compiles to the JVM, that produces good numeric code and has overloading. I don't really know if such a beast exists, but here's a list of languages that you can start on.

There's a serious question here as to how much performance you're willing to sacrifice just to be able to live solely under the JVM, though.

That's a bad idea.

[Estanislao Mart�nez]

If you have to say the same thing twice in a program, you're probably doing something wrong.

Re:That's a bad idea.

[TheLink]

Can you back up/explain your statement?

Re:That's a bad idea.

[Anonymous Brave Guy]

I'll back it up for him...

Putting code in comments is a bad idea, because comments can't be verified. A misleading comment does more harm than good: it takes extra time for a developer unfamiliar with the code to work out what it does, and to realise that the comment is incorrect. This is the most important reason to write "self-documenting" code, i.e., code that describes its own behaviour without the need to duplicate that work in a comment (as the great-great-...-grandparent post so hideously suggested).

Comments, like any other documentation, are beneficial in that they can describe in abstract terms what the code is doing -- the "big picture", if you like -- where sometimes it's not convenient to do that with the code itself.

Comments specifically are also useful if a line of code necessarily looks like it's doing something unusual, although I would always prefer rewriting such a line to be clear in its intent if it's practical to do so.

The point is that these uses complement the code itself. They don't duplicate it, which is just a waste of time and a potential source of errors for no apparent benefit.

Re:That's a bad idea.

[TheLink]

Yeah, but nowhere did I suggest duplicating the code. I said it should be like a CRC (CRCs don't duplicate the data), and you know something is wrong if the "CRC" isn't consistent.

He said that was a bad idea, and talked about saying the same thing twice.

So I was curious to see whether he couldn't read/think properly or if he actually had something interesting to say. Or both.

Re:That's a bad idea.

[CountBrass]

The only problem with this is that if the code is "wrong" (ie works perfectly as code, but just does the wrong thing) then someone else is going to have a hard time telling that's the case.

That said I prefer not to comment and leave it to unit testing to verify my code isn't "wrong": in that sense the unit tests are a kind of verifiable comment.

Ehm... 2 corrections

[insac]

1) I noticed I went slightly offtopic.. (sorry)
The original question was "what can I use to make numerical analysys?" while I followed the track "Operator overloading is good/evil"

2) the sentence "I'm not going to" was "I'm not going to misuse this feature"

Come to think of it

[Estanislao Mart�nez]

If your expected use is constrained enough, you can probably get away with writing some sort of simple code generator. You parse algebraic expressions, generate an abstract syntax tree, and use that tree to spit out appropriate java code.

Re: virtual inheritance

[Anonymous Brave Guy]

If you find yourself doing MI where the same base class gets inherited there's a very good chance you're doing something wrong.

There are schools of thought that would argue any use of MI that doesn't involve common base classes is probably doing something wrong. In practice, either view is rather absolute, no?

There are useful idioms using mix-ins, and there are times when combining two separate hierarchies is justified. There aren't many of either -- hence the unpopularity of any sort of multiple inheritance of implementation in some quarters -- but IME both have their uses, and when the time is right, it's much simpler to use the appropriate MI-based design than to work around it.

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

Re:No, operator overloading is a GOOD THING!

[jilles]

The amount of code should be measured over the whole system. I doubt you could gain more than a few percentage points by including operator overloading in a language, even in math intensive programs.

Clear and consistent syntax is the whole reason + doesn't mean whatever you define it to be. To me a.add(b) is not any less clear than a + b, + a b or a b + which are all equivalent expressions.

Outside the domain of math heavy code, there is no good reason for operator overloading. Inside this domain you probably should be using other languages. If you are doing thousands of lines of codes with only formulas in a language like Java or C++ you are doing something wrong. Very few Java programs are actually math heavy so for most of these programs operator overloading can only decrease readability. Most of the math heavy programs have all the math isolated in a handfull of classes that are relatively stable.

Re:No, operator overloading is a GOOD THING!

[Anonymous Brave Guy]

To me a.add(b) is not any less clear than a + b, + a b or a b + which are all equivalent expressions.

In a simple case, no. But one approach scales much, much better than the other, as exemplified in several code samples posted in this discussion. There's also the generic algorithm issue that is usually over-looked in this debate, which I've mentioned in other posts.

If you are doing thousands of lines of codes with only formulas in a language like Java or C++ you are doing something wrong.

Well, since no other mainstream language is even close to being able to do what we do every day in C++ at work, I'll respectfully disagree on that one. As for Java, /me looks at discussion title, notes the question mark, and smiles.

Re:No, operator overloading is a GOOD THING!

[Anonymous Coward]

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

Are you seriously claiming that it takes five times as long to write

x
=
x
+
1

as it takes to write

x = x + 1

?

Lines of code are the worst possible measure of productivity, therefore the research you claim exists (if you can't be bothered to cite it, I'm sure not going to take you seriously enough to look it up myself) is based on an obviously flawed premise and can safely be ignored.

Re:No, operator overloading is a GOOD THING!

[Anonymous Brave Guy]

Are you seriously claiming that it takes five times as long to write

x
=
x
+
1

as it takes to write

x = x + 1

?

No, of course not, but no serious programming language does that. It does, however, take a roughly proportionate amount of time to write realistic code. I found around half a dozen comparative programming language studies whose data are consistent with this proposition (although that wasn't necessarily what they were testing) in about five minutes using Google, so if you care to learn something rather than making silly arguments the option is there for you.

And by the way, lines of code are a good metric for productivity in the right context. We aren't comparing programmers here, we're comparing the relative power of different languages based on the effectiveness of a diverse sample of programmers of each. Don't parrot, think.

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:cout << "Design error";

[Anonymous Brave Guy]

Almost every basic I/O library, from C's printf() to Java's System.out.println() to Perl's print(), forces you to specify the order that the arguments are displayed.

Sure, and they all suck, as demonstrated by the fact that pretty much no serious UI code uses them. They are child's toys, and several decades after the invention of printf, you'd hope we knew better.

That has nothing to do with operator overloading.

No, it doesn't, but then neither do the major problems with C++ I/O streams. That was kinda my point.

Programming is a skill

[Anonymous Brave Guy]

While many of your points (for either side) have merit, I think it's important to remember that programming is a skill. It is not something just anyone can do, and doing it well requires a sufficient level of knowledge and ability. If you're working with people who Just Don't Get It(TM) so badly that they write misleading operator overloads, then you have far bigger problems than the presence of operator overloading in your language.

Languages can protect against careless errors: everyone knows you shouldn't dereference a NULL pointer, but in some languages, you have the option to do so by mistake. But languages cannot protect against a lack of understanding of how to use your tools, no matter how restrictive they may be.

Re:Programming is a skill

[bonniot]

I completely agree. Operator overloading does not offer more occasions to write misleading code than the ability to write methods with misleading names. In both cases, you need discipline to match the name (or the operator) with the semantics of the method. So in this case the drawbacks are almost non-existent, while the benefits are significant. The situation is less clear about invisible "magic" operations like copy constructors in C++.

Indeed, a language cannot prevent this kind of confusion, since "You cannot go from the informal to the formal by formal means", and the name of a method belongs to the informal. It should try to make as much errors as possible detectable at compile time, like cast errors, dereferencing null references, writes to covariant arrays, ...

Re:Programming is a skill

[insac]

I'm not meaning that "operator overloading" is BAD and therefore we should always limit it (I used C++ and I was happy with "operator overloading" and I feel I never abused it)

I'm just saying that Java (the language) direction has always been for exchanging "flexibility" for "maintanability" and therefore "operator overloading" could be introduced in Java only following the same path.

Someone pointed out that a language cannot prevent the inexperienced developer to abuse a feature: that's absolutely true, but a language can try to make easier for the experienced developer to find and repair the damages with little effort.

When we feel the flexibility and elegance is more important than this kind of "maintanability" we will choose other languages.

P.S.: I'm using "maintanability" but the concept is more like "allowing the experienced developers to compensate for the inexperienced ones". My knowledge of English doesn't allow me to find a better word :-(
I guess it is something similar to what managers call "productivity" :-)

Matlab, schmatlab, I want to compute something!

[Latent Heat]

Matlab is a Good Thing (tm) with respect to extensive libraries and an OK graphics package. The C/C++/Fortran extension system is OK, and the Java extension system (write modules in Java callable from Matlab) is pretty good.

From the standpoint of a language, Matlab is, gee, I don't know where to begin. It really has this cobbled-together lets-figure-out-how-to-graft-on-objects feel to it like Visual Basic only more so. The really simple is simple, and the somewhat complicated gets to be rats' nest really fast.

Operater Overloading doesn't thrill me

[dfj225]

Sure, it can make your classes look like part of the core libraries, but it is only a simple redirection of function calls. It is really just a change in syntax that doesn't really add any new functionality to the language. To me, I'd rather add a toString() method to my Java class so I can use it with print() or println(). If I wanted to do it the c++ way, I would probably make a toString() method anyway and just call that from the overloaded operator. Same idea just different ways of going about it.

Mod AC up

[TheLink]

I see comments as complementary.

Unit tests might sometimes not work (or give useful results) when the program isn't working - e.g. badly broken. Whereas the comments could still be useful in those cases (maybe even more so ;) ).

And if you are looking at the code, means you are going to be spending time with the code anyway, so the comments are a nice and handy reference.

I don't think you'd need comments everywhere - at least for most code - since most code is just run of the mill. Comments would be useful if you are doing something exceptional, or something important. e.g. "This weird stuff is to work-around bug #1467 in version x.y.z of software ABC".

Sure you should write documentation for that and refer to the documentation. But it is handier to have the comments around as well.

Re:Mod AC up

[CountBrass]

If the original developer didn't bother getting the unit tests right do you seriously think he'd get the comments right?

Re:Mod AC up

[TheLink]

I'm saying even if the unit tests work perfectly, you can't use them if the program you want to test is badly broken for that particular area.

It'll just tell you something you know already.

It may be broken by a change in the behaviour of an external system. There's a small hope that the comments might actually help - e.g. the programmer comments: "WARNING!! Change to +1 and remove this comment if XYZ fix bug #1234".

Another correction

[insac]

"Why it is so easy to misuse and mantain?"

was

"Why it is so easy to misuse and hard to mantain?"

Re: No, Operator Overloading is a BAD THING

[Anonymous Coward]

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.

The other AC was pointing out that your second "equivalent" example revealed that your overloaded operators were mutating the objects when they shouldn't (a = a.multiply(b) is the same as a*b?!?!), which actually presents the case against operator overloading: people sometimes feel free to change their meanings.

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

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.

Re:java is the future

[Anonymous Coward]

FYI, java compilers and environment are coded with Java, not with C.

Static import in Java 1.5

[CaptainPinko]

importing static methods in java 1.5 should clean that syntax up a bit since you won't need to have the "Math." everywhere. Or straight from Sun: http://java.sun.com/j2se/1.5.0/docs/guide/language /static-import.html

Re:cout "Design error";

[Anonymous Coward]

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.

It's not a "D'oh!" mistake. Almost every basic I/O library, from C's printf() to Java's System.out.println() to Perl's print(), forces you to specify the order that the arguments are displayed. That has nothing to do with operator overloading. If you want code that allows you to change the order of the arguments in some sort of data file, then you need to use a more complicated library, like Java's java.text.MessageFormat. If you don't, then the basic functionality is perfectly fine.

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.

Screw the language wars ...

[ManikSurtani]

Here's something that's potentially useful.

Jakarta's Commons Math library (http://jakarta.apache.org/commons/math/) 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.

Re: Bad coders are a BAD THING

[Anonymous Coward]

If something is commonly expected not to produce side-effects, then the coder should write it so that it will not produce side-effects.

How hard is that?

Harder than you think.

The problem is that side-effects are not always obvious. In a language without operator redefinition, you can look at "+" and know it has no side-effects. In C++, you have to read the code for the class in question and reason about it yourself, if you want to know. Let's hope you're not using a closed-source library, eh? And even if you have the code and read it, you might well get lost in a maze of twisty little constructors, all alike, and draw the wrong conclusion.

Overloaded operators are unquestionably useful - it's nice to be able to use + for floats and strings as well as ints, for example. But overloading should be left to people who know what they're doing. I trust language designers, I don't trust random programmers, so I don't like C++ libraries that overload operators.

Maybe you do trust random programmers -- but if you do, please post a list of projects you have worked on, so I can avoid them for the safety of my data.

Sparc

[orasio]

Sparc assembler, you mean, of course.

Re: virtual inheritance

[CountBrass]

That's only true for a language that doesn't allow dynamic binding or proxying: ie it's a work-around not a fundamentally requirement. The reason I'd call it a work around is because it uses nheritance for implementation (the same as private inheritance: something that real ;-) OO languages don't have).

Re:java is the future

[Anonymous Coward]

Protozoa can exist without you, too.

Re:cout "Design error";

[dkf]

Almost every basic I/O library, from C's printf() to Java's System.out.println() to Perl's print(), forces you to specify the order that the arguments are displayed.

Not exactly. If your printf() has the XPG3 format extensions (what, yours doesn't?!) then you can completely disconnect the order in which values are placed in the output from the order in which they are specified. If you then pull that format string from a message catalog, you've got i18n-aware printf() for virtually no effort on your part.

A pragmatic solution

[Laz10]

Don't focus too much on what is in the box. If you really want the operator overloading you can get it from JFront as you mention yourself. So add that to the mix in a gentle way.

Here's what I would do:

1. Modulize all the heavy math stuff you do into a couple of well defined modules (or subprojects if you like that term better).

2. Have all other modules interact with the computation modules on a logical level where you work in terms of getBigResult(arg1, arg2).

3. On the math modules use ant: http://jakarta.apache.org/ant to preprocess the code on those modules with JFront before compiling.

That approach would allow you to use JFront and the sugar that provides without getting too painful for the rest of the project.

Don't Repeat Yourself principle

[Estanislao Mart�nez]

The problem is that your comment is saying the exact same thing as the code in question. One of the most useful principles in programming is "Don't Repeat Yourself": if you find yourself having to maintain two separate representations of the same fact, you're doing something wrong.

In the current case, we want to use the more convenient notation for these computations (the plain old mathematical notiation) as the canonical one, and somehow get from it to the executable code. The best solution is to have it happen automatically, i.e., to have some program that will convert "a + b / c" into the program you want. This can be done directly (use a computer language with appropriate features), or indirectly (use a preprocessor to automatically convert the good notation into the java code, and then compile the latter).

Your solution involves (a) writing the same thing twice manually, (b) having the easy, desired notation be a comment, and thus not be the one that's converted into executable code; (c) have the process of translating the friendly notation to the unfriendly one be done manually, one time after the other.

Yeah, but nowhere did I suggest duplicating the code.

But my point is that in this case the comment should be the code. If what's written in your comment needs to be translated manually into something else, then you should write code to translate it automatically.

Re:Don't Repeat Yourself principle

[TheLink]

"If what's written in your comment needs to be translated manually into something else, then you should write code to translate it automatically"

But the comment isn't code. And you're missing my point completely.

Don't tell me you'd want a program to automatically _ensure_ (not _verify_) that your CRCs/checksums are always correct.

As for having multiple representations of the same fact, that's called redundancy. And it's not always a bad thing - go ask people who buy RAID systems or intentionally have 3 different computers running _different_ software from different vendors that's supposed to do the same thing.

We are living in an imperfect world and dealing with many different imperfect people and systems. You're going to have to say the "same" thing many times in different ways so that you are more certain of getting the point across eventually.

There will be differences and inconsistencies but the more times you intentionally say something that is consistent, then the more important you regard it. The other stuff which is said only a few times and is inconsistent should be not so important/critical.

That goes for the spec, the documentation, the comments, the unit tests etc.

It's not "Hello Perfect World".

It's "Hello #@$^%7.4d NO CARRIER

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.

Re:java is the future

[GuyverDH]

And have you ever tried to run Java sans shared libraries?

All those lovely libxyz.so type files...

Those aren't java my friend.

Those are lovely shared objects courtesy of C/C++

Very few languages can be used to compile themselves...

And I do not belive that Java is one of them...

Insifghtful ?! Subjective at most.

[Anonymous Coward]

"Dislike virtual" .. Mwahaha .. give me a break.

Re:cout "Design error";

[Kalani]

How is that a problem? Is it a problem because maybe a date in one country has the year in a difference place than the date in another country? If it's something like that, hey you're in luck! The C++ iostreams library was designed with just such a possibility in mind.

The answer is that you've got to define your own datatype for handling "date" information and deciding on how it's to be output (which elements and in which order). This allows you to *simplify* the code that writes the actual data. For example:

MyDateClass MyDate(1, 1, 2004);
cout << "Today is " << MyDate << endl;

So what's wrong with that?

Re:java is the future

[jasomill]

Very few languages can be used to compile themselves...

Actually, quite a few languages can be used to compile themselves, or, properly speaking, quite a few compilers (for various languages) can be (and are) used to compile themselves (or, for that matter, other compilers for the same language). And most languages could be used to develop a compiler for the same language (though it may not be worthwhile) -- say, any Turing-complete language with appropriate storage capacity and I/O facilities. After all, what is a compiler, other than a fancy data conversion application? Naturally, you need to bootstrap a compiler for a new language using tools written in other languages (possibly building up to a subset of the target language, but that's still another language), but that's necessarily true for all compiled langauges, as well as assembly.

And I do not belive that Java is one of them...

If I'm not mistaken, javac is implemented in Java. To wit:

jasomill@prospero jasomill $ java com.sun.tools.javac.Main
Usage: javac <options> <source files>
where possible options include:
. . . . .

Of course, the back-end of javac emits Java bytecode, but there's no reason a compiler for Java, written in Java, with a native back-end couldn't be written.

Re:java is the future

[bokmann]

huh?

Java is a turing complete language. It can be used to implement any other turing complete language.

Where do yu think C first came from? It did not burst forth, fully formed, from the loins of Kernigan and Ritche... it was originally written in some other language. As it became turing complete, it could be re-written in itself.

-db

Jakarta Commons Math Library

[bernfast]

This way recently announced:
http://jakarta.apache.org/commons/math/

You may also want to take a look at:
http://math.nist.gov/jnt/
http://www.vni.com/products/imsl/jmsl.html
http://www.mathtools.net/Java/Libraries/

operator overloading is a good thing

[JsTwO]

there's a reason why ppl invented those operators (in real math) and continue use it.

according to the easy to misuse theory, gun is bad. it's so easy to kill ppl using a gun.

Operator overloading required for multiinheritance

[HornWumpus]

At least to make multiinheritance worthwhile.

For example with C++ you can make any streamable object persistant by inheritace. You count on streaming operator overloading to make you save and restore functions work.

But the Java zelots don't like multiple inheritance eather. I'd say its lack groups Java with VB as a pseudo OO language.

I hate high level languages

[HornWumpus]

I hate high level code because if hides what's actually happening - machine code. When you are actually debugging code its difficult to see what is in the processor registers.

I also dislike non-plotter output for the same reason.

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

All variable Static in FORTRAN

[HornWumpus]

Worked with a group of FORTRAN people working a heavy numeric problem (chronological simulation of the electrical grid).

In Fortran 77 all variables are static. Saves allocate time and allows for more efficent machine code from the compiler. I've never seen a FORTRAN To C translator that translated all FORTRAN variables into Static C variables (haven't looked in some time). That might produce interesting benchmarks.

Of course the static array demension restriction brings on many problems of it's own.

Re: point #2 (vector add and sub)

[Anonymous Coward]

In the context of mathematics (this thread), vector addition and subtraction should be scalar operations; therefore, your example of concatenation is counterintuitive.

Furthermore, these operations should only be defined for vectors of equal dimension (and that's going to require runtime checking unless you use a typedef for each vector size).

And finally, note that vector multiplication is also troubling since you'd have to pick if you want a scalar (dot product) or vector product (cross product). And once you pick one over the other, you're left with no way to express the other using standard overloadable operators.

These are examples why Java and C++ operator overloading are not suitable for mathematics.

Oops..

[insac]

It seems I mixed contexts... (sorry)

I meant Vector as in Java libraries, that is "a Collection". I should have used "List" instead.

I wanted to say that sometimes "operator overload" is used out of maths/economics context and this is sometimes confusing