possible bug in cl-format (rounding floating-point number)
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 java.lang.NumberFormatException] Backtrace: 0: java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) 1: java.lang.Integer.parseInt(Integer.java:461) 2: java.lang.Integer.valueOf(Integer.java:554) 3: clojure.pprint$round_str.invoke(cl_format.clj:585) After looking at the round-str function, it appears that if round-char = 5, then result is parsed by Integer.valueOf(result), which causes an exception if result is too large. I rewrote part of it to use BigInteger, and it seemed to fix the problem, but I didn't test it extensively. It might be a valid solution in any case. Incidentally, I love using clojure.pprint. It's powerful, and after diving into the CLM spec I have new appreciation for the daunting task it must be to test it. -Travis -- 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
Re: Question about sorted-sets
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... Thanks, -Travis -- 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
Re: Question about sorted-sets
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?) I thought this too, originally, but in my example above, all of the sr likelihoods are set to 1. I was under the assumption that when you tried to add to a set, it would check all of the members of that set before allowing its insertion. In the example above, sr2 is never even checked against sr1, the one SearchResult that is indeed equal to s2. Maybe I'm implementing (overriding, as the case may be) the wrong interfaces to get this working correctly. -Travis -- 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
Re: Question about sorted-sets
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? t1 t2) true user (quasi-isomorphic? t1 t1) true user (quasi-isomorphic? t2 t2) true What I really don't understand, is that when I set a breakpoint in the equals function to see what search records are being compared, the comparison between sr1 and sr2 never occurs, even though sr1 is in the set when sr2 is added. From Rich's videos I think I remember these persistent data structures being ideal hash tries, so I tried to look at the PersistentMap code to see why this was occurring. No luck, yet. I also thought that the deftype might need to implement a different interface for this to work. You should also try using a TreeSet and see if you get the same results as with sorted-set. I will. Thank you for the suggestions. -Travis -- 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
Re: Question about sorted-sets
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.compareTo(y)) == -sgn(y.compareTo(x)) for all x and y. I'll fix that and cross my fingers. Thanks, -Travis -- 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
Question about sorted-sets
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.
--
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
