I'm not sure that map! on a Set makes sense. The behavior of map! is that
it replaces each element of a collection with a transformed value of that
element. Implicit in that is that there is a notion of position – a place
where the original element was and where the transformed value can go. In a
Set, there's inherently no notion of place – there's just a bag of things.
If we can come up with a meaning of map! that generalizes what it does and
makes sense for Set, then I think it could be implemented, but I can't
think of such a generalization. Given that map! on a Set doesn't make
sense, I wonder if map on a Set makes more sense and if so why? I mean,
there's an obvious implementation of iterating over the input set, applying
the transformation and inserting that value into the output set. But is
position really less inherent in map than map!? Don't we expect map applied
to something to give something that is the same size with a one-to-one
correspondence of elements?
On Mon, May 12, 2014 at 9:15 PM, Kevin Squire <kevin.squ...@gmail.com>wrote:
> On Mon, May 12, 2014 at 4:58 PM, Andrew Dabrowski
> <unhandya...@gmail.com>wrote:
>>
>> On Monday, May 12, 2014 7:09:12 PM UTC-4, Kevin Squire wrote:
>>>
>>> `map` seems to work for me:
>>>
>>> julia> a = Set([1,2,3])
>>> Set{Int64}({2,3,1})
>>>
>>>
>> julia> map(x->2x, a)
>>> 3-element Array{Any,1}:
>>> 4
>>> 6
>>> 2
>>>
>>> Can you give an example where it doesn't?
>>>
>>
>> The problem is that it returns an array rather than a Set.
>>
>
> That could probably be accommodated. That's different than not being
> supported, though. ;-)
> Want to implement this and make a pull request?
>
>
>>
>>
>>>
>>> `map!` wouldn't give you any benefit in working with Sets in Julia. The
>>> values in sets are inserted into a hash table, and since each value might
>>> change, it's hash would also change, so it would have to be removed and
>>> reinserted. This is a dicey proposition while iterating over the set.
>>>
>>
>> Aren't you confusing behavior and its implementation? Or are you saying
>> that any implementation of map! would have no performance benefit over map?
>>
>
> I was (obviously) talking about hash tables, but the same issue applies no
> matter how sets are implemented: because you're changing the value, you
> have to remove the current value, and insert the new one. This is unlikely
> to have much, if any, performance advantage (you still have to remove and
> insert a value every iteration), and has some strong disadvantages:
>
> 1. You're changing the underlying data structure while iterating over it.
> 2. You need to guarantee that the function you're applying doesn't map to
> an old value in the set that you haven't seen yet during iteration.
>
> There are very few collection implementations deal with these issues. (*)
>
> Cheers,
> Kevin
>
> (*) Properly implemented immutable/persistent data structures kind of
> allow this, but 1) they're not usually very performant compared to their
> mutable cousins, 2) you're not really modifying them in-place, because,
> well, they're immutable, and 3) they're really hard to implement in a
> correct and performant manner. Examples include most collections in
> Clojure and Zach Allaun's FunctionalCollections.jl for julia.
>
