[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-711) Merge xxxDistribution and xxxDistributionImpl in package distribution
[
https://issues.apache.org/jira/browse/MATH-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-694) Remove XxMoment statistics from the public API
[ https://issues.apache.org/jira/browse/MATH-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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] (MATH-703) Splitting up the distribution hierarchy
[ https://issues.apache.org/jira/browse/MATH-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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] (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-tabpanelfocusedCommentId=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.ToStringStyle.append(ToStringStyle.java:436)
at
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-692) Cumulative probability and inverse cumulative probability inconsistencies
[
https://issues.apache.org/jira/browse/MATH-692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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] (MATH-691) Statistics.setVarianceImpl makes getStandardDeviation produce NaN
[
https://issues.apache.org/jira/browse/MATH-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-691) Statistics.setVarianceImpl makes getStandardDeviation produce NaN
[
https://issues.apache.org/jira/browse/MATH-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] (POOL-191) ConcurrentModificationException in GenericObjectPool LinkedList
[
https://issues.apache.org/jira/browse/POOL-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.server.AisHelper.start(AisHelper.java:136)
at
[jira] [Commented] (POOL-191) ConcurrentModificationException in GenericObjectPool LinkedList
[
https://issues.apache.org/jira/browse/POOL-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (POOL-191) ConcurrentModificationException in GenericObjectPool LinkedList
[
https://issues.apache.org/jira/browse/POOL-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
at
[jira] [Commented] (MATH-689) Breaking up MathUtils
[ https://issues.apache.org/jira/browse/MATH-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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
