Simplicity is a wonderful thing. When problems become increasingly complex, sometimes a simple action, like going for a run or turning off the radio, can often simplify the solution.
Java generally makes programming tasks simple; there is "no need to worry" about memory allocation and garbage collection, and it "just works" on basically any platform. However, unlike its (arguably) simpler counterpart C, Java does not support complex numbers in the standard runtime. There are some independent efforts to create a generic Complex<T> class, which would be necessary for completeness in Java's Object framework, but the primitive complex numeric types are noticeably absent. As far as I'm aware, it's also impossible to define a new native type in Java without modifying the JRE / JDK directly. Why Java didn't add complex numeric types from the beginning is a mystery to me. It might have something to do with Windows compatibility, but I can't say that for certain.
Who uses complex numbers in software anyway?
Although it's clearly simple in any language to define a set of functions (methods) and structures (classes) for dealing with complex numbers, if the API is defined at the language level, then all users of that language can share the advantage of a common, complete, and compatible library for their code. Complex numbers are used heavily by engineers and mathematicians. Generally any mathematical tool (such as Matlab, Mathematica, or GNU Octave) requires complex number support for completion. Complex number support is also heavily used by more specific electrical, RF, signal, and mechanical engineering software - essentially anything that deals with a time-variant oscillatory system. Mobile phones do complex math in the baseband processor, so one could say that we ALL benefit from standardized complex number support.
Personally, I have been hacking with the USRP2 (Universal Software Radio Peripheral) from Ettus Research, Inc, and have been using a custom Java / JNI library to interface with it. Since the data that the USRP2 receives and transmits is in the baseband domain, it is generally always complex. The C / JNI portion of my code can handle complex numbers natively, but when I use my Java interface, my options were limited. I either needed to access the data real and imaginary data independently as float or short variables and arrays, or I needed to write a simple Java class for complex numbers.
Why does native complex number support in Java matter?
Consider the overhead of using a single java.lang.Integer object. First of all, every Integer class must inherit from java.lang.Number, but also from java.lang.Object. Static (class) methods and non-static (instance) generally do not introduce much overhead, since they only exist (maximally) once per Class and share everything but their instance information with other instances. However, for each Integer instance, there exists a non-trivial number of fields, including but not limited to i) a hash code, ii) a reference to the Class, iii) synchronization primitives for wait(), notify(), etc, iv) various flags indicating things like finalization, constant status, etc. There are probably also some additional instance fields inherited from Number.
Now, consider the simplest of Integer collections: an Integer[] (array of Integer objects). Aside from the (generally) 4-byte value of the Integer itself, there are undoubtedly at least an order of magnitude more bytes just for instance information of the Integer object (hash, references, synchronization primitives, flags, etc). Lets assume that there are 28-bytes of additional instance information. For an array of 512 Integer objects, the approximate storage requirement is (28 + 4) * 512 = 16384 bytes, which dramatically exceeds the (approximate) 2048 bytes that a simple int[512] would require.
In order to support a complex Integer type, for the same array length, there would be approximately 32768 bytes versus the 4096 bytes that would be required in C. In actual JRE implementations, there may be some optimizations for arrays of Numeric objects, but when all is said and done, each element in such an array must still be a fully qualified Object upon access.
In C (GNU C at least), any numeric data type can be augmented with the complex keyword, and I think that Java would benefit greatly from introducing the complex keyword into the language specification as well. Naturally, there would need to be special consideration made for various things such as division, casting, etc, but overall it should not be very difficult.
Posix and GNU C take a very simple and elegant approach to complex numbers. They define a special variable, I (and _Complex_I), as well as a set of standard math.h extensions. However, Posix C only defines functions for dealing with double and float complex numbers (much like the majority of functions in math.h). In GNU C, one can additionally use any numeric type with complex numbers. The storage space doubles for a numeric type that is declared complex, with the real and then the complex portion being allocated contiguously. So if I define a complex int x, then & ( __real__ x ) == & x, and & ( __imag__ x ) == & x + 4, while sizeof( x ) == 8. The C language takes this allocation into account with arrays and pointer indexing as well, so & x[5] == & x[4] + 8, and so on.
Although I really have no time to work on this personally, at some point if I do have time, I would probably modify JamVM and the GNU Classpath to implement natively supported complex numbers. With a simple open-source implementation as a reference, putting together a JSR for official adoption would probably widely accepted and welcomed by the majority of the Java community.
If anyone is aware of an existing JSR for the complex keyword and associated modifications, classes, etc. Please let me know. Otherwise, if anyone is interested in collaborating on this, please leave a comment below.
Likewise, I'm fairly certain that C# does not support native complex numbers, although Python might. So, if anyone would like to hack Mono and get native complex types built-in, please leave a comment below.
No comments:
Post a Comment