I had planned to submit "my" Complex classes as part of the iniital
submission and I have been tearing this stuff apart and putting it back
together again for the past several weeks,adding layers of abstraction
and then tearing them away, never quite ending in a satisfied state.
So.. I am asking for a little help.
Here are the decisions that I would like to confirm/discuss:
1. Complex is a concrete, immutable class. The only methods belonging
to Complex itself are things that it makes sense to apply to a single
Complex number  e.g., arg, modulus, re, im, etc.
2. Imaginary is a concrete, immutable class. It's raison d'etre is to
support more efficient, more accurate and in some cases more natural
computations when dealing with complex numbers with no real parts.
3. ComplexUtils is a collection of static methods supporting
mathematical operations involving Complex, Imaginary and Double operands
 e.g., plus(Complex,Complex), plus(Complex,Imaginary),
plus(Complex,double), etc.
4. All use C9x Annex G:IEC 559compatible complex arithmetic for
arithmetic operations / infinity/NaN semantics/branch cuts/topolog, as
defined here
http://std.dkuug.dk/JTC1/SC22/open/n2620/n2620.txt
5. ExpandableComplexArray is an array class with "in place" operations
supported by ComplexUtils  things like
times: (ExpandableComplexArray,int,Complex) > Complex or
times: (ExpandableComplexArray,Complex) > ExpandableComplexArray
To put this in perspective vis a vis the other stuff out there, here are
some comparisons/observiations:
The existing library that I like the most is Visual Numerics
http://www.vni.com/corner/garage/grande/jsr/api/Complex.html
This one class combines Complex, ComplexUtils and Imaginary above. It
also implements the C9x Annex G value semantics. The mathematical scope
of the methods defined there is roughly equivalent to what I have in
mind (really just what is in the C spec), though I would drop a few
things, pull the operations out into ComplexUtils, add proj to support
spherical semantics (as defined here:
http://java.sun.com/people/darcy/complexproposal.html#general) and add
the Imaginary and ExpandableComplexArray classes.
Colt
http://hoschek.home.cern.ch/hoschek/colt/V1.0.3/doc/com/imsl/math/Complex.html
is very similar to VNI. Most importantly, it advertises the same C9x
Annex G value semantics.
So...from a functionality and computational semantics standpoint, it
seems clear that implementing the basic C9x function set with signed
zero and the Annex G semantics is the right thing to do. This will keep
us interoperable with and allow easy migration from VNI or Colt.
What I need help confirming is the organization of the classes above.
Please remember that these things will be used in computationally
intense scenarios embedded in complex code. We need the syntax to be as
simple as possible and the level of indirection to be minimal.
Phil

To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
