Prior art and duplicated functionalities

[mbauman]

I hope you don't mind the pings here, @ReidAtcheson and @mauro3. Are the two of you still using and/or interested in ragged arrays? I've implemented this package from scratch to satisfy my need for a general ragged array that can support multiple dimensions. It does require 0.4, however.

The other cool feature here is that it defines an Abstract ragged type that can be easily extended for custom data structures with fancy ragged indexing that just works (check out https://github.com/mbauman/RangeArrays.jl).

Key differences as compared to https://github.com/ReidAtcheson/RaggedArrays.jl:

• This breaks the rules and makes RaggedArray a subtype of AbstractArray. There's some trickiness involved in making this work safely (without segfaults and corruption), but I think it makes for a more useful type… at least for now while the functionality here is rather minimal.
• I keep an array of ragged lengths around in addition to the array of offsets. This is redundant information that could potentially become out of sync if you ever modify the offsets outside of the package.

Key differences as compared to https://bitbucket.org/maurow/ragged.jl/

• Base.size returns the maximal rectangular extents of the array. If you're curious, I documented this decision pretty thoroughly here: src/array.jl:88-120.
• I explicitly do not allow linear indexing. Since I give Base a valid size there are two meanings for linear iteration: rectangular (within the entire maximal extents) and ragged (hitting only the valid indices). With all the extra support for Cartesian iteration in 0.4, I've found linear iteration is not needed quite as often. This seems to be a decent tradeoff for getting at least some AbstractArray support.
• This doesn't support deferred End computation, but that's a little less needed in 0.4 since : no longer lowers to 1:end. I'm not sure I want to try to support this at all, since I've not run into a use-case for it and it's really tough to generally support.

So… are you interested in collaborating? I think I'd like to register this functionality at some point, but I don't want to trample on your package name, Reid. I'd happily add the two of you as contributors here if you'd like to focus efforts, or I can rename my package if you'd prefer to keep things separate.

[mauro3]

Thanks for putting this together and asking for collaboration! I'll try and have a look at this in detail although time is even in shorter supply than usual.

I use ragged arrays in https://bitbucket.org/maurow/lmesh.jl. 0.4 is fine for me. The End calculation there I use so that a[:,i] will always give me the i-th row, irrespective of whether its a ragged or normal array. (Well, it also supports things like a[1:end/2,i] but that I don't actually use.) I don't think I use linear indexing in LMesh but I need to check, eachindex would be fine anyway.