On Mon, 9 Jan 2017 17:56:32 -0600, Brent Worden wrote:
Are the originally mentioned transforms in or out of scope of
commons-numbers?
It depends on the scope.
Hence my asking about the name.
There could be a rationale that the transforms are "applications"
of the concept of complex numbers, similarly to the claim that
anything that had the word "random" in its description (such as
for the "sampling" functionality) had to be part of "Commons RNG".
Even though my opinion is still that such a relationship is not
the best criterion for defining scope, including the transforms
was a compromise (to reach consensus about getting things to move
without bumping again the count of "Commons" components).
But I actually prefer to have a "Commons FFT" component that would
depend on the "commons-complex" module of "Commons Numbers".
Then, "Commons SigProc" would define its own FFT interface(s) and
users would be free to bridge them to whatever implementations
they choose.
Alternatively, it is up to the "SigProc" developers to assess whether
they would be happy to include the implementation from "Commons Math",
or directly depend on another (perhaps more performant) library.
Gilles
Brent
On Mon, Jan 9, 2017 at 12:02 PM, Gilles
<gil...@harfang.homelinux.org>
wrote:
See discussion thread, copied below.
[ ] Yes
[ ] Yes but I prefer this name: ...
[ ] No, because ...
I'll assume that this is a lazy consensus vote, to be closed in 72
hours
from now (i.e. on January 12, at 18:00:00 UTC).
Thanks,
Gilles
On Mon, 9 Jan 2017 15:57:51 +0000, sebb wrote:
On 9 January 2017 at 11:46, Gilles <gil...@harfang.homelinux.org>
wrote:
On Mon, 9 Jan 2017 09:08:18 +0100, Eric Barnhill wrote:
It is overall a fine plan by me. A precision class makes more
sense than
duplicating equals methods.
From a practical standpoint I think it would be better to see
Quaternion
in
its own subpackage than with Complex. Simply because I don't use
them
and
packages are better maintained by those who use them.
It is hard to see how the transforms fit in. If anything they
belong
with
the new sigproc libraries.
Fine.
Is there any objection on the name "Commons Numbers"?
Since the namespace belongs to the whole of Commons, this question
should be posed to all of Commons, i.e. using the [ALL] prefix.
Are there better matches for the intended scope? [Or do we want
that
the scope grows to also contain the "o.a.c.math4.prime" package"
and
possibly more of number-theoretic functionality (as was proposed
some
time ago to be added to Commons Math)?]
Shall I wait a couple of days before filing the request with
INFRA?
[I.e. to change the "git" repository, JIRA project and github
mirror.]
Gilles
Eric
On 8 Jan 2017 10:17, "Gilles" <gil...@harfang.homelinux.org>
wrote:
Hi.
How about renaming the component to "Commons Numbers" (or
another name
if preferred) that would contain the following modules:
* commons-numbers-core (with classes such as "Precision").
* commons-numbers-complex
* commons-numbers-quaternion
* commons-numbers-fraction
* commons-numbers-continued-fraction
* commons-numbers-fft (Fast Fourier Transform)
* commons-numbers-fct (Fast Cosine Transform)
* ...
?
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
