[cdr-discuss] EQUALS, COMPARE and HASH-CODE
Hi here is the second iteration for the "equality and comparison" proposal. Major changes: Adopted EQUALS Made recursive-p a keyword Added HASH-CODE I can see the merit of the COMPARE-OP proposal of Matthew's but I did not put it in. I am open to it, but I'd like to hear others on the subject. Cheers -- Marco Antoniotti
On 1 March 2011 13:18, Marco Antoniotti <marcoxa@cs.nyu.edu> wrote:
Made recursive-p a keyword
This is truly a minor nit -- so it is probably best ignored -- but I at least mostly use the -P suffix only for function names, not variables or keywords. Consider :JUNK-ALLOWED, not :JUNK-ALLOWED-P. *shrug* Cheers, -- Nikodemus
I actually do debate with myself every time I must write one of these variables :} Any clear preference one way or the other out there? Marco On Mar 1, 2011, at 13:49 , Nikodemus Siivola wrote:
On 1 March 2011 13:18, Marco Antoniotti <marcoxa@cs.nyu.edu> wrote:
Made recursive-p a keyword
This is truly a minor nit -- so it is probably best ignored -- but I at least mostly use the -P suffix only for function names, not variables or keywords.
Consider :JUNK-ALLOWED, not :JUNK-ALLOWED-P.
*shrug*
Cheers,
-- Nikodemus
-- Marco Antoniotti
On Tue, Mar 1, 2011 at 12:18 PM, Marco Antoniotti <marcoxa@cs.nyu.edu> wrote:
Hi here is the second iteration for the "equality and comparison" proposal.
Marco, I'm interested in this proposal as the need for custom equality predicates and hash tables has come up in my work. Here's feedback on the version you just sent: - These example results seem wrong: cl-prompt> (EQUALS "FOO" "Foo") T cl-prompt> (EQUALS "FOO" "Foo" :case-sensitive-p nil) NIL - That EQUALS (a array) (b array) looks at array-total-size instead of the exact dimensions is surprising to me. - Why does this return error, why is it not applying the (T T) method that would return /= ? cl-prompt> (COMPARE (make-array 3 :initial-element 0) (vector 1 2 42)) Error: Uncomparable objects #(0 0 0) and #(1 2 42). - It seems EQUALS and HASH-CODE are not usable in combination for hash tables, if the keys are numbers (sxhash of = numbers of different types, like 2 and 2.0, can be different) or arrays (sxhash could look at dimensions, not just array-total-size). That would be unfortunate. - Willem
On Mar 1, 2011, at 16:20 , Willem Broekema wrote:
On Tue, Mar 1, 2011 at 12:18 PM, Marco Antoniotti <marcoxa@cs.nyu.edu> wrote:
Hi here is the second iteration for the "equality and comparison" proposal.
Marco,
I'm interested in this proposal as the need for custom equality predicates and hash tables has come up in my work. Here's feedback on the version you just sent:
- These example results seem wrong:
cl-prompt> (EQUALS "FOO" "Foo") T cl-prompt> (EQUALS "FOO" "Foo" :case-sensitive-p nil) NIL
Thanks, I will fix it.
- That EQUALS (a array) (b array) looks at array-total-size instead of the exact dimensions is surprising to me.
I guess I was lazy. What would be a fix for this?
- Why does this return error, why is it not applying the (T T) method that would return /= ?
cl-prompt> (COMPARE (make-array 3 :initial-element 0) (vector 1 2 42)) Error: Uncomparable objects #(0 0 0) and #(1 2 42).
Sorry. Bad cut'n'paste. It shoudl return /=.
- It seems EQUALS and HASH-CODE are not usable in combination for hash tables, if the keys are numbers (sxhash of = numbers of different types, like 2 and 2.0, can be different) or arrays (sxhash could look at dimensions, not just array-total-size). That would be unfortunate.
The original proposal did not include HASH-CODE and I am ambivalent about it. In general, there is no way even in Java to enforce the protocol; so HASH-CODE should just be thought as a hook for possible future use. Of course, relying on SXHASH is dubious to start with, given what its entry says and considering that there is not even a guarantee that GETHASH uses it (AFAIK). If this is too controversial, it should be removed. Cheers -- Marco Antoniotti
New version with most egregious mistakes corrected. EQUALS on ARRAYs now suggests checking ARRAY-DIMENSIONS Examples fixed The HASH-CODE issue is still open. As well as the '-P' suffix for variables. Other errors are definitively lurking in the text, as well as missing things (e.g., the definition of some conditions in support of the specification). Cheers -- Marco Antoniotti
On Wed, Mar 2, 2011 at 9:44 AM, Marco Antoniotti <marcoxa@cs.nyu.edu> wrote:
New version with most egregious mistakes corrected.
Thanks for the fixes on the points I raised. I'm feeling like I miss the use case for EQUALS. The document states: "... while writing algorithms and libraries it would be useful to have "hooks" in the type and class system allowing for the definition of extensible equality and comparison tests." If an algorithm does comparison operations, then the interface should accept a :test argument. Where does EQUALS come into play? I'm interested in an example. Thanks, - Willem
On Mar 2, 2011, at 14:00 , Willem Broekema wrote:
On Wed, Mar 2, 2011 at 9:44 AM, Marco Antoniotti <marcoxa@cs.nyu.edu> wrote:
New version with most egregious mistakes corrected.
Thanks for the fixes on the points I raised. I'm feeling like I miss the use case for EQUALS. The document states:
"... while writing algorithms and libraries it would be useful to have "hooks" in the type and class system allowing for the definition of extensible equality and comparison tests."
If an algorithm does comparison operations, then the interface should accept a :test argument. Where does EQUALS come into play? I'm interested in an example.
I guess the answer is: as a default to to :test argument. Apart from that, I find using something like EQUALS allows me to avoid FUNCALL in the code, thus making it more readable. (defun search-node (k n) (when n (if (equals k (node-key n)) n (case (compare k (node-key)) (< (search-node k (node-left n))) (> (search-node k (node-right n))) (/= (error "Cannot discriminate.")) )))) The example above - which can be shot down in a number of ways - may not convince you, but it is an example of code that you may want to write. Having said that, if you want to raise that argument, then, in all fairness, EQUALS is pointless. Yet, IMHO, that is not the point :) Cheers -- Marco Antoniotti
participants (3)
-
Marco Antoniotti -
Nikodemus Siivola -
Willem Broekema