«

The shootout shows Java -server as being head-to-head with C, C++ and
Fortran on the numerical tests (spectral norm, planets, etc.) as far
as the running time is concerned.

Let me first say that Java has some undeniable advantages for use in
number crunching:

It has thread semantics in the language definition.
It is memory-safe (very important for debugging and general
correctness) [1]
You can programmatically generate, compile and load Java code at
runtime (specializing the code at runtime may give a huge edge in some
applications)

However, Java also has a very mundane, but serious flaw as far as
numerical computing is concerned: no typedefs. In C++, I like to
define my floating point type as double or float and only use that
alias. Now, when I need to switch the precision in all of the program,
I only change one line.

Another issue is having to duplicate certain functions. Let's say you
are writing a linear equation solver procedure. You might need four
versions of essentially identical code for float, double,
complex<float>, complex<double>, whereas in C++, you could just have
one template.

I'm wondering if people who use Java for number crunching have
opinions on the above.

[1] Memory safety is guaranteed even for buggy multithreaded code with
race conditions, as far as I know.

wrote:
> However, Java also has a very mundane, but serious flaw as far as
> numerical computing is concerned: no typedefs. In C++, I like to
> define my floating point type as double or float and only use that
> alias. Now, when I need to switch the precision in all of the program,
> I only change one line.

The first thing I would have mentioned is Java doesn't have operator
overloading, resulting in some very unnatural looking algorithms. But I
guess you have a good point. Treating precision as a strategy, and
plugging in a new strategy as desired, as obvious benefits.

>
> Another issue is having to duplicate certain functions. Let's say you
> are writing a linear equation solver procedure. You might need four
> versions of essentially identical code for float, double,
> complex<float>, complex<double>, whereas in C++, you could just have
> one template.

I wonder if something could be added to Java to handle situations like
these. Not a precompiler or C++ style templates, but say a separate
language (like Simula) that handles specialized tasks. The result
should be byte codes and classes linkable to a Java program, although
perhaps not strictly Java internally. A really fancy specialized
handler could handle equations in more than just ascii text. Proper
sigma for summation, anyone?

Actually I'd be surprised if someone hasn't tried to make something like
this already.

Mark Space wrote:

> wrote:
>> However, Java also has a very mundane, but serious flaw as far as
>> numerical computing is concerned: no typedefs. In C++, I like to
>> define my floating point type as double or float and only use that
>> alias. Now, when I need to switch the precision in all of the program,
>> I only change one line.
>
> The first thing I would have mentioned is Java doesn't have operator
> overloading, resulting in some very unnatural looking algorithms. But I
> guess you have a good point. Treating precision as a strategy, and
> plugging in a new strategy as desired, as obvious benefits.
>
>>
>> Another issue is having to duplicate certain functions. Let's say you
>> are writing a linear equation solver procedure. You might need four
>> versions of essentially identical code for float, double,
>> complex<float>, complex<double>, whereas in C++, you could just have
>> one template.
>
> I wonder if something could be added to Java to handle situations like
> these. Not a precompiler or C++ style templates, but say a separate
> language (like Simula) that handles specialized tasks. The result
> should be byte codes and classes linkable to a Java program, although
> perhaps not strictly Java internally. A really fancy specialized
> handler could handle equations in more than just ascii text. Proper
> sigma for summation, anyone?
>
> Actually I'd be surprised if someone hasn't tried to make something like
> this already.

Java already has Templates now. Check it out, they are on version 1.6, and
I think Templates came in around 1.5 if IRCorrectly

none wrote:
> Mark Space wrote:
>
>> wrote:
>>> However, Java also has a very mundane, but serious flaw as far as
>>> numerical computing is concerned: no typedefs. In C++, I like to
>>> define my floating point type as double or float and only use that
>>> alias. Now, when I need to switch the precision in all of the program,
>>> I only change one line.
>> The first thing I would have mentioned is Java doesn't have operator
>> overloading, resulting in some very unnatural looking algorithms. But I
>> guess you have a good point. Treating precision as a strategy, and
>> plugging in a new strategy as desired, as obvious benefits.
>>
>>> Another issue is having to duplicate certain functions. Let's say you
>>> are writing a linear equation solver procedure. You might need four
>>> versions of essentially identical code for float, double,
>>> complex<float>, complex<double>, whereas in C++, you could just have
>>> one template.
>> I wonder if something could be added to Java to handle situations like
>> these. Not a precompiler or C++ style templates, but say a separate
>> language (like Simula) that handles specialized tasks. The result
>> should be byte codes and classes linkable to a Java program, although
>> perhaps not strictly Java internally. A really fancy specialized
>> handler could handle equations in more than just ascii text. Proper
>> sigma for summation, anyone?
>>
>> Actually I'd be surprised if someone hasn't tried to make something like
>> this already.
>
> Java already has Templates now. Check it out, they are on version 1.6, and
> I think Templates came in around 1.5 if IRCorrectly

You can't use primitive type parameters with Java's generics. It may be
possible to extend Java's generics to allow this, but the interest in
language extensions seems to be elsewhere (closures, properties, etc).

Mark Thornton

none wrote:
> Java already has Templates now. Check it out, they are on version 1.6, and
> I think Templates came in around 1.5 if IRCorrectly

Not quite true.

Java generics was introduced with Java 1.5.

They share some syntax with C++ templates.

But the more you work with them the more you realize that
they are fundamentally different.

Arne

wrote:
> The shootout shows Java -server as being head-to-head with C, C++ and
> Fortran on the numerical tests (spectral norm, planets, etc.) as far
> as the running time is concerned.

Results differ for different tests.

But with -server you should expect something within normal
compiler difference magnitude.

> Let me first say that Java has some undeniable advantages for use in
> number crunching:
>
> It has thread semantics in the language definition.

Java builtin thread support is a plus.

> It is memory-safe (very important for debugging and general
> correctness) [1]

Many really computing intensive calculations will prefer to
verify that the code is correct and then run without the
check.

It can cost some hours to track down the memory overwrite though.

> You can programmatically generate, compile and load Java code at
> runtime (specializing the code at runtime may give a huge edge in some
> applications)

Possible.

> However, Java also has a very mundane, but serious flaw as far as
> numerical computing is concerned: no typedefs. In C++, I like to
> define my floating point type as double or float and only use that
> alias. Now, when I need to switch the precision in all of the program,
> I only change one line.
>
> Another issue is having to duplicate certain functions. Let's say you
> are writing a linear equation solver procedure. You might need four
> versions of essentially identical code for float, double,
> complex<float>, complex<double>, whereas in C++, you could just have
> one template.

Java is driven by business computing not scientific computing.

Those are limitations.

And I do not see them resolved in the foreseeable future.

It is not unusual that a language has both pro's and con's.

Arne

On Sun, 4 May 2008 23:23:16 -0700 (PDT), ""
<> wrote, quoted or indirectly quoted someone who
said :

> In C++, I like to
>define my floating point type as double or float and only use that
>alias.

Probably a search/replace script to generate the two variants would be
the way to handle it. Each version generates quite different byte
codes. You need two totally different classes you then plug into an
interface.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

none wrote:
> Mark Space wrote:
>
>> wrote:
>>> However, Java also has a very mundane, but serious flaw as far as
>>> numerical computing is concerned: no typedefs. In C++, I like to
>>> define my floating point type as double or float and only use that
>>> alias. Now, when I need to switch the precision in all of the program,
>>> I only change one line.
>> The first thing I would have mentioned is Java doesn't have operator
>> overloading, resulting in some very unnatural looking algorithms. But I
>> guess you have a good point. Treating precision as a strategy, and
>> plugging in a new strategy as desired, as obvious benefits.
>>
>>> Another issue is having to duplicate certain functions. Let's say you
>>> are writing a linear equation solver procedure. You might need four
>>> versions of essentially identical code for float, double,
>>> complex<float>, complex<double>, whereas in C++, you could just have
>>> one template.
>> I wonder if something could be added to Java to handle situations like
>> these. Not a precompiler or C++ style templates, but say a separate
>> language (like Simula) that handles specialized tasks. The result
>> should be byte codes and classes linkable to a Java program, although
>> perhaps not strictly Java internally. A really fancy specialized
>> handler could handle equations in more than just ascii text. Proper
>> sigma for summation, anyone?
>>
>> Actually I'd be surprised if someone hasn't tried to make something like
>> this already.
>
> Java already has Templates now. Check it out, they are on version 1.6, and
> I think Templates came in around 1.5 if IRCorrectly


While I can understand why Sun implemented templates as they did, to me
the problem w/ Java templates is that the type parameters can't be
primitives. I don't like boxing and unboxing primitives as there is a
space and speed penality (or is there? some optimization?)

I mostly use templates for reducing cast clutter and enforcing type
safety to reduce/eliminate cast exceptions. I wan't holding my breath
for performance boost due to some optimizations that leverage templates.


Monty

On May 6, 12:10*am, Roedy Green <see_webs...@mindprod.com.invalid>
wrote:
> On Sun, 4 May 2008 23:23:16 -0700 (PDT), "jhc0...@gmail.com"
> <jhc0...@gmail.com> wrote, quoted or indirectly quoted someone who
> said :
>
> > In C++, I like to
> >define my floating point type as double or float and only use that
> >alias.
>
> Probably a search/replace script to generate the two variants would be
> the way to handle it. *Each version generates quite different byte
> codes. *You need two totally different classes you then plug into an
> interface.

Also, there is nothing preventing one from running the C pre-processor
on a Java source file....

Lew wrote:
> Monty Hall wrote:
>> While I can understand why Sun implemented templates as they did, to
>> me the problem w/ Java templates is that
>
> Java does not have templates.
>

Sorry, I meant generics.

>> primitives. I don't like boxing and unboxing primitives as there is a
>> space and speed penality (or is there? some optimization?)
>
> Study the matter, then make the claim. There is generally little to no
> "penalty" for boxing and unboxing.
>

WOW! Now that's a claim! Please let Sun, IBM, NIST, the academy, or
any authors of java numerical software know of your insight. I know a
fair number of people who would love a generic java numerics library.
Little or no penalty casting to/fro primitive numerical types? What
libraries are you using? Is it open source and where can I get it!


>> I mostly use templates
>
> but not in Java.
>

The following is from Sun. I would think there would be many
"performance critical inner loops" in numerical code. Study the matter,
then make the claim.

You can have the last word - I suspect you will.

Monty


///////////////////////////////////
// List adapter for primitive int array
public static List<Integer> asList(final int[] a) {
return new AbstractList<Integer>() {
public Integer get(int i) { return a[i]; }
// Throws NullPointerException if val == null
public Integer set(int i, Integer val) {
Integer oldVal = a[i];
a[i] = val;
return oldVal;
}
public int size() { return a.length; }
};
}

The performance of the resulting list is likely to be poor, as it boxes
or unboxes on every get or set operation. It is plenty fast enough for
occasional use, but it would be folly to use it in a performance
critical inner loop.