commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shing Hing Man <mat...@yahoo.com>
Subject Re: [Math] Frequency : Is int comparable to Integer through default comparator
Date Wed, 11 Aug 2004 21:36:14 GMT
Mark,
  Thank you for explaining the cause of the
IllegalArgumentException !

I think there is no need to implement  a 'default
comparator' 
to make objects of type like Integer and Long
comparable.
The current version of the class Frequency would meet
the needs 
of most user.  

In most situations, your data could  be casted to a
common type.
If a user wants to  add data of different types, or
even their 
own custom type, he/she could implement their own
comparator to
avoid the ClassCastException, hence the
IllegalArgumentException,
when retrieving elements from TreeMap.



regards,
Shing


 --- "Mark R. Diggory" <mdiggory@latte.harvard.edu>
wrote: 
> Actually,
> 
> getting the old behavior back should probably look
> more like this. I 
> don't recommend we maintain this as a long term
> solution, we could do 
> some type detection and recognize that a char and a
> String can be equal 
> in some cases, as well, we could modify the class to
> support bins that 
> are "ranges", then frequencies could be done with
> floating point values.
> 
> Right now, if you add floating point values, but
> they get truncated to 
> longs in the comparision and will overwrite the the
> entry, which the 
> user may not see as expected behavior.
> 
> >     private static class NaturalComparator
> implements Comparator {
> >
> >         public int compare(Object o1, Object o2) {
> >             
> >             if(o1 instanceof Number && o2
> instanceof Number){
> >                 long thisVal =
> ((Number)o1).longValue();
> >                 long anotherVal =
> ((Number)o2).longValue();
> >                 return (thisVal<anotherVal ? -1 :
> (thisVal==anotherVal 
> > ? 0 : 1));
> >             }else{
> >                 return
> ((Comparable)o1).compareTo(o2);
> >             }
> >             
> >         }
> >     }
> 
> 
> 
> Mark R. Diggory wrote:
> 
> > It looks as though we will have write our own
> object comparator that 
> > will work with the major objects we want to add to
> the frequecy table. 
> > We need to consider that if we want to be able to
> add any object to 
> > the frequency, that not only does it need to
> extend Comparable, but it 
> > also needs to be castable to any other type stored
> in the Tree.
> >
> > Phil, this looks like an issue that arose when you
> modified Frequency 
> > to use the TreeMap instead of Commons Collections.
> I think we could 
> > still use it if we establish some override on the
> sorting/comparision 
> > mechanism. Like:
> >
> >> /**
> >>      * A Comparator that compares comparable
> objects using the
> >>      * natural order.  Copied from Commons
> Collections 
> >> ComparableComparator.
> >>      */
> >>     private static class NaturalComparator
> implements Comparator {
> >>         /**
> >>          * Compare the two {@link Comparable
> Comparable} arguments.
> >>          * This method is equivalent to:
> >>          * <pre>(({@link Comparable
> Comparable})o1).{@link 
> >> Comparable#compareTo compareTo}(o2)</pre>
> >>          *
> >>          * @param  o1 the first object
> >>          * @param  o2 the second object
> >>          * @return  result of comparison
> >>          * @throws NullPointerException when
> <i>o1</i> is 
> >> <code>null</code>,
> >>          *         or when 
> >> <code>((Comparable)o1).compareTo(o2)</code> does
> >>          * @throws ClassCastException when
> <i>o1</i> is not a {@link 
> >> Comparable Comparable},
> >>          *         or when 
> >> <code>((Comparable)o1).compareTo(o2)</code> does
> >>          */
> >>         public int compare(Object o1, Object o2)
> {
> >>             try{
> >>                 return
> ((Comparable)o1).compareTo(o2);
> >>             }catch(Exception e){
> >>                 return -1;
> >>             }
> >>         }
> >>     }
> >
> >
> >
> > -Mark
> >
> > Mark R. Diggory wrote:
> >
> >> Actually, it looks like the source of this error
> is in a 
> >> Classcastexception when attempting to get the
> object from the 
> >> TreeMap. This is caused because the object (a
> Long) is not an 
> >> "Integer", which the TreeMap is causing in its
> comparison of an 
> >> Integer to a Long object, the comparison of an
> Integer to Long throws 
> >> the class cast exception in the Integer Class.
> >>
> >> It appears we are assuming that Integers and
> Longs can be compared to 
> >> one another just because they Implement
> Comparable is a bad 
> >> assumption, This probably isn't what was
> expected. These objects 
> >> implement Comparable, but they throw exceptions
> when specific 
> >> requirements are not met. I can't say that its a
> very elegant 
> >> solution on Sun's part.
> >>
> >> Ouch <snip from Integer>:
> >>
> >>>    /**
> >>>      * Compares this <code>Integer</code> object
> to another object.
> >>>      * If the object is an <code>Integer</code>,
> this function behaves
> >>>      * like <code>compareTo(Integer)</code>. 
> Otherwise, it throws a
> >>>      * <code>ClassCastException</code> (as
> <code>Integer</code>
> >>>      * objects are only comparable to other
> <code>Integer</code>
> >>>      * objects).
> >>>      *
> >>>      * @param   o the <code>Object</code> to be
> compared.
> >>>      * @return  the value <code>0</code> if the
> argument is a
> >>>      *        <code>Integer</code> numerically
> equal to this
> >>>      *        <code>Integer</code>; a value less
> than <code>0</code>
> >>>      *        if the argument is a
> <code>Integer</code> numerically
> >>>      *        greater than this
> <code>Integer</code>; and a value
> >>>      *        greater than <code>0</code> if the
> argument is a
> >>>      *        <code>Integer</code> numerically
> less than this
> >>>      *        <code>Integer</code>.
> >>>      * @exception
> <code>ClassCastException</code> if the argument is 
> >>> not an
> >>>      *          <code>Integer</code>.
> >>>      * @see     java.lang.Comparable
> >>>      * @since   1.2
> >>>      */
> >>>     public int compareTo(Object o) {
> >>>     return compareTo((Integer)o);
> >>>     }
> >>
> >>
> >>
> >>
> >> Mark R. Diggory wrote:
> >>
> >>> I looked over the code and the default
> comparator uses the default 
> >>> "compare" method of the object. All ints and
> longs are wrapped in a 
> >>> "Long" before being added to the Frequency
> table. I suspect that the 
> >>> Long objects being added cannot be compared to
> the Character objects 
> >>> without throwing an error?
> >>>
> >>> The other thought is that the NaturalComparator
> is not added to 
> >>> default TreeMap when its created.
> >>>
> >>> Frequency.NaturalComparator
> >>>
>
http://jakarta.apache.org/commons/math/xref/org/apache/commons/math/stat/Frequency.html#401
> 
> 
=== message truncated === 

=====
Home page :
  http://uk.geocities.com/matmsh/index.html


	
	
		
___________________________________________________________ALL-NEW Yahoo! Messenger - all
new features - even more fun!  http://uk.messenger.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message