Add complex numbers. If possible as primitives, if not possible at least as a subclass of Number.
Since Tiger improved the math libs (new methods from fdlibm, much enhanced BigDecimal) I think this is the next logical step. I mean, even lowlife languages like C offer complex maths :-)
An ideal implementation would use native (primitive) types, complete with operator support. But this would postpone your RFE for a much later release, because in an ideal world we'd have lightweight/valuetype objects, and maybe operator overloading, to implement this and also other numeric types. One could think that complex types are important enough that Sun could make an exception and extend the basic typesystem and language syntax to accomodate only this RFE without depending on the much bigger RFEs or valuetypes and operator overloading. But the problem here is that the primitive types are not very extensible; for example, I don't think there are many unused bytecodes that could be assigned to operations with complex numbers. Not to mention "mixed" operations: with complex c, double d; c*d can be compiled into c*((complex)d) which only requires a CMUL bytecode, but a specialized "multiply complex by double" operation would be more efficientm although of course good JIT compilers could detect bytecode patterns from the first alternative and discard those conversions... well.
Even a conventional implementations, with a Complex class that requires heap allocation (even worse, performance-wise, if it's immutable, and I'd expect this because all other Number objects are), could deliver much better performance that what's possible today under third-party/hand-made libs because the core Math libraries and the JIT compiler could have optimizations to understand complex maths. The immutable design could even help, because it would make easier for the JIT to discard heap allocations at least for non-escaping local variables, so you end up with inefficient heap-allocated numbers only for arguments, returns, or values assigned to arrays or fields, but not in your performance-critical calculation kernels.
It depends on what you want to do with them whether you want primitive or object types. I you want to do huge amounts of data processing (focus on speed), you would need the primitive type. When you want to do high precision evaluation, you'd need a BigComplex type.
What do you need?
Personally I need neither speed nor high precision. I'd like to use Java instead of having to resort to Scheme (yuk!) to calculate the limits of complex number sequences. Maybe speed is somewhat more important, because one would typically let the program calculate the value for n=1000 or 10000.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.