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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Richard (Jira)
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
             Fix For: 3.1


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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

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

Richard (Jira)

    [ https://issues.apache.org/jira/browse/MATH-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114530#comment-13114530 ]

Arne Plöse commented on MATH-667:
---------------------------------

Sounds interesting,

but you will have to make sure that each functions in math will operate and return the same class (ExtendedComplex|C99Complex) ...

> 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: 3.1
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira


Reply | Threaded
Open this post in threaded view
|

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

Richard (Jira)
In reply to this post by Richard (Jira)

    [ https://issues.apache.org/jira/browse/MATH-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114610#comment-13114610 ]

Gilles commented on MATH-667:
-----------------------------

bq. Sounds interesting,

Actually, I thought that _you_ would be interested in implementing "BasicComplex" (along the lines described) as this would (supposedly) provide the same behaviour as Octave. And the the unit tests which you attached in MATH-620 would be the basis for ensuring this.

bq. but you will have to make sure that each functions [...] return the same class [...]

Currently, I see it as the returned instance will belong to the same class as "{{this}}".

> 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: 3.1
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

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

Richard (Jira)
In reply to this post by Richard (Jira)

    [ https://issues.apache.org/jira/browse/MATH-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114707#comment-13114707 ]

Phil Steitz commented on MATH-667:
----------------------------------

IIUC the examples and what is being proposed here, I suspect Octave is similar to C99X (preserve signed infinities, "recover" infinities from NaNs), not "BasicComplex." It would be instructive to compare Octave directly against the spec or to look at the source to see if they are just delegating to the gcc impls, which IIRC attempt to implement the spec.  "BasicComplex" could be implemented fairly easily by just removing code from what is now in trunk.  Patches welcome!

> 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: 3.1
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

       
Reply | Threaded
Open this post in threaded view
|

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

Richard (Jira)
In reply to this post by Richard (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