You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Eric Barnhill <er...@gmail.com> on 2017/01/14 10:07:12 UTC
[numbers] JTransforms and commons-math
On the subject of FFT and other transforms, I went to take another look at
the JTransforms code, which is AFAIK the premiere transforms package for
Java (even outperforming FFTW) and which I myself use over Commons.
It is now on GitHub so it was easy to browse the source code. It is in pure
Java and even has a commons-3 dependency (on FastMath). Other than that,
from the code I looked at, it is only dependent on another package by the
same author, JLargeArrays.
This must be an issue around commons from time to time. The reasonable
choice for a Java user would be JTransforms. It would be needless time and
effort to reinvent the wheel, this author has been refining the package for
10+ years. On the other hand we will need an FFT going forward, and it is
part of the commons mission to be self-contained.
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. Is there a recommended way to proceed?
Re: [numbers] JTransforms and commons-math
Posted by Gilles <gi...@harfang.homelinux.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [numbers] JTransforms and commons-math
Posted by Eric Barnhill <er...@gmail.com>.
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.
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.
>
> 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. "
This of course was written before the "new reality".
>
> 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
- 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
- something else
Eric
Re: [numbers] JTransforms and commons-math
Posted by Gilles <gi...@harfang.homelinux.org>.
Hi.
On Sat, 14 Jan 2017 11:07:12 +0100, Eric Barnhill wrote:
> On the subject of FFT and other transforms, I went to take another
> look at
> the JTransforms code, which is AFAIK the premiere transforms package
> for
> Java (even outperforming FFTW) and which I myself use over Commons.
>
> It is now on GitHub so it was easy to browse the source code. It is
> in pure
> Java and even has a commons-3 dependency (on FastMath).
Do you know which methods, and why (precision and/or performance)?
> Other than that,
> from the code I looked at, it is only dependent on another package by
> the
> same author, JLargeArrays.
>
> This must be an issue around commons from time to time. The
> reasonable
> choice for a Java user would be JTransforms. It would be needless
> time and
> effort to reinvent the wheel, this author has been refining the
> package for
> 10+ years.
+1 (now)
We've known for a long time that it existed.
IIRC, originally it was not pure Java, so that would have been the main
argument for not dropping the FFT code from Commons Math.
> 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).
> and it is
> part of the commons mission to be self-contained.
Really?
> 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?
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org