Skip to main content

byse type support for complex (planar) number arithmethics

1 reply [Last post]
Joined: 2007-12-15


this is a pretty old topic for the Java community, but still one that has not been addressed since the end of the 90's: support for complex numbers as base data types.

The issue is that modelling complex numbers as classes implies that complex number instances become references. While this is not an issue with most other kinds of objects, it is one for computing intense algorithms like fourier transformations, which in turn has so far inhibited Java's use in areas such as physics or audio/video processing.

As far as I understand, the major obstacle of including complex data types into the JVM so far has been guaranteing result precision for complex functions (as modelled in java.lang.Math). Another (minor) one is that the comparison operators (<, >, ...) are difficult to define properly for complex numbers.

However, I think the Java Community could already gain tremendously in the above areas by introducing only a primitive complex number datatype along with the basic numeric operators (+, -, *, /), implicit type conversion, a simple wrapper type and type boxing/unboxing. Optionally, some base functions like abs() and arg() would be nice, but as with all other complex functions they can be provided by project code rather than Java SE.

For example, such a datatype would allow a single System.arraycopy() operation to copy a complete array of complex numbers in one go, much faster than possible today. Also, algorithms dealing with complex numbers would face no more issues with tons of temporarily created object instances.

The reason I'm posting this here is that I'm unsure on whom to address with this issue. So if you have some thoughts about the general concept or the right person to approach with this ... raise your voice. :)

Sascha Baumeister
Software Architect
Former JCP Spec Lead JSR086

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-10

I think the obstacle to complex isn't technical but social. Treating it as a primitive is intellectually unsatisfying as it is so obviously a composite type. Yet to give adequate performance it need to be treated as an immutable class with value semantics (== compares value not object identity). The issue then isn't technical, but the question of introducing another category of object. Finally there is the vexed issue of operator overloading. While most people would accept that it is justified for complex, it is also difficult to hold the line so there is a tendency to say no more operator overloading at all. There are a couple of other classes with a good claim to overload basic operators (BigInteger, BigDecimal).

If we could get agreement on how to incorporate complex in Java, then the issue of precision would be readily solved.