Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <1596088189.1239758534942.JavaMail.jira@brutus>
Date: Tue, 14 Apr 2009 18:22:14 -0700 (PDT)
From: "Phil Steitz (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (MATH-259) Bugs in Frequency API
In-Reply-To: <2110359616.1239023833579.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/MATH-259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699014#action_12699014 ] 

Phil Steitz commented on MATH-259:
----------------------------------

I am OK with adding a check and throwing illegalArgumentExeption if an object that does not implement Comparable is supplied to these methods (as indicated in the javadoc), but not keen on introducing the compatibility issue.

> Bugs in Frequency API
> ---------------------
>
>                 Key: MATH-259
>                 URL: https://issues.apache.org/jira/browse/MATH-259
>             Project: Commons Math
>          Issue Type: Bug
>            Reporter: Sebb
>
> I think the existing Frequency API has some bugs in it.
> The addValue(Object v) method allows one to add a plain Object, but one cannot add anything further to the instance, as the second add fails with IllegalArgumentException.
> In fact, the problem is with the first call to addValue(Object) which should not allow a plain Object to be added - it should only allow Comparable objects.
> This could be fixed by checking that the object is Comparable.
> Similar considerations apply to the getCumFreq(Object) and getCumPct(Object) methods - they will only work with objects that implement Comparable.
> The getCount(Object) and getPct(Object) methods don't fail when given a non-Comparable object (because the class cast exception is caught), however they just return 0 as if the object was not present:
> {code}
>         final Object OBJ = new Object();
>         f.addValue(OBJ); // This ought to fail, but doesn't, causing the unexpected behaviour below
>         System.out.println(f.getCount(OBJ)); // 0
>         System.out.println(f.getPct(OBJ)); // 0.0
> {code}
> Rather than adding extra checks for Comparable, it seems to me that the API would be much improved by using Comparable instead of Object.
> Also, it should make it easier to implement generics.
> However, this would cause compilation failures for some programs that pass Object rather than Comparable to the class.
> These would need recoding, but I think they would continue to run OK against the new API.
> It would also affect the run-time behaviour slightly, as the first attempt to add a non-Comparable object would fail, rather than the second add of a possibly valid object.
> But is that a viable program? It can only add one object, and any attempt to get statistics will either return 0 or an Exception, and applying the instanceof fix would also cause it to fail.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.