Details

Type: Wish

Status: Resolved

Priority: Minor

Resolution: Won't Do

Affects Version/s: None

Fix Version/s: 4.0

Labels:
Description
Several issues have been raised about the current behaviour of the "Complex" class, located in package "o.a.c.m.complex" (e.g. MATH657, MATH620).
The ensuing discussion revealed various, sometimes incompatible, requirements with focus on efficiency or consistency or backwards compatibility or comparison with other math packages (Octave) or faithfulness to standards (C99x).
It is thus proposed to create several classes, each with a clearly defined purpose.
The consensus seems to be that the first task is to implement a new "BasicComplex" class where the computational formulae (for computing real and imaginary part of a complex) will be applied directly without worrying about limiting cases (NaNs and infinities). Doing so will automatically produce a behaviour similar to the Java double primitive. It is also assumed that it will be the most efficient implementation for "normal" use (i.e. not involving limiting cases).
This task would consist in copying most of the code in the existing "Complex" class over to "BasicComplex". And similarly with "ComplexTest". Then, in "BasicComplex", one would remove all variables that refer to NaNs and infinities together with checks and special assignments, and adapt the unit tests along the way.
A new "ExtendedComplex" class would inherit from "BasicComplex". This class would aim at representing the compactified space of the complex numbers (one pointatinfinity).
A new "C99Complex" class would inherit from "BasicComplex". This class would aim at implementing the C99x standard.
Issue Links
 incorporates

MATH788 Complex bug with NaN: the operation new Complex(0.0).multiply(new Complex(Double.POSITIVE_INFINITY)) gives (Infinity, Infinity) instead of NaN
 Closed
 is superceded by

NUMBERS31 MATH667 (complex numbers)
 Open
Activity
 All
 Comments
 Work Log
 History
 Activity
 Transitions
Issue moved to "Commons Numbers": see NUMBERS31.