Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Issue 28415] Add unique!(f, itr) #28737

Closed
wants to merge 13 commits into from
Closed

Conversation

shaktee
Copy link

@shaktee shaktee commented Aug 18, 2018

I needed to use unique! and had implemented it... but I realized that it was an already open issue. So, just wanted to contribute my change.

If this implementation works for you, please use it.

@shaktee shaktee mentioned this pull request Aug 18, 2018
base/set.jl Outdated
```
"""
function unique!(f::Callable, C)
out = Vector{eltype(C)}()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What should this out do?

@shaktee
Copy link
Author

shaktee commented Aug 18, 2018 via email

…ique(f::Callable, itr) is much faster than the current version. The culprit

seems to be splice!
@shaktee
Copy link
Author

shaktee commented Aug 18, 2018 via email

@KristofferC
Copy link
Sponsor Member

Typically ! versions perform better than the non-bang versions because they don't have to allocate memory for the output. Here, the ! version is actually slower than the non-bang which to me is a bit "dishonest". If there is no efficient way of doing it in-place, perhaps it is ok just to let the user do the copying so it is clear what is actually happening? Just my thought.

@shaktee
Copy link
Author

shaktee commented Aug 19, 2018 via email

@leungbk
Copy link

leungbk commented Aug 20, 2018

It's not appropriate to label this an in-place function if it makes use of the not-in-place version.

This can be done in place, preserving order for the entries that are to appear in the output, with pointer-swapping similar to what is done in the partition subroutine in a standard quicksort.

@shaktee
Copy link
Author

shaktee commented Aug 21, 2018

That's a reasonable critique of the implementation and a reasonable suggestion. The funny thing is that I had implemented that as well initially (even before the first version that I checked in), and I was happy with the lack of complexity in using the not-in-place function. But, I understand philosophically where you come from. I'll push the other implementation.

base/set.jl Outdated
@@ -191,8 +191,7 @@ function unique!(f::Callable, A)
done = true
end
end
if cur != index splice!(A, index:cur-1); end
A
ifelse(cur != index, resize!(A, index-1), A)
Copy link
Sponsor Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This calls resize! unconditionally.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the catch.

Actually, thinking more about it... that was a rookie julia user mistake on my part in the use of ifelse... however, interestingly, it does not impact the correctness of the function.

if
resize!(array, length(array))

is efficient and does not attempt to resize (which seems to be close to the case... when I attempt a resize on a 2_000_000 element array of {Any,1}, it completed in 0.000006 seconds (5 allocations: 176 bytes)

Then, the actual code could just unconditionally return a

resize!(A, index-1)

instead of testing.

Copy link
Sponsor Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True. resize! does that check for you anyway, I'm pretty sure.

@shaktee
Copy link
Author

shaktee commented Aug 24, 2018

Is there anything more I need to do for this pull to be reviewed and dispositioned?

@fredrikekre
Copy link
Member

Hi @shaktee , sorry this slipped through the system, but now that #30141 is merged I am going to close this PR. Hope you will show up for new contributions in the future!

@fredrikekre fredrikekre closed this Dec 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants