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.

jhc0033 at (no spam) gmail.com 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.

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

On Sun, 4 May 2008 23:23:16 -0700 (PDT), "jhc0... at (no spam) gmail.com"
jhc0... at (no spam) 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.

I was thinking about this thread a bit and what kind of improvements
could be made to Java to handle math better and one that hadn't been
mentioned yet, that I would very much like to see in Java, is the ability
to handle objects without references.

That is, I would like to be able to include objects as members
themselves, without a reference to them. I would like to be able to call
methods and pass objects into these methods, not references to these
objects.

Basically, I would like a way to reduce the number of levels of
indirection for tight loops. I believe C# already provides this, and of
course, C always has.

So, basically, Java already gives you what you would like, a way to
reduce the number of levels of indirection for tight loops. It's called
Hotspot.

I was thinking about this thread a bit and what kind of improvements
could be made to Java to handle math better and one that hadn't been
mentioned yet, that I would very much like to see in Java, is the
ability to handle objects without references.

Kenneth P. Turvey wrote:
I was thinking about this thread a bit and what kind of improvements
could be made to Java to handle math better and one that hadn't been
mentioned yet, that I would very much like to see in Java, is the
ability to handle objects without references.

That is, I would like to be able to include objects as members
themselves, without a reference to them. I would like to be able to
call methods and pass objects into these methods, not references to
these objects.
Basically, I would like a way to reduce the number of levels of
indirection for tight loops. I believe C# already provides this, and
of course, C always has.

And Hotspot. This type of thing is better done in HS than in source.
If Hotspot can't do it yet, then have the PTB improve that, rather than
clutter up the language with low-level details. Repeated use of the
same object in a method is easily optimized to the low-level equivalent
of with ( instance ) do { ... }.

Java was not intended as an assembler language. The distinction between
stack and heap is not intrinsic to OO modeling, nor inherent in Java's
object-allocation strategy even today.

Unfortunately the use of == for object identity makes it difficult to
invisibly convert real objects to 'values'. Objects which don't escape
can be held on the stack, but it is harder to merge objects into others.
The fact that reflection can see private fields means that it isn't
possible to just analyse the visible java code and verify that the field
is never exposed.

As far as I can see, with the current language specification, HotSpot
can't safely do this type of optimisation.

On Thu, 22 May 2008, Kenneth P. Turvey wrote:

I was thinking about this thread a bit and what kind of improvements
could be made to Java to handle math better and one that hadn't been
mentioned yet, that I would very much like to see in Java, is the
ability to handle objects without references.

As Lew said, this is something you should leave to the compiler; it's
something it can often do if a class is final, and only has final
fields. Introducing explicit pass-objects-by-value, as in C, leads to a
huge mess of extra complexity.

However, there are some fairly unobstrusive changes that could be made
to the language that would make it much easier for the compiler to do
its magic. The key stumbling block is, i believe, object identity: if a
compiler can't prove that an object will never be subjected to an
identity test (==) which might succeed, it can't inline/unbox it. I

Which compiler, javac or Hotspot?

Hotspot most certainly can determine whether an object is subject to an
== comparison. It doesn't need to determine that it never is subject to
it, only that it's not subject to it for a while.

Mark Thornton wrote:
Unfortunately the use of == for object identity makes it difficult to
invisibly convert real objects to 'values'. Objects which don't escape
can be held on the stack, but it is harder to merge objects into
others. The fact that reflection can see private fields means that
it isn't possible to just analyse the visible java code and verify
that the field is never exposed.

As far as I can see, with the current language specification, HotSpot
can't safely do this type of optimisation.

Hotspot wouldn't optimize portions of the code that contained idioms
that forced a heap allocation, but in blocks that don't do the sorts of
things you mention is most certainly could.

Remember that Hotspot is dynamic, and will de-optimize code at need as
runtime conditions vary. So an object reference might be optimized to
register values in one method but not in another, even though it be the
same object.

If Java were limited to static analysis your objections would carry more
weight.

Lew wrote:
Mark Thornton wrote:
Unfortunately the use of == for object identity makes it difficult to
invisibly convert real objects to 'values'. Objects which don't
escape can be held on the stack, but it is harder to merge objects
into others. The fact that reflection can see private fields means
that it isn't possible to just analyse the visible java code and
verify that the field is never exposed.

As far as I can see, with the current language specification, HotSpot
can't safely do this type of optimisation.

Hotspot wouldn't optimize portions of the code that contained idioms
that forced a heap allocation, but in blocks that don't do the sorts
of things you mention is most certainly could.

Remember that Hotspot is dynamic, and will de-optimize code at need as
runtime conditions vary. So an object reference might be optimized to
register values in one method but not in another, even though it be
the same object.

If Java were limited to static analysis your objections would carry
more weight.


Dynamic code optimisation is one thing, but this would require dynamic
object layout changes. That is most unlikely in the foreseeable future.
It just isn't practical to back out merging an object into a parent
object. It is possible to do this for the stack because the allocation
has a well defined lifetime and you have located all references.

Mark Thornton