[jira] [Updated] (MATH-667) Representations of the complex numbers

2017-04-22 Thread Gilles (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilles updated MATH-667:

   Labels: commons-numbers features  (was: features)
Fix Version/s: (was: 4.X)
   4.0

Issue must be moved to NUMBERS.

> Representations of the complex numbers
> --
>
> Key: MATH-667
> URL: https://issues.apache.org/jira/browse/MATH-667
> Project: Commons Math
>  Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
>  Labels: commons-numbers, features
> Fix For: 4.0
>
>
> Several issues have been raised about the current behaviour of the "Complex" 
> class, located in package "o.a.c.m.complex" (e.g. MATH-657, MATH-620).
> 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 
> point-at-infinity).
> A new "C99Complex" class would inherit from "BasicComplex". This class would 
> aim at implementing the C99x standard.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (MATH-667) Representations of the complex numbers

2017-04-18 Thread Rob Tompkins (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rob Tompkins updated MATH-667:
--
Fix Version/s: 4.X

> Representations of the complex numbers
> --
>
> Key: MATH-667
> URL: https://issues.apache.org/jira/browse/MATH-667
> Project: Commons Math
>  Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
>  Labels: features
> Fix For: 4.X
>
>
> Several issues have been raised about the current behaviour of the "Complex" 
> class, located in package "o.a.c.m.complex" (e.g. MATH-657, MATH-620).
> 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 
> point-at-infinity).
> A new "C99Complex" class would inherit from "BasicComplex". This class would 
> aim at implementing the C99x standard.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (MATH-667) Representations of the complex numbers

2012-07-23 Thread Gilles (JIRA)

 [ 
https://issues.apache.org/jira/browse/MATH-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gilles updated MATH-667:


Fix Version/s: (was: 3.1)

A realistic fix version will be set when this improvement elicits more 
interest...

 Representations of the complex numbers
 --

 Key: MATH-667
 URL: https://issues.apache.org/jira/browse/MATH-667
 Project: Commons Math
  Issue Type: Wish
Reporter: Gilles
Priority: Minor
  Labels: features

 Several issues have been raised about the current behaviour of the Complex 
 class, located in package o.a.c.m.complex (e.g. MATH-657, MATH-620).
 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 
 point-at-infinity).
 A new C99Complex class would inherit from BasicComplex. This class would 
 aim at implementing the C99x standard.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira