Support of algebraic operations on sets

Heh, you're the second one requesting it. Well, so maybe it should be  
added:

symmetricDifference: aCollection
        ^ (self difference: aCollection), (aCollection difference: self)

- Bert -


On Jun 15, 2007, at 17:05 , Ron Teitelbaum wrote:

>
> The actual problem here is that Dictionary is implemented as a
> subclass of Set while it is no proper Set. If it wasn't, then the
> #union: implementation in Collection would do The Right Thing. Of
> course we'd need Dictionary>>asSet defined as "^self values asSet".
>
no, it leads nowhere , because if you return keys or values in #asSet
you losing opposite part of assotiation. also note, that 'self value
asSet' will return you a set where same value appear only once, which
is not true for dictionary.

> So IMHO what *should* happen is that #union: always answers a Set.
>

> Actually, the only sensible thing would be to take the values IMHO.
I'm not agree. A values in dictionary are accessible only by keys.
They have no meaning w/o keys.
Keys in dictionary much more sensible than values. And that's why
dictionaries inherited from sets IMHO. And must behave as sets in
union/difference/intersection operations based only on keys.

> - Bert -
>

On 15/06/07, Klaus D. Witzel <[hidden email]> wrote: In my work i must maintain same number of keys in one dictionary as in
other, while their values are totally different. So, when first
dictionary changed somehow, then later i need to sync keys with second
one, but not values, because they constructed by other means. And
thats where set operations on keys only is useful.

On Jun 15, 2007, at 17:41 , sig wrote:

Well then operate on the keys.

- Bert -

On Fri, 15 Jun 2007 17:41:49 +0200, sig <[hidden email]> wrote:
So you do (aDict keys op: bDict keys)? Is any #op: you need for that not  
in Set and its superclasses?

/Klaus

On 15/06/07, Gary Chambers <[hidden email]> wrote:
> But the semantics of Association should probably be separate from the
> semantics of Dictionary (no direct delegation).
> Depends on your point of view.

in current implementation Association is nothing more than Array with
two elements. And i see no sense in having such class, where
comparison operations having no difference with comparison of two
arrays. Association is the class designed to serve for support
dictionaries, where only keys are viable when performing
insertion/deletion operations. And i'm really disappointed about fact,
that this is not true.

On Jun 15, 2007, at 17:34 , sig wrote:

>> The actual problem here is that Dictionary is implemented as a
>> subclass of Set while it is no proper Set. If it wasn't, then the
>> #union: implementation in Collection would do The Right Thing. Of
>> course we'd need Dictionary>>asSet defined as "^self values asSet".
>>
> no, it leads nowhere , because if you return keys or values in #asSet
> you losing opposite part of assotiation. also note, that 'self value
> asSet' will return you a set where same value appear only once, which
> is not true for dictionary.

Err, we *are* talking about #asSet, which indeed should return a Set  
without duplicates.

> I'm not agree. A values in dictionary are accessible only by keys.

Huh? #do: does not need any keys.

> They have no meaning w/o keys.
> Keys in dictionary much more sensible than values. And that's why
> dictionaries inherited from sets IMHO. And must behave as sets in
> union/difference/intersection operations based only on keys.

I guess these are two different views of Dictionaries. I see them as  
unordered variable-sized collections with non-integer indices. Except  
for order, a Dictionary with integer keys should pretty much behave  
like an OrderedCollection.

You seem to think of Dictionaries as a collection of Associations,  
with meaning sometimes placed on the keys, the values, or both. I  
guess that's where our difference in understanding comes from.

- Bert -

>
> So you do (aDict keys op: bDict keys)? Is any #op: you need for that not
> in Set and its superclasses?
>
No its not. But i'd rather like to see aDict op: bDict with same semantics.

> /Klaus
>
>
>

Why can't we use both keys and values?

aDict1 := Dictionary new
        at: #A put: 1;
        at: #B put: 1;
        at: #C put: 2;
        at: #D put: 2;
        yourself.

aDict2 := Dictionary new
        at: #B put: 1;
        at: #C put: 1;
        at: #D put: 2;
        at: #E put: 2;
        yourself.

aDict1 intersection: aDict2 =
        #(#B->1 #D->2)

aDict1 difference: aDict2 =
        #(#A->1 #C->2)

aDict2 difference: aDict1 =
        #(#C->1 #E->2)

aDict1 symetricDifference: aDict2 =
        #(#A->1 #C->#(1 2) #E->2)

aDict1 union: aDict2 =
        #(#A->1 #B->1 #C->#(1 2) #D->2 #E->2)

Wouldn't this make the most sense for dictionaries?  I know the values of
the resulting dictionary need special handling but wouldn't a developer
expect to have to handle this situation this way?

Everything else seems to leave out valuable information.

Ron Teitelbaum

On Fri, 15 Jun 2007 18:04:19 +0200, sig wrote:
>>
>> So you do (aDict keys op: bDict keys)? Is any #op: you need for that not
>> in Set and its superclasses?
>>
> No its not. But i'd rather like to see aDict op: bDict with same  
> semantics.

An example:

aDict := Dictionary with: $a->1 with: $c->2.
bDict := Dictionary with: $b->3 with: $c->4.

aDict union: bDict

=> a Dictionary($a->1 $b->3 $c->4 )

Why would anybody be happy with $c->4, I expected $c->2. You see what I  
mean (when I wrote earlier that no cDict can hold the "correct" values)?

The expected result is application specific, no?

/Klaus

On 15/06/07, Bert Freudenberg <[hidden email]> wrote:
The main difference between OrderedCollection and Dictionary lies in
insertion/deletion operations, while OrderedCollection serves to
preserve the order of elements (based on < or > operator)
Dictionaries, in contrast, serve to preserve unique placeholder for
values under same key (based on = operator).
OrderedCollection maintains own index (by placing elements in right
order and accessing them in array-like fashion), while Dictionary
gives user a way to maintain own, custom defined index.

I can't use an Association for insertion/deletion operations because
it violates the rules of dictionary (take into account only key, not
value when comparing with = operator). And this is ridicules.

>
> You seem to think of Dictionaries as a collection of Associations,
> with meaning sometimes placed on the keys, the values, or both. I
> guess that's where our difference in understanding comes from.
>
> - Bert -
>

On 15/06/07, Klaus D. Witzel <[hidden email]> wrote: i would care of seeing correct number of keys in algebraic ops at first place.

On Fri, 15 Jun 2007 18:39:21 +0200, sig wrote:
Ah :)

aColl := OrderedCollection with: $a->1 with: $c->2.
bColl := OrderedCollection with: $b->3 with: $c->4.
aColl union: bColl
a Set($a->1 $c->2 $b->3 $c->4)

You also might want to consider using

Association subclass: #SigAssociation ...
SigAssociation methodsFor: 'comparision'
= argv
        ^ super = argv and: [self value = argv value]

/Klaus

On 15/06/07, Ron Teitelbaum <[hidden email]> wrote: As you can see results in your examples have no value at all. There's
no parallels from algebra, to produce such results. And using such ops
on dictionaries with current semantics is meaningless.

Lets take an example from real life: we have two dictionaries with
translation of words from one language into another. Now, the task is
to compare these books to find out, what book contains more
translations and to find out what words is missing in first book that
holds second one. Then, after finding them out, merge new words with
first book. Or remove them from second book.

> Everything else seems to leave out valuable information.
>

On 15/06/07, Klaus D. Witzel <[hidden email]> wrote:
this code is exactly same as in current implementation in Association
in my 3.8 image. Do things changed already? :)
To what i propose is to be the following:

SigAssociation methodsFor: 'comparision'
= argv
     ^ key = argv key


> /Klaus
>
>
>

On Fri, 15 Jun 2007 19:02:52 +0200, sig <[hidden email]> wrote:
...
Dammn, I always think there can be no such change since the Blue Book :|

> To what i propose is to be the following:
>
> SigAssociation methodsFor: 'comparision'
> = argv
>      ^ key = argv key
>

This one is defininitely independent of any previous release.

/Klaus

On Jun 15, 2007, at 18:58 , sig wrote:

> Lets take an example from real life: we have two dictionaries with
> translation of words from one language into another.

book1 := {'hi'->'ho'. 'mu'->'ma'} as: Dictionary.
book2 := {'hi'->'ho'. 'foo'->'bar'. 'be'-> 'boo'} as: Dictionary.

> Now, the task is
> to compare these books to find out, what book contains more
> translations

book1 size > book2 size

> and to find out what words is missing in first book that
> holds second one.

new := book2 keys difference: book1 keys

> Then, after finding them out, merge new words with
> first book.

new do: [:k | book1 at: k put: (book2 at: k)].

> Or remove them from second book.

new do: [:k | book2 removeKey: k].

- Bert -

On 15/06/07, Bert Freudenberg <[hidden email]> wrote:
instead of:
  book1 union: book2
>
> > Or remove them from second book.
>
> new do: [:k | book2 removeKey: k].
>
instead of:
  book2 difference: (book1 intersection: book2)


can't you see the difference?
> - Bert -
>
>
>
>

> book2 difference: (book1 intersection: book2)
oops. mistaken here.
must be:

book2 difference: (book2 difference: book1)

On Jun 15, 2007, at 19:23 , sig wrote:

Sure. As I said before, you seem to think of Dictionaries as  
Collections of Associations. So just use a Collection of Associations:

| book1 book2 new |
book1 := {'hi'->'ho'. 'mu'->'ma'}.
book2 := {'hi'->'ho'. 'foo'->'bar'. 'be'-> 'boo'}.
book1 union: book2.
book2 intersection: book1.

But for *Dictionaries* these semantics would be nonsensical.

- Bert -