I'm glad that the index operator on multisets only accesses one element even if there are several with the same index. That makes it easier to extend it to hold real values.
In the new implementation (which has a well defined order), the indexing operations (including m_delete) always operate on the last element with the given index. I thought that to be most useful since += can be used to add elements which might be duplicates and the normal indexing operations will default to the last of them. (There will of course also be other utility functions to set and get all values that share the same index.)
See the comment blurbs in rbtree.h and multiset.h for more details of how I've intended the operations. Opinions are welcome; now is a good time to affect it.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-02-06 10:12: Subject: Xor
I have been wondering why the index operations on multisets work like they do:
| > multiset v=(<1,1,1>); | > v[1]; | Result: 1 | > v[1]=0; | Result: 0 | > v; | Result: (<1,1>)
This could of course be used to do a `- that removes one for one:
multiset res=copy_value(v); foreach (v;mixed elem;) res[elem]=0; // remove one
But why doesn't v[1] return 3 above, and remove all the elements with v[1]=0?
It would also be much more useful to do v[1]=17 to get 17 of element 1. You can't, however, even add elements using that method now:
| > v[1]=17; | Result: 17 | > v; | Result: (<1,1>) | > v[1]=1; | Result: 1 | > v; | Result: (<1,1>)
How much would break if we fixed this behaviour, so that
multiset v=(<1,1,1>); v[1] == 3 v[1]=0 => v==(<>) v[1]=17 => v==(<1,1,1,1...1,1>) /* 17 elements */
Sidenote: This code works for the above `- for both the current and my suggestion:
multiset res=copy_value(v); foreach (v;mixed elem;int n) res[elem]-=n; // remove n
/ Mirar