On Mon, 6 Jun 2016 10:31:28 +0200, Eric Barnhill wrote:
I am not a mathematician so I would not be able to play a
particularly
catholic role in commons-math.
I don't think that the majority of contributors would have
qualified themselves as "mathematician".
In the current situation, it would be useful to lay out
which options we have for the existing codebase.
But, I am always delighted when my research
needs allow me to spin off contributions into the code base.
I work with complex valued 3 to 6-dimensional image volumes. So I am
happy
to maintain code involving complex numbers first of all, as well as
investigate their integration their integration with Octave and
ImgLib.
Which parts of Commons Math would be dependencies for this type
of applications?
Which algorithms of your applications would be generic enough to
warrant becoming part of a toolbox based on the "Complex" class?
I am also interested in code for array-based math operations which is
overwhelmingly how I compute. I would be happy to maintain that code
and it
does seem that now and again, suggests for how to refactor it come
through
JIRA.
Do you mean Java primitive "array", or the array concept like
implemented in CM's "RealVector"?
I have my own home brewed libraries for syntactically convenient
array wise operations that may also be of interest
How does this compare with Java 8 stream API?
Does it leverage multi-threading?
once everyone is happy
with the current state of the code base.
My view is that the current code base cannot be released unless
it is split supported components; and for those, I propose to
create dedicated Commons "components".
Do you agree?
Regards,
Gilles
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
