JuliaData / CategoricalArrays.jl / 1194 / 3
92%
master: 92%

DEFAULT BRANCH: master
Ran
Files 10
Run time 1s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 91.507% (-1.8%) from 93.298%
1194.3

push

travis-ci

web-flow 
Drop distinction between index and levels (#253)

References now always point to the vector returned by `levels`. This simplifies
a lot of code, especially for packages that use CategoricalArrays. The downside
is that all references need to be recoded when existing levels are removed or reordered.

To ensure `CategoricalValue` objects always remain valid, `CategoricalPool` is now
semi-mutable: only adding new levels is possible. `CategoricalArray`s are now mutable
and replace their pool with a new one when levels are removed or reordered, e.g. in
`levels!` or `setindex!(A::CategoricalArray, v::CategoricalValue, ...)`. This should
not be a problem for performance as changing levels should not be frequent. On the other
hand, adding levels keeps the same pool, which makes creating a `CategoricalArray`
from another array type relatively fast, though references have to be recoded at
the end when sorting levels. And the (very frequent) operations which use levels
in their order should be faster than before as they can use refs directly.

Note that replacing the pool makes it impossible to compare new `CategoricalValue`
objects with old ones with `<` and `>`. This should not be too problematic in practice.

Finally, replace deprecation message with an error when assignment would add new levels
to ordered array, and make `copy` and `copyto!` merge levels even when copying zero
elements (this differs from what the `AbstractArray` fallback would do but makes more sense).

668 of 730 relevant lines covered (91.51%)

5163.39 hits per line

Source Files on job 1194.3