the problem with Java is not in the calculation with complex, but with
the use of separate objects for every complex value.  An array of 1000
complex requires 1000 separate little objects like bubbles hanging off
it.

An efficient complex implementation treats complex like primitives, so
you can have arrays of complex without needing any objects.

That could be done by adding a complex primitive to Java, or by
something more far-reaching, allowing you to inline any small object.

Why not find that out first instead of thinking about premature
optimization?

If you want to do it in standard Java, then you are faced with what you
 just qualified as "the worst". So why do you go for Java at all, if
you think it doesn't work for you?

Count the number of floating point operations needed per complex number
arithmetic operation and you have a good indication. I don't think
anyone here is inclined to do the counting for you.

What do you want to hear? Some probability like "a 0.0003% chance"? What
would that help you? If you want to rely on such behavior you have to
study different VMs and settle on one VM which does it all the time - if
you manage to find one at all.

Which actually has been answered. But in more detail, It depends on the
format in which you store your numbers. The math is different if you
make the unusual decision to model your numbers in goniometric form
instead of arithmetic form. But in all cases, there are no huge
algorithms involved. Any math textbook will give you the formulas. Did
you even look up the formulas before asking about an algorithm?

/Thomas

The word "best" has no definition in that sentence.  Best for what?  For
some kinds of calculations, it's best to represent floating point
numbers in polar coordinates, for example; and for others, in cartesian
coordinates.  Obviously, the implementations will differ greatly
depending on the underlying representation.

Assuming cartesian coordinates (since they are fairly normal), complex
number arithmetic is just an algebraic problem.  You end up with:

(a + ib) * (c + id) = (ac - bd) + i(bc + ad)
(a + ib) / (c + id) = ((ac + bd) + i(bc - ad)) / (c^2 + d^2)

Even division involves only 11 floating point operations.  It's a bit
too straight-forward to use the word "algorithm" as you do above.

Incidentally, if the underlying processor has the capability to perform
these calculations in fewer instructions, then it is possible that the
JIT will recognize this during optimization and generate the more
efficient code.  It depends on the compiler, of course.

As for object instantiation, *if* this becomes a problem then you can
tweak the design... for example by adding operate-and-replace operations
that place the results of a calculation directly into one of the
operands and avoid any object instantiation.  However, keep in mind that
short-lived object instantiation in a garbage collected language is
cheap.  This may not be a concern.

and it has already been answered. Please read the materials given to
you.

This is the SIMD extension -- the Intel floating point co-processor
for vector operations.

I don't know if Java currently uses this at all.

the instructions added: Complex arithmetic (addsubps, addsubpd,
movsldup, movshdup, movddup)

are apparently useful in complex arithmetic even if they don't
implement mult/div directly.

what is happening when you try
http://mindprod.com/jgloss/complex.html
?

It seems to me that actual computation is obvious, posted at
http://mindprod.com/jgloss/complex.html

(a + ib) / (c + id) = ((ac + bd) + i(bc - ad)) / (c*c + d*d)

// or in practice:
double bottom = 1.d / (c*c + d*d);
double real = (ac + bd) * bottom;
double imaginary = (bc - ad) * bottom;

Sounds like premature optimization to me.

If you are optimizing because of that concern, I think you need to run
some tests, the object allocation stuff is very fast (many times faster
that in earlier versions).

-Paul

I would be tempted to go for an approach where the generated bytecodes
contained no Complex objects at all -- or rather, as few as possible.  So an
array of complex number would be implemented (as far as the JVM could tell from
the code it was executing) just as an array of floats or doubles.
Complex-values variables would be represented by two float/double variables at
the JVM level.  Similarly for parameters to methods/functions.  The big problem
is returning a complex value from a function; that can't be done in any
straightforward way, so you would have to use a temporary full object -- either
an instance of Complex or a double[2].  Using a real class, Complex, for these
purposes might make interoperation with "normal" Java code easier, in which
case your compiler would be considered to be just "very aggressive" about
autoboxing Complex data.

One important question to consider is /which/ calculations you are worried
about the performance of.  If the biggest issue is about the creation of many
temporary "objects" whilst doing complex arithmetic then the escape-analysis in
1.6 may help (so don't do anything complicated until you've tried 1.6 ;-)  OTOH
the issue may be the performance of big complex array calculations, where the
space overheads of representing each value as a full object may kill you, or
where the time overhead of a cache miss for accessing each object (via at least
one more level of indirection) may kill you.  In such cases representing the
complex values in-line (as above) would be a good option, but you might also
want to think about making complex array operations into a language primitive,
implemented (via JNI) in C/Fortran/Assembler.  There would be costs associated
with crossing the JNI barrier (which might involve copying the data), but it
might still be a useful design option.

There's no straightforward way to persuade the JIT to use Intel's SSE
extensions -- not least because the code might not be running on Intel, or even
Intel-compatible, hardware.

(BTW, on a side-note, if you had mentioned what you are trying to do in your
earlier post then I doubt if you would have received quite so many dismissive
or hostile responses.  People around here get conditioned to expect stupid
questions, but showing that you are embarking on a challenging and ambitious
project is likely to preempt that.)

   -- chris