Milan Bouchet-Valat

I agree it would make sense to move the Julia package to the same repo as all other implementations. The advantages of that approach may not be striking right now,...

At least it would be a good idea to switch to the Apache license immediately.

OK, thanks. It shouldn't be hard to support more types when we don't skip missing values, but it's more tricky when skipping them. Not sure it's worth adding that complexity...

But I find it much more user-friendly to tell people "to compute pairwise correlation, use `pairwise(cor, df)`" than "use `outer(cor, df)`". Also `pairwise` is already the name used in Distances...

@dkarrasch I don't know whether you've seen this. Ideally this would cohabit nicely with Distances.jl, but the new support for passing vectors of vectors there (https://github.com/JuliaStats/Distances.jl/pull/188 and https://github.com/JuliaStats/Distances.jl/pull/194) will create...

The problem is that Tables.jl objects don't have a particular type. Any object can be a table, including notably vectors or iterators of names tuples. As long as Distances only...

@dkarrasch Regarding your comment at https://github.com/JuliaStats/Distances.jl/pull/188#pullrequestreview-550171749 (better keep the discussion in a single place): > @nalimilan I wonder if it helps FreqTables.jl if we made these pairwise methods fully generic...

After discussing this on Slack with @bkamins and @quinnj I think the way forward is to require passing iterators over rows or columns of Tables.jl objects explicitly, via `Tables.AbstractRows` and...

Actually, unwrapping categorical values may not be a good idea, as that makes it impossible to index the table with `CategoricalValue{Int}` (other than via `Name`). I've filed https://github.com/davidavdav/NamedArrays.jl/issues/84 to allow...

The last commit reverts the unwrapping of categorical values. Tests will fail until the new NamedArrays release.