You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@steitz.com> on 2003/06/05 08:25:52 UTC
[math] Complex dilemmas
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 559-compatible 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/complex-proposal.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, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Complex dilemmas
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thursday, June 5, 2003, at 02:20 PM, Phil Steitz wrote:
<snip>
> Given that it will be a fair amount of work to get a numerically sound
> C9x compliant implementation together (what I have now does not implement
> the transcendental functions at all and does not comply fully with C9x),
> I propose that we drop this from our goals for initial release. If
> people really want direct support for complex numbers, we can bring them
> in to a subsequent release.
(i wrote a basic complex numbers library (just for kicks) a few years ago
and i also ran into design issues.) your plan seems like a good one. later,
we might create a sub-package for complex number and dump the stuff you
have into it (so that everyone can discuss it) but exclude it from
releases.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Complex dilemmas
Posted by Al Chou <ho...@yahoo.com>.
--- Phil Steitz <ph...@steitz.com> wrote:
> Al Chou wrote:
> > One question that comes to mind is: "What problems does having complex
> > mathematics solve?" Basically I am wondering whether we should consider
> how or
> > even if real-world users would employ these facilities before going through
> the
> > exercise of getting them right.
>
> This is a very good question and one that we should *always* ask. I
> have to confess that I have used "my" implementation only for
> mathematical applications. I know that there are direct engineering
> applications, but I frankly do not know how common they are in the "real
> world".
>
> It is also troubling that the VNI implementation started out as the
> reference implementation for a JSR that never went anywhere and it is
> clear from this:
> http://java.sun.com/people/darcy/complex-proposal.html#general
> which dates back to dec 2000, that Sun has looked carefully at providing
> direct support in the language, but concluded that it is not worth the
> effort.
>
> Given that it will be a fair amount of work to get a numerically sound
> C9x compliant implementation together (what I have now does not
> implement the transcendental functions at all and does not comply fully
> with C9x), I propose that we drop this from our goals for initial
> release. If people really want direct support for complex numbers, we
> can bring them in to a subsequent release.
I think removing complex mathematics from the scope of the initial release is
the right thing to do. Including it will delay the release, and unless we find
we have mathematical/scientific/engineering users out there who really need it,
I don't think most of our audience would even notice if we included it.
Al
=====
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Complex dilemmas
Posted by Phil Steitz <ph...@steitz.com>.
Al Chou wrote:
> --- Phil Steitz <ph...@steitz.com> wrote:
>
>>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 559-compatible 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/complex-proposal.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.
>
>
> And no wonder, Colt includes VNI according to
> http://hoschek.home.cern.ch/hoschek/colt/ .
>
>
>
>>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.
>
>
> From what you've described so far, it sounds pretty good. Is there a way you
> can provide more specifics, such as via a Web page?
Well, I suppose that I could submit the code....Will do if we get past
the next issue.
>
> One question that comes to mind is: "What problems does having complex
> mathematics solve?" Basically I am wondering whether we should consider how or
> even if real-world users would employ these facilities before going through the
> exercise of getting them right.
This is a very good question and one that we should *always* ask. I
have to confess that I have used "my" implementation only for
mathematical applications. I know that there are direct engineering
applications, but I frankly do not know how common they are in the "real
world".
It is also troubling that the VNI implementation started out as the
reference implementation for a JSR that never went anywhere and it is
clear from this:
http://java.sun.com/people/darcy/complex-proposal.html#general
which dates back to dec 2000, that Sun has looked carefully at providing
direct support in the language, but concluded that it is not worth the
effort.
Given that it will be a fair amount of work to get a numerically sound
C9x compliant implementation together (what I have now does not
implement the transcendental functions at all and does not comply fully
with C9x), I propose that we drop this from our goals for initial
release. If people really want direct support for complex numbers, we
can bring them in to a subsequent release.
>
> A side question: even if Java permitted operator overloading, I have read
> comments to the effect that the technique is not to be preferred. Never having
> done much with it in a language that permits it, I don't have the experience to
> know why. As someone who thinks mathematically (at least at times), operator
> overloading seems like the most natural thing to do to preserve the semantics
> I'm accustomed to among number systems that contain one another (a seemingly
> very natural inheritance hierarchy). Can anyone out there explain why operator
> overloading might be considered bad?
>
>
>
> Al
>
> =====
> Albert Davidson Chou
>
> Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
> http://calendar.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Complex dilemmas
Posted by Al Chou <ho...@yahoo.com>.
--- Phil Steitz <ph...@steitz.com> wrote:
> 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 559-compatible 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/complex-proposal.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.
And no wonder, Colt includes VNI according to
http://hoschek.home.cern.ch/hoschek/colt/ .
> 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.
>From what you've described so far, it sounds pretty good. Is there a way you
can provide more specifics, such as via a Web page?
One question that comes to mind is: "What problems does having complex
mathematics solve?" Basically I am wondering whether we should consider how or
even if real-world users would employ these facilities before going through the
exercise of getting them right.
A side question: even if Java permitted operator overloading, I have read
comments to the effect that the technique is not to be preferred. Never having
done much with it in a language that permits it, I don't have the experience to
know why. As someone who thinks mathematically (at least at times), operator
overloading seems like the most natural thing to do to preserve the semantics
I'm accustomed to among number systems that contain one another (a seemingly
very natural inheritance hierarchy). Can anyone out there explain why operator
overloading might be considered bad?
Al
=====
Albert Davidson Chou
Get answers to Mac questions at http://www.Mac-Mgrs.org/ .
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org