[Math] About MATH-667 (Complex numbers)

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

[Math] About MATH-667 (Complex numbers)

Gilles Sadowski
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Eric Barnhill
That is interesting. I'd be happy to work on synchronizing the way
commons-math and octave handle complex numbers for a next project.

JIRA is on some kind of spam shutdown with no letup in sight, so... My
latest pull followed your instructions including tracking the branch.
However I thought I did this before. So if new master commits are still
mixed up in it somehow, perhaps there is some other answer to why this
is happening.

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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Gilles Sadowski
On Sun, 24 Apr 2016 10:27:13 +0200, Eric Barnhill wrote:
> That is interesting. I'd be happy to work on synchronizing the way
> commons-math and octave handle complex numbers for a next project.

Good to know. :-)

> JIRA is on some kind of spam shutdown with no letup in sight, so...

I've added your id in the "Contributors" category in JIRA; so you
might be able to update pages even while the lockdown is active.

> My latest pull followed your instructions including tracking the
> branch. However I thought I did this before. So if new master commits
> are still mixed up in it somehow, perhaps there is some other answer
> to why this is happening.

For what it's worth, I could handle this pull request
   https://issues.apache.org/jira/browse/MATH-1350
without any problem.

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Eric Barnhill
In reply to this post by Gilles Sadowski
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Gilles Sadowski
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: [hidden email]
For additional commands, e-mail: [hidden email]