I'm not sure that would be better. rehash() will be called as soon as you start inserting elements, because more than 3/4 of the elements will have been deleted.
On Tue, May 13, 2014 at 12:20 PM, Stefan Karpinski <[email protected]>wrote: > 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!. >>>> >>> >
