[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 52 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: 11 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.159 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 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: 10 seconds [INFO] Finished at: Mon Aug 22 10:48:39 UTC 2011 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom: http://vmgump.apache.o
Re: [chain][discuss] v2 upgrade
I am generally in favor. I think it could be good to apply his patch on a branch so we can discuss the clirr results and agree on the severity of the (IMHO forgivable) backward-compatibility breaches. Then we will understand the proper path forward with respect to versions and all the changes that cascade from the potential major version bump. Matt On Mon, Aug 22, 2011 at 1:03 AM, Simone Tripodi wrote: > Hi all guys, > Elijah, a [chain] user, has been submitting worthy contributions[1] to > improve and actualize the commons-chains component, providing also > patches[2]. > I think it is the good time to start speaking about the next [chain] > version (no new releases/development in the last months), any > objections on applying Elijah patch? > I can take care of it but please let me know if anyone else want to do. > Many thanks in advance, have a nice day!!! > Simo > > [1] http://markmail.org/message/ajh3sunrst7x5klv > [2] https://issues.apache.org/jira/browse/CHAIN-53 > > http://people.apache.org/~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: [chain][discuss] v2 upgrade
Any thoughts on dumping the checked exception?
public interface Command { ... boolean execute(T
context) throws Exception; }
Paul
On Mon, Aug 22, 2011 at 9:46 AM, Matt Benson wrote:
> I am generally in favor. I think it could be good to apply his patch
> on a branch so we can discuss the clirr results and agree on the
> severity of the (IMHO forgivable) backward-compatibility breaches.
> Then we will understand the proper path forward with respect to
> versions and all the changes that cascade from the potential major
> version bump.
>
> Matt
>
> On Mon, Aug 22, 2011 at 1:03 AM, Simone Tripodi
> wrote:
>> Hi all guys,
>> Elijah, a [chain] user, has been submitting worthy contributions[1] to
>> improve and actualize the commons-chains component, providing also
>> patches[2].
>> I think it is the good time to start speaking about the next [chain]
>> version (no new releases/development in the last months), any
>> objections on applying Elijah patch?
>> I can take care of it but please let me know if anyone else want to do.
>> Many thanks in advance, have a nice day!!!
>> Simo
>>
>> [1] http://markmail.org/message/ajh3sunrst7x5klv
>> [2] https://issues.apache.org/jira/browse/CHAIN-53
>>
>> http://people.apache.org/~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: [chain][discuss] v2 upgrade
On 22 August 2011 15:53, Paul Benedict wrote:
> Any thoughts on dumping the checked exception?
> public interface Command { ... boolean execute(T
> context) throws Exception; }
No view on whether it is needed or not.
I'd just point out that Exceptions are not part of the method
signatures used to resolve run-time references, so they only affect
source compatibility, not binary compatibility.
> Paul
>
> On Mon, Aug 22, 2011 at 9:46 AM, Matt Benson wrote:
>> I am generally in favor. I think it could be good to apply his patch
>> on a branch so we can discuss the clirr results and agree on the
>> severity of the (IMHO forgivable) backward-compatibility breaches.
>> Then we will understand the proper path forward with respect to
>> versions and all the changes that cascade from the potential major
>> version bump.
>>
>> Matt
>>
>> On Mon, Aug 22, 2011 at 1:03 AM, Simone Tripodi
>> wrote:
>>> Hi all guys,
>>> Elijah, a [chain] user, has been submitting worthy contributions[1] to
>>> improve and actualize the commons-chains component, providing also
>>> patches[2].
>>> I think it is the good time to start speaking about the next [chain]
>>> version (no new releases/development in the last months), any
>>> objections on applying Elijah patch?
>>> I can take care of it but please let me know if anyone else want to do.
>>> Many thanks in advance, have a nice day!!!
>>> Simo
>>>
>>> [1] http://markmail.org/message/ajh3sunrst7x5klv
>>> [2] https://issues.apache.org/jira/browse/CHAIN-53
>>>
>>> http://people.apache.org/~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
Releasing components
I have copied the distribution artifacts to people.apache.org:/www/ www.apache.org/dist/commons/vfs and updated the README.html. I have published the site to people.apache.org:/www/commons.apache.org/vfs. I have told Nexus to release the component from staging. Am I missing anything? Is there something that needs to be done to "publish" these? Ralph
Re: Releasing components
On 22 August 2011 19:17, ralph.goers @dslextreme.com wrote: > I have copied the distribution artifacts to people.apache.org:/www/ > www.apache.org/dist/commons/vfs and updated the README.html. > I have published the site to people.apache.org:/www/commons.apache.org/vfs. > I have told Nexus to release the component from staging. > > Am I missing anything? Is there something that needs to be done to "publish" > these? Patience ;-) You need to wait until the mirrors have had time to catch up (allow a day for the slower ones) before making any announcements, otherwise there may be lots of complaints from users who cannot download the release. [Happened recently with Tomcat]. BTW, I assume we will be leaving the 1.0 release artifacts as a legacy release, as was done with Lang? > Ralph > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Releasing components
I've left the 1.0 web site out there as vfs1 for the time being. I figured I'd delete it once I could verify the new site. The artifacts for 1.0 are still in the dist directory but I seem to recall only the most current artifacts are supposed to be in there and the older stuff should be archived somewhere. I'm not a fan of deleting things until I'm sure I didn't screw it up. Unfortunately, neither of the two web pages I referenced are completely clear on this part of things. Ralph On Mon, Aug 22, 2011 at 11:36 AM, sebb wrote: > On 22 August 2011 19:17, ralph.goers @dslextreme.com > wrote: > > I have copied the distribution artifacts to people.apache.org:/www/ > > www.apache.org/dist/commons/vfs and updated the README.html. > > I have published the site to people.apache.org:/www/ > commons.apache.org/vfs. > > I have told Nexus to release the component from staging. > > > > Am I missing anything? Is there something that needs to be done to > "publish" > > these? > > Patience ;-) > > You need to wait until the mirrors have had time to catch up (allow a > day for the slower ones) before making any announcements, otherwise > there may be lots of complaints from users who cannot download the > release. [Happened recently with Tomcat]. > > BTW, I assume we will be leaving the 1.0 release artifacts as a legacy > release, as was done with Lang? > > > Ralph > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: Releasing components
On 22 August 2011 19:42, ralph.goers @dslextreme.com wrote: > I've left the 1.0 web site out there as vfs1 for the time being. I figured > I'd delete it once I could verify the new site. Ideally the new site should include links to 1.0 javadocs etc. > The artifacts for 1.0 are still in the dist directory but I seem to recall > only the most current artifacts are supposed to be in there and the older > stuff should be archived somewhere. That's only true for superceded releases, not different products as this is. So a week or so after 2.0.1 is released, 2.0 can be deleted from dist/ At some point in the future if there is no further need for VFS 1.0 then it can be deleted. Same with Lang and Math. > I'm not a fan of deleting things until I'm sure I didn't screw it up. > Unfortunately, neither of the two web pages I referenced are completely > clear on this part of things. WHich pages? > Ralph > > On Mon, Aug 22, 2011 at 11:36 AM, sebb wrote: > >> On 22 August 2011 19:17, ralph.goers @dslextreme.com >> wrote: >> > I have copied the distribution artifacts to people.apache.org:/www/ >> > www.apache.org/dist/commons/vfs and updated the README.html. >> > I have published the site to people.apache.org:/www/ >> commons.apache.org/vfs. >> > I have told Nexus to release the component from staging. >> > >> > Am I missing anything? Is there something that needs to be done to >> "publish" >> > these? >> >> Patience ;-) >> >> You need to wait until the mirrors have had time to catch up (allow a >> day for the slower ones) before making any announcements, otherwise >> there may be lots of complaints from users who cannot download the >> release. [Happened recently with Tomcat]. >> >> BTW, I assume we will be leaving the 1.0 release artifacts as a legacy >> release, as was done with Lang? >> >> > Ralph >> > >> >> - >> 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-646
Hi, I've just posted a new patch for the implementation of UnmodifiableRealVector. Thanks for your comments! Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[math] RealMatrix.set(double)
Hi, I believe that in o.a.c.m.linear.RealMatrix, there is no method set(double) which would set *all* entries to the same value. Such a method exists (and is useful) in o.a.c.m.linear.RealVector. I propose (if you think that could be useful) to open a JIRA issue. Thanks for your comments! Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Releasing components
On Mon, Aug 22, 2011 at 11:56 AM, sebb wrote: > On 22 August 2011 19:42, ralph.goers @dslextreme.com > > > > I'm not a fan of deleting things until I'm sure I didn't screw it up. > > Unfortunately, neither of the two web pages I referenced are completely > > clear on this part of things. > > WHich pages? > > http://wiki.apache.org/commons/CreatingReleases is the closest thing I've found to how to do a Maven-based release. http://commons.apache.org/releases/release.html (and its companion pages) are more about the manual process. The first page documents the maven release plugin but pretty much ignores the Nexus repository and doesn't really discuss where stuff is supposed to end up. The second page is useful in that it identifies the specific locations that should be updated but it completely ignores the release plugin and the Nexus repository. FWIW, none of the documentation covers the problems introduced by having a multi-module project.
Re: [math] RealMatrix.set(double)
I think it would be good to add this, but it would probably be better to give it a different name. What name, I am not sure. Maybe setAll or fill. Might also be useful to have versions that fill submatrics. Here is a little joke to lighten things up a bit. What if we just allow people to specify negative indices to mean "everything." So for example, setEntry(-1, -1, 0) sets all entries to 0, setEntry(1, -1, 0) sets the first row to 0. Just kidding ;) Phil On 8/22/11 12:00 PM, Sébastien Brisard wrote: > Hi, > I believe that in o.a.c.m.linear.RealMatrix, there is no method > set(double) which would set *all* entries to the same value. Such a > method exists (and is useful) in o.a.c.m.linear.RealVector. I propose > (if you think that could be useful) to open a JIRA issue. > Thanks for your comments! > Sébastien > > - > 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] RealMatrix.set(double)
On Mon, Aug 22, 2011 at 1:27 PM, Phil Steitz wrote: > I think it would be good to add this, but it would probably be > better to give it a different name. What name, I am not sure. > Maybe setAll or fill. Might also be useful to have versions that > fill submatrics. > Mahout allows this via overloading of an assign method. Matrix.assign(double) over-writes all cells with a constant value. Matrix.assign(Matrix) copies data into the target. x.assign(Matrix y, BinaryFunction f) does element-wise x_ij = f(x_ij, y_ij) > Here is a little joke to lighten things up a bit. What if we just > allow people to specify negative indices to mean "everything." So > for example, setEntry(-1, -1, 0) sets all entries to 0, setEntry(1, > -1, 0) sets the first row to 0. Just kidding ;) > Can be useful. I find the TCL convention more useful where -1 refers to the last element of a vector. This sort of thing does tend to freak out the more mathematically inclined and it does make it harder to catch errors in mathematical code since it mutes indexing errors.
[Math] TridiagonalTransformer
Hello All,
In TriaDiagonalTransformer, I notice the following (commencing at line 104).
final double[] hK = householderVectors[k - 1];
final double inv = 1.0 / (secondary[k - 1] * hK[k]);
cachedQt.setEntry(k, k, 1);
if (hK[k] != 0.0) {
Shouldn't the line:
final double inv = 1.0 / (secondary[k - 1] * hK[k]);
be after the test for hK[k] != 0?
-Greg
[codec] next releases
Hi All: After the last round of discussion WRT generics, a 2.0, version, and the new BM encoder, it seems the consensus is: - Release a version based on trunk. Trunk requires Java 5 and includes the new BM encoder. - Revert the trunk changes that break binary compatibility, specifically, based on Clirr: SeverityMessageClassMethod / Field ErrorMethod 'public StringEncoderComparator()' has been removed org.apache.commons.codec.StringEncoderComparatorpublic StringEncoderComparator() ErrorMethod 'public boolean isArrayByteBase64(byte[])' has been removedorg.apache.commons.codec.binary.Base64public boolean isArrayByteBase64(byte[]) ErrorClass org.apache.commons.codec.language.Caverphone removed org.apache.commons.codec.language.Caverphone ErrorMethod 'public int getMaxLength()' has been removed org.apache.commons.codec.language.Soundexpublic int getMaxLength() ErrorMethod 'public void setMaxLength(int)' has been removed org.apache.commons.codec.language.Soundexpublic void setMaxLength(int) ErrorField charset is now final org.apache.commons.codec.net.URLCodeccharset ErrorMethod 'public java.lang.String getEncoding()' has been removed org.apache.commons.codec.net.URLCodecpublic java.lang.String getEncoding() - Continue the generics discussion toward a major release which would likely require a package name change. Question: Because the code now requires Java 5, should the new version be 1.6 or 2.0? 1.6 feels right because we are adding an encoder. The only reason now for a 2.0 label is because we are using Java 5. Thoughts? Thank you, Gary -- http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
Re: [codec] next releases
On 23 August 2011 03:32, Gary Gregory wrote: > Hi All: > > After the last round of discussion WRT generics, a 2.0, version, and the new > BM encoder, it seems the consensus is: > > - Release a version based on trunk. Trunk requires Java 5 and includes the > new BM encoder. > > - Revert the trunk changes that break binary compatibility, specifically, > based on Clirr: > > Severity Message Class Method / Field > Error Method 'public StringEncoderComparator()' has been removed > org.apache.commons.codec.StringEncoderComparator public > StringEncoderComparator() > Error Method 'public boolean isArrayByteBase64(byte[])' has been > removed org.apache.commons.codec.binary.Base64 public boolean > isArrayByteBase64(byte[]) > Error Class org.apache.commons.codec.language.Caverphone removed > org.apache.commons.codec.language.Caverphone > Error Method 'public int getMaxLength()' has been removed > org.apache.commons.codec.language.Soundex public int getMaxLength() > Error Method 'public void setMaxLength(int)' has been removed > org.apache.commons.codec.language.Soundex public void setMaxLength(int) > Error Field charset is now final > org.apache.commons.codec.net.URLCodec charset > Error Method 'public java.lang.String getEncoding()' has been removed > org.apache.commons.codec.net.URLCodec public java.lang.String > getEncoding() > > - Continue the generics discussion toward a major release which would likely > require a package name change. > > Question: Because the code now requires Java 5, should the new version be > 1.6 or 2.0? > > 1.6 feels right because we are adding an encoder. > The only reason now for a 2.0 label is because we are using Java 5. > > Thoughts? A major version bump is required for API breaks; it is not required for changes in base Java level. [1] Though if we were suddenly to require Java 7 it might make sense to go to 2.0. Given that Java 1.5 has been out for some years now, and most users will probably be on at least Java 1.5 now, it seems to me that it's not necessary to have a major version bump; 1.6 is fine by me. [1] http://commons.apache.org/releases/versioning.html > Thank you, > Gary > -- > http://garygregory.wordpress.com/ > http://garygregory.com/ > http://people.apache.org/~ggregory/ > http://twitter.com/GaryGregory > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] RealMatrix.set(double)
Maybe setAllEntries? That would be consistent with setEntry? What about RealVector? The method set(double) should be renamed also? Sébastien 2011/8/22 Ted Dunning : > On Mon, Aug 22, 2011 at 1:27 PM, Phil Steitz wrote: > >> I think it would be good to add this, but it would probably be >> better to give it a different name. What name, I am not sure. >> Maybe setAll or fill. Might also be useful to have versions that >> fill submatrics. >> > > Mahout allows this via overloading of an assign method. > Matrix.assign(double) over-writes all cells with a constant value. > Matrix.assign(Matrix) copies data into the target. x.assign(Matrix y, > BinaryFunction f) does element-wise x_ij = f(x_ij, y_ij) > > >> Here is a little joke to lighten things up a bit. What if we just >> allow people to specify negative indices to mean "everything." So >> for example, setEntry(-1, -1, 0) sets all entries to 0, setEntry(1, >> -1, 0) sets the first row to 0. Just kidding ;) >> > > Can be useful. > > I find the TCL convention more useful where -1 refers to the last element of > a vector. > > This sort of thing does tend to freak out the more mathematically inclined > and it does make it harder to catch errors in mathematical code since it > mutes indexing errors. > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] SimpleRegression
If no one has objections, I would like to harmonize simpleregression with
the Regression Interfaces. What is the best way to proceed?
On Sun, Aug 21, 2011 at 9:25 PM, Greg Sterijevski wrote:
> Opened a ticket. Submitted patches. -Greg
>
>
> On Sat, Aug 20, 2011 at 4:47 PM, Phil Steitz wrote:
>
>> On 8/12/11 9:30 PM, Phil Steitz wrote:
>> > On 8/12/11 7:16 PM, Greg Sterijevski wrote:
>> >> Hello All,
>> >>
>> >> Before I chum the water with more JIRA tickets, I thought I would see
>> >> whether people thought this was important.
>> >>
>> >> In the SimpleRegression you have two methods:
>> >>
>> >> public void addData(double x, double y) {
>> >> ...some code that is not germane to discussion..
>> >>
>> >> if (n > 2) {
>> >> distribution = new TDistributionImpl(n - 2);
>> >> }
>> >> }
>> >>
>> >> public void removeData(double x, double y) {
>> >> ...some code that is not germane..
>> >>
>> >> if (n > 2) {
>> >> distribution = new TDistributionImpl(n - 2);
>> >> }
>> >> }
>> >> }
>> >>
>> >> >From the perspective of a user, you are likely to call add/remove
>> repeatedly
>> >> before you ever need to check for statistical significance. Wouldn't it
>> be
>> >> better to instantiate the TDistribution when it is needed?
>> >>
>> >> So you would have to make the following two methods a bit more
>> complicated:
>> >>
>> >> public double getSlopeConfidenceInterval(double alpha)
>> >> throws MathException {
>> >> if (alpha >= 1 || alpha <= 0) {
>> >> throw new
>> >> OutOfRangeException(LocalizedFormats.SIGNIFICANCE_LEVEL,
>> >> alpha, 0, 1);
>> >> }
>> >> if( distribution == null || distribution.getDegreesOfFreedom()
>> !=
>> >> n-2){
>> >> distribution = new TDistributionImpl(n - 2);
>> >> }
>> >> return getSlopeStdErr() *
>> >> distribution.inverseCumulativeProbability(1d - alpha / 2d);
>> >> }
>> >>
>> >> Similarly getSignificance() would have to be modified with the check of
>> the
>> >> degrees of freedom of the distribution.
>> >>
>> >> There is nothing wrong with the current code, but making the change
>> means
>> >> faster updates.
>> > Slightly, yes. There is not much code at all in the distribution
>> > constructor, but you are correct. Moreover, I can see now that the
>> > "immutability-everywhere" changes in trunk have made the code in the
>> > class a little funny. In versions <=2.2, the TDistribution used by
>> > the class was pluggable - i.e., there was a constructor that took at
>> > TDistribution as an argument, so if for some reason you wanted to
>> > use an impl different from TDistributionImpl, you could do that.
>> > There was also a setter for the distribution. In addition,
>> > TDistributionImpl itself was mutable, exposing a setDegreesOfFreedom
>> > method. So the distribution member was set at construction time and
>> > the data update methods called the setter for DF on the
>> > distribution. We decided to make the distributions immutable in 3.0
>> > (search the archives for discussion), so the current mods were done
>> > to basically accomplish that. But the code should be cleaned up.
>> > The constructor taking an int is meaningless and should be
>> > deprecated or removed (unfortunately, we added that in 2.2 and
>> > advertised it as a deprecation replacement for the version that took
>> > a distribution as parameter. We should have realized then that it
>> > was meaningless. My bad for missing that. I would favor dropping it
>> > in 3.0, since even if anyone is using it, it isn't doing anything
>> > meaningful for them.) Given that constructing a TDistributionImpl
>> > is trivial, we might as well eliminate the member field altogether
>> > and just create one when needed. If you agree and no one else
>> > objects, I will make these changes. Thanks for reviewing the code.
>>
>> Tracked as MATH-648, fixed in r1159918.
>>
>> Phil
>> >
>> > Phil
>> >> Thoughts?
>> >>
>> >> -Greg
>> >>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
Re: [math] SimpleRegression
On 8/22/11 8:42 PM, Greg Sterijevski wrote:
> If no one has objections, I would like to harmonize simpleregression with
> the Regression Interfaces. What is the best way to proceed?
JFDI - go ahead and take a stab at a patch to do it.
Phil
>
> On Sun, Aug 21, 2011 at 9:25 PM, Greg Sterijevski
> wrote:
>
>> Opened a ticket. Submitted patches. -Greg
>>
>>
>> On Sat, Aug 20, 2011 at 4:47 PM, Phil Steitz wrote:
>>
>>> On 8/12/11 9:30 PM, Phil Steitz wrote:
On 8/12/11 7:16 PM, Greg Sterijevski wrote:
> Hello All,
>
> Before I chum the water with more JIRA tickets, I thought I would see
> whether people thought this was important.
>
> In the SimpleRegression you have two methods:
>
> public void addData(double x, double y) {
> ...some code that is not germane to discussion..
>
> if (n > 2) {
> distribution = new TDistributionImpl(n - 2);
> }
> }
>
> public void removeData(double x, double y) {
> ...some code that is not germane..
>
> if (n > 2) {
> distribution = new TDistributionImpl(n - 2);
> }
> }
> }
>
> >From the perspective of a user, you are likely to call add/remove
>>> repeatedly
> before you ever need to check for statistical significance. Wouldn't it
>>> be
> better to instantiate the TDistribution when it is needed?
>
> So you would have to make the following two methods a bit more
>>> complicated:
> public double getSlopeConfidenceInterval(double alpha)
> throws MathException {
> if (alpha >= 1 || alpha <= 0) {
> throw new
> OutOfRangeException(LocalizedFormats.SIGNIFICANCE_LEVEL,
> alpha, 0, 1);
> }
> if( distribution == null || distribution.getDegreesOfFreedom()
>>> !=
> n-2){
> distribution = new TDistributionImpl(n - 2);
> }
> return getSlopeStdErr() *
> distribution.inverseCumulativeProbability(1d - alpha / 2d);
> }
>
> Similarly getSignificance() would have to be modified with the check of
>>> the
> degrees of freedom of the distribution.
>
> There is nothing wrong with the current code, but making the change
>>> means
> faster updates.
Slightly, yes. There is not much code at all in the distribution
constructor, but you are correct. Moreover, I can see now that the
"immutability-everywhere" changes in trunk have made the code in the
class a little funny. In versions <=2.2, the TDistribution used by
the class was pluggable - i.e., there was a constructor that took at
TDistribution as an argument, so if for some reason you wanted to
use an impl different from TDistributionImpl, you could do that.
There was also a setter for the distribution. In addition,
TDistributionImpl itself was mutable, exposing a setDegreesOfFreedom
method. So the distribution member was set at construction time and
the data update methods called the setter for DF on the
distribution. We decided to make the distributions immutable in 3.0
(search the archives for discussion), so the current mods were done
to basically accomplish that. But the code should be cleaned up.
The constructor taking an int is meaningless and should be
deprecated or removed (unfortunately, we added that in 2.2 and
advertised it as a deprecation replacement for the version that took
a distribution as parameter. We should have realized then that it
was meaningless. My bad for missing that. I would favor dropping it
in 3.0, since even if anyone is using it, it isn't doing anything
meaningful for them.) Given that constructing a TDistributionImpl
is trivial, we might as well eliminate the member field altogether
and just create one when needed. If you agree and no one else
objects, I will make these changes. Thanks for reviewing the code.
>>> Tracked as MATH-648, fixed in r1159918.
>>>
>>> Phil
Phil
> Thoughts?
>
> -Greg
>
>>>
>>> -
>>> 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
