commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject [Math] About a new component based around "Complex" (Was: Commons Math (r)evolution)
Date Wed, 08 Jun 2016 22:21:23 GMT
Hi.

On Wed, 8 Jun 2016 09:30:24 +0200, Eric Barnhill wrote:
> On Wed, Jun 8, 2016 at 12:08 AM, Gilles 
> <gilles@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message