avoid applying fast_sortable on integer arrays #21
Conversation
|
Bump? |
src/PooledArrays.jl
Outdated
| @@ -428,6 +428,8 @@ function Base.vcat(a::PooledArray{T, <:Integer, 1}, b::PooledArray{S, <:Integer, | |||
| return PooledArray(RefArray(newrefs), convert(Dict{U, refT}, newlabels)) | |||
| end | |||
|
|
|||
| fast_sortable(y::PooledArray{<:Integer}) = y | |||
There was a problem hiding this comment.
@piever Should we additionally check isbitstype(eltype(y)) and otherwise use the "slow" path?
There was a problem hiding this comment.
Good point, I imagine non-isbits comparison can be quite slow, even though in practice I doubt anyone has a PooledArray{BigInt} or things like that. I've changed that to the slow path. The important part (for me) is that fast_sortable is idempotent which should always be the case as sortperm returns isbits integers.
|
Unrelated, but I'm glad the package was moved to JuliaData and is getting more maintenance! |
|
@piever - could you please resolve the merge conflicts in this PR as I would like to finalize it. @nalimilan - could you please have a quick look at the PR before merging. Thank you both! |
|
Rebased in #46 (sorry about the confusion, but the original branch had been deleted!) |
The whole idea of
fast_sortableis to return aAbstractVector{<:Integer}with the same sorting as the original. If the original was already of integer eltype we don't actually need to do anything.