Re: svn commit: r1139126 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/analysis/solvers/ site/xdoc/ test/java/org/apache/commons/math/analysis/ test/java/org/apache/commons/ma
Hi all, The provided patch for MATH-599 includes a number of no-brace if statements like the following ones: +if (method == Method.ILLINOIS) f0 *= 0.5; +if (method == Method.PEGASUS) f0 *= f1 / (f1 + fx); I'm not sure if we have an unwritten rule for this, but personally I dislike this style a lot. Checkstyle provides a NeedBraces rule to avoid this. What about activating this rule ? Luc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1139126 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/analysis/solvers/ site/xdoc/ test/java/org/apache/commons/math/analysis/ test/java/org/apache/commons/ma
I agree with you that braces should always be used. Personally, I do have one exception though, and that is if the statement following it is on the same line. That way, it is one line, instead of 3 lines, which makes it more readable. If the 'if' statement spans multiple lines, I always include braces, even if there is only one single statement involved. But that is just me... I think the rule is already active in Checkstyle. I think I just chose to ignore it here. In general (not just this Checkstyle rule), is it allowed to ignore checkstyle errors, if one believes that the code would be better if the rule is ignored for a specific instance; that is, in case of false positives? Dennis Luc Maisonobe wrote: Hi all, The provided patch for MATH-599 includes a number of no-brace if statements like the following ones: +if (method == Method.ILLINOIS) f0 *= 0.5; +if (method == Method.PEGASUS) f0 *= f1 / (f1 + fx); I'm not sure if we have an unwritten rule for this, but personally I dislike this style a lot. Checkstyle provides a NeedBraces rule to avoid this. What about activating this rule ? Luc - 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
[GUMP@vmgump]: Project commons-math (in module apache-commons) failed
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-math has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 10 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-math : The Jakarta Mathematics Library Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-math/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-math-24062011.jar] identifier set to project name -DEBUG- Dependency on junit exists, no need to add for property junit.jar. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/math/target/surefire-reports -WARNING- No directory [/srv/gump/public/workspace/apache-commons/math/target/surefire-reports] -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/math/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-math/gump_work/build_apache-commons_commons-math.html Work Name: build_apache-commons_commons-math (Type: Build) Work ended in a state of : Failed Elapsed: 5 mins 35 secs Command Line: /usr/lib/jvm/java-6-openjdk/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 -Djunit.jar=/srv/gump/public/workspace/junit/dist/junit-24062011.jar -Dfinal.name=commons-math-24062011 jar [Working Directory: /srv/gump/public/workspace/apache-commons/math] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/apache-commons/math/target/classes:/srv/gump/public/workspace/apache-commons/math/target/test-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/packages/junit3.8.1/junit.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-24062011.jar:/srv/gump/public/workspace/junit/dist/junit-dep-24062011.jar - [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.176 sec [junit] Running org.apache.commons.math.stat.ranking.NaturalRankingTest [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.174 sec [junit] Running org.apache.commons.math.stat.regression.GLSMultipleLinearRegressionTest [junit] Tests run: 21, Failures: 0, Errors: 0, Time elapsed: 1.089 sec [junit] Running org.apache.commons.math.stat.regression.OLSMultipleLinearRegressionTest [junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 0.247 sec [junit] Running org.apache.commons.math.stat.regression.SimpleRegressionTest [junit] Tests run: 16, Failures: 0, Errors: 0, Time elapsed: 0.206 sec [junit] Running org.apache.commons.math.transform.FastCosineTransformerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.177 sec [junit] Running org.apache.commons.math.transform.FastFourierTransformerTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.191 sec [junit] Running org.apache.commons.math.transform.FastHadamardTransformerTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.168 sec [junit] Running org.apache.commons.math.transform.FastSineTransformerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.168 sec [junit] Running org.apache.commons.math.util.BigRealFieldTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.03 sec [junit] Running org.apache.commons.math.util.BigRealTest [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.063 sec [junit] Running org.apache.commons.math.util.ContinuedFractionTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.136 sec [junit] Running org.apache.commons.math.util.DefaultTransformerTest [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.042 sec [junit] Running org.apache.co
Re: svn commit: r1139126 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/analysis/solvers/ site/xdoc/ test/java/org/apache/commons/math/analysis/ test/java/org/apache/commons/ma
Le 24/06/2011 09:09, Dennis Hendriks a écrit : I agree with you that braces should always be used. Personally, I do have one exception though, and that is if the statement following it is on the same line. That way, it is one line, instead of 3 lines, which makes it more readable. If the 'if' statement spans multiple lines, I always include braces, even if there is only one single statement involved. But that is just me... So we have at least two different opinions here, which is good. Let's see what other people think. I think the rule is already active in Checkstyle. I think I just chose to ignore it here. No, the rule is not active in our checkstyle configuration. I have tested it, there are about 130 violations of this rule in our code base, so it is really simple to fix all of them. In general (not just this Checkstyle rule), is it allowed to ignore checkstyle errors, if one believes that the code would be better if the rule is ignored for a specific instance; that is, in case of false positives? No, we tend to fix really everything, at least at release time. If we let warnings, it becomes difficult to sort real problems from false positive. People have to take time to check every warning manually each time, so allowing warnings really wastes more time in the long term that it saves in the short term. If a piece of code really needs to not comply to a rule, then we use the warning suppression mechanism around that piece of code. See at the end of our checkstyle configuration, there are already 5 SuppressionCommentFilter set up. This also applies to findbugs, and we use findbugs-exclude-filter for false positives. Luc Dennis Luc Maisonobe wrote: Hi all, The provided patch for MATH-599 includes a number of no-brace if statements like the following ones: + if (method == Method.ILLINOIS) f0 *= 0.5; + if (method == Method.PEGASUS) f0 *= f1 / (f1 + fx); I'm not sure if we have an unwritten rule for this, but personally I dislike this style a lot. Checkstyle provides a NeedBraces rule to avoid this. What about activating this rule ? Luc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1139126 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/analysis/solvers/ site/xdoc/ test/java/org/apache/commons/math/analysis/ test/java/org/apache/commons/ma
Hi. > >I agree with you that braces should always be used. Personally, I do > >have one exception though, and that is if the statement following it is > >on the same line. That way, it is one line, instead of 3 lines, which > >makes it more readable. If the 'if' statement spans multiple lines, I > >always include braces, even if there is only one single statement > >involved. But that is just me... > > So we have at least two different opinions here, which is good. > Let's see what other people think. I prefer to have _one_ rule for code formatting. [Also, you nvere know when you might need an additional statement wihtin the conditional branch (e.g. when debugging).] > > > >I think the rule is already active in Checkstyle. I think I just chose > >to ignore it here. > > No, the rule is not active in our checkstyle configuration. I have > tested it, there are about 130 violations of this rule in our code > base, so it is really simple to fix all of them. +1 for enabling the rule. > [...] Best regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1139126 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/analysis/solvers/ site/xdoc/ test/java/org/apache/commons/math/analysis/ test/java/org/apache/commons/ma
> No, we tend to fix really everything, at least at release time. I got this output this morning for trunk: [INFO] There are 22792 checkstyle errors. So there is a lot of work to do for the next release... > If we > let warnings, it becomes difficult to sort real problems from false > positive. People have to take time to check every warning manually each > time, so allowing warnings really wastes more time in the long term that > it saves in the short term. I agree. Dennis Luc Maisonobe wrote: Le 24/06/2011 09:09, Dennis Hendriks a écrit : I agree with you that braces should always be used. Personally, I do have one exception though, and that is if the statement following it is on the same line. That way, it is one line, instead of 3 lines, which makes it more readable. If the 'if' statement spans multiple lines, I always include braces, even if there is only one single statement involved. But that is just me... So we have at least two different opinions here, which is good. Let's see what other people think. I think the rule is already active in Checkstyle. I think I just chose to ignore it here. No, the rule is not active in our checkstyle configuration. I have tested it, there are about 130 violations of this rule in our code base, so it is really simple to fix all of them. In general (not just this Checkstyle rule), is it allowed to ignore checkstyle errors, if one believes that the code would be better if the rule is ignored for a specific instance; that is, in case of false positives? No, we tend to fix really everything, at least at release time. If we let warnings, it becomes difficult to sort real problems from false positive. People have to take time to check every warning manually each time, so allowing warnings really wastes more time in the long term that it saves in the short term. If a piece of code really needs to not comply to a rule, then we use the warning suppression mechanism around that piece of code. See at the end of our checkstyle configuration, there are already 5 SuppressionCommentFilter set up. This also applies to findbugs, and we use findbugs-exclude-filter for false positives. Luc Dennis Luc Maisonobe wrote: Hi all, The provided patch for MATH-599 includes a number of no-brace if statements like the following ones: + if (method == Method.ILLINOIS) f0 *= 0.5; + if (method == Method.PEGASUS) f0 *= f1 / (f1 + fx); I'm not sure if we have an unwritten rule for this, but personally I dislike this style a lot. Checkstyle provides a NeedBraces rule to avoid this. What about activating this rule ? Luc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1139126 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/analysis/solvers/ site/xdoc/ test/java/org/apache/commons/math/analysis/ test/java/org/apache/commons/ma
> I prefer to have _one_ rule for code formatting. > [Also, you nvere know when you might need an additional statement wihtin > the conditional branch (e.g. when debugging).] I would indeed consider that a reasonable reason to indeed force the braces. Dennis Gilles Sadowski wrote: Hi. I agree with you that braces should always be used. Personally, I do have one exception though, and that is if the statement following it is on the same line. That way, it is one line, instead of 3 lines, which makes it more readable. If the 'if' statement spans multiple lines, I always include braces, even if there is only one single statement involved. But that is just me... So we have at least two different opinions here, which is good. Let's see what other people think. I prefer to have _one_ rule for code formatting. [Also, you nvere know when you might need an additional statement wihtin the conditional branch (e.g. when debugging).] I think the rule is already active in Checkstyle. I think I just chose to ignore it here. No, the rule is not active in our checkstyle configuration. I have tested it, there are about 130 violations of this rule in our code base, so it is really simple to fix all of them. +1 for enabling the rule. [...] Best regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1139126 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/analysis/solvers/ site/xdoc/ test/java/org/apache/commons/math/analysis/ test/java/org/apache/commons/ma
Le 24/06/2011 10:57, Dennis Hendriks a écrit : > No, we tend to fix really everything, at least at release time. I got this output this morning for trunk: [INFO] There are 22792 checkstyle errors. I have 137 errors only adding the check for braces, and only a handful without this check! Do you use our checkstyle.xml file ? Luc So there is a lot of work to do for the next release... > If we > let warnings, it becomes difficult to sort real problems from false > positive. People have to take time to check every warning manually each > time, so allowing warnings really wastes more time in the long term that > it saves in the short term. I agree. Dennis Luc Maisonobe wrote: Le 24/06/2011 09:09, Dennis Hendriks a écrit : I agree with you that braces should always be used. Personally, I do have one exception though, and that is if the statement following it is on the same line. That way, it is one line, instead of 3 lines, which makes it more readable. If the 'if' statement spans multiple lines, I always include braces, even if there is only one single statement involved. But that is just me... So we have at least two different opinions here, which is good. Let's see what other people think. I think the rule is already active in Checkstyle. I think I just chose to ignore it here. No, the rule is not active in our checkstyle configuration. I have tested it, there are about 130 violations of this rule in our code base, so it is really simple to fix all of them. In general (not just this Checkstyle rule), is it allowed to ignore checkstyle errors, if one believes that the code would be better if the rule is ignored for a specific instance; that is, in case of false positives? No, we tend to fix really everything, at least at release time. If we let warnings, it becomes difficult to sort real problems from false positive. People have to take time to check every warning manually each time, so allowing warnings really wastes more time in the long term that it saves in the short term. If a piece of code really needs to not comply to a rule, then we use the warning suppression mechanism around that piece of code. See at the end of our checkstyle configuration, there are already 5 SuppressionCommentFilter set up. This also applies to findbugs, and we use findbugs-exclude-filter for false positives. Luc Dennis Luc Maisonobe wrote: Hi all, The provided patch for MATH-599 includes a number of no-brace if statements like the following ones: + if (method == Method.ILLINOIS) f0 *= 0.5; + if (method == Method.PEGASUS) f0 *= f1 / (f1 + fx); I'm not sure if we have an unwritten rule for this, but personally I dislike this style a lot. Checkstyle provides a NeedBraces rule to avoid this. What about activating this rule ? Luc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1139223 - /commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/AllowedSolutions.java
> + * {@link org.apache.commons.math.odeODEIntegrator ODE solvers}, it
Seems to be missing a dot between ode and ODEIntegrator...
Dennis
er...@apache.org wrote:
Author: erans
Date: Fri Jun 24 09:43:33 2011
New Revision: 1139223
URL: http://svn.apache.org/viewvc?rev=1139223&view=rev
Log:
Javadoc fix.
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/AllowedSolutions.java
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/AllowedSolutions.java
URL:
http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/AllowedSolutions.java?rev=1139223&r1=1139222&r2=1139223&view=diff
==
---
commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/AllowedSolutions.java
(original)
+++
commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/AllowedSolutions.java
Fri Jun 24 09:43:33 2011
@@ -28,7 +28,8 @@ package org.apache.commons.math.analysis
* or slightly larger than the actual root. Root-finding algorithms generally
* only guarantee that the returned solution is within the requested
* tolerances. In certain cases however, in particular for
- * {@link EventHandler state events} of {@link ODEIntegrator ODE solvers}, it
+ * {@link org.apache.commons.math.ode.eventsEventHandler state events} of
+ * {@link org.apache.commons.math.odeODEIntegrator ODE solvers}, it
* may be necessary to guarantee that a solution is returned that does not
* under-approximate the solution.
*
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Apache Commons - Commons Math - Default Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=9296&projectId=97 Build statistics: State: Failed Previous State: Failed Started at: Fri 24 Jun 2011 10:20:33 + Finished at: Fri 24 Jun 2011 10:21:05 + Total time: 31s Build Trigger: Schedule Build Number: 316 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.6.0_24" Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_24 Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: "unix" SCM Changes: Changed: erans @ Fri 24 Jun 2011 09:43:33 + Comment: Javadoc fix. Files changed: /commons/proper/math/trunk/src/main/java/org/apache/commons/math/analysis/solvers/AllowedSolutions.java ( 1139223 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean install Arguments: --batch-mode -Pjava-1.5 Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Default Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 0 Failures: 0 Errors: 0 Total time: 0.0 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
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 65 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: 16 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 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.039 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.024 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.163 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec Results : Tests in error: testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) Tests run: 179, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 13 seconds [INFO] Finished at: Fri Jun 24 12:05:42 UTC 2011 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom: http://vmgump.apache.or
Re: svn commit: r1139126 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/analysis/solvers/ site/xdoc/ test/java/org/apache/commons/math/analysis/ test/java/org/apache/commons/ma
+1 2011/6/24 Luc Maisonobe : > Hi all, > > The provided patch for MATH-599 includes a number of no-brace if statements > like the following ones: > >> + if (method == Method.ILLINOIS) f0 *= 0.5; >> + if (method == Method.PEGASUS) f0 *= f1 / (f1 + fx); > > I'm not sure if we have an unwritten rule for this, but personally I dislike > this style a lot. Checkstyle provides a NeedBraces rule to avoid this. > > What about activating this rule ? > > Luc > > - > 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
Additions to support Large Linear Regression problems
Hello All, I have been a user of the math commons jar for a little over a year and am very impressed with it. I was wondering whether anyone is actively working on implementing functionality to do regressions on very very large data sets. The current implementation of the OLS routine is an in-core QR decomposition with substitution. While the solutions are typically accurate, the in-core nature limits the usefulness of these objects. Looking through the code, most of the implementation of an InputStream based regression routine would respect the contract implicit in the interface MultipleLinearRegression. However, large regression problems are important enough that there should be a way to: 1. Wrap a potentially large data source, perhaps as an InputStream of some sort. 2. Have a separate contract with methods like clear() ( to clear whatever intermediate calculations are stored), and regress() which generates immutable results that are not affected by further updates of the data. I would appreciate any thoughts or comments, as well suggestions about functionality already in math commons which might address some points I raised. Thank you, -Greg
[GUMP@vmgump]: Project commons-math (in module apache-commons) failed
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-math has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-math : The Jakarta Mathematics Library Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-math/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-math-24062011.jar] identifier set to project name -DEBUG- Dependency on junit exists, no need to add for property junit.jar. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/math/target/surefire-reports -WARNING- No directory [/srv/gump/public/workspace/apache-commons/math/target/surefire-reports] -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/math/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-math/gump_work/build_apache-commons_commons-math.html Work Name: build_apache-commons_commons-math (Type: Build) Work ended in a state of : Failed Elapsed: 5 mins 36 secs Command Line: /usr/lib/jvm/java-6-openjdk/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 -Djunit.jar=/srv/gump/public/workspace/junit/dist/junit-24062011.jar -Dfinal.name=commons-math-24062011 jar [Working Directory: /srv/gump/public/workspace/apache-commons/math] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/apache-commons/math/target/classes:/srv/gump/public/workspace/apache-commons/math/target/test-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/packages/junit3.8.1/junit.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-24062011.jar:/srv/gump/public/workspace/junit/dist/junit-dep-24062011.jar - [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.154 sec [junit] Running org.apache.commons.math.stat.ranking.NaturalRankingTest [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.184 sec [junit] Running org.apache.commons.math.stat.regression.GLSMultipleLinearRegressionTest [junit] Tests run: 21, Failures: 0, Errors: 0, Time elapsed: 1.055 sec [junit] Running org.apache.commons.math.stat.regression.OLSMultipleLinearRegressionTest [junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 0.253 sec [junit] Running org.apache.commons.math.stat.regression.SimpleRegressionTest [junit] Tests run: 16, Failures: 0, Errors: 0, Time elapsed: 0.212 sec [junit] Running org.apache.commons.math.transform.FastCosineTransformerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.17 sec [junit] Running org.apache.commons.math.transform.FastFourierTransformerTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.182 sec [junit] Running org.apache.commons.math.transform.FastHadamardTransformerTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.172 sec [junit] Running org.apache.commons.math.transform.FastSineTransformerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.188 sec [junit] Running org.apache.commons.math.util.BigRealFieldTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.03 sec [junit] Running org.apache.commons.math.util.BigRealTest [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.062 sec [junit] Running org.apache.commons.math.util.ContinuedFractionTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.136 sec [junit] Running org.apache.commons.math.util.DefaultTransformerTest [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.041 sec [junit] Running org.apache.commons.math.util.FastMathStrictComparison
[math] Re: Additions to support Large Linear Regression problems
On 6/24/11 11:44 AM, Greg Sterijevski wrote: > Hello All, > > I have been a user of the math commons jar for a little over a year and am > very impressed with it. I was wondering whether anyone is actively working > on implementing functionality to do regressions on very very large data > sets. The current implementation of the OLS routine is an in-core QR > decomposition with substitution. While the solutions are typically accurate, > the in-core nature limits the usefulness of these objects. > > Looking through the code, most of the implementation of an InputStream based > regression routine would respect the contract implicit in the interface > MultipleLinearRegression. However, large regression problems are important > enough that there should be a way to: > > 1. Wrap a potentially large data source, perhaps as an InputStream of some > sort. > 2. Have a separate contract with methods like clear() ( to clear whatever > intermediate calculations are stored), and regress() which generates > immutable results that are not affected by further updates of the data. > > I would appreciate any thoughts or comments, as well suggestions about > functionality already in math commons which might address some points I > raised. > > Thank you, > > -Greg > Hi Greg, Thanks for the feedback and suggestion. You are correct that the multiple regression classes use QR decomp of the design matrix, so are not really suitable for very large datasets. I agree that this would make a good enhancement and I would be willing to work with you on design and implementation. The SimpleRegression class, which handles only bivariate regression has what amounts to a streaming interface now, so for just bivariate models, arbitrary-sized datasets can be accommodated with the current code. But multiple regression will require some more work. If you are interested in working on this, please open a JIRA and start with a patch proposing the API enhancements above in a new class. I am not sure if it makes sense to have the new class extend AbstractMultipleLinearRegression, since that class really is fixed-model oriented and methods like getResidials() would have to be dropped or replaced by methods returning streams. I would say start with a new class and do not feel constrained to conform to the matrix-oriented API in the current (multiple) regression classes. The API of SimpleRegression may actually be a better model to start with. As we prepare for 3.0, we have the opportunity to improve / repair the 2.x API, so if you have comments or suggestions for improvement of the existing classes, those would also be most welcome. Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Additions to support Large Linear Regression problems
Mahout has this. We have an LSMR implementation that can accept a generic linear operator. You can implement this linear operator as an out of core multiplication or as a cluster operation. You don't say how large you want the system to be or whether you have sparse data. That might change the answer. See http://www.stanford.edu/group/SOL/software/lsmr.html On Fri, Jun 24, 2011 at 11:44 AM, Greg Sterijevski wrote: > Hello All, > > I have been a user of the math commons jar for a little over a year and am > very impressed with it. I was wondering whether anyone is actively working > on implementing functionality to do regressions on very very large data > sets. The current implementation of the OLS routine is an in-core QR > decomposition with substitution. While the solutions are typically > accurate, > the in-core nature limits the usefulness of these objects. > > Looking through the code, most of the implementation of an InputStream > based > regression routine would respect the contract implicit in the interface > MultipleLinearRegression. However, large regression problems are important > enough that there should be a way to: > > 1. Wrap a potentially large data source, perhaps as an InputStream of some > sort. > 2. Have a separate contract with methods like clear() ( to clear whatever > intermediate calculations are stored), and regress() which generates > immutable results that are not affected by further updates of the data. > > I would appreciate any thoughts or comments, as well suggestions about > functionality already in math commons which might address some points I > raised. > > Thank you, > > -Greg >
Re: [codec] submitting a StringEncoder
Hi, I've submitted an issue: https://issues.apache.org/jira/browse/CODEC-125 I have BMPM implemented now, with good (but not complete) test coverage. It's certainly ready for someone else to try to break it for me. So, 1. The original authors are very keen to see this integrated with commons-codec. Could somebody contact me directly so that I can hook them up with you so that we can sort out the licensing issues? 2. How do I go about uploading the code? I can make one big svn patch file, if you would like. Thanks, Matthew -- Dr Matthew Pocock Visitor, School of Computing Science, Newcastle University mailto: turingatemyhams...@gmail.com gchat: turingatemyhams...@gmail.com msn: matthew_poc...@yahoo.co.uk irc.freenode.net: drdozer (0191) 2566550
Re: Additions to support Large Linear Regression problems
Hi Ted, I will look at the Mahout library. I was not aware of this. I will see if this is amenable to my problems. A large problem would be one where it does not make sense to pull all the data into core, whether its 10Gb or 100Tb. While some of these design matrices might be sparse, there is no reason to expect it. -Greg On Fri, Jun 24, 2011 at 2:10 PM, Ted Dunning wrote: > Mahout has this. > > We have an LSMR implementation that can accept a generic linear operator. > You can implement this linear operator as an out of core multiplication or > as a cluster operation. > > You don't say how large you want the system to be or whether you have > sparse > data. That might change the answer. > > See http://www.stanford.edu/group/SOL/software/lsmr.html > > On Fri, Jun 24, 2011 at 11:44 AM, Greg Sterijevski > wrote: > > > Hello All, > > > > I have been a user of the math commons jar for a little over a year and > am > > very impressed with it. I was wondering whether anyone is actively > working > > on implementing functionality to do regressions on very very large data > > sets. The current implementation of the OLS routine is an in-core QR > > decomposition with substitution. While the solutions are typically > > accurate, > > the in-core nature limits the usefulness of these objects. > > > > Looking through the code, most of the implementation of an InputStream > > based > > regression routine would respect the contract implicit in the interface > > MultipleLinearRegression. However, large regression problems are > important > > enough that there should be a way to: > > > > 1. Wrap a potentially large data source, perhaps as an InputStream of > some > > sort. > > 2. Have a separate contract with methods like clear() ( to clear whatever > > intermediate calculations are stored), and regress() which generates > > immutable results that are not affected by further updates of the data. > > > > I would appreciate any thoughts or comments, as well suggestions about > > functionality already in math commons which might address some points I > > raised. > > > > Thank you, > > > > -Greg > > >
[GUMP@vmgump]: Project commons-math (in module apache-commons) failed
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-math has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-math : The Jakarta Mathematics Library Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-math/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-math-25062011.jar] identifier set to project name -DEBUG- Dependency on junit exists, no need to add for property junit.jar. -INFO- Failed with reason build failed -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/math/target/surefire-reports -WARNING- No directory [/srv/gump/public/workspace/apache-commons/math/target/surefire-reports] -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/math/target/test-reports -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-math/gump_work/build_apache-commons_commons-math.html Work Name: build_apache-commons_commons-math (Type: Build) Work ended in a state of : Failed Elapsed: 5 mins 40 secs Command Line: /usr/lib/jvm/java-6-openjdk/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 -Djunit.jar=/srv/gump/public/workspace/junit/dist/junit-25062011.jar -Dfinal.name=commons-math-25062011 jar [Working Directory: /srv/gump/public/workspace/apache-commons/math] CLASSPATH: /usr/lib/jvm/java-6-openjdk/lib/tools.jar:/srv/gump/public/workspace/apache-commons/math/target/classes:/srv/gump/public/workspace/apache-commons/math/target/test-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/packages/junit3.8.1/junit.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-25062011.jar:/srv/gump/public/workspace/junit/dist/junit-dep-25062011.jar - [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.17 sec [junit] Running org.apache.commons.math.stat.ranking.NaturalRankingTest [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.172 sec [junit] Running org.apache.commons.math.stat.regression.GLSMultipleLinearRegressionTest [junit] Tests run: 21, Failures: 0, Errors: 0, Time elapsed: 1.151 sec [junit] Running org.apache.commons.math.stat.regression.OLSMultipleLinearRegressionTest [junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 0.269 sec [junit] Running org.apache.commons.math.stat.regression.SimpleRegressionTest [junit] Tests run: 16, Failures: 0, Errors: 0, Time elapsed: 0.199 sec [junit] Running org.apache.commons.math.transform.FastCosineTransformerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.167 sec [junit] Running org.apache.commons.math.transform.FastFourierTransformerTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.188 sec [junit] Running org.apache.commons.math.transform.FastHadamardTransformerTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.177 sec [junit] Running org.apache.commons.math.transform.FastSineTransformerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.196 sec [junit] Running org.apache.commons.math.util.BigRealFieldTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.033 sec [junit] Running org.apache.commons.math.util.BigRealTest [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.065 sec [junit] Running org.apache.commons.math.util.ContinuedFractionTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.138 sec [junit] Running org.apache.commons.math.util.DefaultTransformerTest [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.396 sec [junit] Running org.apache.com
