Hello.
On Thu, 24 Nov 2016 08:20:10 +0000, Bernd Porr wrote:
Hi Gilles,
I like the idea of "SigProc". Filter is a bit too narrow especially
when we also include more exoctic processing and/or analysis etc.
In terms of complex: the filter package uses complex numbers but
that's totally transparent to the user so for those who are not into
DSP might not look it up there.
Hopefully, search engines will index the project's web site not
only on its name but also on its contents.
And we can also change the name of "Commons Complex" if there is
a better proposal, but this all depends on the scope (which in
turn has implications on what components are to be created).
Also, if we add FIR filter design at
some point then that's usually done with the Fourier Transform.
At first sight, the Fourier transform functionality should be a
module in "Commons Complex".
How would you organise the different sub-packages in SigProc? Let say
we have IIR, Kalman and FIR. At least IIR and Kalman consist of
approx
10 java files so ideally they should live in subdirectories at least
so we could create sub-packages then?
Please have a look at "Commons RNG":
http://commons.apache.org/proper/commons-rng/modules.html
That project was very small[1], yet it could be split into several
modules so that application developers can have (close to) minimal
dependencies.
In the same way, in "Commons SigProc" (or a another name) there could
be the following modules[2]:
* commons-sigproc-complex
* commons-sigproc-quaternion
* commons-sigproc-fft
* commons-sigproc-iir
* commons-sigproc-kalman
* ...
Personally, I'd prefer two separate components
"Commons Complex" with modules[2]:
* commons-complex
* commons-complex-quaternion
* commons-complex-fft
and
"Commons SigProc" with modules:
* commons-sigproc-core
* commons-sigproc-iir
* commons-sigproc-kalman
* ...
(that would of course depend on some of the "Common Complex" modules).
IMO, that provides even greater flexibility, in terms of project
management, as I've advocated extensively (for splitting up
"Commons Math").
But to get work started,[3] I'd suggest to use the already available
"git" repository:
https://git-wip-us.apache.org/repos/asf?p=commons-complex.git
[And as things evolve, we can ask for an additional repository.]
Best regards,
Gilles
[1] Despite I've now worked on it for almost a year!
[2] That make also more sense as a functionality that is at the core
of other applications. See e.g. (FTR):
https://issues.apache.org/jira/browse/MATH-1397
Wouldn't it be a pity to have to re-release the whole of "SigProc"
because of a bug (in the "complex" module) that does not affect the
"filter" functionality?
[3] As some of the PMC members are extremely reluctant to the creation
of new components, for no clear reason.
Best,
/Bernd
On 23/11/16 13:34, Gilles wrote:
Hi Bernd, Eric (and others).
I was about to request a JIRA project for the "filter" component.[1]
The name "FILTER" is not taken (as a JIRA project) but it would
be better if we are sure that the name will stick (rather than have
to later change the JIRA id or keep one that would not be close to
the component's name.
How about "Sig(nal) Proc(essing)"?
Alternatively, would there be any sense to develop this codebase as
a module within the "Commons Complex" project.[2]
IOW, is it foreseen that "Filter" will depend on any code other than
what is going to end up in the "Complex" project?[3]
Regards,
Gilles
[1] Currently, an empty directory in the "sandbox" SVN repository.
[2] Currently, an empty git repository.
[3] AFAICT: Classes from
o.a.c.math4.complex
o.a.c.math4.analysis.solvers
o.a.c.math4.transform
packages.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
