Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Numerical Computing in Java?

Cliff posted more than 9 years ago | from the calculating-coffee dept.

Java 196

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

cancel ×

196 comments

Sorry! There are no comments related to the filter you selected.

No Operator Overloading is a BAD THING (4, Insightful)

digerata (516939) | more than 9 years ago | (#10300658)

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 (1, Insightful)

Anonymous Coward | more than 9 years ago | (#10300988)

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 (1, Informative)

Anonymous Coward | more than 9 years ago | (#10301141)

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

Re: No, Operator Overloading is a BAD THING (2, Informative)

digerata (516939) | more than 9 years ago | (#10302217)

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.

Re: No, Operator Overloading is a BAD THING (2, Informative)

Anonymous Coward | more than 9 years ago | (#10303882)

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

Re: Bad coders are a BAD THING (1)

E_elven (600520) | more than 9 years ago | (#10305384)

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?

Re:No Operator Overloading is a BAD THING (1)

FedeTXF (456407) | more than 9 years ago | (#10301524)

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 (1)

fatmonkeyboy (257833) | more than 9 years ago | (#10301805)

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 (1)

digerata (516939) | more than 9 years ago | (#10301968)

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 (4, Funny)

cft_128 (650084) | more than 9 years ago | (#10303250)

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 (2, Insightful)

TheLink (130905) | more than 9 years ago | (#10304244)

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

That's a bad idea. (1)

Estanislao Martnez (203477) | more than 9 years ago | (#10306082)

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

Re:That's a bad idea. (1)

TheLink (130905) | more than 9 years ago | (#10306189)

Can you back up/explain your statement?

Re:No Operator Overloading is a BAD THING (0)

Anonymous Coward | more than 9 years ago | (#10306315)

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 (1)

jilles (20976) | more than 9 years ago | (#10301674)

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 (1)

digerata (516939) | more than 9 years ago | (#10302011)

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 (1)

stoborrobots (577882) | more than 9 years ago | (#10306135)

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 (1)

fm6 (162816) | more than 9 years ago | (#10302798)

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 (1)

TheLink (130905) | more than 9 years ago | (#10304267)

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.

Operator Overloading is evil, evil, evil (4, Insightful)

melquiades (314628) | more than 9 years ago | (#10302552)

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.

Okay, mom.... (1)

Tim (686) | more than 9 years ago | (#10305974)

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

CountBrass (590228) | more than 9 years ago | (#10306563)

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

toxis (323509) | more than 9 years ago | (#10302920)

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 (1)

gdchinacat (186298) | more than 9 years ago | (#10303218)

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

But what about creation of temporaries (1)

ufnoise (732845) | more than 9 years ago | (#10305041)

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

Fallen Andy (795676) | more than 9 years ago | (#10305436)

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 (1)

RedWizzard (192002) | more than 9 years ago | (#10306020)

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 (1)

stoborrobots (577882) | more than 9 years ago | (#10306151)

I'm sure you meant
You'll end up with s = "<><><>"
and
You'll get s = "<>>>",

Use the right tools for the right job... (4, Insightful)

Chilles (79797) | more than 9 years ago | (#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...

Re:Use the right tools for the right job... (0)

Anonymous Coward | more than 9 years ago | (#10301564)

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

Clover_Kicker (20761) | more than 9 years ago | (#10303974)

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

Operator overloading is only half the story (0)

Anonymous Coward | more than 9 years ago | (#10304125)

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 (1)

E_elven (600520) | more than 9 years ago | (#10305423)

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.

I hate overloading (3, Insightful)

Anonymous Coward | more than 9 years ago | (#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.

Re:I hate overloading (1)

FedeTXF (456407) | more than 9 years ago | (#10301231)

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: virtual inheritance (0)

Anonymous Coward | more than 9 years ago | (#10304375)

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.

Re: virtual inheritance (1)

E_elven (600520) | more than 9 years ago | (#10305431)

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

Re:I hate overloading (1, Funny)

Anonymous Coward | more than 9 years ago | (#10302195)

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 (1)

stoborrobots (577882) | more than 9 years ago | (#10306164)

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

Re:I hate overloading (1)

aminorex (141494) | more than 9 years ago | (#10303942)

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 (0)

Anonymous Coward | more than 9 years ago | (#10304785)

> Consider instead, Fortran 2003

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

Re:I hate overloading (1)

angel'o'sphere (80593) | more than 9 years ago | (#10305543)

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 (1)

godglike (643670) | more than 9 years ago | (#10306319)

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.

Java Hurt (3, Interesting)

Anonymous Coward | more than 9 years ago | (#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 (3, Interesting)

Too Much Noise (755847) | more than 9 years ago | (#10301112)

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 (1, Insightful)

Anonymous Coward | more than 9 years ago | (#10301756)

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 (1)

Fallen Andy (795676) | more than 9 years ago | (#10305481)

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.

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

Anonymous Coward | more than 9 years ago | (#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 (1)

Bob Zer Fish (568540) | more than 9 years ago | (#10301711)

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.

Matlab may be slower than C++... (1)

AuraSeer (409950) | more than 9 years ago | (#10302097)

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++... (0)

Anonymous Coward | more than 9 years ago | (#10302403)

"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:These are not the languages you are looking for (3, Interesting)

4of12 (97621) | more than 9 years ago | (#10302203)

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.

Re:These are not the languages you are looking for (1)

Sara Chan (138144) | more than 9 years ago | (#10304563)

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.

Re:These are not the languages you are looking for (1)

Camel Pilot (78781) | more than 9 years ago | (#10305963)

Or go get Octave [octave.org] which is an open source Matlab like languange...

Jython (5, Interesting)

FullMetalAlchemist (811118) | more than 9 years ago | (#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.

Re:Jython (2, Insightful)

anonymous cowherd (m (783253) | more than 9 years ago | (#10301824)

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! (2, Interesting)

cwensley (741704) | more than 9 years ago | (#10300901)

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! (1)

aminorex (141494) | more than 9 years ago | (#10303987)

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

In other words.. (-1, Flamebait)

GigsVT (208848) | more than 9 years ago | (#10301074)

for a variety of reasons, we've decided that Java is the future of the group

So, in other words, you bought into the hype. Have fun running your computations with an interpreted language running on an emulator.

Can you elaborate? (-1, Flamebait)

sfjoe (470510) | more than 9 years ago | (#10301279)

The problem is that we do a lot of numerical computing and Java has no operator overloading!

I'm not following how operator overloading solves your problem. For example, how is this:
a = a + b;
an improvement over:
a.add(b);

Re:Can you elaborate? (4, Insightful)

Anonymous Coward | more than 9 years ago | (#10301657)

how about
a = sqrt(abs((b + c) * (d / e)));
vs
a = Math.sqrt(Math.abs((b.add(c).multiply(d.divide(e)) ));

for the small cases (such as this one) it doesn't make as much difference, but for complex equations it adds up quickly.

Re:Can you elaborate? (1)

sfjoe (470510) | more than 9 years ago | (#10302018)



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.

Re:Can you elaborate? (1)

AuraSeer (409950) | more than 9 years ago | (#10302205)

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:Can you elaborate? (1)

sfjoe (470510) | more than 9 years ago | (#10302529)



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? (1, Informative)

Anonymous Coward | more than 9 years ago | (#10302540)

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.

MOD PARENT DOWN (0)

Anonymous Coward | more than 9 years ago | (#10304123)

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 (0)

Anonymous Coward | more than 9 years ago | (#10306085)

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.

Re:Can you elaborate? (1)

DrEasy (559739) | more than 9 years ago | (#10302578)

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.

java is the future (-1, Troll)

tickticktickfast (663451) | more than 9 years ago | (#10301357)

Java is the future, C/C++ is today. Live with it.

Re:java is the future (0)

Anonymous Coward | more than 9 years ago | (#10301910)

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 (1)

GuyverDH (232921) | more than 9 years ago | (#10301987)

Hmmmm..

And without C, where would Java be?

Nowhere!

Re:java is the future (1)

aled (228417) | more than 9 years ago | (#10302098)

And that proves what?

Re:java is the future (2, Insightful)

GuyverDH (232921) | more than 9 years ago | (#10302187)

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?

Try Java on .NET... (1)

jungd (223367) | more than 9 years ago | (#10301516)

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

ADRA (37398) | more than 9 years ago | (#10302204)

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.

Isn't floating point implementation broken in Java (0)

Anonymous Coward | more than 9 years ago | (#10301758)

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

Pathetic (2)

kaffiene (38781) | more than 9 years ago | (#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.

Re:Pathetic (1)

k4_pacific (736911) | more than 9 years ago | (#10302047)

#define BEGIN {
#define END }

So there.

Re:Pathetic (1)

kaffiene (38781) | more than 9 years ago | (#10302179)

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

Re:Pathetic (1)

augustw (785088) | more than 9 years ago | (#10302291)

Steve Bourne did this when he wrote the Bourne Shell [goof.com]

Re:Pathetic (1)

lkaos (187507) | more than 9 years ago | (#10305272)

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 (1)

stoborrobots (577882) | more than 9 years ago | (#10306221)

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

the people who designed it to run on toasters? [sun.com]

multiple options (2, Informative)

BeerMilkshake (699747) | more than 9 years ago | (#10302033)

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

The Only Real Langauage (-1, Troll)

Anonymous Coward | more than 9 years ago | (#10302130)

Is Assembler, Everything else is just glorified scripting.

Interfaces (4, Interesting)

GlobalEcho (26240) | more than 9 years ago | (#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 (3, Insightful)

barries (15577) | more than 9 years ago | (#10302375)

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 (1)

cerberusss (660701) | more than 9 years ago | (#10306117)

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.

here's a thought (1, Informative)

Anonymous Coward | more than 9 years ago | (#10302428)

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.

yup! (1)

DrEasy (559739) | more than 9 years ago | (#10302616)

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

My new hammer is so easy to use (1)

DrSkwid (118965) | more than 9 years ago | (#10302595)


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 (2, Interesting)

beliavsky (814870) | more than 9 years ago | (#10302609)

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 (2, Insightful)

miyako (632510) | more than 9 years ago | (#10302614)

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.

list (1, Interesting)

Anonymous Coward | more than 9 years ago | (#10302998)

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.

Use Nice! (4, Interesting)

bonniot (633930) | more than 9 years ago | (#10303298)

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.

MathML + library + code generator (1)

angel'o'sphere (80593) | more than 9 years ago | (#10305385)

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

No religion wars, please (2, Insightful)

insac (623145) | more than 9 years ago | (#10305981)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ehm... 2 corrections (1)

insac (623145) | more than 9 years ago | (#10306119)

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"

Here's a general idea (1)

Estanislao Martnez (203477) | more than 9 years ago | (#10306047)

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 [tu-berlin.de] 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.

Come to think of it (1)

Estanislao Martnez (203477) | more than 9 years ago | (#10306231)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>