Re: [Math] About MATH-667 (Complex numbers)

[Eric Barnhill <er...@gmail.com>]

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 will also go mention it on 
octave-maintainers and see what I can come up with for a plan.

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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [Math] About MATH-667 (Complex numbers)

[Gilles <gi...@harfang.homelinux.org>]

Hi.

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.

Anyways...

> 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,
Gilles

> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org