Slashdot Mirror

← Back to Stories (view on slashdot.org)

Numerical Computing in Java?

Posted by Cliff on from the calculating-coffee dept.

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

7 of 196 comments (clear)

  1. No Operator Overloading is a BAD THING by digerata · · Score: 4, Insightful
    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?

    --

    1;
  2. Use the right tools for the right job... by Chilles · · Score: 4, Insightful

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

  3. I hate overloading by Anonymous Coward · · Score: 3, Insightful

    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.

  4. These are not the languages you are looking for by Anonymous Coward · · Score: 5, Insightful

    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.

  5. Re:Can you elaborate? by Anonymous Coward · · Score: 4, Insightful

    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.

  6. Horses for courses by barries · · Score: 3, Insightful

    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

  7. Operator Overloading is evil, evil, evil by melquiades · · Score: 4, Insightful
    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.