commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [Math] About MATH-667 (Complex numbers)
Date Tue, 03 May 2016 11:02:35 GMT

On Mon, 2 May 2016 20:51:32 +0200, Eric Barnhill wrote:
> Reading over the discussion, there were some contrasting views about
> which of the common complex number behaviors Complex() ought to
> emulate. One commentator suggested GNU Octave. My quick take is that
> Octave has some good momentum right now, with its new editor and it's
> GSOC presence, and that synchronizing Complex() with GNU octave would
> be a good path to take. This would also be a good way for me to get
> started writing some methods that create a smooth bridge between
> octave and commons. Ideally the octave standard is identical with the
> C99x standard, but I don't know yet.
> If the group is happy with this,

I wonder who is the "group" in the last 4 months.
This and other issues would definitely benefit from a larger spectrum
of opinions in order not to leave out potential use-cases.


> I will also go mention it on
> octave-maintainers and see what I can come up with for a plan.

... It would be safer to lay out the differences between the various
"standards" that purport to represent the complex numbers (e.g. with
and without the "point-at-infinity").

The primary issue would be to agree if a single implementation is OK.
Or if a single choice would have irredeemable drawbacks for some users.
[IIRC, the current choice led to some surprise (wrt infinities).]

If several are required, then we might consider using inheritance if
some implementation (conceptually) extends another.

Another issue (not high priority) might be to consider implementing
a separate class to hold polar coordinates (assuming that some
operations would benefit from not going through the conversions from
and to Cartesian coordinates).

Best regards,

> Eric
> On 23/04/16 01:27, Gilles wrote:
>> Hi.
>> Branch "feature-MATH-1290" deals with "Complex" utilities.
>> It is perhaps a good opportunity to review this very old
>> issue.  And decide whether it is worth keeping it open.
>> Regards,
>> Gilles

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message