Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Java Programming Software Technology

Numerical Computing in Java? 196

Posted by Cliff 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?"
This discussion has been archived. No new comments can be posted.

Numerical Computing in Java? More

Numerical Computing in Java?

Comments Filter:

  • No Operator Overloading is a BAD THING (Score:5, Insightful)

    by digerata ( 516939 ) on Monday September 20, 2004 @03:45PM (#10300658) Homepage
    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?

    • 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();

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

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

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

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

      • 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
        • 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 proba

          • 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, sin

    • Operator Overloading is evil, evil, evil (Score:5, Insightful)

      by melquiades ( 314628 ) on Monday September 20, 2004 @06:44PM (#10302552) Homepage
      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.
      • 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 lan

        • 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 lo

        • 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 i

      • 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

    • 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() meth

  • Use the right tools for the right job... (Score:5, Insightful)

    by Chilles ( 79797 ) on Monday September 20, 2004 @03:51PM (#10300721)
    Sure it might be easier on the administration side to use just one tool. But in the end a language is just that, a tool. You don't see carpenters throwing away all their tools except the hammer just to keep their tool-shed clean...

  • I hate overloading (Score:3, Insightful)

    by Anonymous Coward on Monday September 20, 2004 @03:56PM (#10300765)
    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.
    • 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.
    • 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,
    • 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

  • Java Hurt (Score:3, Interesting)

    by Anonymous Coward on Monday September 20, 2004 @03:58PM (#10300790)
    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 (Score:4, Interesting)

      by Too Much Noise ( 755847 ) on Monday September 20, 2004 @04:30PM (#10301112) Journal
      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.

  • These are not the languages you are looking for (Score:5, Insightful)

    by Anonymous Coward on Monday September 20, 2004 @04:00PM (#10300804)
    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 (Score:4, Interesting)

      by 4of12 ( 97621 ) on Monday September 20, 2004 @06:05PM (#10302203) Homepage Journal

      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 [mindview.net]. 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.

    • I agree with the parent comment. Additionally, note that Maple [maplesoft.com] tends to have more reliable numerics than Mathematica [wolfram.com]. (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.

      • 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 calcul
    • Or go get Octave [octave.org] which is an open source Matlab like languange...
    • 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 real

  • Jython (Score:5, Interesting)

    by FullMetalAlchemist ( 811118 ) on Monday September 20, 2004 @04:07PM (#10300877)
    You might want to try Jython [jython.org] and the Numerical Python for Jython [sourceforge.net].
    I have not used either for a long time, but use plain Python [python.org] and Numerical Python a lot [pfdubois.com]; sure beats Matlab [mathworks.com] and Mathematica [wolfram.com] for most things. Right now for solving optimization problems with 10k+ s.t. constraints.
    • 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! (Score:2, Interesting)

    by cwensley ( 741704 )
    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
  • 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).
    • 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.

      • 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 sti

  • Pathetic (Score:3)

    by kaffiene ( 38781 ) on Monday September 20, 2004 @05:47PM (#10302006)
    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.
    • #define BEGIN {
      #define END }

      So there.

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

  • multiple options (Score:2, Informative)

    by BeerMilkshake ( 699747 )
    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) exc

  • Interfaces (Score:5, Interesting)

    by GlobalEcho ( 26240 ) on Monday September 20, 2004 @06:17PM (#10302328)
    [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.

  • Horses for courses (Score:4, Insightful)

    by barries ( 15577 ) on Monday September 20, 2004 @06:23PM (#10302375) Homepage
    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
    • 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.


  • 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 [dotgeek.org]

  • Use Fortran 95 (Score:2, Interesting)

    by beliavsky ( 814870 )
    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.

  • Try JNI (Score:3, Insightful)

    by miyako ( 632510 ) <miyako AT gmail DOT com> on Monday September 20, 2004 @06:52PM (#10302614) Homepage Journal
    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.
  • Take a look at J.A.D.E. Java Addition to Default Environment [dautelle.com].
    It seems to have some nice math and physics packages.

  • Use Nice! (Score:5, Interesting)

    by bonniot ( 633930 ) on Monday September 20, 2004 @08:04PM (#10303298) Homepage Journal
    You could use Nice [sf.net], 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.

  • 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'spher
  • 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 Jav

    • 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

      • 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

  • 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.
  • First, you might be interested in Jakarta Commons Math, which is about to release version 1.0 : http://jakarta.apache.org/commons/math/index.html [apache.org]

    Secondly, I'd probably consider isolating all the formulas and then put them aside somewhere (XML, database, ...) in a human-readable format.
    Then make a parser that can read that format (i.e. using the libraries you mentioned), substitute variables, and calculate a result. The advantages that I see:
    1) you centralize all numerical stuff
    2) in a readable format
    3) so
  • 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 recom
  • Here's something that's potentially useful.

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

Slashdot Top Deals

Genetics explains why you look like your father, and if you don't, why you should.

Close