On Mon, Jan 10, 2011 at 10:23 PM, Travis Treseder
<travis.trese...@gmail.com> wrote:
> 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
> likelihood. Equal SearchResults have the same likelihood and have
> quasi-isomorphic tree structures.
> (deftype SearchResult [lik tree]
> Object
> (toString [sr]
> (str lik ":" tree))
> (equals [sr other]
> (and (= lik (.lik other)) (quasi-isomorphic? tree (.tree other))))
> (hashCode [sr]
> (int lik))
>
> Comparable
> (compareTo [sr sr2]
> (cond
> (= sr sr2) 0
> (> (.lik sr) (.lik sr2)) -1
> :default 1)))
> I've defined some dummy data, which should illustrate the unusual behavior
> I'm seeing when I add SearchResults to a sorted-set.
> user> (def t1 [{:name 0} [{:name 1} [{:name 3}] [{:name 2}]] [{:name 4}]])
> user> (def t2 [{:name 0} [{:name 1} [{:name 2}] [{:name 3}]] [{:name 4}]])
> user> (def t3 [{:name 0} [{:name 1} [{:name 4}] [{:name 2}]] [{:name 3}]])
> user> (def t4 [{:name 0} [{:name 1} [{:name 4}] [{:name 3}]] [{:name 2}]])
> user> (quasi-isomorphic? t1 t2)
> true
> user> (quasi-isomorphic? t1 t3)
> false
> user> (quasi-isomorphic? t1 t4)
> false
> user> (def sr1 (SearchResult. 1 t1))
> user> (def sr2 (SearchResult. 1 t2))
> user> (def sr3 (SearchResult. 1 t3))
> user> (def sr4 (SearchResult. 1 t4))
> user> (= sr1 sr2)
> true
> user> (= sr1 sr3)
> false
> user> (= sr1 sr4)
> false
> user> (def ss (sorted-set))
> true
> user> (count (conj ss sr1 sr3 sr4 sr2))
> 4
> user> (count (conj ss sr1 sr2 sr3 sr4))
> 3
> Of the four SearchResults, only sr1 and sr2 should be equal per the equals
> and compareTo functions defined in SearchResult. Based on that assumption,
> I thought that evaluating (conj ss sr1 sr3 sr4 sr2) would only return a set
> containing sr1, sr3, sr4, but it actually returns a set containing all four
> SearchResults. However, if I change the order of the SearchResults, as
> in (conj ss sr1 sr2 sr3 sr4), it works as expected, returning the set
> containing sr1, sr3, sr4.
> I've tried debugging the equals function to see what, exactly, is being
> compared, and it looks like in (conj ss sr1 sr3 sr4 sr2), sr2 is never
> actually compared to sr1, so sr2 gets added to the set. What am I missing?
> Any help would be greatly appreciated.
> -Travis
> p.s. Yes, the hashCode function isn't the best, but from what I could read,
> it does fulfill the requirements of the contract outlined in the javadocs.
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 the compareTo is separately broken and doesn't
total-order by likelihood?)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
