commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject [Math] Moving on or not?
Date Tue, 05 Feb 2013 14:08:51 GMT
Hi.

In the thread about "static import", Stephen noted that decisions on a
component's evolution are dependent on whether the future of the Java
language is taken into account, or not.
A question on the same theme also arose after the presentation of 
Commons
Math in FOSDEM 2013.

If we assume that efficiency is among the important qualities for 
Commons
Math, the future is to allow usage of the tools provided by the 
standard
Java library in order to ease the development of multi-threaded 
algorithms.

Maintaining Java 1.5 source compatibility for the reason that we may 
need
to support legacy applications will turn out to be self-defeating:
1. New users will not consider Commons Math's features that are notably
    apt to parallel processing.
2. Current users might at some point simply switch to another library 
if
    it proves more efficient (because it actually uses multi-threading).
3. New Java developers will be turned away because they will want to 
use
    the more convenient features of the language in order to provide
    potential contributions.

If maintaining 1.5 source compatibility is kept as a requirement, the
consequence is that Commons Math will _become_ a legacy library.
In that perspective, implementing/improving algorithms for which a
parallel version is known to be more efficient is plainly a waste of
development and maintenance time.

In order to mitigate the risks (both of upgrading and of not upgrading
the source compatibility requirement), I would propose to create a new
project (say, "Commons Math MT") where we could implement new 
features[1]
without being encumbered with the 1.5 requirement.[2]
The "Commons Math MT" would depend on "Commons Math" where we would
continue developing single-thread (and thread-safe) "tasks", i.e.
independent units of processing that could be used in algorithms
located in "Commons Math MT".

In summary:
- Commons Math (as usual):
   * single-thread (sequential) algorithms,
   * (pure) Java 5,
   * no dependencies.
- Commons Math MT:
   * multi-thread (parallel) algorithms,
   * Java 7 and beyond,
   * JNI allowed,
   * dependencies allowed (jCuda).

What do you think?


Best regards,
Gilles

[1] Also, we would gradually move there the algorithms that would 
obviously
     benefit from a multi-thread implementation (e.g Fourier transform,
     genetic algorithms, etc.)
[2] This project would also be a place where people could experiment 
with
     "jCuda" (http://www.jcuda.org).


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message