Hi.
On Wed, 8 Jun 2016 09:30:24 +0200, Eric Barnhill wrote:
On Wed, Jun 8, 2016 at 12:08 AM, Gilles
<gil...@harfang.homelinux.org>
wrote:
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?
It seems to me that the priority here is packaging up Complex into a
semiautonomous module.
Why "semi"?
I'm happy to take that on.
Thanks a lot.
What I might add to it
later strikes me as something to address after the transition.
Sure.
But it might help provide guidelines for desirable design changes
or choices.
However the
question of conforming some of the methods and data structures with
C99
probably should be addressed as part of the transition (which is to
say,
right now).
It's certainly desirable to do it before the initial release of this
new would-be component.
But the first thing is to decouple whatever would go into the new
module
from everything that wouldn't.
To be probably included: complex solvers (currently in
"o.a.c.m.analysis.solvers").
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"?
Exactly. I am not sure I even have a full grasp on how primitive
arrays,
MathArray objects, RealVectors, and objects like FieldMatrix all
inter-relate. Is it possible that together, these issues form a
coherent
module of their own?
I doubt it.
As they are currently, "MathArrays" and "RealVector" are at opposite
ends of
the design spectrum: the former mostly contains C-like functions
operating
on primitive arrays, the latter is OO.
The focus of "MathArrays" was speed (and also implement methods that
were
available in Java 6.
The API of "RealVector" is a mix between a "list of numbers", "single
row or
column matrix", "Cartesian coordinates" (IMHO a design mistake that
should
not be repeated).
Depending on the expected applications, some choices might be crucial.
E.g.: fixed or variable dimension (impacting
immutability/thread-safety)?
Or could be re-factored in such a way that they do
form a sensible module, grounded in a very generic class like
FieldElement?
I guess that it depends on the intended applications.
Even if the generalization sounds appealing, I'd be wary of creating a
mathematical framework which nobody would need.
The more so that this would probably involve inheritance, which is more
and more decried as the weakest point of OO.
Do you have examples in mind?
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?
I am just a noob with no sense of the history but it's okay by me.
I also nominate myself to look after the interpolation libraries. I
have
used them a lot and I really like the structure. It is a pleasure to
use
them to compare interpolation methods for example. I'll be pursuing
nonsmooth and L1-related types of interpolation in the very near
future. So
that seems like a straightforward expansion of the library I could
contribute.
Great.
Another candidate component; I assume.
[If so, in another thread. Again first thing would probably be to
decouple it from the legacy code.]
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
