commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MATH-667) Representations of the complex numbers
Date Mon, 26 Sep 2011 15:00:28 GMT

    [ 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

        

Mime
View raw message