Re: [Math] Java version (Was: [MATH] Jenkins build)
So, for places where you want to make use of streams, make your API take a StreamT rather than a CollectionT or whatever, and require the user to choose whether to call parallelStream() or stream(). On Thu, Jan 15, 2015 at 5:41 PM, Phil Steitz phil.ste...@gmail.com 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 +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 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. Much better to let Hadoop / Mahout et al parallelize using fast and accurate piece parts that we can provide. 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. Phil just my 2cents Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Java version (Was: [MATH] Jenkins build)
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 * 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 * staying at Java 6/7 does not block users to use math in a Java 8 environment if wanted just my 2cents Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Java version (Was: [MATH] Jenkins build)
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 +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 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. Much better to let Hadoop / Mahout et al parallelize using fast and accurate piece parts that we can provide. 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. Phil just my 2cents Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Java version (Was: [MATH] Jenkins build)
On 01/15/2015 03: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
* 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
Creating thread safe classes / algorithms has traditionally been Tricky.
With Java 8 parallel streams processing concurrency is a lower hanging fruit. For
example (Taken from http://winterbe.com/posts/2014/07/31/java8-stream-tutorial-examples/):
|=
Integer ageSum = persons
.parallelStream()
.reduce(0,
(sum, p) - {
System.out.format(accumulator: sum=%s; person=%s\n, sum, p);
return sum += p.age;
},
(sum1, sum2) - {
System.out.format(combiner: sum1=%s; sum2=%s\n, sum1, sum2);
return sum1 + sum2;
});
// accumulator: sum=0; person=Pamela
// accumulator: sum=0; person=David
// accumulator: sum=0; person=Max
// accumulator: sum=0; person=Peter
// combiner: sum1=18; sum2=23
// combiner: sum1=23; sum2=12
// combiner: sum1=41; sum2=35
|
|=
Less boilerplate, easier to read code, that's more efficient. Java 8
encourages making use of the fluid functional programming internally that
that the newer APIs aim to provide Externally.
|
Cheers,
Ole
Re: [Math] Java version (Was: [MATH] Jenkins build)
Le 08/01/2015 12:34, Gilles a écrit : Hi. Raising this issue once again. Are we going to upgrade the requirement for the next major release? [ ] Java 5 [ ] Java 6 [ ] Java 7 [ ] Java 8 [ ] Java 9 I would say 7 or 8. best regards, Luc ? Gilles On Thu, 8 Jan 2015 10:34:20 +, sebb wrote: I've had to give up trying to get Continuum to use Git, so I set up a Jenkins build for Math It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME variables don't seem to have been set up on the Jenkins hosts, so the -Pjava-1.5 profile does not work as is. However I found that the JAVA_1_5_HOME variable can be defined on the Maven command-line. This works, provided that Java 1.5 is always installed in the same location on different hosts. [The JAVA_1_x_HOME variables were designed get around this restriction, as they can be differently defined on different hosts] Hopefully the builds will be useful in detecting accidental use of Java 1.6+ APIs So far I have only added Commons Math itself. I hope to add the examples shortly. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Java version (Was: [MATH] Jenkins build)
I wouldn't think you'd want to begin anything new using an EOLed version of Java. I'd go with at least 7. On Thu, Jan 8, 2015 at 6:34 AM, Gilles gil...@harfang.homelinux.org wrote: Hi. Raising this issue once again. Are we going to upgrade the requirement for the next major release? [ ] Java 5 [ ] Java 6 [ ] Java 7 [ ] Java 8 [ ] Java 9 ? Gilles On Thu, 8 Jan 2015 10:34:20 +, sebb wrote: I've had to give up trying to get Continuum to use Git, so I set up a Jenkins build for Math It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME variables don't seem to have been set up on the Jenkins hosts, so the -Pjava-1.5 profile does not work as is. However I found that the JAVA_1_5_HOME variable can be defined on the Maven command-line. This works, provided that Java 1.5 is always installed in the same location on different hosts. [The JAVA_1_x_HOME variables were designed get around this restriction, as they can be differently defined on different hosts] Hopefully the builds will be useful in detecting accidental use of Java 1.6+ APIs So far I have only added Commons Math itself. I hope to add the examples shortly. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Java version (Was: [MATH] Jenkins build)
On 1/8/15 4:34 AM, Gilles wrote: Hi. Raising this issue once again. Are we going to upgrade the requirement for the next major release? [ ] Java 5 [ ] Java 6 [x] Java 7 [ ] Java 8 [ ] Java 9 Phil ? Gilles On Thu, 8 Jan 2015 10:34:20 +, sebb wrote: I've had to give up trying to get Continuum to use Git, so I set up a Jenkins build for Math It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME variables don't seem to have been set up on the Jenkins hosts, so the -Pjava-1.5 profile does not work as is. However I found that the JAVA_1_5_HOME variable can be defined on the Maven command-line. This works, provided that Java 1.5 is always installed in the same location on different hosts. [The JAVA_1_x_HOME variables were designed get around this restriction, as they can be differently defined on different hosts] Hopefully the builds will be useful in detecting accidental use of Java 1.6+ APIs So far I have only added Commons Math itself. I hope to add the examples shortly. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org . - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Java version (Was: [MATH] Jenkins build)
Hi, I am only a user of the library, but I would be excited to see CM take advantage of the new features of java 8. Best regards, Martin Grotle Soukup 2015-01-08 12:34 GMT+01:00 Gilles gil...@harfang.homelinux.org: Hi. Raising this issue once again. Are we going to upgrade the requirement for the next major release? [ ] Java 5 [ ] Java 6 [ ] Java 7 [x] Java 8 [ ] Java 9 ? Gilles On Thu, 8 Jan 2015 10:34:20 +, sebb wrote: I've had to give up trying to get Continuum to use Git, so I set up a Jenkins build for Math It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME variables don't seem to have been set up on the Jenkins hosts, so the -Pjava-1.5 profile does not work as is. However I found that the JAVA_1_5_HOME variable can be defined on the Maven command-line. This works, provided that Java 1.5 is always installed in the same location on different hosts. [The JAVA_1_x_HOME variables were designed get around this restriction, as they can be differently defined on different hosts] Hopefully the builds will be useful in detecting accidental use of Java 1.6+ APIs So far I have only added Commons Math itself. I hope to add the examples shortly. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Java version (Was: [MATH] Jenkins build)
My clients started to use Java 7 a few months before, so I wouldn't choose Java 8. I know it's new and shinny and as a developer I'd love to play with it, but unfortunately, users are using it. I'd go for Java 7 and plan Java 8 for Math 5.0 On Thu, Jan 8, 2015 at 4:16 PM, Benedikt Ritter brit...@apache.org wrote: 2015-01-08 13:57 GMT+01:00 Martin Grotle Soukup martin.grotle.sou...@gmail.com: Hi, I am only a user of the library, but I would be excited to see CM take advantage of the new features of java 8. Best regards, Martin Grotle Soukup 2015-01-08 12:34 GMT+01:00 Gilles gil...@harfang.homelinux.org: Hi. Raising this issue once again. Are we going to upgrade the requirement for the next major release? [ ] Java 5 [ ] Java 6 [ ] Java 7 [x] Java 8 The java.util.function package seems like a natural fit for a mathematics library. OTOH my feeling is, that most users are still using Java 6/7... Benedikt [ ] Java 9 ? Gilles On Thu, 8 Jan 2015 10:34:20 +, sebb wrote: I've had to give up trying to get Continuum to use Git, so I set up a Jenkins build for Math It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME variables don't seem to have been set up on the Jenkins hosts, so the -Pjava-1.5 profile does not work as is. However I found that the JAVA_1_5_HOME variable can be defined on the Maven command-line. This works, provided that Java 1.5 is always installed in the same location on different hosts. [The JAVA_1_x_HOME variables were designed get around this restriction, as they can be differently defined on different hosts] Hopefully the builds will be useful in detecting accidental use of Java 1.6+ APIs So far I have only added Commons Math itself. I hope to add the examples shortly. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- - OCPJP7 (90%) - OCAJP7 (93%) - Java and Big Data Enthusiast
Re: [Math] Java version (Was: [MATH] Jenkins build)
2015-01-08 13:57 GMT+01:00 Martin Grotle Soukup martin.grotle.sou...@gmail.com: Hi, I am only a user of the library, but I would be excited to see CM take advantage of the new features of java 8. Best regards, Martin Grotle Soukup 2015-01-08 12:34 GMT+01:00 Gilles gil...@harfang.homelinux.org: Hi. Raising this issue once again. Are we going to upgrade the requirement for the next major release? [ ] Java 5 [ ] Java 6 [ ] Java 7 [x] Java 8 The java.util.function package seems like a natural fit for a mathematics library. OTOH my feeling is, that most users are still using Java 6/7... Benedikt [ ] Java 9 ? Gilles On Thu, 8 Jan 2015 10:34:20 +, sebb wrote: I've had to give up trying to get Continuum to use Git, so I set up a Jenkins build for Math It seems Jenkins itself needs Java 1.6+, and the JAVA_1_x_HOME variables don't seem to have been set up on the Jenkins hosts, so the -Pjava-1.5 profile does not work as is. However I found that the JAVA_1_5_HOME variable can be defined on the Maven command-line. This works, provided that Java 1.5 is always installed in the same location on different hosts. [The JAVA_1_x_HOME variables were designed get around this restriction, as they can be differently defined on different hosts] Hopefully the builds will be useful in detecting accidental use of Java 1.6+ APIs So far I have only added Commons Math itself. I hope to add the examples shortly. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
