[jira] [Commented] (POOL-203) GenericKeyedObjectPool.ObjectDeque could be better encapsulated
[ https://issues.apache.org/jira/browse/POOL-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172084#comment-13172084 ] Phil Steitz commented on POOL-203: -- I tend to agree with Mark on this. It may be a matter of taste; but I see it as desirable actually that "the main code" be aware of the internals of this particular data structure. It makes the code easier for me to understand and trace. There are a lot of things that you have to hold in your head when working with this code, no matter how you cut it and having more of the structure immediately evident makes it a little easier to work with. Better in-line and javadoc documentation explaining all of the invariants and contracts is definitely needed; but I am not sure more data abstraction will really help much at this point. Also, the first two above are likely trivial because they are not accessed that frequently, but the last one might have a slight negative performance impact, as it is very frequently activated and, like the other two, forces an additional stack operation to activate the wrapper function. > GenericKeyedObjectPool.ObjectDeque could be better encapsulated > --- > > Key: POOL-203 > URL: https://issues.apache.org/jira/browse/POOL-203 > Project: Commons Pool > Issue Type: Improvement >Reporter: Sebb >Priority: Minor > > GenericKeyedObjectPool.ObjectDeque is currently basically just a collection > of Objects with getters. > This necessarily exposes the implementation, and makes adding invariant > checks a lot harder - e.g. ensuring createCount >=0. > The suggestion is to replace the getters with functional methods, for example: > objectDeque.getCreateCount().incrementAndGet() => objectDeque.createdEntry(); > objectDeque.getAllObjects().put(t, p); => objectDeque.addNew(t, p); > objectDeque.getIdleObjects().addFirst(p)/addLast(p) => > objectDeque.idle(p,getLifo()) > The new methods could include assertions for invariants, and adding debug > would be a doddle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-726) Ridders derivative
[ https://issues.apache.org/jira/browse/MATH-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13171044#comment-13171044 ] Phil Steitz commented on MATH-726: -- +1 to moving the [nabla] numerics code into [math] and standardizing on the [nabla] API (which will become the [math] API that [nabla] will depend on). If the API is not to everyone's liking, we can change it. The relevant classes are in o.a.c.nabla.numerical and o.a.c.nabla.core in the [nabla] sandbox svn, per Luc's links above. Might be best to postpone this until post-3.0, as the package additions could be done in 3.1 without breaks; but I would personally be OK with a lift and load from [nabla] (along with the proposed Ridder's impl) for 3.0 if someone is willing to do the work. > Ridders derivative > -- > > Key: MATH-726 > URL: https://issues.apache.org/jira/browse/MATH-726 > Project: Commons Math > Issue Type: New Feature >Reporter: Gilles >Assignee: Gilles >Priority: Minor > Labels: features > Fix For: 3.0 > > Attachments: RiddersFirstDerivative.java > > > Implementation of the numerical first derivative, as described in: > {noformat} > Accurate computation of F'(x) and F'(x) F''(x) > C. J. F. Ridders > Adv. Eng. Software, 1982, Vol 4, No. 2 > {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-724) RandomDataImpl.nextInt does not distribute uniformly for negative lower bound
[ https://issues.apache.org/jira/browse/MATH-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13167594#comment-13167594 ] Phil Steitz commented on MATH-724: -- Thanks for reporting this. The problem is in the rounding, which does not work correctly for negative values. My first inclination is to test for negative lower bound and just shift the interval in that case. Any better ideas? > RandomDataImpl.nextInt does not distribute uniformly for negative lower bound > - > > Key: MATH-724 > URL: https://issues.apache.org/jira/browse/MATH-724 > Project: Commons Math > Issue Type: Bug >Affects Versions: Nightly Builds >Reporter: Dennis Hendriks > Attachments: NextIntUniformTest.java > > > When using the RandomDataImpl.nextInt function to get a uniform sample in a > [lower, upper] interval, when the lower value is less than zero, the output > is not uniformly distributed, as the lowest value is practically never > returned. > See the attached NextIntUniformTest.java file. It uses a [-3, 5] interval. > For several values between 0 and 1, testNextIntUniform1 prints the return > value of RandomDataImpl.nextInt (as double and as int). We see that -2 > through 5 are returned several times. The -3 value however, is only returned > for 0.0, and is thus under-respresented in the integer samples. The output of > test method testNextIntUniform2 also clearly shows that value -3 is never > sampled. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-704) One of Variance.evaluate() methods does not work correctly
[ https://issues.apache.org/jira/browse/MATH-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157670#comment-13157670 ] Phil Steitz commented on MATH-704: -- I can't seem to make this fail and I have added tests that would indicate that array segments are being handled properly. Can you provide an example showing a failure? > One of Variance.evaluate() methods does not work correctly > -- > > Key: MATH-704 > URL: https://issues.apache.org/jira/browse/MATH-704 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.2 > Environment: Java 1.6 >Reporter: Leonid Ilyevsky >Assignee: Phil Steitz > Fix For: 3.0 > > > The method > org.apache.commons.math.stat.descriptive.moment.Variance.evaluate(double[] > values, double[] weights, double mean, int begin, int length) does not work > properly. Looks loke it ignores the length parameter and grabs the whole > dataset. > Similar method in Mean class seems to work. > I did not check other methods taking the part of the array; they may have the > same problem. > Workaround: I had to shrink my arrays and use the method without the length. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-694) Remove XxMoment statistics from the public API
[ https://issues.apache.org/jira/browse/MATH-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157650#comment-13157650 ] Phil Steitz commented on MATH-694: -- I did not reduce visibility of SecondMoment, because that statistic is used in several places outside its package. If anyone feels strongly that it should be renamed, please reopen and we can do that. The new name I considered was "TotalSumOfSquares," That is a little misleading though, because it sits in the hierarchy between the now hidden First and Third moments and carries an embedded FirstMoment. > Remove XxMoment statistics from the public API > -- > > Key: MATH-694 > URL: https://issues.apache.org/jira/browse/MATH-694 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 1.0, 1.1, 1.2, 2.0, 2.1, 2.2 >Reporter: Phil Steitz > Fix For: 3.0 > > > The Second, Third and FourthMoment statistics in > o.a.c.m.stat.descriptive.moment are non-standard and are really just there to > make updating more efficient in other statistics that embed them and the > aggregates. The naming is misleading and I am not sure there is much > independent value to these statistics, so I propose that we change them to > have package scope in 3.0. I am happy to close this as WONT_FIX if anyone > has objections. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-711) Merge xxxDistribution and xxxDistributionImpl in package distribution
[ https://issues.apache.org/jira/browse/MATH-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157504#comment-13157504 ] Phil Steitz commented on MATH-711: -- We need to remember to update the code in the User Guide to reflect the changes made here. > Merge xxxDistribution and xxxDistributionImpl in package distribution > - > > Key: MATH-711 > URL: https://issues.apache.org/jira/browse/MATH-711 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Sébastien Brisard >Assignee: Sébastien Brisard > > This ticket follows the general trend aiming at removing unnecessary > interfaces. In this package, the concerned interfaces are > (/) {{BetaDistribution}}: done in r1205739 > (/) {{BinomialDistribution}}: done in r1205963 > (/) {{CauchyDistribution}}: done in r1206053 > (/) {{ChiSquaredDistribution}}: done in r1206060 > (/) {{ExponentialDistribution}}: done in r1206399 > (/) {{FDistribution}}: done in r1206399 > (/) {{GammaDistribution}}: done in r1206399 > (/) {{HypergeometricDistribution}}: done in r1206406 > (/) {{KolmogorovSmirnovDistribution}}: done in r1206425 > (/) {{NormalDistribution}}: done in r1206421 > (/) {{PascalDistribution}}: done in r1206421 > (/) {{PoissonDistribution}}: done in r1206434 > (/) {{TDistribution}}: done in r1206434 > (/) {{WeibullDistribution}}: done in r1206434 > (x) {{ZipfDistribution}} > Corresponding implementations {{xxxDistributionImpl}} will be renamed > {{xxxDistribution}}. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-703) Splitting up the distribution hierarchy
[ https://issues.apache.org/jira/browse/MATH-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157311#comment-13157311 ] Phil Steitz commented on MATH-703: -- I would say yes to removing toRealDistribution. I may be missing a range of practical use cases for this, though. How might the need for this arise in applications? I am also +1 for merging *Default* into the children. I agree with Sebastian's first point. Lets drop the caching support in the parent for the characteristics. While we have agreed within [math] that our distributions should be immutable, there is no guarantee that someone else might not want to implement a mutable one. Sebastien's second point is what I mean be merging the *Default* into the children. With those changes, I am +1 to applying the patch. THANKS! > Splitting up the distribution hierarchy > --- > > Key: MATH-703 > URL: https://issues.apache.org/jira/browse/MATH-703 > Project: Commons Math > Issue Type: Improvement >Reporter: Christian Winter >Priority: Minor > Attachments: MATH-703_patch.zip > > > As discussed on the mailing list > (http://apache-commons.680414.n4.nabble.com/math-Distributions-over-sample-spaces-other-than-R-tp3931349p3931349.html), > the distribution interfaces should be restructured. > The most important point is to create one root interface for each domain. > There should *not* be a common super-interace because different domains > require different functionality. Additionally, a super-inferface would > require to parametrize the domain which makes things more complicated (e.g., > "double" would have to be replaced by "Double"). Currently, Commons Math > supports distributions with real domain and distributions with integer > domain. Thus there will be the interfaces RealDistribution and > IntegerDistribution. > Another point is to drop the special cases of distributions with real domain > in order to simplify the structure. There won't be an interface for > absolutely continuous distributions, and there won't be an interface for > discrete distributions on the real domain. All the functionality required by > the special cases can be defined in RealDistribution. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157310#comment-13157310 ] Phil Steitz commented on MATH-699: -- Wow, we can really improve the code when we put our heads together :) Great observation by Christian - we can switch on plateau detection iff isSupportConnected is false. Otherwise, I would say the "new" implementation is good to go. I would also be happy to celebrate dropping all of the getXxx(p) methods, which are not needed any more. We can all thank Mikkel, btw, for suggesting a while back that we add the numerical mean, variance and connected support properties. Came in very handy here! > inverseCumulativeDistribution fails with cumulative distribution having a > plateau > - > > Key: MATH-699 > URL: https://issues.apache.org/jira/browse/MATH-699 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Sébastien Brisard >Assignee: Sébastien Brisard >Priority: Minor > Attachments: AbstractContinuousDistributionTest.java, > inv-cum-new-impl.zip > > > This bug report follows MATH-692. The attached unit test fails. As required > by the definition in MATH-692, the lower-bound of the interval on which the > cdf is constant should be returned. This is not so at the moment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-189) close() does not release threads blocked on borrowObject()
[ https://issues.apache.org/jira/browse/POOL-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151790#comment-13151790 ] Phil Steitz commented on POOL-189: -- I am sorry, but I am still not finished performance testing the patch. One round of tests made it look like I could measure the difference in performance du to the added check on each wake/borrow sequence. The difference is not statistically significant, but appears measurable. I am running some longer running tests to see if this is a real effect. > close() does not release threads blocked on borrowObject() > -- > > Key: POOL-189 > URL: https://issues.apache.org/jira/browse/POOL-189 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.6 > Environment: java 1.6.0_24 >Reporter: Adrian Nistor > Fix For: 1.5.7 > > Attachments: BUG-189v1.diff, BUG-189v2.diff, Test.java > > > Hi, > When I call close() and borrowObject() concurrently with no objects in > the pool, close() will finish but borrowObject() is blocked forever. > The documentation of close() mentions that borrowObject() should fail > with IllegalStateException, so I would expect the waiting threads to > throw IllegalStateException. > I will attach a test that exposes this problem. For this test, the > expected output is: > 0 > 1 > 2 > ... > 4999 > DONE > But when the bug manifests (almost always for this test), the output > is: > 0 > 1 > 2 > The test does not finish, it just gets stuck after printing several > values. > Is this a bug or am I reading the documentation wrongly? Is there > a patch for this? > Thanks! > Adrian -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-189) close() does not release threads blocked on borrowObject()
[ https://issues.apache.org/jira/browse/POOL-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149769#comment-13149769 ] Phil Steitz commented on POOL-189: -- Thanks, Bill! You used the right branch and my initial reaction is this looks good. You are right that this also affects GKOP and a similar fix should work there. I will look more carefully at this tonight. Additional review / comments welcome. Thanks for the patch! > close() does not release threads blocked on borrowObject() > -- > > Key: POOL-189 > URL: https://issues.apache.org/jira/browse/POOL-189 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.6 > Environment: java 1.6.0_24 >Reporter: Adrian Nistor > Fix For: 1.5.7 > > Attachments: BUG-189v1.diff, Test.java > > > Hi, > When I call close() and borrowObject() concurrently with no objects in > the pool, close() will finish but borrowObject() is blocked forever. > The documentation of close() mentions that borrowObject() should fail > with IllegalStateException, so I would expect the waiting threads to > throw IllegalStateException. > I will attach a test that exposes this problem. For this test, the > expected output is: > 0 > 1 > 2 > ... > 4999 > DONE > But when the bug manifests (almost always for this test), the output > is: > 0 > 1 > 2 > The test does not finish, it just gets stuck after printing several > values. > Is this a bug or am I reading the documentation wrongly? Is there > a patch for this? > Thanks! > Adrian -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-190) Add API BaseObjectPool.isOpen()
[ https://issues.apache.org/jira/browse/POOL-190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13149417#comment-13149417 ] Phil Steitz commented on POOL-190: -- Not a major version bump, but not appropriate for a patch release. The 1.5.x releases from here on should be bug fix only. It may actually be best to close this as WONT_FIX because BOP has been removed from 2.0. > Add API BaseObjectPool.isOpen() > --- > > Key: POOL-190 > URL: https://issues.apache.org/jira/browse/POOL-190 > Project: Commons Pool > Issue Type: New Feature >Affects Versions: 1.5.6 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Fix For: 2.0 > > Attachments: isOpen.diff > > > Add API BaseObjectPool.isOpen() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-762) Handle or document ReflectionToStringBuilder and ToStringBuilder for collections that are not thread safe
[ https://issues.apache.org/jira/browse/LANG-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13147468#comment-13147468 ] Phil Steitz commented on LANG-762: -- Looking at this again, I am pretty well convinced that [lang] is never going to be able to "fix" this issue. Consider the case where a class uses its own private Lock instances to protect data members. Unless you want to get into the byte code analysis business, you are not going to be able to pick this up or access the relevant locks. Moreoever, even if you could discern and acquire the right locks, you might risk introducing deadlocks or liveness problems for the code, because the class may have lock acquisition / release order invariants that you don't know about. The risks associated with using the ReflectionToStringBuilder to access fields protected by synchronization should be documented. I would suggest just adding something like the following to the class javadoc, after the sentence that reads "This will fail under a security manager, unless the appropriate permissions are set up correctly" add "Using reflection to access private fields also circumvents any synchronization protection guarding access to private fields. Fields that cannot safely be read at any time by toString should be excluded from the generated method, or synchronization consistent with the underlying class' lock management should be added around invocation of the method. Special care should be taken to avoid including non-threadsafe collection classes, as these classes may throw ConcurrentModificationException if modified while the toString method is executing." Above is probably too long, but something like it should be added. > Handle or document ReflectionToStringBuilder and ToStringBuilder for > collections that are not thread safe > - > > Key: LANG-762 > URL: https://issues.apache.org/jira/browse/LANG-762 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > Attachments: ReflectionToStringBuilderConcurrencyTest.java, > patch-LANG762.txt > > > Moving discussion here from https://issues.apache.org/jira/browse/POOL-191 > ConcurrentModificationException in GenericObjectPool LinkedList. > It is possible to get a {{ConcurrentModificationException}} in a > {{LinkedList}} from a Commons Pool {{GenericObjectPool}}. > This happens when I call {{ReflectionToStringBuilder.toString(this)}} from a > subclass of {{GenericObjectPool}}. My guess is that it would happen with just > {{ReflectionToStringBuilder.toString(gop)}}. IOW, subclassing does not have > anything to do with it I would venture. > For example, in this stack trace {{JmsSessionPool}} is a subclass of > {{GenericObjectPool}}. > {noformat} > java.util.ConcurrentModificationException > at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:761) > at java.util.LinkedList$ListItr.next(LinkedList.java:696) > at java.util.AbstractCollection.toString(AbstractCollection.java:421) > at java.lang.String.valueOf(String.java:2826) > at java.lang.StringBuffer.append(StringBuffer.java:219) > at > org.apache.commons.lang3.builder.ToStringStyle.appendDetail(ToStringStyle.java:598) > at > org.apache.commons.lang3.builder.ToStringStyle.appendInternal(ToStringStyle.java:473) > at > org.apache.commons.lang3.builder.ToStringStyle.append(ToStringStyle.java:436) > at > org.apache.commons.lang3.builder.ToStringBuilder.append(ToStringBuilder.java:848) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:528) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:692) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:288) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:119) > at > com.seagullsw.appinterface.comm.jms.JmsSessionPool.toString(JmsSessionPool.java:120) > at java.lang.String.valueOf(String.java:2826) > at java.lang.StringBuffer.append(StringBuffer.java:219) > at > org.apache.commons.lang3.builder.ToStringStyle.appendDetail(ToStringStyle.java:586) > at > org.apache.commons.lang3.builder.ToStringStyle.appendInternal(ToStringStyle.java:550) > at > org.apache.commons.lang3.builder.T
[jira] [Commented] (MATH-692) Cumulative probability and inverse cumulative probability inconsistencies
[ https://issues.apache.org/jira/browse/MATH-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13147115#comment-13147115 ] Phil Steitz commented on MATH-692: -- Hey, that's how it always works :) I don't know about "wise" but I certainly qualify as "old" by any standard, so will have a look once you have reviewed and committed. Thanks! > Cumulative probability and inverse cumulative probability inconsistencies > - > > Key: MATH-692 > URL: https://issues.apache.org/jira/browse/MATH-692 > Project: Commons Math > Issue Type: Bug >Affects Versions: 1.0, 1.1, 1.2, 1.3, 2.0, 2.1, 2.2, 2.2.1, 3.0 >Reporter: Christian Winter >Priority: Minor > Fix For: 3.0 > > Attachments: Math-692_realDomain_patch1.patch > > > There are some inconsistencies in the documentation and implementation of > functions regarding cumulative probabilities and inverse cumulative > probabilities. More precisely, '<' and '<=' are not used in a consistent way. > Besides I would move the function inverseCumulativeProbability(double) to the > interface Distribution. A true inverse of the distribution function does > neither exist for Distribution nor for ContinuosDistribution. Thus we need to > define the inverse in terms of quantiles anyway, and this can already be done > for Distribution. > On the whole I would declare the (inverse) cumulative probability functions > in the basic distribution interfaces as follows: > Distribution: > - cumulativeProbability(double x): returns P(X <= x) > - cumulativeProbability(double x0, double x1): returns P(x0 < X <= x1) [see > also 1)] > - inverseCumulativeProbability(double p): > returns the quantile function inf{x in R | P(X<=x) >= p} [see also 2), 3), > and 4)] > 1) An aternative definition could be P(x0 <= X <= x1). But this requires to > put the function probability(double x) or another cumulative probability > function into the interface Distribution in order be able to calculate P(x0 > <= X <= x1) in AbstractDistribution. > 2) This definition is stricter than the definition in ContinuousDistribution, > because the definition there does not specify what to do if there are > multiple x satisfying P(X<=x) = p. > 3) A modification could be defined for p=0: Returning sup{x in R | P(X<=x) = > 0} would yield the infimum of the distribution's support instead of a > mandatory -infinity. > 4) This affects issue MATH-540. I'd prefere the definition from above for the > following reasons: > - This definition simplifies inverse transform sampling (as mentioned in the > other issue). > - It is the standard textbook definition for the quantile function. > - For integer distributions it has the advantage that the result doesn't > change when switching to "x in Z", i.e. the result is independent of > considering the intergers as sole set or as part of the reals. > ContinuousDistribution: > nothing to be added regarding (inverse) cumulative probability functions > IntegerDistribution: > - cumulativeProbability(int x): returns P(X <= x) > - cumulativeProbability(int x0, int x1): returns P(x0 < X <= x1) [see also 1) > above] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146739#comment-13146739 ] Phil Steitz commented on MATH-699: -- Interesting idea. Worth playing with. One more archaeological fact that occurred to me is that the current setup with domain upper / lower bounds used in bracketing was developed before we required either mean or variance from distributions. We now have getNumericalMean and getNumericalVariance. When these both exist and are finite, inequalities such as Chebyshev's might be useful in setting up brackets. > inverseCumulativeDistribution fails with cumulative distribution having a > plateau > - > > Key: MATH-699 > URL: https://issues.apache.org/jira/browse/MATH-699 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Sébastien Brisard >Assignee: Sébastien Brisard >Priority: Minor > Attachments: AbstractContinuousDistributionTest.java > > > This bug report follows MATH-692. The attached unit test fails. As required > by the definition in MATH-692, the lower-bound of the interval on which the > cdf is constant should be returned. This is not so at the moment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146060#comment-13146060 ] Phil Steitz commented on MATH-699: -- I am sorry, Sebastien. I am not being very helpful here. As I dig deeper into the code and archaeology, I am having a hard time seeing how we can really improve the default impl without knowledge of the underlying distribution. I agree with you that we should clearly document its limitations, though, and fix the javadoc contracts everywhere to be correct and consistent. The default impl was never really intended to be universal - just a simple solver-based impl that would work for well-behaved distributions. The normal distribution example above points to a slight improvement that could now be done. When that code was written, we had yet to define the supportLowerBound and supportUpperBound properties. Now that we have those, the test in the normal dist case could be moved up into the default impl, using the getters on the distribution for the return values. By all means if you can find a way to deal with plateaus or otherwise improve robustness of the default impl, go for it. In particular, if you can come up with a better way to set up the solver, possibly eliminating the domainLower/upperBound methods, that would be great. It has always seemed a little ugly to me that we had to implement these methods for every distribution just so we could get initial guesses for the inverse cum solver. > inverseCumulativeDistribution fails with cumulative distribution having a > plateau > - > > Key: MATH-699 > URL: https://issues.apache.org/jira/browse/MATH-699 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Sébastien Brisard >Assignee: Sébastien Brisard >Priority: Minor > Attachments: AbstractContinuousDistributionTest.java > > > This bug report follows MATH-692. The attached unit test fails. As required > by the definition in MATH-692, the lower-bound of the interval on which the > cdf is constant should be returned. This is not so at the moment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145544#comment-13145544 ] Phil Steitz commented on MATH-699: -- My inclination would be to keep the implementation in the base class as simple as possible, documenting what it does and pushing the responsibility for dealing with plateaus in the distribution to the implementations that have these. I don't think any of the currently implemented real distributions have this problem. Correct? The invariant you are proposing for when to return infinities for domain lower and upper bounds would make sense if these were intended to be the bounds of support for the distribution, but this is not what these properties represent. They are initial guesses for where to start when trying to bracket a root. That means they have to be values that can be fed into the cumulative probability function. Have you convinced yourself that we do not need to bracket a root at the beginning? What bounds would we then provide to the solver? The code you reference is trying to do the bracketing, starting with the domain upper and lower bounds as initial guesses. Remember to consider convergence problems when the actual parameter to inverse cum is close to or exactly equal to 0 or 1. Per the comment in the code above the test that uses (or should use) the function value absolute accuracy, if the distribution has bounded support and the argument is 0 or 1, bracketing will fail. > inverseCumulativeDistribution fails with cumulative distribution having a > plateau > - > > Key: MATH-699 > URL: https://issues.apache.org/jira/browse/MATH-699 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Sébastien Brisard >Assignee: Sébastien Brisard >Priority: Minor > Attachments: AbstractContinuousDistributionTest.java > > > This bug report follows MATH-692. The attached unit test fails. As required > by the definition in MATH-692, the lower-bound of the interval on which the > cdf is constant should be returned. This is not so at the moment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144933#comment-13144933 ] Phil Steitz commented on MATH-699: -- Be careful eliminating the bracketing step. IIRC it is in there to resolve a bug involving some corner case. In theory, the unit tests should pick up any regressions, but it would be a good idea to review the commit logs and issue reports for this class before ripping out the bracketing step. > inverseCumulativeDistribution fails with cumulative distribution having a > plateau > - > > Key: MATH-699 > URL: https://issues.apache.org/jira/browse/MATH-699 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Sébastien Brisard >Assignee: Sébastien Brisard >Priority: Minor > Attachments: AbstractContinuousDistributionTest.java > > > This bug report follows MATH-692. The attached unit test fails. As required > by the definition in MATH-692, the lower-bound of the interval on which the > cdf is constant should be returned. This is not so at the moment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144740#comment-13144740 ] Phil Steitz commented on MATH-699: -- I agree that the wrong solver property is being used. I would say yes, add the property with a reasonable default. > inverseCumulativeDistribution fails with cumulative distribution having a > plateau > - > > Key: MATH-699 > URL: https://issues.apache.org/jira/browse/MATH-699 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Sébastien Brisard >Assignee: Sébastien Brisard >Priority: Minor > Attachments: AbstractContinuousDistributionTest.java > > > This bug report follows MATH-692. The attached unit test fails. As required > by the definition in MATH-692, the lower-bound of the interval on which the > cdf is constant should be returned. This is not so at the moment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-701) Seeding a default RNG
[ https://issues.apache.org/jira/browse/MATH-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144170#comment-13144170 ] Phil Steitz commented on MATH-701: -- I thought about changing the default seeding in AbstractWell and agree that would be a good idea. I still like to supply the seed explicitly and document it in RandomDataImpl, though, so users of that class know exactly what they are getting by default. There is a little wrinkle here, too that keeping the seeding expressed and documented in RandomDataImpl makes easier to keep track of. If we ever implement hashcode in RandomDataImpl (or the Well generators), things could get messed up if it does not separate generator instances the way the system identity haschcode does. > Seeding a default RNG > - > > Key: MATH-701 > URL: https://issues.apache.org/jira/browse/MATH-701 > Project: Commons Math > Issue Type: Bug >Reporter: Gilles >Assignee: Gilles > Fix For: 3.0 > > > In "RandomDataImpl": > {code} > private RandomGenerator getRan() { > if (rand == null) { > rand = new JDKRandomGenerator(); > rand.setSeed(System.currentTimeMillis()); > } > return rand; > } > {code} > The conditional branch is used by "sample()" in > "AbstractContinuousDistribution". > When several "...Distribution" objects are instantiated in a short time > interval, they are seeded with the same value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-701) Seeding a default RNG
[ https://issues.apache.org/jira/browse/MATH-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144122#comment-13144122 ] Phil Steitz commented on MATH-701: -- I just committed (r1197626) a) change to Well generator as default for non-secure generator b) seeding like the Harmony code. Can we resolve this and take the refactoring discussion to the dev list? > Seeding a default RNG > - > > Key: MATH-701 > URL: https://issues.apache.org/jira/browse/MATH-701 > Project: Commons Math > Issue Type: Bug >Reporter: Gilles >Assignee: Gilles > Fix For: 3.0 > > > In "RandomDataImpl": > {code} > private RandomGenerator getRan() { > if (rand == null) { > rand = new JDKRandomGenerator(); > rand.setSeed(System.currentTimeMillis()); > } > return rand; > } > {code} > The conditional branch is used by "sample()" in > "AbstractContinuousDistribution". > When several "...Distribution" objects are instantiated in a short time > interval, they are seeded with the same value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-701) Seeding a default RNG
[ https://issues.apache.org/jira/browse/MATH-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143706#comment-13143706 ] Phil Steitz commented on MATH-701: -- +1 to changing the default in the RandomDataImpl to a Well generator (documenting this) +1 as well to trying to find a better default seed (documenting how it works). Harmony still belongs to us, so we can certainly look at / imitate the impl there. The reason that the argumentless constructor exists is to allow users to accept the default generator. The lazy initialization idiom was chosen because in some cases, users may choose to invoke the setter instead of passing a generator as a constructor argument. This is an older style no longer in use much in [math]. I would be OK getting rid of this - i.e., having the argumentless constructor take the hit to create a default instance. -0 for separating out the secure stuff. RandomDataImpl is an aggregate class that bundles a lot of commonly used random data generation methods. Just as the random generator is pluggable, so is the secure random generator, which makes the class convenient to use for applications that require both kinds of random values. I think its simpler and more convenient to bundle things as they are. Of course, I have been using this class for a long time, so I may not be the best judge of what is simplest / easiest to use. > Seeding a default RNG > - > > Key: MATH-701 > URL: https://issues.apache.org/jira/browse/MATH-701 > Project: Commons Math > Issue Type: Bug >Reporter: Gilles >Assignee: Gilles > Fix For: 3.0 > > > In "RandomDataImpl": > {code} > private RandomGenerator getRan() { > if (rand == null) { > rand = new JDKRandomGenerator(); > rand.setSeed(System.currentTimeMillis()); > } > return rand; > } > {code} > The conditional branch is used by "sample()" in > "AbstractContinuousDistribution". > When several "...Distribution" objects are instantiated in a short time > interval, they are seeded with the same value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-701) Seeding a default RNG
[ https://issues.apache.org/jira/browse/MATH-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13143322#comment-13143322 ] Phil Steitz commented on MATH-701: -- I agree that there is a problem here; but I would solve it in AbstractContinuousDistribution by passing a seeded generator to the RandomDataImpl constructor. The code above is for the default case where no generator has been supplied or set. For sampling, a Well generator would be a better choice. > Seeding a default RNG > - > > Key: MATH-701 > URL: https://issues.apache.org/jira/browse/MATH-701 > Project: Commons Math > Issue Type: Bug >Reporter: Gilles >Assignee: Gilles > Fix For: 3.0 > > > In "RandomDataImpl": > {code} > private RandomGenerator getRan() { > if (rand == null) { > rand = new JDKRandomGenerator(); > rand.setSeed(System.currentTimeMillis()); > } > return rand; > } > {code} > The conditional branch is used by "sample()" in > "AbstractContinuousDistribution". > When several "...Distribution" objects are instantiated in a short time > interval, they are seeded with the same value. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CHAIN-61) Chain 2.0 trunk build is throwing many warnings as a result of generification changes
[ https://issues.apache.org/jira/browse/CHAIN-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13135462#comment-13135462 ] Phil Steitz commented on CHAIN-61: -- Usually this is the result of some change being committed between the time the patch was created and when you are trying to apply it. Succeeded usually means succeeded - i.e., the patch command was successful in figuring out how to adjust for the changes in the file. What I do in these cases is compare what I get doing svn diff locally *after* applying the patch to the patch itself. It the changes are the same (and of course, I am happy with the patch), I go ahead and commit. I don't know about the content of this patch, but the patch itself looks fine to me. > Chain 2.0 trunk build is throwing many warnings as a result of generification > changes > - > > Key: CHAIN-61 > URL: https://issues.apache.org/jira/browse/CHAIN-61 > Project: Commons Chain > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Elijah Zupancic > Fix For: 2.0 > > Attachments: chain-61.diff > > Original Estimate: 2h > Remaining Estimate: 2h > > When warnings on turned on for build, there are many unchecked conversion > errors. These should be systematically investigated and fixed or given a > @SuppressWarnings("unchecked") where needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-692) Cumulative probability and inverse cumulative probability inconsistencies
[ https://issues.apache.org/jira/browse/MATH-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133745#comment-13133745 ] Phil Steitz commented on MATH-692: -- I guess I am OK with pushing p(x) up. See related post to follow in commons-dev. > Cumulative probability and inverse cumulative probability inconsistencies > - > > Key: MATH-692 > URL: https://issues.apache.org/jira/browse/MATH-692 > Project: Commons Math > Issue Type: Bug >Affects Versions: 1.0, 1.1, 1.2, 1.3, 2.0, 2.1, 2.2, 2.2.1, 3.0 >Reporter: Christian Winter >Priority: Minor > Fix For: 3.0 > > > There are some inconsistencies in the documentation and implementation of > functions regarding cumulative probabilities and inverse cumulative > probabilities. More precisely, '<' and '<=' are not used in a consistent way. > Besides I would move the function inverseCumulativeProbability(double) to the > interface Distribution. A true inverse of the distribution function does > neither exist for Distribution nor for ContinuosDistribution. Thus we need to > define the inverse in terms of quantiles anyway, and this can already be done > for Distribution. > On the whole I would declare the (inverse) cumulative probability functions > in the basic distribution interfaces as follows: > Distribution: > - cumulativeProbability(double x): returns P(X <= x) > - cumulativeProbability(double x0, double x1): returns P(x0 < X <= x1) [see > also 1)] > - inverseCumulativeProbability(double p): > returns the quantile function inf{x in R | P(X<=x) >= p} [see also 2), 3), > and 4)] > 1) An aternative definition could be P(x0 <= X <= x1). But this requires to > put the function probability(double x) or another cumulative probability > function into the interface Distribution in order be able to calculate P(x0 > <= X <= x1) in AbstractDistribution. > 2) This definition is stricter than the definition in ContinuousDistribution, > because the definition there does not specify what to do if there are > multiple x satisfying P(X<=x) = p. > 3) A modification could be defined for p=0: Returning sup{x in R | P(X<=x) = > 0} would yield the infimum of the distribution's support instead of a > mandatory -infinity. > 4) This affects issue MATH-540. I'd prefere the definition from above for the > following reasons: > - This definition simplifies inverse transform sampling (as mentioned in the > other issue). > - It is the standard textbook definition for the quantile function. > - For integer distributions it has the advantage that the result doesn't > change when switching to "x in Z", i.e. the result is independent of > considering the intergers as sole set or as part of the reals. > ContinuousDistribution: > nothing to be added regarding (inverse) cumulative probability functions > IntegerDistribution: > - cumulativeProbability(int x): returns P(X <= x) > - cumulativeProbability(int x0, int x1): returns P(x0 < X <= x1) [see also 1) > above] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-692) Cumulative probability and inverse cumulative probability inconsistencies
[ https://issues.apache.org/jira/browse/MATH-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133665#comment-13133665 ] Phil Steitz commented on MATH-692: -- Have a look at the default implementation of cum(-,-) now in AbstractDistribution. I think the incorrectness in the documentation there may have been what triggered Christian to raise this issue. The equation cum(a,b) = F(b) - F(a) where F is the distribution function is natural and what the impl there is trying to do. In the discrete case, this equation fails, however, unless you define the cum to exclude the *lower* endpoint. That's why P(x0 < X <= x1) is a better definition. > Cumulative probability and inverse cumulative probability inconsistencies > - > > Key: MATH-692 > URL: https://issues.apache.org/jira/browse/MATH-692 > Project: Commons Math > Issue Type: Bug >Affects Versions: 1.0, 1.1, 1.2, 1.3, 2.0, 2.1, 2.2, 2.2.1, 3.0 >Reporter: Christian Winter >Priority: Minor > Fix For: 3.0 > > > There are some inconsistencies in the documentation and implementation of > functions regarding cumulative probabilities and inverse cumulative > probabilities. More precisely, '<' and '<=' are not used in a consistent way. > Besides I would move the function inverseCumulativeProbability(double) to the > interface Distribution. A true inverse of the distribution function does > neither exist for Distribution nor for ContinuosDistribution. Thus we need to > define the inverse in terms of quantiles anyway, and this can already be done > for Distribution. > On the whole I would declare the (inverse) cumulative probability functions > in the basic distribution interfaces as follows: > Distribution: > - cumulativeProbability(double x): returns P(X <= x) > - cumulativeProbability(double x0, double x1): returns P(x0 < X <= x1) [see > also 1)] > - inverseCumulativeProbability(double p): > returns the quantile function inf{x in R | P(X<=x) >= p} [see also 2), 3), > and 4)] > 1) An aternative definition could be P(x0 <= X <= x1). But this requires to > put the function probability(double x) or another cumulative probability > function into the interface Distribution in order be able to calculate P(x0 > <= X <= x1) in AbstractDistribution. > 2) This definition is stricter than the definition in ContinuousDistribution, > because the definition there does not specify what to do if there are > multiple x satisfying P(X<=x) = p. > 3) A modification could be defined for p=0: Returning sup{x in R | P(X<=x) = > 0} would yield the infimum of the distribution's support instead of a > mandatory -infinity. > 4) This affects issue MATH-540. I'd prefere the definition from above for the > following reasons: > - This definition simplifies inverse transform sampling (as mentioned in the > other issue). > - It is the standard textbook definition for the quantile function. > - For integer distributions it has the advantage that the result doesn't > change when switching to "x in Z", i.e. the result is independent of > considering the intergers as sole set or as part of the reals. > ContinuousDistribution: > nothing to be added regarding (inverse) cumulative probability functions > IntegerDistribution: > - cumulativeProbability(int x): returns P(X <= x) > - cumulativeProbability(int x0, int x1): returns P(x0 < X <= x1) [see also 1) > above] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-692) Cumulative probability and inverse cumulative probability inconsistencies
[ https://issues.apache.org/jira/browse/MATH-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133464#comment-13133464 ] Phil Steitz commented on MATH-692: -- I am not sure it is really makes sense to add probability(double x) to the Distribution interface. It would have to be defined as density (referring to the distribution function) to make sense in the continuous case, since defined as p(X = x) it would in most cases be identically 0 for continuous distributions. Regarding the cum definition, I am fine with P(x0 < X <= x1). > Cumulative probability and inverse cumulative probability inconsistencies > - > > Key: MATH-692 > URL: https://issues.apache.org/jira/browse/MATH-692 > Project: Commons Math > Issue Type: Bug >Affects Versions: 1.0, 1.1, 1.2, 1.3, 2.0, 2.1, 2.2, 2.2.1, 3.0 >Reporter: Christian Winter >Priority: Minor > Fix For: 3.0 > > > There are some inconsistencies in the documentation and implementation of > functions regarding cumulative probabilities and inverse cumulative > probabilities. More precisely, '<' and '<=' are not used in a consistent way. > Besides I would move the function inverseCumulativeProbability(double) to the > interface Distribution. A true inverse of the distribution function does > neither exist for Distribution nor for ContinuosDistribution. Thus we need to > define the inverse in terms of quantiles anyway, and this can already be done > for Distribution. > On the whole I would declare the (inverse) cumulative probability functions > in the basic distribution interfaces as follows: > Distribution: > - cumulativeProbability(double x): returns P(X <= x) > - cumulativeProbability(double x0, double x1): returns P(x0 < X <= x1) [see > also 1)] > - inverseCumulativeProbability(double p): > returns the quantile function inf{x in R | P(X<=x) >= p} [see also 2), 3), > and 4)] > 1) An aternative definition could be P(x0 <= X <= x1). But this requires to > put the function probability(double x) or another cumulative probability > function into the interface Distribution in order be able to calculate P(x0 > <= X <= x1) in AbstractDistribution. > 2) This definition is stricter than the definition in ContinuousDistribution, > because the definition there does not specify what to do if there are > multiple x satisfying P(X<=x) = p. > 3) A modification could be defined for p=0: Returning sup{x in R | P(X<=x) = > 0} would yield the infimum of the distribution's support instead of a > mandatory -infinity. > 4) This affects issue MATH-540. I'd prefere the definition from above for the > following reasons: > - This definition simplifies inverse transform sampling (as mentioned in the > other issue). > - It is the standard textbook definition for the quantile function. > - For integer distributions it has the advantage that the result doesn't > change when switching to "x in Z", i.e. the result is independent of > considering the intergers as sole set or as part of the reals. > ContinuousDistribution: > nothing to be added regarding (inverse) cumulative probability functions > IntegerDistribution: > - cumulativeProbability(int x): returns P(X <= x) > - cumulativeProbability(int x0, int x1): returns P(x0 < X <= x1) [see also 1) > above] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-692) Cumulative probability and inverse cumulative probability inconsistencies
[ https://issues.apache.org/jira/browse/MATH-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131245#comment-13131245 ] Phil Steitz commented on MATH-692: -- Thanks for raising this issue, Christian - especially now as we finalize the 3.0 API. I am +1 for these changes. I agree that the inf-based definition of inverse cum is more standard and we are in a position now make the change, so I say lets do it. I am also +1 on the move of this up to the distribution interface. The reason we did not include it there originally was that we thought we might implement distributions for which we could not define inverses. That has not happened in the last 8 years, so I think its safe enough to push it up. The code, test, user guide and doc changes for this have to be done carefully. Patches most welcome. Is everyone else OK with this change? > Cumulative probability and inverse cumulative probability inconsistencies > - > > Key: MATH-692 > URL: https://issues.apache.org/jira/browse/MATH-692 > Project: Commons Math > Issue Type: Bug >Affects Versions: 1.0, 1.1, 1.2, 1.3, 2.0, 2.1, 2.2, 2.2.1, 3.0 >Reporter: Christian Winter >Priority: Minor > Fix For: 3.0 > > > There are some inconsistencies in the documentation and implementation of > functions regarding cumulative probabilities and inverse cumulative > probabilities. More precisely, '<' and '<=' are not used in a consistent way. > Besides I would move the function inverseCumulativeProbability(double) to the > interface Distribution. A true inverse of the distribution function does > neither exist for Distribution nor for ContinuosDistribution. Thus we need to > define the inverse in terms of quantiles anyway, and this can already be done > for Distribution. > On the whole I would declare the (inverse) cumulative probability functions > in the basic distribution interfaces as follows: > Distribution: > - cumulativeProbability(double x): returns P(X <= x) > - cumulativeProbability(double x0, double x1): returns P(x0 < X <= x1) [see > also 1)] > - inverseCumulativeProbability(double p): > returns the quantile function inf{x in R | P(X<=x) >= p} [see also 2), 3), > and 4)] > 1) An aternative definition could be P(x0 <= X <= x1). But this requires to > put the function probability(double x) or another cumulative probability > function into the interface Distribution in order be able to calculate P(x0 > <= X <= x1) in AbstractDistribution. > 2) This definition is stricter than the definition in ContinuousDistribution, > because the definition there does not specify what to do if there are > multiple x satisfying P(X<=x) = p. > 3) A modification could be defined for p=0: Returning sup{x in R | P(X<=x) = > 0} would yield the infimum of the distribution's support instead of a > mandatory -infinity. > 4) This affects issue MATH-540. I'd prefere the definition from above for the > following reasons: > - This definition simplifies inverse transform sampling (as mentioned in the > other issue). > - It is the standard textbook definition for the quantile function. > - For integer distributions it has the advantage that the result doesn't > change when switching to "x in Z", i.e. the result is independent of > considering the intergers as sole set or as part of the reals. > ContinuousDistribution: > nothing to be added regarding (inverse) cumulative probability functions > IntegerDistribution: > - cumulativeProbability(int x): returns P(X <= x) > - cumulativeProbability(int x0, int x1): returns P(x0 < X <= x1) [see also 1) > above] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (POOL-191) ConcurrentModificationException in GenericObjectPool LinkedList
[ https://issues.apache.org/jira/browse/POOL-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128677#comment-13128677 ] Phil Steitz commented on POOL-191: -- Having dug a little bit into the lang code, I am inclined to bounce this back to [lang]. At the very least, the various private collection traversal thingies should come with warning labels. They should *not* be used in concurrent applications and the javadoc should indicate that. There do not appear to be any guards to prevent exactly this kind of exception, when the code breaks access protection and then ends up throwing CoMod exceptions because private collections are being modified while iterated. Other than the lack of a threadsafe toString, I don't see a [pool] bug here. > ConcurrentModificationException in GenericObjectPool LinkedList > --- > > Key: POOL-191 > URL: https://issues.apache.org/jira/browse/POOL-191 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.6 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > > It is possible to get a {{ConcurrentModificationException}} in a > {{LinkedList}} from a {{GenericObjectPool}}. > This happens when I call {{ReflectionToStringBuilder.toString(this)}} from a > subclass of {{GenericObjectPool}}. My guess is that it would happen with just > {{ReflectionToStringBuilder.toString(gop)}}. IOW, subclassing does not have > anything to do with it I would venture. > For example, in this stack trace {{JmsSessionPool}} is a subclass of > {{GenericObjectPool}}. > {noformat} > java.util.ConcurrentModificationException > at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:761) > at java.util.LinkedList$ListItr.next(LinkedList.java:696) > at java.util.AbstractCollection.toString(AbstractCollection.java:421) > at java.lang.String.valueOf(String.java:2826) > at java.lang.StringBuffer.append(StringBuffer.java:219) > at > org.apache.commons.lang3.builder.ToStringStyle.appendDetail(ToStringStyle.java:598) > at > org.apache.commons.lang3.builder.ToStringStyle.appendInternal(ToStringStyle.java:473) > at > org.apache.commons.lang3.builder.ToStringStyle.append(ToStringStyle.java:436) > at > org.apache.commons.lang3.builder.ToStringBuilder.append(ToStringBuilder.java:848) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:528) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:692) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:288) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:119) > at > com.seagullsw.appinterface.comm.jms.JmsSessionPool.toString(JmsSessionPool.java:120) > at java.lang.String.valueOf(String.java:2826) > at java.lang.StringBuffer.append(StringBuffer.java:219) > at > org.apache.commons.lang3.builder.ToStringStyle.appendDetail(ToStringStyle.java:586) > at > org.apache.commons.lang3.builder.ToStringStyle.appendInternal(ToStringStyle.java:550) > at > org.apache.commons.lang3.builder.ToStringStyle.append(ToStringStyle.java:436) > at > org.apache.commons.lang3.builder.ToStringBuilder.append(ToStringBuilder.java:848) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:528) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:689) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:288) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:119) > at > com.seagullsw.appinterface.server.comm.BasicCommunicationManager.toString(BasicCommunicationManager.java:828) > at > com.seagullsw.appinterface.server.comm.BasicCommunicationManager.toString(BasicCommunicationManager.java:817) > at java.lang.String.valueOf(String.java:2826) > at java.lang.StringBuilder.append(StringBuilder.java:115) > at > com.seagullsw.appinterface.server.AisHelper.waitForCommuncationManagers(AisHelper.java:217) > at com.seagullsw.appinterface.server.AisHelper.start(AisHelper.java:136) > at > com.seagullsw.appinterface.server.AisHelper.startFromResource(AisHelper.java:161) > at > com.seagullsw.appinterface.server.AbstractServerJunit4.startServer(AbstractServerJunit4.java:179) > a
[jira] [Commented] (POOL-191) ConcurrentModificationException in GenericObjectPool LinkedList
[ https://issues.apache.org/jira/browse/POOL-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128631#comment-13128631 ] Phil Steitz commented on POOL-191: -- I forgot that the allocation queue is a LinkedList, so in theory the exception could be coming from there. I would strongly recommend against trying to dump the contents of that field while the pool is running. I don't know how the reflection tostring builder stuff above works, but I would not recommend using reflection to circumvent visibility with classes such as GOP that rely on synchronization and limiting visibility to protect data structures. It would be better to code a threadsafe toString directly if that is what you need. > ConcurrentModificationException in GenericObjectPool LinkedList > --- > > Key: POOL-191 > URL: https://issues.apache.org/jira/browse/POOL-191 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.6 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > > It is possible to get a {{ConcurrentModificationException}} in a > {{LinkedList}} from a {{GenericObjectPool}}. > This happens when I call {{ReflectionToStringBuilder.toString(this)}} from a > subclass of {{GenericObjectPool}}. My guess is that it would happen with just > {{ReflectionToStringBuilder.toString(gop)}}. IOW, subclassing does not have > anything to do with it I would venture. > For example, in this stack trace {{JmsSessionPool}} is a subclass of > {{GenericObjectPool}}. > {noformat} > java.util.ConcurrentModificationException > at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:761) > at java.util.LinkedList$ListItr.next(LinkedList.java:696) > at java.util.AbstractCollection.toString(AbstractCollection.java:421) > at java.lang.String.valueOf(String.java:2826) > at java.lang.StringBuffer.append(StringBuffer.java:219) > at > org.apache.commons.lang3.builder.ToStringStyle.appendDetail(ToStringStyle.java:598) > at > org.apache.commons.lang3.builder.ToStringStyle.appendInternal(ToStringStyle.java:473) > at > org.apache.commons.lang3.builder.ToStringStyle.append(ToStringStyle.java:436) > at > org.apache.commons.lang3.builder.ToStringBuilder.append(ToStringBuilder.java:848) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:528) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:692) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:288) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:119) > at > com.seagullsw.appinterface.comm.jms.JmsSessionPool.toString(JmsSessionPool.java:120) > at java.lang.String.valueOf(String.java:2826) > at java.lang.StringBuffer.append(StringBuffer.java:219) > at > org.apache.commons.lang3.builder.ToStringStyle.appendDetail(ToStringStyle.java:586) > at > org.apache.commons.lang3.builder.ToStringStyle.appendInternal(ToStringStyle.java:550) > at > org.apache.commons.lang3.builder.ToStringStyle.append(ToStringStyle.java:436) > at > org.apache.commons.lang3.builder.ToStringBuilder.append(ToStringBuilder.java:848) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:528) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:689) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:288) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:119) > at > com.seagullsw.appinterface.server.comm.BasicCommunicationManager.toString(BasicCommunicationManager.java:828) > at > com.seagullsw.appinterface.server.comm.BasicCommunicationManager.toString(BasicCommunicationManager.java:817) > at java.lang.String.valueOf(String.java:2826) > at java.lang.StringBuilder.append(StringBuilder.java:115) > at > com.seagullsw.appinterface.server.AisHelper.waitForCommuncationManagers(AisHelper.java:217) > at com.seagullsw.appinterface.server.AisHelper.start(AisHelper.java:136) > at > com.seagullsw.appinterface.server.AisHelper.startFromResource(AisHelper.java:161) > at > com.seagullsw.appinterface.server.AbstractServerJunit4.startServer(AbstractServerJunit4.java:179) > at > com.seagullsw.appinterface.server.comm.jms.A
[jira] [Commented] (POOL-191) ConcurrentModificationException in GenericObjectPool LinkedList
[ https://issues.apache.org/jira/browse/POOL-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128618#comment-13128618 ] Phil Steitz commented on POOL-191: -- How exactly does JmsSessionPool.toString() work? GOP 1.5.6 does not implement toString and it does not expose the backing store, which is a ConcurrentLinkedList (a direct linked list impl stolen from [collections], not a subclass of j.u.LinkedList). My guess would be that you used GOP 1.5.6's package-scoped debugInfo method; but then the top of the trace does not make sense, because it should be ConcurrentLinkedList throwing. In theory, using debugInfo with the relaxed synchronization in borrow/return in 1.5.6 could cause ConcurrentMod exceptions, because while that method is synchronized, borrow and return are not fully synched. I will see if I can make this happen using [performance]. Can you share the relevant bits of the code of the subclass? Obviously a test case against [pool] itself would be best. > ConcurrentModificationException in GenericObjectPool LinkedList > --- > > Key: POOL-191 > URL: https://issues.apache.org/jira/browse/POOL-191 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 1.5.6 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary D. Gregory > > It is possible to get a {{ConcurrentModificationException}} in a > {{LinkedList}} from a {{GenericObjectPool}}. > This happens when I call {{ReflectionToStringBuilder.toString(this)}} from a > subclass of {{GenericObjectPool}}. My guess is that it would happen with just > {{ReflectionToStringBuilder.toString(gop)}}. IOW, subclassing does not have > anything to do with it I would venture. > For example, in this stack trace {{JmsSessionPool}} is a subclass of > {{GenericObjectPool}}. > {noformat} > java.util.ConcurrentModificationException > at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:761) > at java.util.LinkedList$ListItr.next(LinkedList.java:696) > at java.util.AbstractCollection.toString(AbstractCollection.java:421) > at java.lang.String.valueOf(String.java:2826) > at java.lang.StringBuffer.append(StringBuffer.java:219) > at > org.apache.commons.lang3.builder.ToStringStyle.appendDetail(ToStringStyle.java:598) > at > org.apache.commons.lang3.builder.ToStringStyle.appendInternal(ToStringStyle.java:473) > at > org.apache.commons.lang3.builder.ToStringStyle.append(ToStringStyle.java:436) > at > org.apache.commons.lang3.builder.ToStringBuilder.append(ToStringBuilder.java:848) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:528) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:692) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:288) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:119) > at > com.seagullsw.appinterface.comm.jms.JmsSessionPool.toString(JmsSessionPool.java:120) > at java.lang.String.valueOf(String.java:2826) > at java.lang.StringBuffer.append(StringBuffer.java:219) > at > org.apache.commons.lang3.builder.ToStringStyle.appendDetail(ToStringStyle.java:586) > at > org.apache.commons.lang3.builder.ToStringStyle.appendInternal(ToStringStyle.java:550) > at > org.apache.commons.lang3.builder.ToStringStyle.append(ToStringStyle.java:436) > at > org.apache.commons.lang3.builder.ToStringBuilder.append(ToStringBuilder.java:848) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.appendFieldsIn(ReflectionToStringBuilder.java:528) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:689) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:288) > at > org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(ReflectionToStringBuilder.java:119) > at > com.seagullsw.appinterface.server.comm.BasicCommunicationManager.toString(BasicCommunicationManager.java:828) > at > com.seagullsw.appinterface.server.comm.BasicCommunicationManager.toString(BasicCommunicationManager.java:817) > at java.lang.String.valueOf(String.java:2826) > at java.lang.StringBuilder.append(StringBuilder.java:115) > at > com.seagullsw.appinterface.server.AisHelper.waitForCommuncationManagers(AisHelper.java:217) > at com.seagullsw.appinterface.serv
[jira] [Commented] (MATH-691) Statistics.setVarianceImpl makes getStandardDeviation produce NaN
[ https://issues.apache.org/jira/browse/MATH-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128497#comment-13128497 ] Phil Steitz commented on MATH-691: -- Warren reported that the second workaround above does not work. He is correct. That is the result of yet another problem in this class. {code} public double getVariance() { if (varianceImpl == variance) { return new Variance(secondMoment).getResult(); } else { return varianceImpl.getResult(); } } {code} In the first case, varianceImpl is not used, so setting its properties has no effect. The mean has a similar problem. The root cause of all of these problems is the reuse of momemts (i.e., just incrementing the moments instead of both them and the Mean and Variance instances). We could either toss this (slight loss in performance, but likely trivial) or expose or allow moments to be attached to Mean, Variance instances. > Statistics.setVarianceImpl makes getStandardDeviation produce NaN > - > > Key: MATH-691 > URL: https://issues.apache.org/jira/browse/MATH-691 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.2 > Environment: Windows 7 64-bit, java version 1.6.0_23 >Reporter: Warren Tang >Priority: Minor > Original Estimate: 5h > Remaining Estimate: 5h > > Invoking SummaryStatistics.setVarianceImpl(new Variance(true/false) makes > getStandardDeviation produce NaN. The code to reproduce it: > {code:java} > int[] scores = {1, 2, 3, 4}; > SummaryStatistics stats = new SummaryStatistics(); > stats.setVarianceImpl(new Variance(false)); //use "population variance" > for(int i : scores) { > stats.addValue(i); > } > double sd = stats.getStandardDeviation(); > System.out.println(sd); > {code} > A workaround suggested by Mikkel is: > {code:java} > double sd = FastMath.sqrt(stats.getSecondMoment() / stats.getN()); > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-691) Statistics.setVarianceImpl makes getStandardDeviation produce NaN
[ https://issues.apache.org/jira/browse/MATH-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128454#comment-13128454 ] Phil Steitz commented on MATH-691: -- Thanks for reporting this. Another workaround is to work with the default impl: {code} SummaryStatistics stats = new SummaryStatistics(); Variance variance = (Variance) stats.getVarianceImpl(); variance.setBiasCorrected(false); {code} and then just use the stats instance directly. The problem in the SummaryStatistics code is in addValue: {code} // If mean, variance or geomean have been overridden, // need to increment these if (!(meanImpl instanceof Mean)) { meanImpl.increment(value); } if (!(varianceImpl instanceof Variance)) { varianceImpl.increment(value); } if (!(geoMeanImpl instanceof GeometricMean)) { geoMeanImpl.increment(value); } {code} The default impls get incremented via their embedded moments, so the code above skips incrementing them. If, however, they have been overridden by instances of the same class (as in this bug report), this causes a problem. > Statistics.setVarianceImpl makes getStandardDeviation produce NaN > - > > Key: MATH-691 > URL: https://issues.apache.org/jira/browse/MATH-691 > Project: Commons Math > Issue Type: Bug >Affects Versions: 2.2 > Environment: Windows 7 64-bit, java version 1.6.0_23 >Reporter: Warren Tang >Priority: Minor > Original Estimate: 5h > Remaining Estimate: 5h > > Invoking SummaryStatistics.setVarianceImpl(new Variance(true/false) makes > getStandardDeviation produce NaN. The code to reproduce it: > {code:title=test.java} > int[] scores = {1, 2, 3, 4}; > SummaryStatistics stats = new SummaryStatistics(); > stats.setVarianceImpl(new Variance(false)); //use "population variance" > for(int i : scores) { > stats.addValue(i); > } > double sd = stats.getStandardDeviation(); > System.out.println(sd); > {code} > A workaround is: > {code:title=test.java} > double sd = FastMath.sqrt(stats.getSecondMoment() / stats.getN()); > {code} > as suggested by Mikkel. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-689) Breaking up "MathUtils"
[ https://issues.apache.org/jira/browse/MATH-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13126356#comment-13126356 ] Phil Steitz commented on MATH-689: -- Sorry I missed this before. Can we change "ArithmeticsUtils" to "ArithmeticUtils." > Breaking up "MathUtils" > --- > > Key: MATH-689 > URL: https://issues.apache.org/jira/browse/MATH-689 > Project: Commons Math > Issue Type: Task >Reporter: Gilles >Priority: Trivial > Labels: api-change > Fix For: 3.0 > > > Issue related to this > [proposal|http://www.mail-archive.com/dev@commons.apache.org/msg25617.html]. > There seemed to be a global agreement on the following break-up: > * Arithmetics (for "addAndCheck", "factorial", "gcd", ...) > * Precision (for "equals", "compare", ...) > * Binomial (for "binomialCoefficient") > * MathArrays (for "linearCombination", "distance", "safeNorm", > "sortInPlace", "copyOf", ...) > I think that "ordinary" mathematical functions ("pow", "cosh", ...) should go > into "FastMath" (if not already available there). > Those who are willing to work on this issue, please coordinate here. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-682) Pascal triangle
[ https://issues.apache.org/jira/browse/MATH-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119349#comment-13119349 ] Phil Steitz commented on MATH-682: -- This is already available via the various binomial coefficient methods. What am I missing here? > Pascal triangle > > > Key: MATH-682 > URL: https://issues.apache.org/jira/browse/MATH-682 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 > Environment: All >Reporter: DI COSTANZO >Priority: Trivial > Attachments: PascalTriangle.java, PascalTriangle.java, > PascalTriangle.java, PascalTriangleTest.java, PascalTriangleTest.java > > > Create a method to get Pascal's triangle coefficient. This method could be > implemented in MathUtils, in a static way, with the following signature : > double[] getTriangleCoefficient(final int order) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-445) Replace "package.html" by "package-info.java"
[ https://issues.apache.org/jira/browse/MATH-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13118901#comment-13118901 ] Phil Steitz commented on MATH-445: -- Might be good to commit the script somewhere, like committers/tools for other projects that may want to do this. > Replace "package.html" by "package-info.java" > - > > Key: MATH-445 > URL: https://issues.apache.org/jira/browse/MATH-445 > Project: Commons Math > Issue Type: Task >Reporter: Gilles >Priority: Trivial > Fix For: 3.0 > > > The newest (and recommended, I think) way of documenting packages is through > "package-info.java" files. > CM still uses "package.html" files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira