[GUMP@vmgump]: Project commons-chain2 (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-chain2 has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 20 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-chain2 : GoF "Chain of Responsibility" pattern Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole jar output [commons-chain2-*[0-9T].jar] identifier set to project name -DEBUG- Sole pom output [pom.xml] identifier set to project name -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/chain/pom.xml -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/gump_work/build_apache-commons_commons-chain2.html Work Name: build_apache-commons_commons-chain2 (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 29 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/chain/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/apache-commons/chain] M2_HOME: /opt/maven2 - [INFO] Building war: /srv/gump/public/workspace/apache-commons/chain/apps/cookbook-examples/target/chain-cookbook-examples-2.0-SNAPSHOT.war [INFO] [INFO] Building Apache Commons Chain :: Distribution Packages [INFO]task-segment: [package] [INFO] [INFO] snapshot org.apache.commons:commons-chain2-configuration:2.0-SNAPSHOT: checking for updates from apache.snapshots Downloading: http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.pom [INFO] Unable to find resource 'org.apache.commons:commons-chain2-configuration:pom:2.0-SNAPSHOT' in repository apache.snapshots (http://repository.apache.org/snapshots) Downloading: http://localhost:8192/repo/m2-snapshot-repository/org/apache/commons/commons-chain2-configuration/2.0-SNAPSHOT/commons-chain2-configuration-2.0-SNAPSHOT.jar [INFO] Unable to find resource 'org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT' in repository apache.snapshots (http://repository.apache.org/snapshots) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.commons -DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.commons -DartifactId=commons-chain2-configuration -Dversion=2.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT 2) org.apache.commons:commons-chain2-configuration:jar:2.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.apache.commons:commons-chain2:pom:2.0-SNAPSHOT from the specified remote repositories: gump-central (http://localhost:8192/maven2), gump-apache.snapshots (http://localhost:8192/repo/m2-snapshot-repository) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 25 seconds [INFO] Finished at: Mon Aug 06 08:19:59 UTC 2012 [INFO] Final Memory: 118M/283M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-chain2/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commo
Re: [math] MATH-841 gcd speed up
On 6 August 2012 04:58, Phil Steitz wrote: > 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. And then please add the details to the code itself for future readers/maintainers. > 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 > - 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 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-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: 28 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.005 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.048 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 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.013 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.321 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 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.078 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: 24 seconds [INFO] Finished at: Mon Aug 06 08:40:39 UTC 2012 [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.org/g
[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,
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-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: 31 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.278 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.102 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]
[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, 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-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-06082012.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: 3 secs 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: 2 seconds Finished at: Mon Aug 06 11:52:10 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 1106082012, vmgump.apache.org:vmgump:1106082012 Gump E-mail Identifier (unique within run) #51. -- 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] Test failure in Continuum
On Aug 5, 2012, at 11:21 PM, Dennis Hendriks wrote:
> 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?
>
All have the method now, but the impls delegate to RandomDataImpl. In some
cases, there is nothing better implemented than just inversion, provided by the
default inversion sampler. That is OK. What we need to do is just move the
implementations of the default and specialized samplers to the actual
distribution classes. These can't be static, as they use the RamdomData
instance. I will take care of this.
Phil
>>
>> 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
>
-
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.
Dennis
On 08/06/2012 02:48 PM, Phil Steitz wrote:
On Aug 5, 2012, at 11:21 PM, Dennis Hendriks wrote:
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?
All have the method now, but the impls delegate to RandomDataImpl. In some
cases, there is nothing better implemented than just inversion, provided by the
default inversion sampler. That is OK. What we need to do is just move the
implementations of the default and specialized samplers to the actual
distribution classes. These can't be static, as they use the RamdomData
instance. I will take care of this.
I'm not sure if I made myself clear. I meant to say that not all
distributions have a corresponding nextX method in RandomData(Impl). What I
propose is to make sure that for every distribution class, there is a
corresponding method in RandomData(Impl) to make sure that RandomData(Impl)
is actually a substitute for using the distributions.
Obviously, the implementation should be only in the distributions OR in the
RandomDataImpl. I agree that in the distributions would be better. I like
the static methods in distributions idea.
Phil
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
On Mon, Aug 06, 2012 at 05:48:14AM -0700, Phil Steitz wrote:
>
>
>
>
> On Aug 5, 2012, at 11:21 PM, Dennis Hendriks wrote:
>
> > 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?
> >
>
> All have the method now, but the impls delegate to RandomDataImpl.
They do not.
> In some cases, there is nothing better implemented than just inversion,
> provided by the default inversion sampler. That is OK. What we need to do
> is just move the implementations of the default and specialized samplers to
> the actual distribution classes. These can't be static, as they use the
> RamdomData instance. I will take care of this.
Thanks for reading fully this message
http://markmail.org/message/5fpmwyiiw2xq4o3q
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 Aug 6, 2012, at 6:08 AM, Gilles Sadowski
wrote:
> On Mon, Aug 06, 2012 at 05:48:14AM -0700, Phil Steitz wrote:
>>
>>
>>
>>
>> On Aug 5, 2012, at 11:21 PM, Dennis Hendriks wrote:
>>
>>> 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?
>>>
>>
>> All have the method now, but the impls delegate to RandomDataImpl.
>
> They do not.
The method is in the interface. There is a default, inversion-based
implementation in the abstract base class. Not all distributions override the
default impl. The ones that do delegate to the specialized methods in
RandomDataImpl.
>
>> In some cases, there is nothing better implemented than just inversion,
>> provided by the default inversion sampler. That is OK. What we need to do
>> is just move the implementations of the default and specialized samplers to
>> the actual distribution classes. These can't be static, as they use the
>> RamdomData instance. I will take care of this.
>
> Thanks for reading fully this message
> http://markmail.org/message/5fpmwyiiw2xq4o3q
I don't get the desire to make sample() static. It us
[chain2] ServiceLoader in Chain2 to load Jackson supported formats
Hi all guys, I am prototyping the Jackson support as described in CHAIN-76 and found an elegant solution with ServiceLoader to support, via Jackson, multiple format support without hardcoding them in the ConfigParser code but rather loading available parsers at runtime. Since [chain2] hasn't been published yet and my prototype would require an API which is not available on Java5, we have 3 options: * using the [discovery] component * using a backport[1] component I wrote time ago for java5 (it's ALv2) * upgrade to java6 The second option sounds to me the more reasonable since uses java standard APIs and is Java6 compatible, while keeping Java5 backward compatibility... WDYT? Many thanks in advance, all the best! -Simo [1] http://99soft.github.com/backport-spi/ 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
Re: [chain2] ServiceLoader in Chain2 to load Jackson supported formats
I vote for going to Java 6. Java 6 is end of life in November, so it seems a bit silly to support two end of life versions of Java. One seems sufficient. That said - I may be breaking from the consensus here at the Apache Commons. -Elijah On Mon, Aug 6, 2012 at 8:13 AM, Simone Tripodi wrote: > Hi all guys, > > I am prototyping the Jackson support as described in CHAIN-76 and > found an elegant solution with ServiceLoader to support, via Jackson, > multiple format support without hardcoding them in the ConfigParser > code but rather loading available parsers at runtime. > > Since [chain2] hasn't been published yet and my prototype would > require an API which is not available on Java5, we have 3 options: > > * using the [discovery] component > > * using a backport[1] component I wrote time ago for java5 (it's ALv2) > > * upgrade to java6 > > The second option sounds to me the more reasonable since uses java > standard APIs and is Java6 compatible, while keeping Java5 backward > compatibility... > > WDYT? > Many thanks in advance, all the best! > -Simo > > [1] http://99soft.github.com/backport-spi/ > > 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 > -- -Elijah - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [chain2] ServiceLoader in Chain2 to load Jackson supported formats
+1 to upgrade to Java 6. On Mon, Aug 6, 2012 at 11:13 AM, Simone Tripodi wrote: > Hi all guys, > > I am prototyping the Jackson support as described in CHAIN-76 and > found an elegant solution with ServiceLoader to support, via Jackson, > multiple format support without hardcoding them in the ConfigParser > code but rather loading available parsers at runtime. > > Since [chain2] hasn't been published yet and my prototype would > require an API which is not available on Java5, we have 3 options: > > * using the [discovery] component > > * using a backport[1] component I wrote time ago for java5 (it's ALv2) > > * upgrade to java6 > > The second option sounds to me the more reasonable since uses java > standard APIs and is Java6 compatible, while keeping Java5 backward > compatibility... > > WDYT? > Many thanks in advance, all the best! > -Simo > > [1] http://99soft.github.com/backport-spi/ > > 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 > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [chain2] ServiceLoader in Chain2 to load Jackson supported formats
+1 for Java 6 as well. Matt On Mon, Aug 6, 2012 at 10:59 AM, James Carman wrote: > +1 to upgrade to Java 6. > > On Mon, Aug 6, 2012 at 11:13 AM, Simone Tripodi > wrote: >> Hi all guys, >> >> I am prototyping the Jackson support as described in CHAIN-76 and >> found an elegant solution with ServiceLoader to support, via Jackson, >> multiple format support without hardcoding them in the ConfigParser >> code but rather loading available parsers at runtime. >> >> Since [chain2] hasn't been published yet and my prototype would >> require an API which is not available on Java5, we have 3 options: >> >> * using the [discovery] component >> >> * using a backport[1] component I wrote time ago for java5 (it's ALv2) >> >> * upgrade to java6 >> >> The second option sounds to me the more reasonable since uses java >> standard APIs and is Java6 compatible, while keeping Java5 backward >> compatibility... >> >> WDYT? >> Many thanks in advance, all the best! >> -Simo >> >> [1] http://99soft.github.com/backport-spi/ >> >> 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 >> > > - > 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: [chain2] ServiceLoader in Chain2 to load Jackson supported formats
Democracy wins, long live Java6! :) thanks for the feedbacks! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Aug 6, 2012 at 6:08 PM, Matt Benson wrote: > +1 for Java 6 as well. > > Matt > > On Mon, Aug 6, 2012 at 10:59 AM, James Carman > wrote: >> +1 to upgrade to Java 6. >> >> On Mon, Aug 6, 2012 at 11:13 AM, Simone Tripodi >> wrote: >>> Hi all guys, >>> >>> I am prototyping the Jackson support as described in CHAIN-76 and >>> found an elegant solution with ServiceLoader to support, via Jackson, >>> multiple format support without hardcoding them in the ConfigParser >>> code but rather loading available parsers at runtime. >>> >>> Since [chain2] hasn't been published yet and my prototype would >>> require an API which is not available on Java5, we have 3 options: >>> >>> * using the [discovery] component >>> >>> * using a backport[1] component I wrote time ago for java5 (it's ALv2) >>> >>> * upgrade to java6 >>> >>> The second option sounds to me the more reasonable since uses java >>> standard APIs and is Java6 compatible, while keeping Java5 backward >>> compatibility... >>> >>> WDYT? >>> Many thanks in advance, all the best! >>> -Simo >>> >>> [1] http://99soft.github.com/backport-spi/ >>> >>> 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 >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [MATH] Test failure in Continuum
> > [...] > >>> > >>> 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? > >>> > >> > >> All have the method now, but the impls delegate to RandomDataImpl. > > > > They do not. > > The method is in the interface. There is a default, inversion-based > implementation in the abstract base class. Not all distributions override > the default impl. > The ones that do delegate to the specialized methods in RandomDataImpl. ^ No; as indicated before (cf. message referred to below), the distribution classes do not delegate anymore to "RandomDataImpl", since revision 1363604 (resolution of MATH-764 and MATH-823). > > > > >> In some cases, there is nothing better implemented than just inversion, > >> provided by the default inversion sampler. That is OK. What we need to > >> do is just move the implementations of the default and specialized > >> samplers to the actual distribution classes. These can't be static, as > >> they use the RamdomData instance. I will take care of this. > > > > Thanks for reading fully this message > > http://markmail.org/message/5fpmwyiiw2xq4o3q > > I don't get the desire to make sample() static. There is no such desire stated in that message. The proposed static method is a "helper" that will take everything needed as arguments. It will be defined in the appropriate distribution class, to be called both by "sample()" from that class and by the convenience methods in "RandomDataImpl". > [...] 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/6/12 11:41 AM, Gilles Sadowski wrote: >>> [...] > 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? > All have the method now, but the impls delegate to RandomDataImpl. >>> They do not. >> The method is in the interface. There is a default, inversion-based >> implementation in the abstract base class. Not all distributions override >> the default impl. >> The ones that do delegate to the specialized methods in RandomDataImpl >^ > > No; as indicated before (cf. message referred to below), the distribution > classes do not delegate anymore to "RandomDataImpl", since revision 1363604 > (resolution of MATH-764 and MATH-823). Sorry, my mistake. I see the code has been duplicated. I will see if I can modify the methods in RandomDataImpl to use the impls in the distribution classes. Should be possible by creating instances using the configured RandomGenerator. See more below. > In some cases, there is nothing better implemented than just inversion, provided by the default inversion sampler. That is OK. What we need to do is just move the implementations of the default and specialized samplers to the actual distribution classes. These can't be static, as they use the RamdomData instance. I will take care of this. >>> Thanks for reading fully this message >>> http://markmail.org/message/5fpmwyiiw2xq4o3q >> I don't get the desire to make sample() static. > There is no such desire stated in that message. > The proposed static method is a "helper" that will take everything needed as > arguments. It will be defined in the appropriate distribution class, to be > called both by "sample()" from that class and by the convenience methods in > "RandomDataImpl". OK, I now think I get what you mean. Non-static methods of "RandomDataImpl" could use static methods from the distribution classes, passing the configured RandomGenerator as an argument. Is that what you mean? I don't know how much direct usage the static methods in the distribution classes would get; since most actual examples involve generating sequences using the same generator repeatedly (so sample() is more natural). I guess "RandomDataImpl" would then not have to instantiate distributions, but there is not much overhead to creating the ones we have, so not sure it is worth the effort to add all of these methods. Phil > >> [...] > > 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
Fwd: svn commit: r1369931 - in /commons/proper/collections/trunk/src/main/java/org/apache/commons/collections: keyvalue/ list/
=== %< ==
Betreff: svn commit: r1369931 - in
/commons/proper/collections/trunk/src/main/java/org/apache/commons/collections:
keyvalue/ list/
Absender: tn-1odqgaof3lkdnm+yrof...@public.gmane.org
Datum: Mon, 06 Aug 2012 19:21:30 +
Newsgruppe: gmane.comp.jakarta.commons.scm
Author: tn
Date: Mon Aug 6 19:21:29 2012
New Revision: 1369931
URL: http://svn.apache.org/viewvc?rev=1369931&view=rev
Log:
Checkstyle fixes.
[snip]
@@ -55,14 +55,18 @@ public abstract class AbstractMapEntryDe
}
//---
+
+/** {@inheritDoc} */
public K getKey() {
return entry.getKey();
}
+/** {@inheritDoc} */
public V getValue() {
return entry.getValue();
}
+/** {@inheritDoc} */
public V setValue(V object) {
return entry.setValue(object);
}
=== %< ==
Geeez, what's that for an annoying change? Since Java 5 this is already the
default for Javadoc when overwriting/implementing methods, so adding a Javdoc
comment with a single @inheritDoc is completely superfluous and adds simply
clutter!
Can we stop Checkstyle complaining about it and revert these lines again?
- Jörg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: Fwd: svn commit: r1369931 - in /commons/proper/collections/trunk/src/main/java/org/apache/commons/collections: keyvalue/ list/
On 08/06/2012 10:00 PM, Jörg Schaible wrote:
>
> === %< ==
>
> Betreff: svn commit: r1369931 - in
> /commons/proper/collections/trunk/src/main/java/org/apache/commons/collections:
>
> keyvalue/ list/
> Absender: tn-1odqgaof3lkdnm+yrof...@public.gmane.org
> Datum: Mon, 06 Aug 2012 19:21:30 +
> Newsgruppe: gmane.comp.jakarta.commons.scm
>
> Author: tn
> Date: Mon Aug 6 19:21:29 2012
> New Revision: 1369931
>
> URL: http://svn.apache.org/viewvc?rev=1369931&view=rev
> Log:
> Checkstyle fixes.
>
> [snip]
>
> @@ -55,14 +55,18 @@ public abstract class AbstractMapEntryDe
> }
>
> //---
> +
> +/** {@inheritDoc} */
> public K getKey() {
> return entry.getKey();
> }
>
> +/** {@inheritDoc} */
> public V getValue() {
> return entry.getValue();
> }
>
> +/** {@inheritDoc} */
> public V setValue(V object) {
> return entry.setValue(object);
> }
> === %< ==
>
> Geeez, what's that for an annoying change? Since Java 5 this is already the
> default for Javadoc when overwriting/implementing methods, so adding a Javdoc
> comment with a single @inheritDoc is completely superfluous and adds simply
> clutter!
>
> Can we stop Checkstyle complaining about it and revert these lines again?
If you have a better solution, I am really willing to include it.
My suggestion to go for java 6 source compatibility to be able to use
@Override tags was so far objected.
Thomas
-
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 Mon, Aug 06, 2012 at 12:44:24PM -0700, Phil Steitz wrote: > On 8/6/12 11:41 AM, Gilles Sadowski wrote: > >>> [...] > > 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? > > > All have the method now, but the impls delegate to RandomDataImpl. > >>> They do not. > >> The method is in the interface. There is a default, inversion-based > >> implementation in the abstract base class. Not all distributions override > >> the default impl. > >> The ones that do delegate to the specialized methods in RandomDataImpl > >^ > > > > No; as indicated before (cf. message referred to below), the distribution > > classes do not delegate anymore to "RandomDataImpl", since revision 1363604 > > (resolution of MATH-764 and MATH-823). > > Sorry, my mistake. I see the code has been duplicated. I will see > if I can modify the methods in RandomDataImpl to use the impls in > the distribution classes. Should be possible by creating instances > using the configured RandomGenerator. Yes, that was what I also proposed when we started talking about transferring the (sampling) code from RAndomDataImpl over to the "sample()" methods. > See more below. > > > In some cases, there is nothing better implemented than just inversion, > provided by the default inversion sampler. That is OK. What we need to > do is just move the implementations of the default and specialized > samplers to the actual distribution classes. These can't be static, as > they use the RamdomData instance. I will take care of this. > >>> Thanks for reading fully this message > >>> http://markmail.org/message/5fpmwyiiw2xq4o3q > >> I don't get the desire to make sample() static. > > There is no such desire stated in that message. > > The proposed static method is a "helper" that will take everything needed as > > arguments. It will be defined in the appropriate distribution class, to be > > called both by "sample()" from that class and by the convenience methods in > > "RandomDataImpl". > > OK, I now think I get what you mean. Non-static methods of > "RandomDataImpl" could use static methods from the distribution > classes, passing the configured RandomGenerator as an argument. Is > that what you mean? Yes! :-) > I don't know how much direct usage the static > methods in the distribution classes would get; since most actual > examples involve generating sequences using the same generator > repeatedly (so sample() is more natural). I totally agree. They would exist only for the sake of not duplicating the sampling code. > I guess "RandomDataImpl" > would then not have to instantiate distributions, but there is not > much overhead to creating the ones we have, so not sure it is worth > the effort to add all of these methods. Fine then. I'd also prefer not to create new public methods just for the sake of a convenience class. I.e. we could mention (in "RandomDataImpl") that the convenience comes at a slight efficiency cost. [And that for heavy usage of sampling, one should use the distribution classes directly.] 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/6/12 2:28 PM, Gilles Sadowski wrote: > On Mon, Aug 06, 2012 at 12:44:24PM -0700, Phil Steitz wrote: >> On 8/6/12 11:41 AM, Gilles Sadowski wrote: > [...] >>> 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? >>> >> All have the method now, but the impls delegate to RandomDataImpl. > They do not. The method is in the interface. There is a default, inversion-based implementation in the abstract base class. Not all distributions override the default impl. The ones that do delegate to the specialized methods in RandomDataImpl >>>^ >>> >>> No; as indicated before (cf. message referred to below), the distribution >>> classes do not delegate anymore to "RandomDataImpl", since revision 1363604 >>> (resolution of MATH-764 and MATH-823). >> Sorry, my mistake. I see the code has been duplicated. I will see >> if I can modify the methods in RandomDataImpl to use the impls in >> the distribution classes. Should be possible by creating instances >> using the configured RandomGenerator. > Yes, that was what I also proposed when we started talking about > transferring the (sampling) code from RAndomDataImpl over to the "sample()" > methods. > >> See more below. >> In some cases, there is nothing better implemented than just inversion, >> provided by the default inversion sampler. That is OK. What we need to >> do is just move the implementations of the default and specialized >> samplers to the actual distribution classes. These can't be static, as >> they use the RamdomData instance. I will take care of this. > Thanks for reading fully this message > http://markmail.org/message/5fpmwyiiw2xq4o3q I don't get the desire to make sample() static. >>> There is no such desire stated in that message. >>> The proposed static method is a "helper" that will take everything needed as >>> arguments. It will be defined in the appropriate distribution class, to be >>> called both by "sample()" from that class and by the convenience methods in >>> "RandomDataImpl". >> OK, I now think I get what you mean. Non-static methods of >> "RandomDataImpl" could use static methods from the distribution >> classes, passing the configured RandomGenerator as an argument. Is >> that what you mean? > Yes! :-) > >> I don't know how much direct usage the static >> methods in the distribution classes would get; since most actual >> examples involve generating sequences using the same generator >> repeatedly (so sample() is more natural). > I totally agree. They would exist only for the sake of not duplicating the > sampling code. > >> I guess "RandomDataImpl" >> would then not have to instantiate distributions, but there is not >> much overhead to creating the ones we have, so not sure it is worth >> the effort to add all of these methods. > Fine then. I'd also prefer not to create new public methods just for the > sake of a convenience class. > I.e. we could mention (in "RandomDataImpl") that the convenience comes at a > slight efficiency cost. [And that for heavy usage of sampling, one should > use the distribution classes directly.] OK, sorry to be a little thick on this. I think I can do this. Thanks! Phil > > > 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] spinning BOBYQAOptimizerTest
On Sun, Aug 05, 2012 at 03:13:33PM -0700, Phil Steitz wrote: > 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) Runs fine here... Excerpt from Cobertura report: BOBYQAOptimizer 87% 1022/1162 84% 525/624 23 Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] spinning BOBYQAOptimizerTest
On 8/6/12 2:53 PM, Gilles Sadowski wrote: > On Sun, Aug 05, 2012 at 03:13:33PM -0700, Phil Steitz wrote: >> 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) > Runs fine here... > Excerpt from Cobertura report: > BOBYQAOptimizer 87% 1022/1162 84% 525/624 23 Interesting. Hangs every time for me on BOBYQAOptimizer.doOptimize(BOBYQAOptimizer.java:246) running Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) java version "1.6.0_33" Java(TM) SE Runtime Environment (build 1.6.0_33-b03-424-11M3720) Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03-424, mixed mode) Phil > > > 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] spinning BOBYQAOptimizerTest
On Mon, Aug 06, 2012 at 03:21:04PM -0700, Phil Steitz wrote: > On 8/6/12 2:53 PM, Gilles Sadowski wrote: > > On Sun, Aug 05, 2012 at 03:13:33PM -0700, Phil Steitz wrote: > >> 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) > > Runs fine here... > > Excerpt from Cobertura report: > > BOBYQAOptimizer 87% 1022/1162 84% 525/624 23 > > Interesting. Hangs every time for me on > > BOBYQAOptimizer.doOptimize(BOBYQAOptimizer.java:246) > > running > > Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) > java version "1.6.0_33" > Java(TM) SE Runtime Environment (build 1.6.0_33-b03-424-11M3720) > Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03-424, mixed mode) > $ mvn -version Apache Maven 3.0.4 Maven home: /usr/share/maven Java version: 1.7.0_03-icedtea, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-7-openjdk-amd64/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "2.6.32-5-vserver-amd64", arch: "amd64", family: "unix" 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: 58 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.038 sec
Running org.apache.commons.logging.WeakHashTableTestCase
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 10.031 sec <<<
FAILURE!
Results :
Failed tests:
testLOGGING_119(org.apache.commons.logging.WeakHashTableTestCase): Attempt: 142
Stuck threads: 9
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: 56 seconds
[INFO] Finished at: Tue Aug 07 00:25:28 UTC 2012
[INFO] Final Memory: 39M/94M
[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
Fwd: Re: [MATH] Test failure in Continuum
Forward to commons-dev, as the reply was (accidentally?) only sent to me...
Dennis
Original Message
Subject: Re: [MATH] Test failure in Continuum
Date: Mon, 6 Aug 2012 17:29:59 +0200
From: Phil Steitz
To: Hendriks, D.
On Aug 6, 2012, at 6:06 AM, Dennis Hendriks wrote:
See below.
Dennis
On 08/06/2012 02:48 PM, Phil Steitz wrote:
On Aug 5, 2012, at 11:21 PM, Dennis Hendriks wrote:
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?
All have the method now, but the impls delegate to RandomDataImpl. In some
cases, there is nothing better implemented than just inversion, provided by the
default inversion sampler. That is OK. What we need to do is just move the
implementations of the default and specialized samplers to the actual
distribution classes. These can't be static, as they use the RamdomData
instance. I will take care of this.
I'm not sure if I made myself clear. I meant to say that not all distributions
have a corresponding nextX method in RandomData(Impl). What I propose is to
make sure that for every distribution class, there is a corresponding method in
RandomData(Impl) to make sure that RandomData(Impl) is actually a substitute
for using the distributions.
I get it now, but I don't think I agree. RandomData is meant to be a
general-purpose class used for generating random data with commonly
desired characteristics, like coming from commonly used distributions such
as Poisson, Gaussian, etc. This class predates the sample() method that
has been added to *all* distributions. The default implementation of
sampling for re
Re: [MATH] Test failure in Continuum
See below.
On 08/06/2012 05:29 PM, Phil Steitz wrote:
On Aug 6, 2012, at 6:06 AM, Dennis Hendriks wrote:
See below.
Dennis
On 08/06/2012 02:48 PM, Phil Steitz wrote:
On Aug 5, 2012, at 11:21 PM, Dennis Hendriks wrote:
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?
All have the method now, but the impls delegate to RandomDataImpl. In some
cases, there is nothing better implemented than just inversion, provided by the
default inversion sampler. That is OK. What we need to do is just move the
implementations of the default and specialized samplers to the actual
distribution classes. These can't be static, as they use the RamdomData
instance. I will take care of this.
I'm not sure if I made myself clear. I meant to say that not all distributions
have a corresponding nextX method in RandomData(Impl). What I propose is to
make sure that for every distribution class, there is a corresponding method in
RandomData(Impl) to make sure that RandomData(Impl) is actually a substitute
for using the distributions.
I get it now, but I don't think I agree. RandomData is meant to be a
general-purpose class used for generating random data with commonly desired
characteristics, like coming from commonly used distributions such as Poisson,
Gaussian, etc. This class predates the sample() method that has been added to
*all* distributions. The default implementation of sampling for real
distributions (inversion-based sampling) has no dependency on RandomDataImpl,
but the specialized implementations (impls that are better than inversion) for
some dis
