On Thu, 15 Jan 2015 15:41:11 -0700, Phil Steitz wrote:
On 1/15/15 2:24 PM, Thomas Neidhart wrote:
On 01/08/2015 12:34 PM, Gilles wrote:
Hi.
Raising this issue once again.
Are we going to upgrade the requirement for the next major release?
[ ] Java 5
[x] Java 6
[x] Java 7
[ ] Java 8
[ ] Java 9
A while ago I thought that it would be cool to switch to Java 7/8
for
some of the nice new features (mainly fork/join, lambda expressions
and
diamond operator, the rest is more or less unimportant for math
imho).
But after some thoughts I think they are not really needed for the
following reasons:
* the main focus of math is on developing high-quality, well tested
and
documented algorithms, the existing language features are more than
enough for this
Sure.
Not so long ago, some people were claiming that nothing beats
programming in "assembly" language.
+1
* coming up with multi-threaded algorithms might be appealing but
it is
also hard work and I wonder if it really makes sense in the times of
projects like mahout / hadoop / ... which aim for even better
scalability
+1
Hard work / easy work. Yes and no. It depends on the motivation
of the contributor. Or we have to (re)define clearly the scope of
CM, and start some serious clean-up.
It's not all black or white; I'm quite convinced that it's better
to handle multi-threading externally when the core computation is
sequential. But CM already contains algorithms that are inherently
parallel (a.o. genetic algorithms) and improvement in those areas
would undoubtedly benefit from (internal) parallel processing.
My HO is we should focus on getting the best single-threaded
implementations we can and, where possible, setting things up to be
executed in parallel by other engines. Spawning and managing
threads internal to [math] actually *reduces* the range of
applicability of our stuff.
Examples?
Much better to let Hadoop / Mahout et
al parallelize using fast and accurate piece parts that we can
provide.
Do they really do that?
[Or do they implement their own algorithms knowing that they must
be thread-safe (which is something we don't focus a lot on).]
If there are parallel algorithms that we are really dying
to implement directly, I would rather see that done in a way that
encapsulates and enables externalization of the thread management.
* staying at Java 6/7 does not block users to use math in a Java 8
environment if wanted
+1 - the examples I have seen thus far are all things that could be
done fairly easily with client code. I know we don't all agree with
this, but I think the biggest service we can provide to our user
base is good, tested, supported implementations of standard
algorithms. I wish we could find a way to focus more on that and
less on fiddling with the API or language features.
The problem is that those discussions constantly mix considerations
about contents, with political moves that do not necessarily match.
For example, a statement about contents would be: CM only provides
implementations of sequential mathematical algorithms.
But recent political moves, like changing the version control system
or advertizing "free for all" commit rights, aim at increasing the
contributor base.
What about those people interested in API fixing and new language
features? You'll make them want to contribute to another project.
Now that Java is, at last, beginning to catch up with other
languages incomparably more widely used in the scientific community,
Commons Math is discussing how far behind it is going to lag!
Regards,
Gilles
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
