[GUMP@vmgump]: Project commons-scxml-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-scxml-test 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-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: 19 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.18 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 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 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 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 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 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 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.041 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]
[INFO] There are test failures.
Please refer
[GUMP@vmgump]: Project commons-jelly-tags-jmx (in module commons-jelly) 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-jelly-tags-jmx 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-jelly-tags-jmx : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jmx/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-jelly-tags-jmx-05082012.jar] identifier set to project name -ERROR- Output with id mx4j-jmx was not found in project mx4j -ERROR- Unhandled Property: maven.jar.mx4j-jmx on: Maven1 on Project:commons-jelly-tags-jmx -DEBUG- Dependency on mx4j exists, no need to add for property maven.jar.mx4j-jmx. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- Dependency on commons-jexl-1.x exists, no need to add for property maven.jar.commons-jexl. -DEBUG- (Apache Gump generated) Apache Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jmx/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jmx/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jmx/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/jmx/target/test-reports -WARNING- No directory [/srv/gump/public/workspace/commons-jelly/jelly-tags/jmx/target/test-reports] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jmx/gump_work/build_commons-jelly_commons-jelly-tags-jmx.html Work Name: build_commons-jelly_commons-jelly-tags-jmx (Type: Build) Work ended in a state of : Failed Elapsed: 1 sec Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/jmx] - __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 You are working offline so the build will continue, but commons-jelly-1.1-SNAPSHOT.jar may be out of date! The build cannot continue because of the following unsatisfied dependency: mx4j-jmx-1.1.1.jar; path override doesn't exist: /srv/gump/public/workspace/commons-jelly/jelly-tags/jmx/*Unset* Total time: 1 seconds Finished at: Sun Aug 05 07:55:57 UTC 2012 - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jmx/rss.xml - Atom: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-jmx/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 1305082012, vmgump.apache.org:vmgump:1305082012 Gump E-mail Identifier (unique within run) #49. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] MATH-610 (please vote)
Le 05/08/2012 01:16, Gilles Sadowski a écrit : > On Sat, Aug 04, 2012 at 03:01:49PM -0700, Phil Steitz wrote: >> On 8/4/12 11:57 AM, Gilles Sadowski wrote: >>> Hi. >>> >>> It seems that the patch for MATH-610 >>> https://issues.apache.org/jira/browse/MATH-610 >>> is fairly innocuous. >>> >>> Does anyone object to it being applied? >>> >>> >>> Gilles >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> No strong objections, but I see it as needless code bloat >> personally. Also, without changing visibility (which I am -1 on) >> for the inner class, I don't see an easy way to add tests for the >> proposed new code. > > Then I would rephrase: > Has anyone an objection to resolving MATH-610 as "Won't fix"? +1 Luc > > > 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: [graph] renaming packages
!Hola! > Addition would have signatures like "sum" and "negate", while Multiplication > would have "multiply" and "invert". >> What about having Monoid with package visibility and then >> "Addition/Multiplication... extends Monoid" ? > > > Then it would become a bit painless if a class had to implement both > interfaces (the current "Integer[...]Operations" is an example). I'd just > have them fully independent from each other, without a common ancestor > (Monoid). OK we have an agreement here :) I'll prepare a patch and attach to an issue to let you review before applying it. > cool. Class name = "GraphPopulator"? Though it sounds sooo bad to my ears... > Maybe a mother tongue can help us with the matter :-) agreed :) Any suggestion? TIA!!! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - 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 - Group (shared) Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=24523&projectId=97 Build statistics: State: Failed Previous State: Failed Started at: Sun 5 Aug 2012 10:37:30 + Finished at: Sun 5 Aug 2012 10:43:29 + Total time: 5m 59s Build Trigger: Schedule Build Number: 910 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-31-server" arch: "amd64" Family: "unix" SCM Changes: Changed: tn @ Sun 5 Aug 2012 09:32:46 + Comment: Fixed findbugs finding when comparing Integer references. Files changed: /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optimization/linear/SimplexSolver.java ( 1369540 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.5 -Dgpg.skip -Prelease Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Group (shared) Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 3989 Failures: 0 Errors: 1 Success Rate: 99 Total time: 288.0952 - 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. 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-05082012.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 -DEBUG- Extracted 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: 8 mins 16 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-05082012.jar -Dfinal.name=commons-math-05082012 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/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-05082012.jar:/srv/gump/public/workspace/junit/dist/junit-dep-05082012.jar - [junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 0.093 sec [junit] Running org.apache.commons.math3.transform.FastCosineTransformerTest [junit] Tests run: 18, Failures: 0, Errors: 0, Time elapsed: 0.421 sec [junit] Running org.apache.commons.math3.transform.FastFourierTransformerTest [junit] Tests run: 12, Failures: 0, Errors: 0, Time elapsed: 0.552 sec [junit] Running org.apache.commons.math3.transform.FastHadamardTransformerTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.041 sec [junit] Running org.apache.commons.math3.transform.FastSineTransformerTest [junit] Tests run: 20, Failures: 0, Errors: 0, Time elapsed: 0.395 sec [junit] Running org.apache.commons.math3.util.ArithmeticUtilsTest [junit] Tests run: 20, Failures: 0, Errors: 0, Time elapsed: 3.022 sec [junit] Running org.apache.commons.math3.util.BigRealFieldTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.029 sec [junit] Running org.apache.commons.math3.util.BigRealTest [junit] Tests run: 14, Failures: 0, Errors: 0, Time elapsed: 0.086 sec [junit] Running org.apache.commons.math3.util.ContinuedFractionTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.02 sec [junit] Running org.apache.commons.math3.util.Decimal64Test [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.02 sec [junit] Running org.apache.commons.math3.util.DefaultTransformerTest [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.049 sec [junit] Running org.apache.commons.math3.util.FastMathStrictComparisonTest [junit] Tests run: 53, Failures: 0, Errors: 0, Time elapsed: 0.258 sec [junit] Running org.apache.commons.math3.util.FastMathTest [junit] Tests run: 43, Failures: 0, Errors: 0, Time elapsed: 18.098 sec [junit] Running org.apache.commons.math3.util.IncrementorTest [junit] Tests run: 10, Failures: 0, Errors: 0, Time elapsed: 0.03 sec [junit] Running org.apache.co
Re: svn commit: r1369540 - /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optimization/linear/SimplexSolver.java
On Sun, Aug 05, 2012 at 09:32:46AM -, t...@apache.org wrote:
> Author: tn
> Date: Sun Aug 5 09:32:46 2012
> New Revision: 1369540
>
> URL: http://svn.apache.org/viewvc?rev=1369540&view=rev
> Log:
> Fixed findbugs finding when comparing Integer references.
>
> Modified:
>
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optimization/linear/SimplexSolver.java
>
> Modified:
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optimization/linear/SimplexSolver.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optimization/linear/SimplexSolver.java?rev=1369540&r1=1369539&r2=1369540&view=diff
> ==
> ---
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optimization/linear/SimplexSolver.java
> (original)
> +++
> commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optimization/linear/SimplexSolver.java
> Sun Aug 5 09:32:46 2012
> @@ -142,8 +142,9 @@ public class SimplexSolver extends Abstr
> int minIndex = tableau.getWidth();
> for (Integer row : minRatioPositions) {
> int i = tableau.getNumObjectiveFunctions();
> -for (; i < tableau.getWidth() - 1 && minRow != row; i++)
> {
> -if (row == tableau.getBasicRow(i)) {
> +for (; i < tableau.getWidth() - 1 &&
> !row.equals(minRow); i++) {
This is a needlessly not standard way to write a for-loop. [Better to
tighten the scope the loop variable.]
> +Integer basicRow = tableau.getBasicRow(i);
> +if (basicRow != null && basicRow.equals(row)) {
> if (i < minIndex) {
> minIndex = i;
> minRow = row;
>
>
Any objection to rewrite as
for (int i = tableau.getNumObjectiveFunctions();
i < tableau.getWidth() - 1 &&
!row.equals(minRow)
i++) {
?
If I correctly read the code of that functions, it would be slightly more
efficient to call once "tableau.getNumObjectiveFunctions()" at the top of
the method and reuse a local variable:
final int numObjFunc = tableau.getNumObjectiveFunctions();
// ...
for (int i = numObjFunc;
i < tableau.getWidth() - 1 &&
!row.equals(minRow)
i++) {
And similarly for "tableau.getWidth() - 1".
[IMHO, little changes like those make the code more readable and,
consequently, help to locate bugs in the long run.]
Thanks,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-exec-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-exec-test 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-exec-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-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/exec/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/exec/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/gump_work/build_apache-commons_commons-exec-test.html Work Name: build_apache-commons_commons-exec-test (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 25 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/exec] M2_HOME: /opt/maven2 - Running org.apache.commons.exec.util.StringUtilTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.exec.util.MapUtilTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.exec.DefaultExecutorTest FOO.. gdal_translate HDF5:"/home/kk/grass/data/4404.he5"://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif FOO.. PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.020 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.025 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.028 ms Process completed in 2005 millis; below is its output Process timed out and was killed by watchdog. org.apache.commons.exec.ExecuteException: Process exited with an error: 143 (Exit value: 143) Process completed in 2005 millis; below is its output Process timed out and was killed. Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Executing [sh, -c, src/test/scripts/invoker.sh] invoker.sh -- going to start daemon process invoker.sh -- daemon process was started cd: 21: can't cd to ../../../target Process completed in 8048 millis; above is its output Processes terminated: 6 killed: 0 Multiplier: 1 MaxRetries: 180 Elapsed (avg ms): 1009 Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 71.912 sec <<< FAILURE! Results : Failed tests: testExec_60(org.apache.commons.exec.DefaultExecutorTest) Tests run: 95, Failures: 1, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/exec/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 24 seconds [INFO] Finished at: Sun Aug 05 14:02:47 UTC 2012 [INFO] Final Memory: 25M/65M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 06001205082012, vmgump.apache.org:vmgump:06001205082012 Gump E-mail Identifier (unique within run) #2. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - 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 - Group (shared) Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=24533&projectId=97 Build statistics: State: Failed Previous State: Ok Started at: Sun 5 Aug 2012 17:36:08 + Finished at: Sun 5 Aug 2012 17:42:48 + Total time: 6m 39s Build Trigger: Schedule Build Number: 911 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-31-server" arch: "amd64" Family: "unix" SCM Changes: Changed: tn @ Sun 5 Aug 2012 16:32:52 + Comment: Added MATH-828 to changes.xml. Files changed: /commons/proper/math/trunk/src/changes/changes.xml ( 1369616 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.5 -Dgpg.skip -Prelease Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Group (shared) Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 3989 Failures: 0 Errors: 1 Success Rate: 99 Total time: 322.4472 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[MATH] Resignation as a committer
Dear all, As you all know, I have not been sufficiently active the past one to two years due to other tasks with higher priority. This is not going to change the next many years due to happy circumstances. I therefore wish to resign as a committer. Which actions should I take to do so? At the same time, I want to express my deepest gratitude for all you guys and your work! I still think it is awesome and I hope that I am able to contribute again at some point. Cheers, MIkkel. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [MATH] Test failure in Continuum
On 8/4/12 10:57 AM, Gilles Sadowski wrote:
> Hello.
>
> Referring to this failed test (cf. messages from Continuum):
> ---CUT---
> org.apache.commons.math3.exception.NumberIsTooLargeException: lower bound
> (65) must be strictly less than upper bound (65)
> at
> org.apache.commons.math3.distribution.UniformIntegerDistribution.(UniformIntegerDistribution.java:73)
> at
> org.apache.commons.math3.distribution.UniformIntegerDistribution.(UniformIntegerDistribution.java:53)
> at
> org.apache.commons.math3.stat.descriptive.AggregateSummaryStatisticsTest.generatePartition(AggregateSummaryStatisticsTest.java:275)
> at
> org.apache.commons.math3.stat.descriptive.AggregateSummaryStatisticsTest.testAggregationConsistency(AggregateSummaryStatisticsTest.java:89)
>
>
> It is due to a precondition check while creating the
> "UniformIntegerDistribution" instance:
> ---CUT---
> if (lower >= upper) {
> throw new NumberIsTooLargeException(
>LocalizedFormats.LOWER_BOUND_NOT_BELOW_UPPER_BOUND,
>lower, upper, false);
> }
> ---CUT---
>
> The test referred to above was using this code (before I changed it use a
> "UniformIntegerDistribution" instance):
> ---CUT---
> final int next = (i == 4 || cur == length - 1) ? length - 1 :
> randomData.nextInt(cur, length - 1);
> ---CUT---
>
> It is now (after the change):
> ---CUT---
> final IntegerDistribution partitionPoint = new
> UniformIntegerDistribution(cur, length - 1);
> final int next = (i == 4 || cur == length - 1) ? length - 1 :
> partitionPoint.sample();
> ---CUT---
>
> Thus, AFAIK, the failure did not appear before because there was no
> precondition enforcement in "nextInt".
>
> The question is: Was the code in the test correct (in allowing the same
> value for both bounds?
> * In the negative, how to change it?
> * The affirmative would mean that the precondition check in
>"UniformIntegerDistribution" should be relaxed to allow equal bounds.
>Does this make sense?
>If so, can we change it now, or is it forbidden in order to stay
>backwards compatible?
Your analysis above is correct. The failure after the change is due
to the fact that post-change the distribution is instantiated before
the bounds check. I changed the test to fix this. Both the
randomData nextInt and the UniformIntegerDistribution constructor
now forbid the degenerate case where there is only one point in the
domain. In retrospect, I guess it would have probably been better
to allow this degenerate case. Unfortunately, this would be an
incompatible change, so will have to wait until 4.0 if we want to do it.
The original code above illustrates the convenience of being able to
just make direct calls to randomData.nextXxx, which is why this
class exists ;)
Phil
>
>
> 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: [MATH] Resignation as a committer
Le 05/08/2012 20:29, Mikkel Meyer Andersen a écrit : > Dear all, Hi Mikkel, > > As you all know, I have not been sufficiently active the past one to > two years due to other tasks with higher priority. This is not going > to change the next many years due to happy circumstances. I therefore > wish to resign as a committer. Which actions should I take to do so? For a committer, there are no specific actions on your side. I am sad to see one of our developers leave, but its a relief to learn the circumstances are happy for you. > > At the same time, I want to express my deepest gratitude for all you > guys and your work! I still think it is awesome and I hope that I am > able to contribute again at some point. I hope so too. In the Apache Software Foundation, everything is based on merit, and merit never expire, so when you will be ready to join again, just write to the list again. best regards, Luc > > Cheers, MIkkel. > > - > 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] integer factorization
Am 04.08.2012 14:22, schrieb ma...@nimp.co.uk: > Thanks for your feedback and the pointer to PARI/GP. About existing stuff, > it seems there is none written in Java: I asked the question on > stackoverflow a while ago, nobody knows any library for the JVM. Hehe, even StackOverflow fails occasionally. Try http://krum.rz.uni-mannheim.de/jas/ for a start. Search for "java quadratic sieve" for some more code, although most of the results seems to be more sample code rather than production quality. I vaguely remember there should be up to 12 Java based projects including more or less sophisticated integer factorization stuff, although I'm not current there and most of them could be dead. > About the applications, well, I agree it is not the #1 required > functionality in most applications. Still applications beyond pure maths do > exist: hash tables, pseudo random numbers, cryptography, electronics... Yes, developing and testing hash algorithms, pseudo random number generators, crypto stuff etc. uses factorization, but everyday use generally doesn't. Apparently you are into serious hard core stuff. As fascinating as these problems most likely are, they are not the primary target for commons math, at least until now. J.Pietschmann - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1369655 - in /commons/proper/compress/trunk/src: main/java/org/apache/commons/compress/archivers/tar/TarUtils.java test/java/org/apache/commons/compress/archivers/tar/TarArchiveInputS
On 5 August 2012 20:51, wrote:
> Author: jukka
> Date: Sun Aug 5 19:51:15 2012
> New Revision: 1369655
>
> URL: http://svn.apache.org/viewvc?rev=1369655&view=rev
> Log:
> COMPRESS-197: Tar file for Android backup cannot be read
>
> Allow more than one or two NUL or space characters at the end of a field
>
> Added:
> commons/proper/compress/trunk/src/test/resources/COMPRESS-197.tar
> Modified:
>
> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/tar/TarUtils.java
>
> commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/tar/TarArchiveInputStreamTest.java
>
> Modified:
> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/tar/TarUtils.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/tar/TarUtils.java?rev=1369655&r1=1369654&r2=1369655&view=diff
> ==
> ---
> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/tar/TarUtils.java
> (original)
> +++
> commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/tar/TarUtils.java
> Sun Aug 5 19:51:15 2012
> @@ -130,10 +130,11 @@ public class TarUtils {
> throw new IllegalArgumentException(
> exceptionMessage(buffer, offset, length, end-1,
> trailer));
> }
> -// May have additional NUL or space
> -trailer = buffer[end-1];
> -if (trailer == 0 || trailer == ' '){
> +// May have additional NULs or spaces
The Javadoc also needs adjusting please.
> +trailer = buffer[end - 1];
> +while (start < end - 1 && (trailer == 0 || trailer == ' ')) {
> end--;
> +trailer = buffer[end - 1];
> }
>
> for ( ;start < end; start++) {
>
> Modified:
> commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/tar/TarArchiveInputStreamTest.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/tar/TarArchiveInputStreamTest.java?rev=1369655&r1=1369654&r2=1369655&view=diff
> ==
> ---
> commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/tar/TarArchiveInputStreamTest.java
> (original)
> +++
> commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/tar/TarArchiveInputStreamTest.java
> Sun Aug 5 19:51:15 2012
> @@ -20,10 +20,12 @@ package org.apache.commons.compress.arch
>
> import static org.junit.Assert.assertEquals;
> import static org.junit.Assert.assertTrue;
> +import static org.junit.Assert.fail;
>
> import java.io.ByteArrayInputStream;
> import java.io.File;
> import java.io.FileInputStream;
> +import java.io.IOException;
> import java.net.URI;
> import java.net.URL;
> import java.util.Calendar;
> @@ -120,4 +122,24 @@ public class TarArchiveInputStreamTest {
> }
> }
>
> -}
> \ No newline at end of file
> +@Test
> +public void testCompress197() throws Exception {
> +TarArchiveInputStream tar = getTestStream("/COMPRESS-197.tar");
> +try {
> +TarArchiveEntry entry = tar.getNextTarEntry();
> +while (entry != null) {
> +entry = tar.getNextTarEntry();
> +}
> +} catch (IOException e) {
> +fail("COMPRESS-197: " + e.getMessage());
> +} finally {
> +tar.close();
> +}
> +}
> +
> +private TarArchiveInputStream getTestStream(String name) {
> +return new TarArchiveInputStream(
> +TarArchiveInputStreamTest.class.getResourceAsStream(name));
> +}
> +
> +}
>
> Added: commons/proper/compress/trunk/src/test/resources/COMPRESS-197.tar
> URL:
> http://svn.apache.org/viewvc/commons/proper/compress/trunk/src/test/resources/COMPRESS-197.tar?rev=1369655&view=auto
> ==
> Files commons/proper/compress/trunk/src/test/resources/COMPRESS-197.tar
> (added) and commons/proper/compress/trunk/src/test/resources/COMPRESS-197.tar
> Sun Aug 5 19:51:15 2012 differ
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[math] spinning BOBYQAOptimizerTest
The site build just hung on me due to BOBYQAOptimizerTest.testConstrainedRosenWithMoreInterpolationPoints spinning. A sample thread dump showing the spinning thread is show below. Above the reference to BOBYQAOptimizer.doOptimize(BOBYQAOptimizer.java:246), successive dumps change. The code continues to run, but does not complete. The hang happened during the coberta instrumented test run. at org.apache.commons.math3.optimization.direct.BOBYQAOptimizer.bobyqb(BOBYQAOptimizer.java:970) at org.apache.commons.math3.optimization.direct.BOBYQAOptimizer.bobyqa(BOBYQAOptimizer.java:334) at org.apache.commons.math3.optimization.direct.BOBYQAOptimizer.doOptimize(BOBYQAOptimizer.java:246) at org.apache.commons.math3.optimization.direct.BaseAbstractMultivariateOptimizer.optimize(BaseAbstractMultivariateOptimizer.java:126) at org.apache.commons.math3.optimization.direct.BaseAbstractMultivariateSimpleBoundsOptimizer.optimize(BaseAbstractMultivariateSimpleBoundsOptimizer.java:139) at org.apache.commons.math3.optimization.direct.BOBYQAOptimizerTest.doTest(BOBYQAOptimizerTest.java:321) at org.apache.commons.math3.optimization.direct.BOBYQAOptimizerTest.testConstrainedRosenWithMoreInterpolationPoints(BOBYQAOptimizerTest.java:249) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [MATH] Test failure in Continuum
On Sun, Aug 05, 2012 at 12:54:11PM -0700, Phil Steitz wrote:
> On 8/4/12 10:57 AM, Gilles Sadowski wrote:
> > Hello.
> >
> > Referring to this failed test (cf. messages from Continuum):
> > ---CUT---
> > org.apache.commons.math3.exception.NumberIsTooLargeException: lower bound
> > (65) must be strictly less than upper bound (65)
> > at
> > org.apache.commons.math3.distribution.UniformIntegerDistribution.(UniformIntegerDistribution.java:73)
> > at
> > org.apache.commons.math3.distribution.UniformIntegerDistribution.(UniformIntegerDistribution.java:53)
> > at
> > org.apache.commons.math3.stat.descriptive.AggregateSummaryStatisticsTest.generatePartition(AggregateSummaryStatisticsTest.java:275)
> > at
> > org.apache.commons.math3.stat.descriptive.AggregateSummaryStatisticsTest.testAggregationConsistency(AggregateSummaryStatisticsTest.java:89)
> >
> >
> > It is due to a precondition check while creating the
> > "UniformIntegerDistribution" instance:
> > ---CUT---
> > if (lower >= upper) {
> > throw new NumberIsTooLargeException(
> >LocalizedFormats.LOWER_BOUND_NOT_BELOW_UPPER_BOUND,
> >lower, upper, false);
> > }
> > ---CUT---
> >
> > The test referred to above was using this code (before I changed it use a
> > "UniformIntegerDistribution" instance):
> > ---CUT---
> > final int next = (i == 4 || cur == length - 1) ? length - 1 :
> > randomData.nextInt(cur, length - 1);
> > ---CUT---
> >
> > It is now (after the change):
> > ---CUT---
> > final IntegerDistribution partitionPoint = new
> > UniformIntegerDistribution(cur, length - 1);
> > final int next = (i == 4 || cur == length - 1) ? length - 1 :
> > partitionPoint.sample();
> > ---CUT---
> >
> > Thus, AFAIK, the failure did not appear before because there was no
> > precondition enforcement in "nextInt".
> >
> > The question is: Was the code in the test correct (in allowing the same
> > value for both bounds?
> > * In the negative, how to change it?
> > * The affirmative would mean that the precondition check in
> >"UniformIntegerDistribution" should be relaxed to allow equal bounds.
> >Does this make sense?
> >If so, can we change it now, or is it forbidden in order to stay
> >backwards compatible?
>
> Your analysis above is correct. The failure after the change is due
> to the fact that post-change the distribution is instantiated before
> the bounds check. I changed the test to fix this.
Thanks.
> Both the
> randomData nextInt and the UniformIntegerDistribution constructor
> now forbid the degenerate case where there is only one point in the
> domain. In retrospect, I guess it would have probably been better
> to allow this degenerate case. Unfortunately, this would be an
> incompatible change, so will have to wait until 4.0 if we want to do it.
>
> The original code above illustrates the convenience of being able to
> just make direct calls to randomData.nextXxx, which is why this
> class exists ;)
As I wrote in another post, I'm not against the convenience methods. But
IMO, they should be located in a new "DistributionUtils" class.
And we should also find a way to remove the code duplication (in the
distribution's "sample()" method and in the corresponding "next..." method).
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1369591 - /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optimization/linear/SimplexSolver.java
On Sun, Aug 05, 2012 at 02:00:33PM -, t...@apache.org wrote: > Author: tn > Date: Sun Aug 5 14:00:33 2012 > New Revision: 1369591 > > URL: http://svn.apache.org/viewvc?rev=1369591&view=rev > Log: > Fixed warnings spotted by checkgilles. Thanks! ;-) Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [MATH] Test failure in Continuum
On 8/5/12 3:49 PM, Gilles Sadowski wrote:
> On Sun, Aug 05, 2012 at 12:54:11PM -0700, Phil Steitz wrote:
>> On 8/4/12 10:57 AM, Gilles Sadowski wrote:
>>> Hello.
>>>
>>> Referring to this failed test (cf. messages from Continuum):
>>> ---CUT---
>>> org.apache.commons.math3.exception.NumberIsTooLargeException: lower bound
>>> (65) must be strictly less than upper bound (65)
>>> at
>>> org.apache.commons.math3.distribution.UniformIntegerDistribution.(UniformIntegerDistribution.java:73)
>>> at
>>> org.apache.commons.math3.distribution.UniformIntegerDistribution.(UniformIntegerDistribution.java:53)
>>> at
>>> org.apache.commons.math3.stat.descriptive.AggregateSummaryStatisticsTest.generatePartition(AggregateSummaryStatisticsTest.java:275)
>>> at
>>> org.apache.commons.math3.stat.descriptive.AggregateSummaryStatisticsTest.testAggregationConsistency(AggregateSummaryStatisticsTest.java:89)
>>>
>>>
>>> It is due to a precondition check while creating the
>>> "UniformIntegerDistribution" instance:
>>> ---CUT---
>>> if (lower >= upper) {
>>> throw new NumberIsTooLargeException(
>>>LocalizedFormats.LOWER_BOUND_NOT_BELOW_UPPER_BOUND,
>>>lower, upper, false);
>>> }
>>> ---CUT---
>>>
>>> The test referred to above was using this code (before I changed it use a
>>> "UniformIntegerDistribution" instance):
>>> ---CUT---
>>> final int next = (i == 4 || cur == length - 1) ? length - 1 :
>>> randomData.nextInt(cur, length - 1);
>>> ---CUT---
>>>
>>> It is now (after the change):
>>> ---CUT---
>>> final IntegerDistribution partitionPoint = new
>>> UniformIntegerDistribution(cur, length - 1);
>>> final int next = (i == 4 || cur == length - 1) ? length - 1 :
>>> partitionPoint.sample();
>>> ---CUT---
>>>
>>> Thus, AFAIK, the failure did not appear before because there was no
>>> precondition enforcement in "nextInt".
>>>
>>> The question is: Was the code in the test correct (in allowing the same
>>> value for both bounds?
>>> * In the negative, how to change it?
>>> * The affirmative would mean that the precondition check in
>>>"UniformIntegerDistribution" should be relaxed to allow equal bounds.
>>>Does this make sense?
>>>If so, can we change it now, or is it forbidden in order to stay
>>>backwards compatible?
>> Your analysis above is correct. The failure after the change is due
>> to the fact that post-change the distribution is instantiated before
>> the bounds check. I changed the test to fix this.
> Thanks.
>
>> Both the
>> randomData nextInt and the UniformIntegerDistribution constructor
>> now forbid the degenerate case where there is only one point in the
>> domain. In retrospect, I guess it would have probably been better
>> to allow this degenerate case. Unfortunately, this would be an
>> incompatible change, so will have to wait until 4.0 if we want to do it.
>>
>> The original code above illustrates the convenience of being able to
>> just make direct calls to randomData.nextXxx, which is why this
>> class exists ;)
> As I wrote in another post, I'm not against the convenience methods. But
> IMO, they should be located in a new "DistributionUtils" class.
Why? RandomData is pretty descriptive and exactly what these
methods do. They generate random data.
> And we should also find a way to remove the code duplication (in the
> distribution's "sample()" method and in the corresponding "next..." method).
+1 - the implementations can be moved. When I last looked
carefully at this, the distribution methods were delegating to impls
in RandomDataImpl. What we have agreed is to move the impls into
the distribution classes for the basic sampling methods. That
should not be too hard to do. I will do that if no one beats me to it.
Phil
I a
>
>
> 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: [MATH] Test failure in Continuum
> >> [...]
> >> The original code above illustrates the convenience of being able to
> >> just make direct calls to randomData.nextXxx, which is why this
> >> class exists ;)
> > As I wrote in another post, I'm not against the convenience methods. But
> > IMO, they should be located in a new "DistributionUtils" class.
>
> Why? RandomData is pretty descriptive and exactly what these
> methods do. They generate random data.
Fine...
But can we plan to merge "RandomData" and "RandomDataImpl"?
> > And we should also find a way to remove the code duplication (in the
> > distribution's "sample()" method and in the corresponding "next..." method).
>
> +1 - the implementations can be moved. When I last looked
> carefully at this, the distribution methods were delegating to impls
> in RandomDataImpl. What we have agreed is to move the impls into
> the distribution classes for the basic sampling methods. That
> should not be too hard to do. I will do that if no one beats me to it.
I did it in r1363604.
What still needs to be done is redirect the "next..." to the "sample()"
method of the appropriate distribution.
But I had already raised the issue of efficiency: each call to e.g.
nextInt(p, q)
will entail the instantiation of a UniformRealDistribution object.
What could be done is
1. create a static method in the distribution class
2. have the "sample()" method call that one
---
public class UniformRealDistribution extends ... {
// ...
public static int nextInt(RandomGenerator rng,
int a,
int b) {
final double u = rng.nextDouble();
return u * b + (1 - u) * a;
}
public int sample() {
// Here "random", "lower" and "upper" are instance variables.
return nextInt(random, lower, upper);
}
}
---
And "nextInt" from "RandomDataImpl" would also be redirected to the static
method in the distribution class:
---
import org.apache.commons.math3.distribution.UniformRealDistribution;
public class RandomDataImpl ... {
// ...
public int nextInt(int lower, int upper) {
return UniformRealDistribution.nextInt(getRan(), lower, upper);
}
}
---
OK?
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] integer factorization
Thanks for the pointer to JAS, however its API is scary for someone who just want to get the factors of a "small" integer... If the factorization of integers is not in scope of commons math, what about removing it from "MathWishList" then ? Best regards, Sebastien Original Message: - From: J.Pietschmann j3322...@yahoo.de Date: Sun, 05 Aug 2012 23:26:37 +0200 To: dev@commons.apache.org Subject: Re: [math] integer factorization Am 04.08.2012 14:22, schrieb ma...@nimp.co.uk: > Thanks for your feedback and the pointer to PARI/GP. About existing stuff, > it seems there is none written in Java: I asked the question on > stackoverflow a while ago, nobody knows any library for the JVM. Hehe, even StackOverflow fails occasionally. Try http://krum.rz.uni-mannheim.de/jas/ for a start. Search for "java quadratic sieve" for some more code, although most of the results seems to be more sample code rather than production quality. I vaguely remember there should be up to 12 Java based projects including more or less sophisticated integer factorization stuff, although I'm not current there and most of them could be dead. > About the applications, well, I agree it is not the #1 required > functionality in most applications. Still applications beyond pure maths do > exist: hash tables, pseudo random numbers, cryptography, electronics... Yes, developing and testing hash algorithms, pseudo random number generators, crypto stuff etc. uses factorization, but everyday use generally doesn't. Apparently you are into serious hard core stuff. As fascinating as these problems most likely are, they are not the primary target for commons math, at least until now. J.Pietschmann - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org myhosting.com - Premium Microsoft® Windows® and Linux web and application hosting - http://link.myhosting.com/myhosting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [MATH] Test failure in Continuum
On 8/5/12 5:30 PM, Gilles Sadowski wrote:
[...]
The original code above illustrates the convenience of being able to
just make direct calls to randomData.nextXxx, which is why this
class exists ;)
>>> As I wrote in another post, I'm not against the convenience methods. But
>>> IMO, they should be located in a new "DistributionUtils" class.
>> Why? RandomData is pretty descriptive and exactly what these
>> methods do. They generate random data.
> Fine...
> But can we plan to merge "RandomData" and "RandomDataImpl"?
Definitely want to do this. Unfortunately, it is incompatible
change. I guess we could create a new class named something else,
deprecate both of the above and have RandomDataImpl delegate to the
new class. How about RandomDataGenerator in the random package as
the new class?
>
>>> And we should also find a way to remove the code duplication (in the
>>> distribution's "sample()" method and in the corresponding "next..." method).
>> +1 - the implementations can be moved. When I last looked
>> carefully at this, the distribution methods were delegating to impls
>> in RandomDataImpl. What we have agreed is to move the impls into
>> the distribution classes for the basic sampling methods. That
>> should not be too hard to do. I will do that if no one beats me to it.
> I did it in r1363604.
> What still needs to be done is redirect the "next..." to the "sample()"
> method of the appropriate distribution.
> But I had already raised the issue of efficiency: each call to e.g.
> nextInt(p, q)
> will entail the instantiation of a UniformRealDistribution object.
>
> What could be done is
> 1. create a static method in the distribution class
> 2. have the "sample()" method call that one
>
> ---
> public class UniformRealDistribution extends ... {
> // ...
>
> public static int nextInt(RandomGenerator rng,
> int a,
> int b) {
> final double u = rng.nextDouble();
> return u * b + (1 - u) * a;
> }
>
> public int sample() {
> // Here "random", "lower" and "upper" are instance variables.
> return nextInt(random, lower, upper);
> }
> }
> ---
>
> And "nextInt" from "RandomDataImpl" would also be redirected to the static
> method in the distribution class:
>
> ---
> import org.apache.commons.math3.distribution.UniformRealDistribution;
>
> public class RandomDataImpl ... {
> // ...
>
> public int nextInt(int lower, int upper) {
> return UniformRealDistribution.nextInt(getRan(), lower, upper);
> }
> }
> ---
>
> OK?
>
>
> 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
[math] MATH-841 gcd speed up
Hello, The gcd(int,int) method of ArithmeticUtils seems 2 times slower than the naive approach using modulo operator. Gilles tested the patch separately and found similar performance penalty. Please check it out: https://issues.apache.org/jira/browse/MATH-841?page=com.atlassian.jira.plugi n.system.issuetabpanels:comment-tabpanel&focusedCommentId=13428944#comment-1 3428944 Anyone aware of an environment were the modulo operator is painfully slow ? Gilles pointed out that my patch don't conform to CM formating style, I will correct that as well as the javadoc (its mention of the binary gcd algorithm) if the code change is basically approved here. Please let me know. Sebastien mail2web.com - Microsoft® Exchange solutions from a leading provider - http://link.mail2web.com/Business/Exchange - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] integer factorization
On Sun, Aug 05, 2012 at 08:43:57PM -0400, ma...@nimp.co.uk wrote: > Thanks for the pointer to JAS, however its API is scary for someone who > just want to get the factors of a "small" integer... > If the factorization of integers is not in scope of commons math, what > about removing it from "MathWishList" then ? Maybe we can add it in "ArithmeticUtils". However do you have a concrete use-case for this feature? Given the scarce human resources, Commons Math cannot currently be a source code repository for everything that could hypothetically be useful. What about an implementation with "BigInteger"? I'd guess that would make the feature more apt to be used in "real" applications (just guessing). Best regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-logging-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-logging-test 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-logging-test : Apache Commons
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-logging-test/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/apache-commons/logging/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/logging/pom.xml
-INFO- Project Reports in:
/srv/gump/public/workspace/apache-commons/logging/target/surefire-reports
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-logging-test/gump_work/build_apache-commons_commons-logging-test.html
Work Name: build_apache-commons_commons-logging-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 50 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings
/srv/gump/public/workspace/apache-commons/logging/gump_mvn_settings.xml test
[Working Directory: /srv/gump/public/workspace/apache-commons/logging]
M2_HOME: /opt/maven2
-
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Compiling 52 source files to
/srv/gump/public/workspace/apache-commons/logging/target/test-classes
Downloading:
http://localhost:8192/maven2/org/apache/maven/surefire/surefire-booter/2.9/surefire-booter-2.9.pom
2K downloaded (surefire-booter-2.9.pom)
Downloading:
http://localhost:8192/maven2/org/apache/maven/surefire/surefire-api/2.9/surefire-api-2.9.pom
2K downloaded (surefire-api-2.9.pom)
Downloading:
http://localhost:8192/maven2/org/apache/maven/surefire/maven-surefire-common/2.9/maven-surefire-common-2.9.pom
3K downloaded (maven-surefire-common-2.9.pom)
Downloading:
http://localhost:8192/maven2/org/apache/maven/surefire/surefire-booter/2.9/surefire-booter-2.9.jar
32K downloaded (surefire-booter-2.9.jar)
Downloading:
http://localhost:8192/maven2/org/apache/maven/surefire/surefire-api/2.9/surefire-api-2.9.jar
155K downloaded (surefire-api-2.9.jar)
Downloading:
http://localhost:8192/maven2/org/apache/maven/surefire/maven-surefire-common/2.9/maven-surefire-common-2.9.jar
59K downloaded (maven-surefire-common-2.9.jar)
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory:
/srv/gump/public/workspace/apache-commons/logging/target/surefire-reports
Downloading:
http://localhost:8192/maven2/org/apache/maven/surefire/surefire-junit3/2.9/surefire-junit3-2.9.pom
1K downloaded (surefire-junit3-2.9.pom)
Downloading:
http://localhost:8192/maven2/org/apache/maven/surefire/surefire-providers/2.9/surefire-providers-2.9.pom
2K downloaded (surefire-providers-2.9.pom)
Downloading:
http://localhost:8192/maven2/org/apache/maven/surefire/surefire-junit3/2.9/surefire-junit3-2.9.jar
25K downloaded (surefire-junit3-2.9.jar)
---
T E S T S
---
Running org.apache.commons.logging.avalon.AvalonLoggerTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.072 sec
Running org.apache.commons.logging.WeakHashTableTestCase
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 9.317 sec <<<
FAILURE!
Results :
Failed tests:
testLOGGING_119(org.apache.commons.logging.WeakHashTableTestCase): Attempt: 161
Stuck threads: 10
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] There are test failures.
Please refer to
/srv/gump/public/workspace/apache-commons/logging/target/surefire-reports for
the individual test results.
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 48 seconds
[INFO] Finished at: Mon Aug 06 03:05:43 UTC 2012
[INFO] Final Memory: 39M/95M
[INFO]
-
To subscribe to this information via syndicated feeds:
- RSS:
http://vmgump.apache.org/gump/public/apache-commons/commons-logging-test/rss.xml
- Atom:
http://vmgump.apache.org/gu
[GUMP@vmgump]: Project commons-io-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-io-test has an issue affecting its community integration. This issue affects 1 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-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: 2 mins 12 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.123 sec Running org.apache.commons.io.comparator.DirectoryFileComparatorTest Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.148 sec Running org.apache.commons.io.comparator.ExtensionFileComparatorTest Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.124 sec Running org.apache.commons.io.comparator.PathFileComparatorTest Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.132 sec Running org.apache.commons.io.comparator.NameFileComparatorTest Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.134 sec Running org.apache.commons.io.IOUtilsTestCase Tests run: 63, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.715 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.266 sec Running org.apache.commons.io.FileUtilsCleanDirectoryTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.197 sec Running org.apache.commons.io.IOUtilsWriteTestCase Tests run: 53, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.394 sec Running org.apache.commons.io.FilenameUtilsWildcardTestCase Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.186 sec Running org.apache.commons.io.FileUtilsListFilesTestCase Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.153 sec Running org.apache.commons.io.FileSystemUtilsTestCase Tests run: 28, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.31 sec Running org.apache.commons.io.DirectoryWalkerTestCaseJava4 Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.281 sec Results : Failed tests: testIsFileNewerOlder(org.apache.commons.io.FileUtilsTestCase): New File - Newer - Date Tests run: 966, Failures: 1, Errors: 0, Skipped: 0 [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: 2 minutes 10 seconds [INFO] Finished at: Mon Aug 06 03:57:18 UTC 2012 [INFO] Final Memory: 31M/76M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-io-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-io-test/atom.xml =
Re: [math] MATH-841 gcd speed up
On 8/5/12 6:44 PM, ma...@nimp.co.uk wrote: > Hello, > > The gcd(int,int) method of ArithmeticUtils seems 2 times slower than the > naive approach using modulo operator. > Gilles tested the patch separately and found similar performance penalty. > Please check it out: > https://issues.apache.org/jira/browse/MATH-841?page=com.atlassian.jira.plugi > n.system.issuetabpanels:comment-tabpanel&focusedCommentId=13428944#comment-1 > 3428944 > > Anyone aware of an environment were the modulo operator is painfully slow ? > > Gilles pointed out that my patch don't conform to CM formating style, I > will correct that as well as the javadoc (its mention of the binary gcd > algorithm) if the code change is basically approved here. Please let me > know. It is probably worth doing some research in the archives on this function. I suspect there are reasons for the implementation choices made in the current impl. Could be bad reasons / bad impl, but IIRC there was a fair amount of discussion on this. Phil > > Sebastien > > > mail2web.com - Microsoft® Exchange solutions from a leading provider - > http://link.mail2web.com/Business/Exchange > > > > - > 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-digester3 (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-digester3 has an issue affecting its community integration.
This issue affects 2 projects,
and has been outstanding for 3 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 24 secs
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: 1344228388290
[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.a
Re: [MATH] Test failure in Continuum
> What could be done is
> 1. create a static method in the distribution class
> 2. have the "sample()" method call that one
+1. I like that the sample implementation for a distribution is in the
actual distribution class.
Denis
On 08/06/2012 02:30 AM, Gilles Sadowski wrote:
[...]
The original code above illustrates the convenience of being able to
just make direct calls to randomData.nextXxx, which is why this
class exists ;)
As I wrote in another post, I'm not against the convenience methods. But
IMO, they should be located in a new "DistributionUtils" class.
Why? RandomData is pretty descriptive and exactly what these
methods do. They generate random data.
Fine...
But can we plan to merge "RandomData" and "RandomDataImpl"?
And we should also find a way to remove the code duplication (in the
distribution's "sample()" method and in the corresponding "next..." method).
+1 - the implementations can be moved. When I last looked
carefully at this, the distribution methods were delegating to impls
in RandomDataImpl. What we have agreed is to move the impls into
the distribution classes for the basic sampling methods. That
should not be too hard to do. I will do that if no one beats me to it.
I did it in r1363604.
What still needs to be done is redirect the "next..." to the "sample()"
method of the appropriate distribution.
But I had already raised the issue of efficiency: each call to e.g.
nextInt(p, q)
will entail the instantiation of a UniformRealDistribution object.
What could be done is
1. create a static method in the distribution class
2. have the "sample()" method call that one
---
public class UniformRealDistribution extends ... {
// ...
public static int nextInt(RandomGenerator rng,
int a,
int b) {
final double u = rng.nextDouble();
return u * b + (1 - u) * a;
}
public int sample() {
// Here "random", "lower" and "upper" are instance variables.
return nextInt(random, lower, upper);
}
}
---
And "nextInt" from "RandomDataImpl" would also be redirected to the static
method in the distribution class:
---
import org.apache.commons.math3.distribution.UniformRealDistribution;
public class RandomDataImpl ... {
// ...
public int nextInt(int lower, int upper) {
return UniformRealDistribution.nextInt(getRan(), lower, upper);
}
}
---
OK?
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: [MATH] Test failure in Continuum
See below.
On 08/06/2012 12:49 AM, Gilles Sadowski wrote:
On Sun, Aug 05, 2012 at 12:54:11PM -0700, Phil Steitz wrote:
On 8/4/12 10:57 AM, Gilles Sadowski wrote:
Hello.
Referring to this failed test (cf. messages from Continuum):
---CUT---
org.apache.commons.math3.exception.NumberIsTooLargeException: lower bound (65)
must be strictly less than upper bound (65)
at
org.apache.commons.math3.distribution.UniformIntegerDistribution.(UniformIntegerDistribution.java:73)
at
org.apache.commons.math3.distribution.UniformIntegerDistribution.(UniformIntegerDistribution.java:53)
at
org.apache.commons.math3.stat.descriptive.AggregateSummaryStatisticsTest.generatePartition(AggregateSummaryStatisticsTest.java:275)
at
org.apache.commons.math3.stat.descriptive.AggregateSummaryStatisticsTest.testAggregationConsistency(AggregateSummaryStatisticsTest.java:89)
It is due to a precondition check while creating the
"UniformIntegerDistribution" instance:
---CUT---
if (lower>= upper) {
throw new NumberIsTooLargeException(
LocalizedFormats.LOWER_BOUND_NOT_BELOW_UPPER_BOUND,
lower, upper, false);
}
---CUT---
The test referred to above was using this code (before I changed it use a
"UniformIntegerDistribution" instance):
---CUT---
final int next = (i == 4 || cur == length - 1) ? length - 1 :
randomData.nextInt(cur, length - 1);
---CUT---
It is now (after the change):
---CUT---
final IntegerDistribution partitionPoint = new UniformIntegerDistribution(cur,
length - 1);
final int next = (i == 4 || cur == length - 1) ? length - 1 :
partitionPoint.sample();
---CUT---
Thus, AFAIK, the failure did not appear before because there was no
precondition enforcement in "nextInt".
The question is: Was the code in the test correct (in allowing the same
value for both bounds?
* In the negative, how to change it?
* The affirmative would mean that the precondition check in
"UniformIntegerDistribution" should be relaxed to allow equal bounds.
Does this make sense?
If so, can we change it now, or is it forbidden in order to stay
backwards compatible?
Your analysis above is correct. The failure after the change is due
to the fact that post-change the distribution is instantiated before
the bounds check. I changed the test to fix this.
Thanks.
Both the
randomData nextInt and the UniformIntegerDistribution constructor
now forbid the degenerate case where there is only one point in the
domain. In retrospect, I guess it would have probably been better
to allow this degenerate case. Unfortunately, this would be an
incompatible change, so will have to wait until 4.0 if we want to do it.
The original code above illustrates the convenience of being able to
just make direct calls to randomData.nextXxx, which is why this
class exists ;)
As I wrote in another post, I'm not against the convenience methods. But
IMO, they should be located in a new "DistributionUtils" class.
And we should also find a way to remove the code duplication (in the
distribution's "sample()" method and in the corresponding "next..." method).
The RandomData class (or whatever it would be called) does indeed seem
useful. If we plan to keep it, we should probably make sure that there is a
sample/next/... method in that class for EVERY distribution, as some of
them are missing, if I remember correctly. Perhaps this is a separate issue
though?
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
