On Sat, 14 Jan 2017 16:34:24 +0100, Eric Barnhill wrote:
Do you know which methods, and why (precision and/or performance)?
I can look at the code this week, alternatively I could contact the
developer.
It's "sin" and "cos".
Our CM-internal micro-benchmark indeed showed better performance, at
least for short run times. [JMH benchmark should be run to confirm
long the trend for long runs.]
On the other hand we will need an FFT going forward,
As for similar issues (cf TEXT), "SigProc" can define custom
interfaces
and bridge(s).
I will go back and look at some of that discussion.
It's here:
https://issues.apache.org/jira/browse/TEXT-36
and it is
part of the commons mission to be self-contained.
Really?
from http://commons.apache.org/proper/commons-math/
"Commons Math is a library of lightweight, self-contained mathematics
and
statistics components addressing the most common problems not
available in
the Java programming language or Commons Lang. "
I think that this description was a wish, not an operational
definition.
It should have been updated years ago, when CM was becoming
"heavyweight".
The phrase "library of [...] mathematics and statistics components" is
weird:
Isn't statistics a part of mathematics?
Given the known outcome, anything which CM did (or did not do) at the
level
of project management is open to questioning.
This of course was written before the "new reality".
As you also seem to have hinted at in your post in the other thread
http://markmail.org/message/ild3dohn7ddiu5vg
my opinion is that the root of evil was to assume that we forever could
expand a "component" into a container for anything, as long as one
could
use the word "mathematics".
People talked more about their disagreements than about how to evolve
around what they were agreeing on.
And the larger the library, the more there are possibilities to
disagree.
The CM community failed because there was too many degrees of freedom!
JTransforms is open source so it could potentially be adapted for
sigproc
and numbers. For example, it doesn't take Complex arrays but only
double
arrays that alternate real and imaginary, which are awkward to deal
with
--
that is why I wrote methods, now in ComplexUtils, to deal with it.
But there's no question that overwhelmingly such an adaptation
would
remain
the same as the current library.
I don't understand the above sentence.
Is there a recommended way to proceed?
To do what?
More concretely, would it be better if I:
- contact Wendykier to see if he wanted to contribute his code to the
project or otherwise support using his code as part of commons
Highly unrealistic expectation, IMHO. ;-)
- just adapt JTransforms code, and integrate the parts we want, in
the way
that suits us, keeping his original copyright as per the open source
license
Do you mean "shading"?
- something else
If FFT is only used internally in the filtering routines, I'd suggest
defining
* private (or "internal") FFT interfaces
* private bridges to "shaded" JTransforms
Otherwise, we should create an API that will allow users to switch
implementation (see Ray DeCampo's solution for TEXT-36).
Best regards,
Gilles
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
