[jira] [Updated] (MATH-418) add a storeless version of Percentile
[ https://issues.apache.org/jira/browse/MATH-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Venkatesha Murthy TS updated MATH-418: -- Attachment: 30-may-2014-418-psquare-patch I have incorporated almost all comments. Please find the latest patch by date 30-may-2014-418-psquare-patch. Please suggest for further changes and i am greatly indebted to the review comments and hope to have much less going further. One question i have though is if i need to major algorithm part which is under private static now; i am under the impression to provide a creation method and expose the object as an protected interface. In order to do coverage and tests ; was forced to do this. Please help me if this is ok. Now with this i have made sure to not impact existing instance. Summary: - a) Modified to use appropriate exception such as NullArgumentException etc where required b) Turned all inner classes as private static; however keeping a thin interfaces as protected. Even this will not impact the existing instance of PSquaredPercentile. c) I have cleared findbugs, checkstyle, pmd and about 93% of jacoco code coverage. Thanks a ton. Please let me know if i could do a quick chat over so that i can quickly understand context and rationale of any further comments. Regards Venkat. > add a storeless version of Percentile > - > > Key: MATH-418 > URL: https://issues.apache.org/jira/browse/MATH-418 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Luc Maisonobe > Fix For: 4.0 > > Attachments: 30-may-2014-418-psquare-patch, 418-psquare-patch, > psquare-patch > > > The Percentile class can handle only in-memory data. > It would be interesting to use an on-line algorithm to estimate quantiles as > a storeless statistic. > An example of such an algorithm is the exponentially weighted stochastic > approximation described in a 2000 paper by Fei Chen , Diane Lambert and > José C. Pinheiro "Incremental Quantile Estimation for Massive Tracking" which > can be retrieved from CiteSeerX at > [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.105.1580]. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (WEAVER-1) Enhance [weaver] documentation
[ https://issues.apache.org/jira/browse/WEAVER-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved WEAVER-1. -- Resolution: Fixed Applied, thanks again! > Enhance [weaver] documentation > -- > > Key: WEAVER-1 > URL: https://issues.apache.org/jira/browse/WEAVER-1 > Project: Commons Weaver > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Labels: docuentation > Attachments: WEAVER-1.patch, weaver.png, weaver.svg > > > Enhance the documentation of [weaver] component. We can maybe add a user's > guide, a 5 minute introduction, images or re-format the existing > documentation. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COLLECTIONS-531) Generic Wildcards specified in CollectionUtils#isEqualCollection(Collection, Collection, Equator) may throw ClassCastException in certain cases
[
https://issues.apache.org/jira/browse/COLLECTIONS-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012671#comment-14012671
]
Thomas Neidhart commented on COLLECTIONS-531:
-
Committed in r1598357.
I have verified that the change does not break b/c and it should be fine.
Additionally added a note to the javadoc that providing incompatible types,
e.g. by casting, will result in a ClassCastException at runtime. This is
probably a worthwhile distinction to the isEqualCollection(C, C) method which
does support incompatible types (although will always return false for
non-empty collections in such a case).
Thanks for the report!
> Generic Wildcards specified in CollectionUtils#isEqualCollection(Collection,
> Collection, Equator) may throw ClassCastException in certain cases
> ---
>
> Key: COLLECTIONS-531
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-531
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 4.0
>Reporter: Dipanjan Laha
>Priority: Minor
> Fix For: 4.1
>
> Attachments: IsEqualCollectionTest.java
>
>
> CollectionUtils#isEqualCollection(Collection, Collection, Equator) is defined
> as
> {code}
> public static boolean isEqualCollection(final Collection a, final
> Collection b, final Equator equator) {
> ...
> }
> {code}
> This makes it possible to invoke it with a code like
> {code}
> public static class IntegerEquator implements Equator {
> public boolean equate(Integer o1, Integer o2) {
> return o1.intValue() == o2.intValue();
> }
> public int hash(Integer o) {
> return o.intValue();
> }
> }
> @Test
> public void test() {
> List longList = Arrays.asList(1L, 2L);
> List intList = Arrays.asList(1, 2);
> assertTrue(CollectionUtils.isEqualCollection(longList, intList, new
> IntegerEquator()));
> }
> {code}
> which compiles perfectly but throws a ClassCastException as Long cannot be
> cast to an Integer. However, the generics should be defined such that this is
> stopped at compile time itself.
> If we modify the method to something like
> {code}
> public static boolean isEqualCollection(final Collection a,
> final Collection b, final Equator equator) {
> ...
> }
> {code}
> the above example would give a compile time error. imho we should modify this
> method with bounded wildcards. I don't think this change would break any
> existing binaries if the method is being used correctly, otherwise it is
> probably throwing ClassCastExceptions anyway.
> Test case attached
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (COLLECTIONS-531) Generic Wildcards specified in CollectionUtils#isEqualCollection(Collection, Collection, Equator) may throw ClassCastException in certain cases
[
https://issues.apache.org/jira/browse/COLLECTIONS-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved COLLECTIONS-531.
-
Resolution: Fixed
Fix Version/s: 4.1
> Generic Wildcards specified in CollectionUtils#isEqualCollection(Collection,
> Collection, Equator) may throw ClassCastException in certain cases
> ---
>
> Key: COLLECTIONS-531
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-531
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection
>Affects Versions: 4.0
>Reporter: Dipanjan Laha
>Priority: Minor
> Fix For: 4.1
>
> Attachments: IsEqualCollectionTest.java
>
>
> CollectionUtils#isEqualCollection(Collection, Collection, Equator) is defined
> as
> {code}
> public static boolean isEqualCollection(final Collection a, final
> Collection b, final Equator equator) {
> ...
> }
> {code}
> This makes it possible to invoke it with a code like
> {code}
> public static class IntegerEquator implements Equator {
> public boolean equate(Integer o1, Integer o2) {
> return o1.intValue() == o2.intValue();
> }
> public int hash(Integer o) {
> return o.intValue();
> }
> }
> @Test
> public void test() {
> List longList = Arrays.asList(1L, 2L);
> List intList = Arrays.asList(1, 2);
> assertTrue(CollectionUtils.isEqualCollection(longList, intList, new
> IntegerEquator()));
> }
> {code}
> which compiles perfectly but throws a ClassCastException as Long cannot be
> cast to an Integer. However, the generics should be defined such that this is
> stopped at compile time itself.
> If we modify the method to something like
> {code}
> public static boolean isEqualCollection(final Collection a,
> final Collection b, final Equator equator) {
> ...
> }
> {code}
> the above example would give a compile time error. imho we should modify this
> method with bounded wildcards. I don't think this change would break any
> existing binaries if the method is being used correctly, otherwise it is
> probably throwing ClassCastExceptions anyway.
> Test case attached
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JCS-129) don't log stats on dispose
[ https://issues.apache.org/jira/browse/JCS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012628#comment-14012628 ] Hudson commented on JCS-129: UNSTABLE: Integrated in commons-jcs #17 (See [https://builds.apache.org/job/commons-jcs/17/]) JCS-129 removing stats from info log in dispose() (rmannibucau: rev a733b7a87ce7abc0da33a3d56da82b72407683d8) * commons-jcs-core/src/main/java/org/apache/commons/jcs/engine/control/CompositeCache.java > don't log stats on dispose > -- > > Key: JCS-129 > URL: https://issues.apache.org/jira/browse/JCS-129 > Project: Commons JCS > Issue Type: Improvement >Reporter: Romain Manni-Bucau > Fix For: jcs-2.0.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (MATH-1125) TDistribution density function can be sped up.
[ https://issues.apache.org/jira/browse/MATH-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-1125. --- Resolution: Fixed Fix Version/s: 3.4 Fixed in r1598342. thanks for the patch and report! > TDistribution density function can be sped up. > -- > > Key: MATH-1125 > URL: https://issues.apache.org/jira/browse/MATH-1125 > Project: Commons Math > Issue Type: Bug >Reporter: Ajo Fod > Fix For: 3.4 > > Attachments: TDist.java > > > Some precomputable calculations are being done in the TDistirbution.density > function. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (JCS-129) don't log stats on dispose
[ https://issues.apache.org/jira/browse/JCS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Manni-Bucau resolved JCS-129. Resolution: Fixed > don't log stats on dispose > -- > > Key: JCS-129 > URL: https://issues.apache.org/jira/browse/JCS-129 > Project: Commons JCS > Issue Type: Improvement >Reporter: Romain Manni-Bucau > Fix For: jcs-2.0.0 > > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (JCS-129) don't log stats on dispose
Romain Manni-Bucau created JCS-129: -- Summary: don't log stats on dispose Key: JCS-129 URL: https://issues.apache.org/jira/browse/JCS-129 Project: Commons JCS Issue Type: Improvement Reporter: Romain Manni-Bucau Fix For: jcs-2.0.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
