I didn't see this as an open issue on the JIRA bug list, so I thought
I would ask about it here.
(cl-format nil ~,5f -434343.867071)
-434343.86707
(cl-format nil ~,5f -434343.867072)
-434343.86707
(cl-format nil ~,5f -434343.867075)
For input string: 43434386707
[Thrown class
Yes that compareTo doesn't define a total order on your class. I think
you are missing a clause in cond:
You're right on. I refactored the toCompare function to meet the
requirements outlined in its javadoc, and it worked. I'm a little
ashamed I didn't do that before wasting people's time...
My guess is that it's your likelihood function that's actually broken.
If sr1 and sr2 don't come out with the same likelihood, then in some
cases of putting them into the sorted set they'll never end up
compared with each other for equality. (Actually, I'd have thought in
all cases. Perhaps
Stuart,
In order for this to work, the quasi-isomorphic? function has be reflexive.
Is it? (The .equals implementation is also missing a type test, but that
probably isn't the problem here.)
Yes, it is reflexive, and symmetric:
user (quasi-isomorphic? t2 t1)
true
user (quasi-isomorphic?
You should also try using a TreeSet and see if you get the same results as
with sorted-set.
I get the same results with TreeSet. After looking at the javadocs
more carefully, I realized the Comparator isn't implemented properly,
namely, it's not doing this:
The implementor must ensure
All,
I'm hoping another, wiser set of eyes can help me to see what I'm doing
wrong.
I've defined a deftype below that stores a likelihood and a tree structure
(nested vectors). The deftype overrides equals, etc, and implements
Comparable so I can add SearchResults to a sorted-set and sort by
