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 [EMAIL PROTECTED] Comparable Comparable} arguments.
* This method is equivalent to:
* <pre>(([EMAIL PROTECTED] Comparable Comparable})o1)[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
public int compare(Object o1, Object o2) { return ((Comparable)o1).compareTo(o2); }
Shing Hing Man wrote:
Deal all, It would be appreciated if someone could clarify the following on org.apache.commons.math.stat.univariate.Frequency.
My version of org.apache.commons.math is dated 10
August, 2004.
The following snippet piece of code is from
http://jakarta.apache.org/commons/math/userguide/stat.html#1.3%20Frequency%20distributions
Frequency f = new Frequency(); f.addValue(1); f.addValue(new Integer(1)); // (*) f.addValue(new Long(1)); f.addValue(2); f.addValue(new Integer(-1)); System.out.println(f.getCount(1)); // displays 3 System.out.println(f.getCumPct(0)); // displays 0.2 System.out.println(f.getPct(new Integer(1))); // displays 0.6 System.out.println(f.getCumPct(-2)); // displays 0 System.out.println(f.getCumPct(10)); // displays 1
When I run it, I got the following exception at line (*).
Exception in thread "main" java.lang.IllegalArgumentException: Value not comparable to existing values.
It looks as though the default comparator can not compare primitive type int with Integer object. I thought this piece of code is supposed to demonstrate the otherwise.
Thanks in advice for your help !
Shing
===== 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Mark R. Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
