A Ones type

[matthieugomez]

A Ones type would be something like

immutable Ones{N} <: AbstractArray{Int,N}
    dims::NTuple{N, Int}
end
Base.size(O::Ones) = O.dims
Base.getindex(O::Ones, I::Int...) = (checkbounds(O, I...); 1)

(see this stackoverflow answer for the original proposal by @mbauman).

It's helpful because it allows to write efficient, generic code:

• Its default behavior matches a vector of ones, without the memory allocation
• Frequently, a non weighted operation can be written more efficiently than the weighted case with a vector of ones. Defining a neutral weight type such as Ones allows to branch elegantly between the weighted and the non weighted versions.

It's a good application of multiple dispatch. It would be great to define something like this in StatsBase.

[matthieugomez]

Why should such a type be defined in StatsBase?

• Suppose I need to compute the median. For efficiency, I'd like to call median(x) in the no weight case and median(x, w) in the weight case. If median(x, w::Ones) = median(x) is defined in StatsBase, I could generically write median(x, w).
• Moreover, suppose I actually did not know that the algorithm for unweighted median was more efficient than the weighted case with a vector of ones. I would still write median(x, Ones(length(x))) for the syntax simplicity (compared to median(x) vs median(x, w) ). But now, thanks to the definition median(x, w::Ones) = median(x) in StatsBase, the command is automatically redirected to the efficient unweighted method.

[johnmyleswhite]

I think this is pretty reasonable and a potentially good change, but it adds more complexity.

I would like us to improve the design of our weighting functionality at some point to handle weights with different interpretations (right now everything is a frequency weight); maybe we can address this concern then?

We probably need a different name than Ones, which is too vague. Something like UniformWeights would be better.

[nalimilan]

UnitWeights might be even better. In the literature, uniform weights sometimes mean 1/N, N being the number of cases. Unit weights doesn't have that ambiguity.

[matthieugomez]

Great! I'm also a supporter of different kinds of weights.

[sbromberger]

Hi,

I may have implemented something like this in LightGraphs: see https://github.com/JuliaGraphs/LightGraphs.jl/blob/v4/src/distance.jl#L5-L14). Let me know if it's useful.

[nalimilan]

I've just realized it might be possible to implement this using repeated() from Julia Base. See JuliaLang/julia#15988.

[Nosferican]

Any updates in implementing UnitWeights?

[nalimilan]

Do you want to give it a try? It shouldn't be hard to do (most of the work should be adapting tests to cover it).

[Nosferican]

Sure. I will see if I can give it a try in the next few days and get a PR to review.

[Nosferican]

FillArrays.Ones