Yes, that seems better.
On Tue, May 13, 2014 at 3:16 PM, Ivar Nesje <[email protected]> wrote: > Wouldn't it be faster to copy all the elements of the set into an array, > empty the set, and then fill the modified values back? > > kl. 21:03:47 UTC+2 tirsdag 13. mai 2014 skrev Kevin Squire følgende: >> >> Thinking about it, map! could be implemented by creating and filling in a >> new Set, then moving the underlying members back to the original Set. >> >> It's kinda kludgy, and wouldn't be any more efficient, but it would allow >> for a convenient and uniform interface. >> >> Thoughts? >> >> Andrew, I'll reiterate that a pull request would be very welcome. I think >> you would find the Set functionality rather self contained, and the map >> function implementation should be pretty straightforward. >> >> Cheers, Kevin >> >> On Tuesday, May 13, 2014, Andrew Dabrowski <[email protected]> wrote: >> >>> >>> Given that set replacement is a fundamental mathematical operation (e.g. >>> it's an axiom of ZFC) I tend to regard an implementation of map as slightly >>> broken if map( <function>, <set> ) doesn't return a set. I realize though >>> that unordered collections are unnatural from a computer's point of view. >>> >>> I take the point about map!: there is no performance benefit, and so no >>> reason for it, on sets. I'll just comment that the documentation on map! >>> doesn't suggest that there any circumstances in which map would work but >>> not map!. >>> >>
