commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [Math] Java version
Date Fri, 16 Jan 2015 00:30:59 GMT
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message