date:20121118

[GUMP@vmgump]: Project commons-io-test (in module apache-commons) failed

2012-11-18 Thread Gump

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-io-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 23 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-io-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-io-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/io/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/io/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/io/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/io/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-io-test/gump_work/build_apache-commons_commons-io-test.html
Work Name: build_apache-commons_commons-io-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 53 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/io/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/io]
M2_HOME: /opt/maven2
-
Running org.apache.commons.io.comparator.CompositeFileComparatorTest
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.159 sec
Running org.apache.commons.io.comparator.DefaultFileComparatorTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.131 sec
Running org.apache.commons.io.comparator.DirectoryFileComparatorTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.145 sec
Running org.apache.commons.io.comparator.ExtensionFileComparatorTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.134 sec
Running org.apache.commons.io.comparator.PathFileComparatorTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.134 sec
Running org.apache.commons.io.comparator.NameFileComparatorTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.137 sec
Running org.apache.commons.io.IOUtilsTestCase
Tests run: 63, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.717 sec
Running org.apache.commons.io.IOCaseTestCase
Tests run: 17, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.146 sec
Running org.apache.commons.io.LineIteratorTestCase
Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.25 sec
Running org.apache.commons.io.FileUtilsCleanDirectoryTestCase
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.175 sec
Running org.apache.commons.io.IOUtilsWriteTestCase
Tests run: 53, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.396 sec
Running org.apache.commons.io.FilenameUtilsWildcardTestCase
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.208 sec
Running org.apache.commons.io.FileUtilsListFilesTestCase
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.16 sec
Running org.apache.commons.io.FileSystemUtilsTestCase
Tests run: 28, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.36 sec
Running org.apache.commons.io.DirectoryWalkerTestCaseJava4
Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.225 sec

Results :

Failed tests:   
testIO_356(org.apache.commons.io.input.CharSequenceInputStreamTest): 
bufferSize=10 dataSize=13: arrays first differed at element [0]; expected:65 
but was:78

Tests run: 984, Failures: 1, Errors: 0, Skipped: 1

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/apache-commons/io/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 1 minute 52 seconds
[INFO] Finished at: Sun Nov 18 08:21:26 UTC 2012
[INFO] Final Memory: 37M/89M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-io-test/rss.xml
- Atom:

Re: [math] Making last iteration data available when iterative algorithms fail to converge (MATH-902)

2012-11-18 Thread Sébastien Brisard

Hi,


2012/11/17 Gilles Sadowski gil...@harfang.homelinux.org

 On Sat, Nov 17, 2012 at 12:34:30PM -0800, Phil Steitz wrote:
  I think MATH-902 makes a reasonable request, but I don't think the
  exception is the right place to communicate last iteration data.
  When iterative algorithms fail to converge and TooManyEvaluations or
  other iteration bounds exceptions are thrown, the request in
  MATH-902 is to make the last iterate available as a field in the
  exception.  My inclination would be to not to do this, but instead
  to adopt the convention that the class doing the iteration should
  maintain last iteration state information.

 I understand the temptation to provide such a facility but it will make
 the implementation more complicated (additional bookkeeping) than necessary
 for the regular case, by which I mean that inputs were passed that don't
 lead to failure.
 Indeed, correct usage rests on the user, who is responsible for providing
 compatible values for maximum number of evaluations and the convergence
 criteria.
 The current design stems from the consideration that is maxEval is
 reached, it means that something has gone wrong: it took more evaluations
 than the _user_ was expecting.
 If this check gets in the way (as suggested by MATH-902), the user can
 always pass Integer.MAX_VALUE, thereby disabling the safe-guard; but he
 must accept that he might wait a long time...

 It would be easier to figure out which approach is correct if we could have
 a concrete use-case.[1]

 The same issue also occurs with iterative linear solvers. I have concrete
use-cases, in this instance. Some of the systems I try to invert are quite
large (as in 128 * 128 * 128 * 6 unknowns). If the system is
ill-conditioned and the requirements on the stopping criterion is too
stringent, then the whole inversion will fail because of the maximum number
of iterations being reached. Now, failure is so brutal (meaning: nothing
is returned) that you can't even know how close the best estimate of the
solution is to the true solution, so you don't even know how to alter the
parameters of your solvers for failure not to happen again. Since these
iterations take a long time, this is a bit annoying.

With iterative solvers, there is a work-around, using the event handling
that is provided, which allows access to the *current* estimate of the
solution.

So I agree with Phil that it would be nice to retrieve the best estimate
of the solution, even if crash occurs. But I also agree with Gilles that
this must be done carefully. All the iterative solvers implemented so far
are almost state-less. The only class variables are related to the stopping
criterion. No data relating to the current system being inverted is stored
as a class variable (and is therefore not accessible). Again, event
handlers might be the way to go, we could add an event which is fired prior
to throwing the failure exception.

Best regards,
Sébastien


Regards,
 Gilles

 [1] There is a similar situation with CMAESOptimizer:
   https://issues.apache.org/jira/browse/MATH-873
 It behaves as the reporter of MATH-902 would like all optimizers to,
 but it changes completely the meaning of maxEval (instead of a
 safe-guard, it becomes a normal termination condition and the user
 must check whether the convergence criteria have been met or not).

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

[GUMP@vmgump]: Project commons-digester3 (in module apache-commons) failed

2012-11-18 Thread Gump

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-digester3 has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 22 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-digester3 :  XML to Java Object Configuration
- commons-digester3-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-digester3-*[0-9T].jar] identifier set to 
project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/srv/gump/public/workspace/apache-commons/digester/pom.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/gump_work/build_apache-commons_commons-digester3.html
Work Name: build_apache-commons_commons-digester3 (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 1 sec
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings 
/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml 
package 
[Working Directory: /srv/gump/public/workspace/apache-commons/digester]
M2_HOME: /opt/maven2
-
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor  svn 
--non-interactive info
[INFO] Working directory: 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildNumber: ?? at timestamp: 1353232494698
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor  svn 
--non-interactive info
[INFO] Working directory: 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 5 source files to 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/classes
[INFO] [bundle:manifest {execution: bundle-manifest}]
[debug] execute contextualize
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/src/test/resources
[INFO] Copying 0 resource to META-INF
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 3 source files to 
/srv/gump/public/workspace/apache-commons/digester/annotations-processor/target/test-classes
@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern=rss/channel)
@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern=rss/channel/image)
@org.apache.commons.digester3.annotations.rules.ObjectCreate(pattern=rss/channel/item)

[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[ERROR] error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule
[INFO] 2 errors 
[INFO] -
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

error: Impossible to generate class 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule: 
Attempt to recreate a file for type 
org.apache.commons.digester3.annotations.processor.GeneratedRulesModule

Re: [math] Making last iteration data available when iterative algorithms fail to converge (MATH-902)

2012-11-18 Thread Luc Maisonobe

Le 18/11/2012 10:53, Sébastien Brisard a écrit :
 Hi,

Hi all,

 
 
 2012/11/17 Gilles Sadowski gil...@harfang.homelinux.org
 
 On Sat, Nov 17, 2012 at 12:34:30PM -0800, Phil Steitz wrote:
 I think MATH-902 makes a reasonable request, but I don't think the
 exception is the right place to communicate last iteration data.
 When iterative algorithms fail to converge and TooManyEvaluations or
 other iteration bounds exceptions are thrown, the request in
 MATH-902 is to make the last iterate available as a field in the
 exception.  My inclination would be to not to do this, but instead
 to adopt the convention that the class doing the iteration should
 maintain last iteration state information.

 I understand the temptation to provide such a facility but it will make
 the implementation more complicated (additional bookkeeping) than necessary
 for the regular case, by which I mean that inputs were passed that don't
 lead to failure.
 Indeed, correct usage rests on the user, who is responsible for providing
 compatible values for maximum number of evaluations and the convergence
 criteria.
 The current design stems from the consideration that is maxEval is
 reached, it means that something has gone wrong: it took more evaluations
 than the _user_ was expecting.
 If this check gets in the way (as suggested by MATH-902), the user can
 always pass Integer.MAX_VALUE, thereby disabling the safe-guard; but he
 must accept that he might wait a long time...

 It would be easier to figure out which approach is correct if we could have
 a concrete use-case.[1]

 The same issue also occurs with iterative linear solvers. I have concrete
 use-cases, in this instance. Some of the systems I try to invert are quite
 large (as in 128 * 128 * 128 * 6 unknowns). If the system is
 ill-conditioned and the requirements on the stopping criterion is too
 stringent, then the whole inversion will fail because of the maximum number
 of iterations being reached. Now, failure is so brutal (meaning: nothing
 is returned) that you can't even know how close the best estimate of the
 solution is to the true solution, so you don't even know how to alter the
 parameters of your solvers for failure not to happen again. Since these
 iterations take a long time, this is a bit annoying.
 
 With iterative solvers, there is a work-around, using the event handling
 that is provided, which allows access to the *current* estimate of the
 solution.
 
 So I agree with Phil that it would be nice to retrieve the best estimate
 of the solution, even if crash occurs. But I also agree with Gilles that
 this must be done carefully. All the iterative solvers implemented so far
 are almost state-less. The only class variables are related to the stopping
 criterion. No data relating to the current system being inverted is stored
 as a class variable (and is therefore not accessible). Again, event
 handlers might be the way to go, we could add an event which is fired prior
 to throwing the failure exception.

I like a lot the idea of registering user event handlers to be called
back by the solver at each iteration. This can be used to only overwrite
better solutions as they are found, but it also has many more usages
like displaying progress. This is what Nikolaus asked for when we
implemented CMAES. I'm not sure about the API though. Either we could
pass many parameters (number of iterations, current point and value) or
simply a reference to the optimizer, and add custom getters for each
optimizers, so the user could retrieve specific information when they
know which optimizer type they use and they can cast the refererence to
call algorithm-specific getters abnout the current state.

We already have something roughly similar to this in the ODE package. We
have both step handlers and events handlers, but they have slightly
differente meanings to what is desired here. Perhaps we should use a
name like IterationHandler to avoid confusion.

best regards,
Luc

 
 Best regards,
 Sébastien
 
 
 Regards,
 Gilles

 [1] There is a similar situation with CMAESOptimizer:
   https://issues.apache.org/jira/browse/MATH-873
 It behaves as the reporter of MATH-902 would like all optimizers to,
 but it changes completely the meaning of maxEval (instead of a
 safe-guard, it becomes a normal termination condition and the user
 must check whether the convergence criteria have been met or not).

 -
 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] Making last iteration data available when iterative algorithms fail to converge (MATH-902)

2012-11-18 Thread Gilles Sadowski

On Sun, Nov 18, 2012 at 10:53:59AM +0100, Sébastien Brisard wrote:
 Hi,
 
 
 2012/11/17 Gilles Sadowski gil...@harfang.homelinux.org
 
  On Sat, Nov 17, 2012 at 12:34:30PM -0800, Phil Steitz wrote:
   I think MATH-902 makes a reasonable request, but I don't think the
   exception is the right place to communicate last iteration data.
   When iterative algorithms fail to converge and TooManyEvaluations or
   other iteration bounds exceptions are thrown, the request in
   MATH-902 is to make the last iterate available as a field in the
   exception.  My inclination would be to not to do this, but instead
   to adopt the convention that the class doing the iteration should
   maintain last iteration state information.
 
  I understand the temptation to provide such a facility but it will make
  the implementation more complicated (additional bookkeeping) than necessary
  for the regular case, by which I mean that inputs were passed that don't
  lead to failure.
  Indeed, correct usage rests on the user, who is responsible for providing
  compatible values for maximum number of evaluations and the convergence
  criteria.
  The current design stems from the consideration that is maxEval is
  reached, it means that something has gone wrong: it took more evaluations
  than the _user_ was expecting.
  If this check gets in the way (as suggested by MATH-902), the user can
  always pass Integer.MAX_VALUE, thereby disabling the safe-guard; but he
  must accept that he might wait a long time...
 
  It would be easier to figure out which approach is correct if we could have
  a concrete use-case.[1]
 
  The same issue also occurs with iterative linear solvers. I have concrete
 use-cases, in this instance. Some of the systems I try to invert are quite
 large (as in 128 * 128 * 128 * 6 unknowns). If the system is
 ill-conditioned and the requirements on the stopping criterion is too
 stringent, then the whole inversion will fail because of the maximum number
 of iterations being reached. Now, failure is so brutal (meaning: nothing
 is returned) that you can't even know how close the best estimate of the
 solution is to the true solution, so you don't even know how to alter the
 parameters of your solvers for failure not to happen again. Since these
 iterations take a long time, this is a bit annoying.
 
 With iterative solvers, there is a work-around, using the event handling
 that is provided, which allows access to the *current* estimate of the
 solution.
 
 So I agree with Phil that it would be nice to retrieve the best estimate
 of the solution, even if crash occurs. But I also agree with Gilles that
 this must be done carefully. All the iterative solvers implemented so far
 are almost state-less. The only class variables are related to the stopping
 criterion. No data relating to the current system being inverted is stored
 as a class variable (and is therefore not accessible). Again, event
 handlers might be the way to go, we could add an event which is fired prior
 to throwing the failure exception.

I think that a framework is indeed the flexible way but this is a lot of
refactoring and not easy to get right as current attempts have shown.
My preference is still to allow extensive logging in CM, as this helps with
the presented uses-cases without getting in the way at all, and it's trivial
to add.

I'll try and to see the implications of just adding a getCurrentBest()
method to the optimizers API.


Best,
Gilles

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

[GUMP@vmgump]: Project commons-chain2 (in module apache-commons) failed

2012-11-18 Thread Gump

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-chain2 has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 213 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-chain2 :  GoF Chain of Responsibility pattern


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-chain2-*[0-9T].jar] identifier set to project 
name
 -DEBUG- Sole pom output [pom.xml] identifier set to project name
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/chain/pom.xml
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/gump_work/build_apache-commons_commons-chain2.html
Work Name: build_apache-commons_commons-chain2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 59 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/chain]
M2_HOME: /opt/maven2
-
[INFO] Building war: 
/srv/gump/public/workspace/apache-commons/chain/apps/cookbook-examples/target/chain-cookbook-examples-2.0-SNAPSHOT.war
[INFO] 
[INFO] Building Apache Commons Chain :: Distribution Packages
[INFO]task-segment: [package]
[INFO] 
[INFO] snapshot org.apache.commons:commons-chain2-configuration:2.0-SNAPSHOT: 
checking for updates from apache.snapshots
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.pom
[INFO] Unable to find resource 
'org.apache.commons:commons-chain2-configuration:pom:2.0-SNAPSHOT' in 
repository apache.snapshots (http://repository.apache.org/snapshots)
Downloading: 
http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.jar
[INFO] Unable to find resource 
'org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT' in 
repository apache.snapshots (http://repository.apache.org/snapshots)
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve artifact.

Missing:
--
1) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.commons 
-DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT 
-Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.commons 
-DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT 
-Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT
2) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT

--
1 required artifact is missing.

for artifact: 
  org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT

from the specified remote repositories:
  gump-central (http://localhost:8192/maven2),
  gump-apache.snapshots (http://localhost:8192/repo/m2-snapshot-repository)



[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 57 seconds
[INFO] Finished at: Sun Nov 18 11:03:47 UTC 2012
[INFO] Final Memory: 114M/241M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/rss.xml
- Atom:

[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed

2012-11-18 Thread Gump

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-proxy-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 27 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-proxy-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html
Work Name: build_apache-commons_commons-proxy-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 15 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/proxy]
M2_HOME: /opt/maven2
-
Running org.apache.commons.proxy.factory.util.TestMethodSignature
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec

Results :

Tests in error: 
  
testMethodInvocationImplementation(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  
testSerialization(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  
testMethodInterception(org.apache.commons.proxy.interceptor.TestMethodInterceptorAdapter)
  testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker)
  
testMethodInvocation(org.apache.commons.proxy.invoker.TestInvocationHandlerAdapter)
  
testInterceptorEquals(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerEquals(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerWithSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testProxiesWithClashingFinalMethodInSuperclass(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerHashCode(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testBooleanInterceptorParameter(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testChangingArguments(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testCreateInterceptorProxy(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptingProxyClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptingProxySerializable(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorProxyWithCheckedException(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorProxyWithUncheckedException(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxy(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxyClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInvokerProxySerializable(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationClassCaching(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationDuplicateMethods(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testMethodInvocationImplementation(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testInterceptorHashCode(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  
testWithNonAccessibleTargetType(org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory)
  testCreateNullObject(org.apache.commons.proxy.TestProxyUtils)
  testCreateNullObjectWithClassLoader(org.apache.commons.proxy.TestProxyUtils)

Tests run: 179, Failures: 0, Errors: 28, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There

[GUMP@vmgump]: Project commons-dbutils (in module apache-commons) failed

2012-11-18 Thread Gump

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-dbutils has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 191 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbutils :  Commons DbUtils


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbutils-*[0-9T].jar] identifier set to 
project name
 -INFO- Optional dependency mockito failed with reason build failed
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/dbutils/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports
 -WARNING- No directory 
[/srv/gump/public/workspace/apache-commons/dbutils/target/surefire-reports]
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbutils/gump_work/build_apache-commons_commons-dbutils.html
Work Name: build_apache-commons_commons-dbutils (Type: Build)
Work ended in a state of : Failed
Elapsed: 16 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/apache-commons/dbutils/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/apache-commons/dbutils]
M2_HOME: /opt/maven2
-
1K downloaded  (mockito-core-1.9.0.pom)
Downloading: 
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.pom
479b downloaded  (hamcrest-all-1.1.pom)
Downloading: 
http://localhost:8192/maven2/org/mockito/mockito-core/1.9.0/mockito-core-1.9.0.jar
Downloading: 
http://localhost:8192/maven2/org/hamcrest/hamcrest-all/1.1/hamcrest-all-1.1.jar
1381K downloaded  (mockito-core-1.9.0.jar)
273K downloaded  (hamcrest-all-1.1.jar)
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks

main:
 [copy] Copying 2 files to 
/srv/gump/public/workspace/apache-commons/dbutils/target/apidocs/META-INF
[INFO] Executed tasks
[WARNING] The parameter expression: 'project.build.resources' used in mojo: 
'process' has been deprecated. Use 'project.resources' instead.
[INFO] [remote-resources:process {execution: default}]
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/dbutils  svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildNumber: ?? at timestamp: 1353238784874
[INFO] Executing: /bin/sh -c cd 
/srv/gump/public/workspace/apache-commons/dbutils  svn --non-interactive info
[INFO] Working directory: /srv/gump/public/workspace/apache-commons/dbutils
[INFO] Storing buildScmBranch: UNKNOWN_BRANCH
[debug] execute contextualize
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'iso-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/srv/gump/public/workspace/apache-commons/dbutils/src/main/resources
[INFO] Copying 2 resources to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 29 source files to 
/srv/gump/public/workspace/apache-commons/dbutils/target/classes
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
 error: DriverProxy is not abstract and does not override abstract method 
getParentLogger() in Driver
[INFO] 1 error
[INFO] -
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure
/srv/gump/public/workspace/apache-commons/dbutils/src/main/java/org/apache/commons/dbutils/DbUtils.java:[334,25]
 error: DriverProxy is not abstract and does not override abstract method 
getParentLogger() in Driver

[INFO] 
[INFO] For more information, run Maven

[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed

2012-11-18 Thread Gump

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-scxml-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 196 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-scxml-test :  Apache Commons


Full details are available at:

http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -WARNING- Overriding Maven settings: 
[/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html
Work Name: build_apache-commons_commons-scxml-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 23 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -Dsimplelog.defaultlog=info 
--settings 
/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test 
[Working Directory: /srv/gump/public/workspace/apache-commons/scxml]
M2_HOME: /opt/maven2
-
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1/e1.2
[INFO] SimpleSCXMLListener - /s2/s2.1
[INFO] SimpleSCXMLListener - /s2
[INFO] SimpleSCXMLListener - transition (event = s2.1.done, cond = null, from = 
/s2, to = /s3)
[INFO] SimpleSCXMLListener - /s3
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.271 sec
Running org.apache.commons.scxml.issues.Issue64Test
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: somedata
[INFO] SCXMLSemantics - null: *somedata
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
[WARN] SCXMLParser - Ignoring element misplaced in namespace 
http://www.w3.org/2005/07/scxml; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:30:21
 and digester match scxml/datamodel/misplaced
[WARN] SCXMLParser - Ignoring element foo in namespace 
http://www.w3.org/2005/07/scxml; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:36:19
 and digester match scxml/state/onentry/foo
[WARN] SCXMLParser - Ignoring element bar in namespace 
http://my.foo.example/; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:37:22
 and digester match scxml/state/onentry/bar
[WARN] SCXMLParser - Ignoring element datamodel in namespace 
http://www.w3.org/2005/07/scxml; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:41:21
 and digester match scxml/state/transition/datamodel
[WARN] SCXMLParser - Ignoring element data in namespace 
http://www.w3.org/2005/07/scxml; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:42:41
 and digester match scxml/state/transition/datamodel/data
[WARN] SCXMLParser - Ignoring element baz in namespace 
http://my.foo.example/; at 
file:/srv/gump/public/workspace/apache-commons/scxml/target/test-classes/org/apache/commons/scxml/issues/issue64-02.xml:49:14
 and digester match scxml/baz
[INFO] SCXMLSemantics - null: Begin transition bug test ...
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SimpleSCXMLListener - /tranbug
[INFO] SCXMLSemantics - null: null
[WARN] SimpleErrorReporter - EXPRESSION_ERROR (eval(''*' + dummy'):null): 
[INFO] SimpleSCXMLListener - transition (event = show.bug, cond = null, from = 
/tranbug, to = /end)
[INFO] SimpleSCXMLListener - /end
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.061 sec

Results :

Failed tests: 
  testCustomActionCallbacks(org.apache.commons.scxml.model.CustomActionTest)

Tests run: 229, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO]

[continuum] BUILD FAILURE: Apache Commons - Apache Commons Digester - Build using Java 1.6

2012-11-18 Thread Continuum@vmbuild

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=25250projectId=75

Build statistics:
  State: Failed
  Previous State: Failed
  Started at: Sun 18 Nov 2012 17:20:06 +
  Finished at: Sun 18 Nov 2012 17:21:05 +
  Total time: 59s
  Build Trigger: Schedule
  Build Number: 165
  Exit code: 1
  Building machine hostname: vmbuild
  Operating system : Linux(unknown)
  Java Home version : 
  java version 1.6.0_30
  Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
  Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)

  Builder version :
  Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
  Java version: 1.6.0_30
  Java home: /usr/lib/jvm/jdk1.6.0_30/jre
  Default locale: en_US, platform encoding: ANSI_X3.4-1968
  OS name: linux version: 2.6.32-41-server arch: amd64 Family: 
unix


SCM Changes:

Changed: simonetripodi @ Sun 18 Nov 2012 17:11:58 +
Comment: [DIGESTER-172] Even with custom ErrorHandler, SAX errors are still 
written to stderr - patch provided by Ivan Diana
Files changed:
  
/commons/proper/digester/trunk/core/src/main/java/org/apache/commons/digester3/Digester.java
 ( 1410929 )
  
/commons/proper/digester/trunk/core/src/test/java/org/apache/commons/digester3/ErrorHandlerTest.java
 ( 1410929 )
  
/commons/proper/digester/trunk/core/src/test/resources/org/apache/commons/digester3/Test-digester-172-wrong.xml
 ( 1410929 )
  /commons/proper/digester/trunk/src/changes/changes.xml ( 1410929 )


Dependencies Changes:

No dependencies changed



Build Definition:

POM filename: pom.xml
Goals: clean deploy   
Arguments: --batch-mode -Pjava-1.6 -Dgpg.skip -Prelease
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Maven 2.2.1
Description: Build using Java 1.6


Test Summary:

Tests: 211
Failures: 0
Errors: 0
Success Rate: 100
Total time: 3.2880003





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

Re: [math] Making last iteration data available when iterative algorithms fail to converge (MATH-902)

2012-11-18 Thread Gilles Sadowski

On Sun, Nov 18, 2012 at 11:19:14AM +0100, Luc Maisonobe wrote:
 Le 18/11/2012 10:53, Sébastien Brisard a écrit :
  Hi,
 
 Hi all,
 
  
  
  2012/11/17 Gilles Sadowski gil...@harfang.homelinux.org
  
  On Sat, Nov 17, 2012 at 12:34:30PM -0800, Phil Steitz wrote:
  I think MATH-902 makes a reasonable request, but I don't think the
  exception is the right place to communicate last iteration data.
  When iterative algorithms fail to converge and TooManyEvaluations or
  other iteration bounds exceptions are thrown, the request in
  MATH-902 is to make the last iterate available as a field in the
  exception.  My inclination would be to not to do this, but instead
  to adopt the convention that the class doing the iteration should
  maintain last iteration state information.
 
  I understand the temptation to provide such a facility but it will make
  the implementation more complicated (additional bookkeeping) than necessary
  for the regular case, by which I mean that inputs were passed that don't
  lead to failure.
  Indeed, correct usage rests on the user, who is responsible for providing
  compatible values for maximum number of evaluations and the convergence
  criteria.
  The current design stems from the consideration that is maxEval is
  reached, it means that something has gone wrong: it took more evaluations
  than the _user_ was expecting.
  If this check gets in the way (as suggested by MATH-902), the user can
  always pass Integer.MAX_VALUE, thereby disabling the safe-guard; but he
  must accept that he might wait a long time...
 
  It would be easier to figure out which approach is correct if we could have
  a concrete use-case.[1]
 
  The same issue also occurs with iterative linear solvers. I have concrete
  use-cases, in this instance. Some of the systems I try to invert are quite
  large (as in 128 * 128 * 128 * 6 unknowns). If the system is
  ill-conditioned and the requirements on the stopping criterion is too
  stringent, then the whole inversion will fail because of the maximum number
  of iterations being reached. Now, failure is so brutal (meaning: nothing
  is returned) that you can't even know how close the best estimate of the
  solution is to the true solution, so you don't even know how to alter the
  parameters of your solvers for failure not to happen again. Since these
  iterations take a long time, this is a bit annoying.
  
  With iterative solvers, there is a work-around, using the event handling
  that is provided, which allows access to the *current* estimate of the
  solution.
  
  So I agree with Phil that it would be nice to retrieve the best estimate
  of the solution, even if crash occurs. But I also agree with Gilles that
  this must be done carefully. All the iterative solvers implemented so far
  are almost state-less. The only class variables are related to the stopping
  criterion. No data relating to the current system being inverted is stored
  as a class variable (and is therefore not accessible). Again, event
  handlers might be the way to go, we could add an event which is fired prior
  to throwing the failure exception.
 
 I like a lot the idea of registering user event handlers to be called
 back by the solver at each iteration. This can be used to only overwrite
 better solutions as they are found, but it also has many more usages
 like displaying progress. This is what Nikolaus asked for when we
 implemented CMAES. I'm not sure about the API though. Either we could
 pass many parameters (number of iterations, current point and value) or
 simply a reference to the optimizer, and add custom getters for each
 optimizers, so the user could retrieve specific information when they
 know which optimizer type they use and they can cast the refererence to
 call algorithm-specific getters abnout the current state.
 
 We already have something roughly similar to this in the ODE package. We
 have both step handlers and events handlers, but they have slightly
 differente meanings to what is desired here. Perhaps we should use a
 name like IterationHandler to avoid confusion.

I don't like what currently exists in CMAESOptimizer just because it is
ad-hoc code. The justification was that, for scientific purpose, it is
necessary to be able to follow the behaviour of the algorithm. I totally
agree with the latter statement, but I do not agree that every
implementation should do it in its own way.
And, more importantly, if we put this justification forward, there is a much
straightforward solution: logging. Logging should be available before
sinking into littering the useful code with infrastructure statements
whose only purpose is to give real-time information.
As it is, we can probably agree that CM is not suitable for analysing an
algorithm's behaviour. But, again, is it the purpose? I think not (from my
interpretation of stated goals): users call CM as a black box, and can only
assume that given some input, it will provide the correct (= expected)
output.


Best

Re: [math] Making last iteration data available when iterative algorithms fail to converge (MATH-902)

2012-11-18 Thread Sébastien Brisard

Hi,


2012/11/18 Gilles Sadowski gil...@harfang.homelinux.org

 On Sun, Nov 18, 2012 at 11:19:14AM +0100, Luc Maisonobe wrote:
  Le 18/11/2012 10:53, Sébastien Brisard a écrit :
   Hi,
 
  Hi all,
 
  
  
   2012/11/17 Gilles Sadowski gil...@harfang.homelinux.org
  
   On Sat, Nov 17, 2012 at 12:34:30PM -0800, Phil Steitz wrote:
   I think MATH-902 makes a reasonable request, but I don't think the
   exception is the right place to communicate last iteration data.
   When iterative algorithms fail to converge and TooManyEvaluations or
   other iteration bounds exceptions are thrown, the request in
   MATH-902 is to make the last iterate available as a field in the
   exception.  My inclination would be to not to do this, but instead
   to adopt the convention that the class doing the iteration should
   maintain last iteration state information.
  
   I understand the temptation to provide such a facility but it will
 make
   the implementation more complicated (additional bookkeeping) than
 necessary
   for the regular case, by which I mean that inputs were passed that
 don't
   lead to failure.
   Indeed, correct usage rests on the user, who is responsible for
 providing
   compatible values for maximum number of evaluations and the
 convergence
   criteria.
   The current design stems from the consideration that is maxEval is
   reached, it means that something has gone wrong: it took more
 evaluations
   than the _user_ was expecting.
   If this check gets in the way (as suggested by MATH-902), the user can
   always pass Integer.MAX_VALUE, thereby disabling the safe-guard;
 but he
   must accept that he might wait a long time...
  
   It would be easier to figure out which approach is correct if we
 could have
   a concrete use-case.[1]
  
   The same issue also occurs with iterative linear solvers. I have
 concrete
   use-cases, in this instance. Some of the systems I try to invert are
 quite
   large (as in 128 * 128 * 128 * 6 unknowns). If the system is
   ill-conditioned and the requirements on the stopping criterion is too
   stringent, then the whole inversion will fail because of the maximum
 number
   of iterations being reached. Now, failure is so brutal (meaning:
 nothing
   is returned) that you can't even know how close the best estimate of
 the
   solution is to the true solution, so you don't even know how to alter
 the
   parameters of your solvers for failure not to happen again. Since these
   iterations take a long time, this is a bit annoying.
  
   With iterative solvers, there is a work-around, using the event
 handling
   that is provided, which allows access to the *current* estimate of the
   solution.
  
   So I agree with Phil that it would be nice to retrieve the best
 estimate
   of the solution, even if crash occurs. But I also agree with Gilles
 that
   this must be done carefully. All the iterative solvers implemented so
 far
   are almost state-less. The only class variables are related to the
 stopping
   criterion. No data relating to the current system being inverted is
 stored
   as a class variable (and is therefore not accessible). Again, event
   handlers might be the way to go, we could add an event which is fired
 prior
   to throwing the failure exception.
 
  I like a lot the idea of registering user event handlers to be called
  back by the solver at each iteration. This can be used to only overwrite
  better solutions as they are found, but it also has many more usages
  like displaying progress. This is what Nikolaus asked for when we
  implemented CMAES. I'm not sure about the API though. Either we could
  pass many parameters (number of iterations, current point and value) or
  simply a reference to the optimizer, and add custom getters for each
  optimizers, so the user could retrieve specific information when they
  know which optimizer type they use and they can cast the refererence to
  call algorithm-specific getters abnout the current state.
 

The first solution is the one used in IterativeSolverEvent, which extends
IterationEvent. I don't like the second option (using custom getters for
each optimizers). As I said, iterative linear solvers do *not* hold
information relating to the system currently being solved. It seems that
things are a bit different in optimizers, but if we assume that all
interesting information can be retrieved from the object which actually
performs the iterations, I think we lose flexibility.

At the moment, for iterative linear solvers, saving the last iterate can
only be done in an event handler. For example, in the corresponding
IterationListener, you could use e.getSolution() each time
iterationPerformed(e) is called. This is potentially costly, though, since
this returns a copy of the (potentially large) vector x. I think that we
could add a method to IterationListener, e.g. aboutToFail(e) (for lack of a
better name). Then a copy of the current solution would be taken only here.
What do you think? I don't know how

Re: [math] Making last iteration data available when iterative algorithms fail to converge (MATH-902)

2012-11-18 Thread Phil Steitz

On 11/18/12 11:00 AM, Sébastien Brisard wrote:
 Hi,


 2012/11/18 Gilles Sadowski gil...@harfang.homelinux.org

 On Sun, Nov 18, 2012 at 11:19:14AM +0100, Luc Maisonobe wrote:
 Le 18/11/2012 10:53, Sébastien Brisard a écrit :
 Hi,
 Hi all,


 2012/11/17 Gilles Sadowski gil...@harfang.homelinux.org

 On Sat, Nov 17, 2012 at 12:34:30PM -0800, Phil Steitz wrote:
 I think MATH-902 makes a reasonable request, but I don't think the
 exception is the right place to communicate last iteration data.
 When iterative algorithms fail to converge and TooManyEvaluations or
 other iteration bounds exceptions are thrown, the request in
 MATH-902 is to make the last iterate available as a field in the
 exception.  My inclination would be to not to do this, but instead
 to adopt the convention that the class doing the iteration should
 maintain last iteration state information.
 I understand the temptation to provide such a facility but it will
 make
 the implementation more complicated (additional bookkeeping) than
 necessary
 for the regular case, by which I mean that inputs were passed that
 don't
 lead to failure.
 Indeed, correct usage rests on the user, who is responsible for
 providing
 compatible values for maximum number of evaluations and the
 convergence
 criteria.
 The current design stems from the consideration that is maxEval is
 reached, it means that something has gone wrong: it took more
 evaluations
 than the _user_ was expecting.
 If this check gets in the way (as suggested by MATH-902), the user can
 always pass Integer.MAX_VALUE, thereby disabling the safe-guard;
 but he
 must accept that he might wait a long time...

 It would be easier to figure out which approach is correct if we
 could have
 a concrete use-case.[1]

 The same issue also occurs with iterative linear solvers. I have
 concrete
 use-cases, in this instance. Some of the systems I try to invert are
 quite
 large (as in 128 * 128 * 128 * 6 unknowns). If the system is
 ill-conditioned and the requirements on the stopping criterion is too
 stringent, then the whole inversion will fail because of the maximum
 number
 of iterations being reached. Now, failure is so brutal (meaning:
 nothing
 is returned) that you can't even know how close the best estimate of
 the
 solution is to the true solution, so you don't even know how to alter
 the
 parameters of your solvers for failure not to happen again. Since these
 iterations take a long time, this is a bit annoying.

 With iterative solvers, there is a work-around, using the event
 handling
 that is provided, which allows access to the *current* estimate of the
 solution.

 So I agree with Phil that it would be nice to retrieve the best
 estimate
 of the solution, even if crash occurs. But I also agree with Gilles
 that
 this must be done carefully. All the iterative solvers implemented so
 far
 are almost state-less. The only class variables are related to the
 stopping
 criterion. No data relating to the current system being inverted is
 stored
 as a class variable (and is therefore not accessible). Again, event
 handlers might be the way to go, we could add an event which is fired
 prior
 to throwing the failure exception.
 I like a lot the idea of registering user event handlers to be called
 back by the solver at each iteration. This can be used to only overwrite
 better solutions as they are found, but it also has many more usages
 like displaying progress. This is what Nikolaus asked for when we
 implemented CMAES. I'm not sure about the API though. Either we could
 pass many parameters (number of iterations, current point and value) or
 simply a reference to the optimizer, and add custom getters for each
 optimizers, so the user could retrieve specific information when they
 know which optimizer type they use and they can cast the refererence to
 call algorithm-specific getters abnout the current state.

 The first solution is the one used in IterativeSolverEvent, which extends
 IterationEvent. I don't like the second option (using custom getters for
 each optimizers). As I said, iterative linear solvers do *not* hold
 information relating to the system currently being solved. It seems that
 things are a bit different in optimizers, but if we assume that all
 interesting information can be retrieved from the object which actually
 performs the iterations, I think we lose flexibility.

 At the moment, for iterative linear solvers, saving the last iterate can
 only be done in an event handler. For example, in the corresponding
 IterationListener, you could use e.getSolution() each time
 iterationPerformed(e) is called. This is potentially costly, though, since
 this returns a copy of the (potentially large) vector x. I think that we
 could add a method to IterationListener, e.g. aboutToFail(e) (for lack of a
 better name). Then a copy of the current solution would be taken only here.
 What do you think? I don't know how applicable to optimizers that would be,
 but it would be fairly

Re: [math] Making last iteration data available when iterative algorithms fail to converge (MATH-902)

2012-11-18 Thread Gilles Sadowski

   [...]
  I like a lot the idea of registering user event handlers to be called
  back by the solver at each iteration. This can be used to only overwrite
  better solutions as they are found, but it also has many more usages
  like displaying progress. This is what Nikolaus asked for when we
  implemented CMAES. I'm not sure about the API though. Either we could
  pass many parameters (number of iterations, current point and value) or
  simply a reference to the optimizer, and add custom getters for each
  optimizers, so the user could retrieve specific information when they
  know which optimizer type they use and they can cast the refererence to
  call algorithm-specific getters abnout the current state.
 
  The first solution is the one used in IterativeSolverEvent, which extends
  IterationEvent. I don't like the second option (using custom getters for
  each optimizers). As I said, iterative linear solvers do *not* hold
  information relating to the system currently being solved. It seems that
  things are a bit different in optimizers, but if we assume that all
  interesting information can be retrieved from the object which actually
  performs the iterations, I think we lose flexibility.
 
  At the moment, for iterative linear solvers, saving the last iterate can
  only be done in an event handler. For example, in the corresponding
  IterationListener, you could use e.getSolution() each time
  iterationPerformed(e) is called. This is potentially costly, though, since
  this returns a copy of the (potentially large) vector x. I think that we
  could add a method to IterationListener, e.g. aboutToFail(e) (for lack of a
  better name). Then a copy of the current solution would be taken only here.
  What do you think? I don't know how applicable to optimizers that would be,
  but it would be fairly straightforward for iterative linear solvers.
 
 
  We already have something roughly similar to this in the ODE package. We
  have both step handlers and events handlers, but they have slightly
  differente meanings to what is desired here. Perhaps we should use a
  name like IterationHandler to avoid confusion.
  I don't like what currently exists in CMAESOptimizer just because it is
  ad-hoc code. The justification was that, for scientific purpose, it is
  necessary to be able to follow the behaviour of the algorithm. I totally
  agree with the latter statement, but I do not agree that every
  implementation should do it in its own way.
  And, more importantly, if we put this justification forward, there is a
  much
  straightforward solution: logging. Logging should be available before
  sinking into littering the useful code with infrastructure statements
  whose only purpose is to give real-time information.
  As it is, we can probably agree that CM is not suitable for analysing an
  algorithm's behaviour. But, again, is it the purpose? I think not (from my
  interpretation of stated goals): users call CM as a black box, and can only
  assume that given some input, it will provide the correct (= expected)
  output.
 
  Yes and no. If each iteration of the algorithm is very long, then the
  ability of monitoring the iterations is very useful -- not only from an
  academic point of view, even if I think this is also important, as there is
  no equivalent to CM with these academic facilities you do not seem to like.
  So I would say: the main purpose of CM is not the analysis of an algo.
  However, if that's not too much of a hassle, opening the algos is a plus
  which we should not reject. I think event handlers offer this flexibility.
 
  You mentioned logging. I was not aware of logging in CM, or even on any
  consensus about logging at all. I'm sorry if this is a silly question, but
  what exactly do you have in mind?
 
 One way to look at this is that logging is what a client app can
 choose to do when it gets an event that it wants to log from
 [math].  I agree that we should try to do two things to make this
 easier for users of [math]:
 
 0) expose properties that can be interrogated at run time that users
 may wish to observe and log or otherwise persist
 1) design appropriate event listener support into the library
 
 The current discussion was started by a user request for an instance
 of problem 0).  We have done some experimenting with 1).  I think it
 is better to continue that than to add logging (and dependency on
 logback or somesuch) to the code.  If we give users access to the
 properties and events they need, they can do their own logging.

I do not hold the same view of the purpose of logging (or maybe I missed a
point here). IMO, the primary goal of logging is to trace the behaviour of
a code in order to ensure that an algorithm behaves as expected. I admit
that it is neither necessary nor sufficient to prove correctness: it is just
a simple tool that usually allows to figure out what is going wrong. [In
debugging CM, I guess that we all resorted to the poor man's logging:

Re: [math] correlation analysis with NaNs

2012-11-18 Thread Thomas Neidhart

On 11/09/2012 11:14 PM, Phil Steitz wrote:
 On 11/9/12 12:18 AM, Thomas Neidhart wrote:
 On Thu, Nov 8, 2012 at 7:21 PM, Phil Steitz phil.ste...@gmail.com wrote:

 On 11/8/12 9:44 AM, Phil Steitz wrote:
 On 11/8/12 8:23 AM, Gilles Sadowski wrote:
 On Thu, Nov 08, 2012 at 05:00:52PM +0100, Thomas Neidhart wrote:
 On 11/08/2012 02:01 PM, Sébastien Brisard wrote:
 Hi,

 2012/11/8 Gilles Sadowski gil...@harfang.homelinux.org:
 On Thu, Nov 08, 2012 at 09:39:00AM +0100, Thomas Neidhart wrote:
 Hi Patrick,

 On 11/07/2012 04:37 PM, Patrick Meyer wrote:
 I agree that it would be nice to have a constructor that allows
 you to
 specific the ranking algorithm only.
 +1 - patches welcome.
 As far as NaN and the Spearman correlation, maybe we should add a
 default
 strategy of NaNStrategy.FAIL so that an exception would occur if
 any NaN is
 encountered. R uses this treatment of missing data and forces
 users to
 choose how to handle it. If we implemented something like listwise
 or
 pairwise deletion it could be used in other classes too. As such,
 treatment
 of missing data should be part of a larger discussion and handled
 in a more
 comprehensive and systematic way.
 +1 to develop a strategy for representing how to represent and
 handle missing data (see below)
 I think this additional option makes sense, but I forward this
 discussion to the dev mailing list where it is better suited.
 I'm wary of having CM handle missing data.
 For one thing we'd have to define a convention to represent
 missing data.
 There is no good way to do that in Java. Using NaN for this purpose
 in a
 low-level library is not a good idea IMHO.

 I agree with Gilles, here. If I remember correctly, R has a special
 value NA, or something similar, which differs from NaN.
 Then, any convention might not be
 suitable for some user applications, which would lead such an
 application's
 developer to filter the data anyway in order to change his
 representation to
 CM's representation. Rather that calling two redundant filtering
 codes, I'd
 rather assume that CM gets a clean input on which its algorithm can
 operate.
 As usual, the input is subjected to precondition checks, and
 exceptions are
 thrown if the data is not clean enough.

 In summary: data validation (in the sense of discarding input)
 should not be
 done _before_ calling CM routines.

 +1.
 ok, I am now confused. First you say that CM should not be involved in
 data cleaning, but then you state that data validation should not be
 done before calling CM? May be there is a *not* too much?
 Yes, you are right: I wrote the opposite of what I meant.
 ---
   In summary: data validation (in the sense of discarding input) should
   be done _before_ calling CM routines.
 ---

 I think the proposition from Patrick was to exactly do that: throw an
 exception if such invalid data is encountered (NaNStrategy.FAIL).

 The other thing is, that the NaNStrategy.REMOVED is broken, so either
 we
 fix is or deprecate it.
 That we should fix.  Please open a JIRA for this.  I assume you are
 talking about the implementation in NaturalRanking.
 +1
 [I mean (I think): If people rely on CM's removal of NaNs, we could fix
 it.
 However, if nobody could actually rely on this feature because it is
 broken,
 I'd prefer to remove it.]
 There are two issues here.  One is specific to ranking algorithms.
 To be well-defined, a RankingAlgorithm needs a NaNStrategy, since
 the result has to be a total ordering.  The NaNStrategy.REMOVED
 strategy is intended to represent removal of NaNs from the data to
 be ordered.  If it is not implemented correctly in NaturalRanking or
 other rankings that is a bug and needs to be fixed.
 Sorry, I just reread Patrick's original mail.  IIUC, there is
 nothing wrong with the implementation of NaNStrategy.REMOVED in
 NaturalRanking or other implemented rankings.  The problem is how
 the Spearman's impl handles it.  That is indeed a bug in Spearman's
 impl that should be fixed.  The correct fix is to throw out the
 corresponding entry in the second array when REMOVED is the
 configured NaNStrategy.  I agree with Patrick that adding .FAIL and
 setting that as the default is a good idea.  Patches welcome.
 The second issue is the more general one of how to represent and
 handle missing data.  I have always seen that as a limitation that
 we would eventually address on an algorithm by algorithm basis.
 Different algorithms can be configured to do different things when
 missing data are encountered.  It is not always possible or
 desirable to preprocess the data to eliminate or impute missing
 data.  Saying that we are just not going to deal with it is a
 limitation that I don't think we should impose.  I am would like to
 hear others' ideas about good ways to model missing data in Java.
 Hi Phil,

 ok I have created three new issues:

  * MATH-891
  * MATH-892
  * MATH-893
 
 Thanks!

 Regarding the NaNStrategy.REMOVED, I think it will be necessary to adjust
 the RankingAlgorithm

Re: [math] Making last iteration data available when iterative algorithms fail to converge (MATH-902)

2012-11-18 Thread Gilles Sadowski

  [...]
  
  So I agree with Phil that it would be nice to retrieve the best estimate
  of the solution, even if crash occurs. But I also agree with Gilles that
  this must be done carefully. All the iterative solvers implemented so far
  are almost state-less. The only class variables are related to the stopping
  criterion. No data relating to the current system being inverted is stored
  as a class variable (and is therefore not accessible). Again, event
  handlers might be the way to go, we could add an event which is fired prior
  to throwing the failure exception.
 
 I think that a framework is indeed the flexible way but this is a lot of
 refactoring and not easy to get right as current attempts have shown.
 My preference is still to allow extensive logging in CM, as this helps with
 the presented uses-cases without getting in the way at all, and it's trivial
 to add.
 
 I'll try and to see the implications of just adding a getCurrentBest()
 method to the optimizers API.

Would it be OK to record one evaluated point per iteration?
[That seems to be a relatively non-intrusive change, but the value could
either be null or be worse than the starting point.]

Ensuring that the current best will always be returned entails changes
that will obscure the code: every call to computeObjectiveValue must be
enclosed in try/catch, catching the exception, setting the current best
then rethrowing. I still have the strong impression that it's working around
the current design (which is based on the user's knowing how to choose
good input values and exceptions indicating that it didn't work out.)


Best,
Gilles

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

Re: [math] correlation analysis with NaNs

2012-11-18 Thread Gilles Sadowski

On Sun, Nov 18, 2012 at 11:01:18PM +0100, Thomas Neidhart wrote:
 On 11/09/2012 11:14 PM, Phil Steitz wrote:
  On 11/9/12 12:18 AM, Thomas Neidhart wrote:
  On Thu, Nov 8, 2012 at 7:21 PM, Phil Steitz phil.ste...@gmail.com wrote:
 
  On 11/8/12 9:44 AM, Phil Steitz wrote:
  On 11/8/12 8:23 AM, Gilles Sadowski wrote:
  On Thu, Nov 08, 2012 at 05:00:52PM +0100, Thomas Neidhart wrote:
  On 11/08/2012 02:01 PM, Sébastien Brisard wrote:
  Hi,
 
  2012/11/8 Gilles Sadowski gil...@harfang.homelinux.org:
  On Thu, Nov 08, 2012 at 09:39:00AM +0100, Thomas Neidhart wrote:
  Hi Patrick,
 
  On 11/07/2012 04:37 PM, Patrick Meyer wrote:
  I agree that it would be nice to have a constructor that allows
  you to
  specific the ranking algorithm only.
  +1 - patches welcome.
  As far as NaN and the Spearman correlation, maybe we should add a
  default
  strategy of NaNStrategy.FAIL so that an exception would occur if
  any NaN is
  encountered. R uses this treatment of missing data and forces
  users to
  choose how to handle it. If we implemented something like listwise
  or
  pairwise deletion it could be used in other classes too. As such,
  treatment
  of missing data should be part of a larger discussion and handled
  in a more
  comprehensive and systematic way.
  +1 to develop a strategy for representing how to represent and
  handle missing data (see below)
  I think this additional option makes sense, but I forward this
  discussion to the dev mailing list where it is better suited.
  I'm wary of having CM handle missing data.
  For one thing we'd have to define a convention to represent
  missing data.
  There is no good way to do that in Java. Using NaN for this purpose
  in a
  low-level library is not a good idea IMHO.
 
  I agree with Gilles, here. If I remember correctly, R has a special
  value NA, or something similar, which differs from NaN.
  Then, any convention might not be
  suitable for some user applications, which would lead such an
  application's
  developer to filter the data anyway in order to change his
  representation to
  CM's representation. Rather that calling two redundant filtering
  codes, I'd
  rather assume that CM gets a clean input on which its algorithm can
  operate.
  As usual, the input is subjected to precondition checks, and
  exceptions are
  thrown if the data is not clean enough.
 
  In summary: data validation (in the sense of discarding input)
  should not be
  done _before_ calling CM routines.
 
  +1.
  ok, I am now confused. First you say that CM should not be involved in
  data cleaning, but then you state that data validation should not be
  done before calling CM? May be there is a *not* too much?
  Yes, you are right: I wrote the opposite of what I meant.
  ---
In summary: data validation (in the sense of discarding input) should
be done _before_ calling CM routines.
  ---
 
  I think the proposition from Patrick was to exactly do that: throw an
  exception if such invalid data is encountered (NaNStrategy.FAIL).
 
  The other thing is, that the NaNStrategy.REMOVED is broken, so either
  we
  fix is or deprecate it.
  That we should fix.  Please open a JIRA for this.  I assume you are
  talking about the implementation in NaturalRanking.
  +1
  [I mean (I think): If people rely on CM's removal of NaNs, we could fix
  it.
  However, if nobody could actually rely on this feature because it is
  broken,
  I'd prefer to remove it.]
  There are two issues here.  One is specific to ranking algorithms.
  To be well-defined, a RankingAlgorithm needs a NaNStrategy, since
  the result has to be a total ordering.  The NaNStrategy.REMOVED
  strategy is intended to represent removal of NaNs from the data to
  be ordered.  If it is not implemented correctly in NaturalRanking or
  other rankings that is a bug and needs to be fixed.
  Sorry, I just reread Patrick's original mail.  IIUC, there is
  nothing wrong with the implementation of NaNStrategy.REMOVED in
  NaturalRanking or other implemented rankings.  The problem is how
  the Spearman's impl handles it.  That is indeed a bug in Spearman's
  impl that should be fixed.  The correct fix is to throw out the
  corresponding entry in the second array when REMOVED is the
  configured NaNStrategy.  I agree with Patrick that adding .FAIL and
  setting that as the default is a good idea.  Patches welcome.
  The second issue is the more general one of how to represent and
  handle missing data.  I have always seen that as a limitation that
  we would eventually address on an algorithm by algorithm basis.
  Different algorithms can be configured to do different things when
  missing data are encountered.  It is not always possible or
  desirable to preprocess the data to eliminate or impute missing
  data.  Saying that we are just not going to deal with it is a
  limitation that I don't think we should impose.  I am would like to
  hear others' ideas about good ways to model missing data in Java.
  Hi Phil,
 
  ok I have

Re: [math] correlation analysis with NaNs

2012-11-18 Thread Phil Steitz

On 11/18/12 2:01 PM, Thomas Neidhart wrote:
 On 11/09/2012 11:14 PM, Phil Steitz wrote:
 On 11/9/12 12:18 AM, Thomas Neidhart wrote:
 On Thu, Nov 8, 2012 at 7:21 PM, Phil Steitz phil.ste...@gmail.com wrote:

 On 11/8/12 9:44 AM, Phil Steitz wrote:
 On 11/8/12 8:23 AM, Gilles Sadowski wrote:
 On Thu, Nov 08, 2012 at 05:00:52PM +0100, Thomas Neidhart wrote:
 On 11/08/2012 02:01 PM, Sébastien Brisard wrote:
 Hi,

 2012/11/8 Gilles Sadowski gil...@harfang.homelinux.org:
 On Thu, Nov 08, 2012 at 09:39:00AM +0100, Thomas Neidhart wrote:
 Hi Patrick,

 On 11/07/2012 04:37 PM, Patrick Meyer wrote:
 I agree that it would be nice to have a constructor that allows
 you to
 specific the ranking algorithm only.
 +1 - patches welcome.
 As far as NaN and the Spearman correlation, maybe we should add a
 default
 strategy of NaNStrategy.FAIL so that an exception would occur if
 any NaN is
 encountered. R uses this treatment of missing data and forces
 users to
 choose how to handle it. If we implemented something like listwise
 or
 pairwise deletion it could be used in other classes too. As such,
 treatment
 of missing data should be part of a larger discussion and handled
 in a more
 comprehensive and systematic way.
 +1 to develop a strategy for representing how to represent and
 handle missing data (see below)
 I think this additional option makes sense, but I forward this
 discussion to the dev mailing list where it is better suited.
 I'm wary of having CM handle missing data.
 For one thing we'd have to define a convention to represent
 missing data.
 There is no good way to do that in Java. Using NaN for this purpose
 in a
 low-level library is not a good idea IMHO.

 I agree with Gilles, here. If I remember correctly, R has a special
 value NA, or something similar, which differs from NaN.
 Then, any convention might not be
 suitable for some user applications, which would lead such an
 application's
 developer to filter the data anyway in order to change his
 representation to
 CM's representation. Rather that calling two redundant filtering
 codes, I'd
 rather assume that CM gets a clean input on which its algorithm can
 operate.
 As usual, the input is subjected to precondition checks, and
 exceptions are
 thrown if the data is not clean enough.

 In summary: data validation (in the sense of discarding input)
 should not be
 done _before_ calling CM routines.

 +1.
 ok, I am now confused. First you say that CM should not be involved in
 data cleaning, but then you state that data validation should not be
 done before calling CM? May be there is a *not* too much?
 Yes, you are right: I wrote the opposite of what I meant.
 ---
   In summary: data validation (in the sense of discarding input) should
   be done _before_ calling CM routines.
 ---

 I think the proposition from Patrick was to exactly do that: throw an
 exception if such invalid data is encountered (NaNStrategy.FAIL).

 The other thing is, that the NaNStrategy.REMOVED is broken, so either
 we
 fix is or deprecate it.
 That we should fix.  Please open a JIRA for this.  I assume you are
 talking about the implementation in NaturalRanking.
 +1
 [I mean (I think): If people rely on CM's removal of NaNs, we could fix
 it.
 However, if nobody could actually rely on this feature because it is
 broken,
 I'd prefer to remove it.]
 There are two issues here.  One is specific to ranking algorithms.
 To be well-defined, a RankingAlgorithm needs a NaNStrategy, since
 the result has to be a total ordering.  The NaNStrategy.REMOVED
 strategy is intended to represent removal of NaNs from the data to
 be ordered.  If it is not implemented correctly in NaturalRanking or
 other rankings that is a bug and needs to be fixed.
 Sorry, I just reread Patrick's original mail.  IIUC, there is
 nothing wrong with the implementation of NaNStrategy.REMOVED in
 NaturalRanking or other implemented rankings.  The problem is how
 the Spearman's impl handles it.  That is indeed a bug in Spearman's
 impl that should be fixed.  The correct fix is to throw out the
 corresponding entry in the second array when REMOVED is the
 configured NaNStrategy.  I agree with Patrick that adding .FAIL and
 setting that as the default is a good idea.  Patches welcome.
 The second issue is the more general one of how to represent and
 handle missing data.  I have always seen that as a limitation that
 we would eventually address on an algorithm by algorithm basis.
 Different algorithms can be configured to do different things when
 missing data are encountered.  It is not always possible or
 desirable to preprocess the data to eliminate or impute missing
 data.  Saying that we are just not going to deal with it is a
 limitation that I don't think we should impose.  I am would like to
 hear others' ideas about good ways to model missing data in Java.
 Hi Phil,

 ok I have created three new issues:

  * MATH-891
  * MATH-892
  * MATH-893
 Thanks!
 Regarding the NaNStrategy.REMOVED, I think it will be

[math] custom profiles in our pom

2012-11-18 Thread Sébastien Brisard

Hi,
someone (I think it was sebb) wrote some months ago about defining custom
profiles in the pom.xml to allow for faster compilation (cobertura being
the culprit).
I've done that locally, and I'm probably not the only one. So I was
wondering whether we could commit one or two custom profiles which would
make our life easier?
The profile I'm using is the following
  profiles
profile
  idfast/id
  properties
skipTeststrue/skipTests
maven.clover.skiptrue/maven.clover.skip
cobertura.skiptrue/cobertura.skip
findbugs.skiptrue/findbugs.skip
pmd.skiptrue/pmd.skip
  /properties
/profile
  /profiles
it allows me to quickly check the generated Javadoc + users guide.
Other profiles could be defined, of course.


What do you think?
Sébastien

[GUMP@vmgump]: Project commons-dbcp (in module commons-dbcp-1.x) failed

2012-11-18 Thread Gump

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-dbcp has an issue affecting its community integration.
This issue affects 18 projects,
 and has been outstanding for 24 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbcp :  Object Pooling
- db-ddlutils :  Easy-to-use component for working with Database Definition 
(...
- jakarta-tomcat-4.0 :  Servlet 2.3 and JSP 1.2 Reference Implementation
- jakarta-tomcat-catalina :  Servlet 2.4 Reference Implementation
- jakarta-tomcat-dbcp :  Servlet 2.4 and JSP 2.0 Reference Implementation
- jakarta-tomcat-jk :  Connectors to various web servers
- javax.el :  Java Servlet 2.5  Server Pages JSP 2.1 implementation (for 
...
- javax.servlet :  Java Servlet 2.5  Server Pages JSP 2.1 implementation 
(for ...
- javax.servlet.jsp :  Java Servlet 2.5  Server Pages JSP 2.1 
implementation (for ...
- solr :  Java Based Search Engine
- solr-test :  Java Based Search Engine
- tomcat-tc6 :  Java Servlet 2.5  Server Pages JSP 2.1 implementation (for 
...
- tomcat-tc7.0.x :  Tomcat 7.x, a web server implementing Java Servlet 3.0,
...
- tomcat-tc7.0.x-dbcp :  Tomcat 7.x, a web server implementing Java Servlet 
3.0,
...
- tomcat-tc7.0.x-test :  Tomcat 7.x, a web server implementing Java Servlet 
3.0,
...
- tomcat-trunk :  Tomcat 8.x, a web server implementing Java Servlet 3.1,
...
- tomcat-trunk-dbcp :  Tomcat 8.x, a web server implementing Java Servlet 
3.1,
...
- tomcat-trunk-test :  Tomcat 8.x, a web server implementing Java Servlet 
3.1,
...


Full details are available at:

http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbcp.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/commons-dbcp-1.x/commons-dbcp/gump_work/build_commons-dbcp-1.x_commons-dbcp.html
Work Name: build_commons-dbcp-1.x_commons-dbcp (Type: Build)
Work ended in a state of : Failed
Elapsed: 9 secs
Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
dist 
[Working Directory: /srv/gump/public/workspace/commons-dbcp-1.x]
CLASSPATH: 
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/junit/dist/junit-19112012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-19112012.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/public/workspace/commons-pool-1.x/dist/commons-pool-1.6.1-SNAPSHOT.jar
-
[javac]^
[javac]   where T is a type-variable:
[javac] T extends Object declared in method 
TgetObject(String,ClassT)
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingConnection.java:65:
 error: DelegatingConnection is not abstract and does not override abstract 
method getNetworkTimeout() in Connection
[javac] public class DelegatingConnection extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingDatabaseMetaData.java:38:
 error: DelegatingDatabaseMetaData is not abstract and does not override 
abstract method generatedKeyAlwaysReturned() in DatabaseMetaData
[javac] public class DelegatingDatabaseMetaData extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/commons-dbcp-1.x/src/java/org/apache/commons/dbcp/DelegatingResultSet.java:61:
 error: DelegatingResultSet is not abstract and does not override abstract 
method TgetObject(String,ClassT) in ResultSet
[javac] public class DelegatingResultSet extends

[GUMP@vmgump]: Project commons-dbcp2 (in module apache-commons) failed

2012-11-18 Thread Gump

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project commons-dbcp2 has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 193 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-dbcp2 :  Database Connection Pool


Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole jar output [commons-dbcp2-*[0-9T].jar] identifier set to project 
name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-dbcp2/gump_work/build_apache-commons_commons-dbcp2.html
Work Name: build_apache-commons_commons-dbcp2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 10 secs
Command Line: /usr/lib/jvm/java-7-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only 
-Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml 
dist 
[Working Directory: /srv/gump/public/workspace/apache-commons/dbcp]
CLASSPATH: 
/usr/lib/jvm/java-7-oracle/lib/tools.jar:/srv/gump/public/workspace/apache-commons/dbcp/dist/classes:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar:/srv/gump/packages/jdbc2_0/jdbc2_0-stdext.jar:/srv/gump/public/workspace/junit/dist/junit-19112012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-19112012.jar:/srv/gump/public/workspace/apache-commons/pool/dist/commons-pool2-2.0-SNAPSHOT.jar
-
[mkdir] Created dir: 
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac] Compiling 52 source files to 
/srv/gump/public/workspace/apache-commons/dbcp/build/classes
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/BasicDataSource.java:52:
 error: BasicDataSource is not abstract and does not override abstract method 
getParentLogger() in CommonDataSource
[javac] public class BasicDataSource implements DataSource {
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingConnection.java:65:
 error: DelegatingConnection is not abstract and does not override abstract 
method getNetworkTimeout() in Connection
[javac] public class DelegatingConnection extends AbandonedTrace
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingStatement.java:46:
 error: DelegatingStatement is not abstract and does not override abstract 
method isCloseOnCompletion() in Statement
[javac] public class DelegatingStatement extends AbandonedTrace implements 
Statement {
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingPreparedStatement.java:57:
 error: DelegatingPreparedStatement is not abstract and does not override 
abstract method isCloseOnCompletion() in Statement
[javac] public class DelegatingPreparedStatement extends DelegatingStatement
[javac]^
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingCallableStatement.java:58:
 error: DelegatingCallableStatement is not abstract and does not override 
abstract method TgetObject(String,ClassT) in CallableStatement
[javac] public class DelegatingCallableStatement extends 
DelegatingPreparedStatement
[javac]^
[javac]   where T is a type-variable:
[javac] T extends Object declared in method 
TgetObject(String,ClassT)
[javac] 
/srv/gump/public/workspace/apache-commons/dbcp/src/java/org/apache/commons/dbcp2/DelegatingDatabaseMetaData.java:36:
 error: DelegatingDatabaseMetaData is not abstract and does not override 
abstract method generatedKeyAlwaysReturned() in DatabaseMetaData
[javac]

[GUMP@vmgump]: Project commons-io-test (in module apache-commons) failed

Re: [math] Making last iteration data available when iterative algorithms fail to converge (MATH-902)

[GUMP@vmgump]: Project commons-digester3 (in module apache-commons) failed

Re: [math] Making last iteration data available when iterative algorithms fail to converge (MATH-902)

Re: [math] Making last iteration data available when iterative algorithms fail to converge (MATH-902)

[GUMP@vmgump]: Project commons-chain2 (in module apache-commons) failed

[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed

[GUMP@vmgump]: Project commons-dbutils (in module apache-commons) failed

[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed

[continuum] BUILD FAILURE: Apache Commons - Apache Commons Digester - Build using Java 1.6

Re: [math] Making last iteration data available when iterative algorithms fail to converge (MATH-902)

Re: [math] Making last iteration data available when iterative algorithms fail to converge (MATH-902)

Re: [math] Making last iteration data available when iterative algorithms fail to converge (MATH-902)

Re: [math] Making last iteration data available when iterative algorithms fail to converge (MATH-902)

Re: [math] correlation analysis with NaNs

Re: [math] Making last iteration data available when iterative algorithms fail to converge (MATH-902)

Re: [math] correlation analysis with NaNs

Re: [math] correlation analysis with NaNs

[math] custom profiles in our pom

[GUMP@vmgump]: Project commons-dbcp (in module commons-dbcp-1.x) failed

[GUMP@vmgump]: Project commons-dbcp2 (in module apache-commons) failed

21 matches

Site Navigation

Mail list logo

Footer information