I would also add that this was part of the expected development path of
math modules. The first thing was to see what actually got developed and
supported; this would then shed light on how best to organize it, rather
than lay out an organization for a "best case" set of math libraries that
might n
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 a
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 Git
Hello all,
It’s been pointed out that there are some APIs that came over from [lang] that
seem odd. Namely, we have, in “EntityArrays.java”, some essentially factory
methods that are named as if they are a constant, all uppercase with
underscores. The question is do we change the API now? It se
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).
>
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
