[ANNOUNCE] Apache Commons Math 3.5 released
The Apache Commons Team is pleased to announce the availability of Apache Commons Math 3.5. Apache Commons Math is a library of lightweight, self-contained mathematics and statistics components addressing the most common problems not available in the Java programming language or Commons Lang. Version 3.5 is a minor release: It combines bug fixes and new features. Changes to existing features were made in a backwards-compatible way such as to allow drop-in replacement of the v3.4.1 JAR file. Most notable among the new features are: getQuadraticMean method added to DescriptiveStatistics SummaryStatistics which calculates the root mean square, and a way to build polyhedrons sets from list of vertices and the facets they belong too. There have been numerous bug fixes. The minimum version of the Java platform required to compile and use Apache Commons Math is Java 5. Users are encouraged to upgrade to this version as this release not only includes bug fixes but also deprecates numerous classes and methods that will be deleted from the next major release (4.0). A full list of all changes can be found in the release notes at http://www.apache.org/dist/commons/math/RELEASE-NOTES.txt Source and binary distributions are available for download from the Apache Commons download site: http://commons.apache.org/proper/commons-math/download_math.cgi When downloading, please verify signatures using the KEYS file available at the above location when downloading the release. Maven artifacts are also available in the maven central repository: GroupId: org.apache.commons ArtifactId: commons-math3 Version: 3.5 For complete information on Apache Commons Math, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Math website: http://commons.apache.org/proper/commons-math/ Luc Maisonobe, on behalf of the Apache Commons community - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] threading redux
On 4/17/15 5:20 PM, Gary Gregory wrote:
> I thought I'd share this read with you guys:
> http://coopsoft.com/ar/CalamityArticle.html
>
> I'm not sure how closely these problems relate with what [math] is trying
> to do, but it's a interesting read.
Thanks! Kind of supports the idea that somehow allowing the
execution framework to be pluggable would be good.
Phil
>
> Gary
>
> On Fri, Apr 17, 2015 at 9:01 AM, Gilles
> wrote:
>
>> On Fri, 17 Apr 2015 08:35:42 -0700, Phil Steitz wrote:
>>
>>> On 4/17/15 3:14 AM, Gilles wrote:
>>>
Hello.
On Thu, 16 Apr 2015 17:06:21 -0500, James Carman wrote:
> Consider me poked!
>
> So, the Java answer to "how do I run things in multiple threads"
> is to
> use an Executor (java.util). This doesn't necessarily mean that you
> *have* to use a separate thread (the implementation could execute
> inline). However, in order to accommodate the separate thread case,
> you would need to code to a Future-like API. Now, I'm not saying to
> use Executors directly, but I'd provide some abstraction layer above
> them or in lieu of them, something like:
>
> public interface ExecutorThingy {
> Future execute(Function fn);
> }
>
> One could imagine implementing different ExecutorThingy
> implementations which allow you to parallelize things in different
> ways (simple threads, JMS, Akka, etc, etc.)
>
I did not understand what is being suggested: parallelization of a
single algorithm or concurrent calls to multiple instances of an
algorithm?
>>> Really both. It's probably best to look at some concrete examples.
>>>
>> Certainly...
>>
>> The two I mentioned in my apachecon talk are:
>>> 1. Threads managed by some external process / application gathering
>>> statistics to be aggregated.
>>>
>>> 2. Allowing multiple threads to concurrently execute GA
>>> transformations within the GeneticAlgorithm "evolve" method.
>>>
>> I could not view the presentation from the link previously mentioned
>> (it did not work with my browser...).
>> Can I download the PDF file from somewhere?
>>
>> It would be instructive to think about how to handle both of these
>>> use cases using something like what James is suggesting. What is
>>> nice about his idea is that it could give us a way to let users /
>>> systems decide whether they want to have [math] algorithms spawn
>>> threads to execute concurrently or to allow an external execution
>>> framework to handle task distribution across threads.
>>>
>> Some (all?) cases of "external" parallelism are trivial for the CM
>> developers: the user must chop his data, pass the chunks as arguments
>> to the CM methods, then collect and reassemble the results, all by
>> himself.
>> IIUC the scenario, this cannot be deemed a "feature".
>>
>> Since 2. above is a good example of "internal" parallelism and it
>>> also has data sharing / transfer challenges, maybe its best to start
>>> with that one.
>>>
>> That's the scenario where usage is simple and performance can match
>> the user's machine capability when running CM algorithms that are
>> inherently parallel.
>>
>> There is an example in CM: see
>> testTravellerSalesmanSquareTourParallelSolver()
>> in
>> org.apache.commons.math4.ml.neuralnet.sofm.KohonenTrainingTaskTest
>>
>> I have just started thinking about this and would
>>> love to get better ideas than my own hacking about how to do it
>>>
>>> a) Using Spark with RDD's to maintain population state data
>>> b) Hadoop with HDFS (or something else?)
>>>
>> I have zero experience with this but I'm interested to know more. :-)
>>
>> Regards,
>> Gilles
>>
>>
>>
>> -
>> 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: svn commit: r1673285 - in /commons/proper/dbutils/trunk/src: main/java/org/apache/commons/dbutils/ main/java/org/apache/commons/dbutils/handlers/ test/java/org/apache/commons/dbutils/handlers/
Thanks for the reminder! I updated changes.xml in a later commit. I will
try to make the update when the relevant work is committed.
On Tue, Apr 14, 2015 at 8:29 AM, Benedikt Ritter wrote:
> Hello Carl,
>
> please remember to add fixes to changes.xml so it is easier for RMs to
> generate release notes :-)
>
> Thank you!
> Benedikt
>
> 2015-04-13 23:19 GMT+02:00 :
>
> > Author: thecarlhall
> > Date: Mon Apr 13 21:19:22 2015
> > New Revision: 1673285
> >
> > URL: http://svn.apache.org/r1673285
> > Log:
> > DBUTILS-82 Applied user-submitted patch and made minor fixes
> >
> > Modified:
> >
> >
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/BasicRowProcessor.java
> >
> >
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/BeanProcessor.java
> >
> >
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/RowProcessor.java
> >
> >
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/handlers/BeanHandler.java
> >
> >
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/handlers/BeanListHandler.java
> >
> >
> commons/proper/dbutils/trunk/src/test/java/org/apache/commons/dbutils/handlers/BeanHandlerTest.java
> >
> >
> commons/proper/dbutils/trunk/src/test/java/org/apache/commons/dbutils/handlers/BeanListHandlerTest.java
> >
> > Modified:
> >
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/BasicRowProcessor.java
> > URL:
> >
> http://svn.apache.org/viewvc/commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/BasicRowProcessor.java?rev=1673285&r1=1673284&r2=1673285&view=diff
> >
> >
> ==
> > ---
> >
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/BasicRowProcessor.java
> > (original)
> > +++
> >
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/BasicRowProcessor.java
> > Mon Apr 13 21:19:22 2015
> > @@ -119,7 +119,7 @@ public class BasicRowProcessor implement
> > * @return the newly created bean
> > */
> > @Override
> > -public T toBean(ResultSet rs, Class type) throws
> SQLException {
> > +public T toBean(ResultSet rs, Class type) throws
> > SQLException {
> > return this.convert.toBean(rs, type);
> > }
> >
> > @@ -136,7 +136,7 @@ public class BasicRowProcessor implement
> > * they were returned by the ResultSet.
> > */
> > @Override
> > -public List toBeanList(ResultSet rs, Class type) throws
> > SQLException {
> > +public List toBeanList(ResultSet rs, Class type)
> > throws SQLException {
> > return this.convert.toBeanList(rs, type);
> > }
> >
> >
> > Modified:
> >
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/BeanProcessor.java
> > URL:
> >
> http://svn.apache.org/viewvc/commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/BeanProcessor.java?rev=1673285&r1=1673284&r2=1673285&view=diff
> >
> >
> ==
> > ---
> >
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/BeanProcessor.java
> > (original)
> > +++
> >
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/BeanProcessor.java
> > Mon Apr 13 21:19:22 2015
> > @@ -135,7 +135,7 @@ public class BeanProcessor {
> > * @throws SQLException if a database access error occurs
> > * @return the newly created bean
> > */
> > -public T toBean(ResultSet rs, Class type) throws
> SQLException {
> > +public T toBean(ResultSet rs, Class type) throws
> > SQLException {
> >
> > PropertyDescriptor[] props = this.propertyDescriptors(type);
> >
> > @@ -178,7 +178,7 @@ public class BeanProcessor {
> > * @throws SQLException if a database access error occurs
> > * @return the newly created List of beans
> > */
> > -public List toBeanList(ResultSet rs, Class type) throws
> > SQLException {
> > +public List toBeanList(ResultSet rs, Class type)
> > throws SQLException {
> > List results = new ArrayList();
> >
> > if (!rs.next()) {
> >
> > Modified:
> >
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/RowProcessor.java
> > URL:
> >
> http://svn.apache.org/viewvc/commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/RowProcessor.java?rev=1673285&r1=1673284&r2=1673285&view=diff
> >
> >
> ==
> > ---
> >
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/RowProcessor.java
> > (original)
> > +++
> >
> commons/proper/dbutils/trunk/src/main/java/org/apache/commons/dbutils/RowProcessor.java
> > Mon Apr 13 21:19:22 2015
> > @@ -55,7 +55,7 @@ public interface RowProcessor {
> > * @throws SQLException if a database access error occurs
> > * @return the newly created bean
> >
[GitHub] commons-lang pull request: #LANG-1114 TypeUtils.equals is broken f...
GitHub user datalorax opened a pull request: https://github.com/apache/commons-lang/pull/65 #LANG-1114 TypeUtils.equals is broken for WildcardType TypeUtils.equals is broken for WildcardType, when compared with non-wildcard type. It was broken because it was returning true! Now returns false. Also added test to cover the issue. You can merge this pull request into a Git repository by running: $ git pull https://github.com/datalorax/commons-lang bug/LANG-1114-TypeUtils.ParameterizedType#equals_does_not_work_with_wildcard_types Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/65.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #65 commit b053737c2e64303cfcaca0fb07c1f13d352a7b8e Author: The Datalorax Date: 2015-04-18T21:14:06Z #LANG-1114 TypeUtils.equals is broken for WildcardType, when compared with non-wildcard type. It was broken because it was returning true! Now returns false. Also added test to highlight issue. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] threading redux
On Fri, 17 Apr 2015 16:53:56 -0500, James Carman wrote:
Do you have any pointers to code for this ForkJoin mechanism? I'm
curious to see it.
The key thing you will need in order to support parallelization in a
generic way
What do you mean by "generic way"?
I'm afraid that we may be trying to compare apples and oranges;
each of us probably has in mind a "prototype" algorithm and an idea
of how to implement it to make it run in parallel.
I think that it would focus the discussion if we could
1. tell what the "prototype" is,
2. show a sort of pseudo-code of the difference between a sequential
and a parallel run of this "prototype" (i.e. what is the data, how
the (sub)tasks operate on them).
Regards,
Gilles
is to not tie it directly to threads, but use some
abstraction layer above threads, since that may not be the "worker"
method you're using at the time.
On Fri, Apr 17, 2015 at 2:57 PM, Thomas Neidhart
wrote:
On 04/17/2015 05:35 PM, Phil Steitz wrote:
On 4/17/15 3:14 AM, Gilles wrote:
Hello.
On Thu, 16 Apr 2015 17:06:21 -0500, James Carman wrote:
Consider me poked!
So, the Java answer to "how do I run things in multiple threads"
is to
use an Executor (java.util). This doesn't necessarily mean that
you
*have* to use a separate thread (the implementation could execute
inline). However, in order to accommodate the separate thread
case,
you would need to code to a Future-like API. Now, I'm not saying
to
use Executors directly, but I'd provide some abstraction layer
above
them or in lieu of them, something like:
public interface ExecutorThingy {
Future execute(Function fn);
}
One could imagine implementing different ExecutorThingy
implementations which allow you to parallelize things in
different
ways (simple threads, JMS, Akka, etc, etc.)
I did not understand what is being suggested: parallelization of a
single algorithm or concurrent calls to multiple instances of an
algorithm?
Really both. It's probably best to look at some concrete examples.
The two I mentioned in my apachecon talk are:
1. Threads managed by some external process / application
gathering
statistics to be aggregated.
2. Allowing multiple threads to concurrently execute GA
transformations within the GeneticAlgorithm "evolve" method.
It would be instructive to think about how to handle both of these
use cases using something like what James is suggesting. What is
nice about his idea is that it could give us a way to let users /
systems decide whether they want to have [math] algorithms spawn
threads to execute concurrently or to allow an external execution
framework to handle task distribution across threads.
I since a more viable option is to take advantage of the ForkJoin
mechanism that we can use now in math 4.
For example, the GeneticAlgorithm could be quite easily changed to
use a
ForkJoinTask to perform each evolution, I will try to come up with
an
example soon as I plan to work on the genetics package anyway.
The idea outlined above sounds nice but it is very unclear how an
algorithm or function would perform its parallelization in such a
way,
and whether it would still be efficient.
Thomas
Since 2. above is a good example of "internal" parallelism and it
also has data sharing / transfer challenges, maybe its best to
start
with that one. I have just started thinking about this and would
love to get better ideas than my own hacking about how to do it
a) Using Spark with RDD's to maintain population state data
b) Hadoop with HDFS (or something else?)
Phil
Gilles
[...]
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] threading redux
I think I got sidetracked when typing that email. I was trying to say that
we need an abstraction layer above raw threads in order to allow for
different types of parallelism. The Future abstraction is there in order
to support remote execution where side effects aren't good enough.
As for a concrete example, you can try Phil's idea of the genetic algorithm
stuff I suppose.
On Saturday, April 18, 2015, Gilles wrote:
> On Fri, 17 Apr 2015 16:53:56 -0500, James Carman wrote:
>
>> Do you have any pointers to code for this ForkJoin mechanism? I'm
>> curious to see it.
>>
>> The key thing you will need in order to support parallelization in a
>> generic way
>>
>
> What do you mean by "generic way"?
>
> I'm afraid that we may be trying to compare apples and oranges;
> each of us probably has in mind a "prototype" algorithm and an idea
> of how to implement it to make it run in parallel.
>
> I think that it would focus the discussion if we could
> 1. tell what the "prototype" is,
> 2. show a sort of pseudo-code of the difference between a sequential
>and a parallel run of this "prototype" (i.e. what is the data, how
>the (sub)tasks operate on them).
>
> Regards,
> Gilles
>
> is to not tie it directly to threads, but use some
>> abstraction layer above threads, since that may not be the "worker"
>> method you're using at the time.
>>
>> On Fri, Apr 17, 2015 at 2:57 PM, Thomas Neidhart
>> wrote:
>>
>>> On 04/17/2015 05:35 PM, Phil Steitz wrote:
>>>
On 4/17/15 3:14 AM, Gilles wrote:
> Hello.
>
> On Thu, 16 Apr 2015 17:06:21 -0500, James Carman wrote:
>
>> Consider me poked!
>>
>> So, the Java answer to "how do I run things in multiple threads"
>> is to
>> use an Executor (java.util). This doesn't necessarily mean that you
>> *have* to use a separate thread (the implementation could execute
>> inline). However, in order to accommodate the separate thread case,
>> you would need to code to a Future-like API. Now, I'm not saying to
>> use Executors directly, but I'd provide some abstraction layer above
>> them or in lieu of them, something like:
>>
>> public interface ExecutorThingy {
>> Future execute(Function fn);
>> }
>>
>> One could imagine implementing different ExecutorThingy
>> implementations which allow you to parallelize things in different
>> ways (simple threads, JMS, Akka, etc, etc.)
>>
>
> I did not understand what is being suggested: parallelization of a
> single algorithm or concurrent calls to multiple instances of an
> algorithm?
>
Really both. It's probably best to look at some concrete examples.
The two I mentioned in my apachecon talk are:
1. Threads managed by some external process / application gathering
statistics to be aggregated.
2. Allowing multiple threads to concurrently execute GA
transformations within the GeneticAlgorithm "evolve" method.
It would be instructive to think about how to handle both of these
use cases using something like what James is suggesting. What is
nice about his idea is that it could give us a way to let users /
systems decide whether they want to have [math] algorithms spawn
threads to execute concurrently or to allow an external execution
framework to handle task distribution across threads.
>>>
>>> I since a more viable option is to take advantage of the ForkJoin
>>> mechanism that we can use now in math 4.
>>>
>>> For example, the GeneticAlgorithm could be quite easily changed to use a
>>> ForkJoinTask to perform each evolution, I will try to come up with an
>>> example soon as I plan to work on the genetics package anyway.
>>>
>>> The idea outlined above sounds nice but it is very unclear how an
>>> algorithm or function would perform its parallelization in such a way,
>>> and whether it would still be efficient.
>>>
>>> Thomas
>>>
>>> Since 2. above is a good example of "internal" parallelism and it
also has data sharing / transfer challenges, maybe its best to start
with that one. I have just started thinking about this and would
love to get better ideas than my own hacking about how to do it
a) Using Spark with RDD's to maintain population state data
b) Hadoop with HDFS (or something else?)
Phil
>
>
> Gilles
>
> [...]
>>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
