Re: Comparing DS_HASH_TABLE objects

On Sun, May 31, 2009 at 11:47 PM, Eric Bezault <ericb-D6Qt/9opevxWk0Htik3J/[email protected]> wrote:
> Paul Cohen wrote:
>> On Sun, May 31, 2009 at 8:43 PM, Eric Bezault <ericb-D6Qt/9opevxWk0Htik3J/[email protected]> wrote:
>>>> How do I compare two DS_HASH_TABLE objects for object equality?
>>> I don't know what you mean. Do you want to consider two
>>> hash tables equal if the items they contain are equal?
>>
>> I am aware that there are different ways of defining equality between
>> two tables t1 and t2. My assumption was something like:
>>
>> t1.keys.is_equal (t2.keys) and then
>> for each key k1 in t1:
>> (t1 @ k1).is_equal (t2 @ k2)
>>
>> I don't think the 'equality_tester':s should be used since they have
>> more with how DS_HASH_TABLE:s work, than what they contain (though how
>> they work will of course affect what they contain!).
>
> I don't see how `equality_tester' has more to do with how hash
> table works than what you try to do.

The 'key_equality_tester' and 'equality_tester' are properties of the
hash table, not of the keys or the items in the hash_table.

> I guess you're confusing
> `equality_tester' with `key_equality_tester'.

No, I am refering to both.

> Which brings to
> my attention the fact that in order to be correct, hash table
> equality should use `key_equality_tester' to compare keys in
> your code above, not `is_equal'. Indeed keys might be equal
> in terms of `is_equal', but they might nevertheless represent
> two different keys in the hash table (which uses `key_equality_
> tester' for that).

Aha, I think I understand what I am asking now! ;-)

I am asking/looking for a feature in DS_HASH_TABLE that should be
named something like:

    are_equivalent, has_the_same_keys_and_items (t: like Current): BOOLEAN
            -- Does `Current' have the same keys and items as `t'
            -- when keys and items are compared for equality
            -- using `is_equal' and for all keys:
            -- (Current @ key).is_equal (t @ key)?

I am interested in comparing the *contents* of the hash tables. Let me
illustrate with the test case problem I'm trying to solve; in JSON you
can have an JSON object (associative array) like:

{"name":"Gustave","surname":"Eiffel"}

where "name" and "surname" are keys and "Gustave" and "Eiffel" are
values or items (JSON strings in this case).

The JSON object above may be represented by two DS_HASH_TABLE
[UC_STRING, UC_STRING] objects that may/or may not contain the same
UC_STRING objects as keys and items and that may/or may not have the
same `key_equality_tester' and/or `equality_tester'. If they don't
have the same `key_equality_tester' they should not be considered
equal as *hash tables*. I fully agree with that.

However, I'm looking for the feature where they *will be considered
equal/equivalent/the same* if one only looked at the key and item
values and how keys are mapped to items.

>>> If so, I don't
>>> think there is a feature for that in DS_HASH_TABLE.
>>> The implementation of `is_equal' uses '=' to compare
>>> items.
>>
>> Yes. I saw that. Why '=' and not 'is_equal'?
>
> But why `is_equal' and not any other kind of comparison?

Simply because 'is_equal' matches my understanding of the semantics of
obj1.is_equal (obj2) as meaning "is the object obj1 considered to be
equal to obj2".

The current solution would mean that two hash tables, that have the
same `key_equality_tester' and `equality_tester', the same keys but
where the items do not reference the same objects yet the items are
equal in an 'is_equal' sense, are not equal!? That feels strange to
me. (I know my feelings can't be used as a basis for formal
specifications). Eg:

    local
        t1, t2: DS_HASH_TABLE [STRING, STRING]
        key: STRING
        value: STRING
        b: BOOLEAN
    do
        create t1.make (2)
        key := "name"
        value := "Gustave"
        t1.put (value, key)
        key := "surname"
        value := "Eiffel"
        t1.put (value, key)
        create t2.make (2)
        key := "name"
        value := "Gustave"
        t2.put (value, key)
        key := "surname"
        value := "Eiffel"
        t2.put (value, key)
        b := t1.is_equal (t2) -- b is False. This feels strange!
    end

> It uses '=' to compare items because `is_equal' is used
> in the postcondition of `copy/twin', and their implementation
> in hash table does not clone the items.

I don't understand the problem. Using `is_equal' to compare items
would not break the postcondition in `copy'

So, to summarize:

   1. I don't understand conceptually why t1.is_equal (t2) = False in
the example given above. And I see that HASH_TABLE works the same.

   2. I'd like an `is_equivalent'  or `has_the_same_keys_and_items'
feature in DS_HASH_TABLE that ignores `key_equality_tester' and
`equality_tester'!

/Paul

-- 
Paul Cohen
www.seibostudios.se
mobile: +46 730 787 035
e-mail: paul.cohen-qf2BM/[email protected]


------------------------------------

To Post a message, send it to:   [email protected]
To Unsubscribe, send a blank message to: [email protected]! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/gobo-eiffel/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/gobo-eiffel/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/