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
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
lik
> 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. Perha
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-isomor
> 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 sgn(x
> 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...
