Added resize! function for OffsetVector

[laborg]

This pull request implements resizing for OffsetVectors.

The code was taken from julia/test/testhelpers/OffsetArrays.jl and by including it, unique!() should subsequently also work for OffsetArrays.

[laborg]

Is it a problem that this pull-request comes from my master (instead of a branch)?

[fredrikekre]

Is it a problem that this pull-request comes from my master (instead of a branch)?

Not at all, but for the future you might find it more convenient to use branches on your own fork too.

[timholy]

Sorry I didn't notice this when you submitted it, August was busy.

I like this, but before I merge it let me raise one conceptual issue. resize! seems to live in a world where vectors are just lists and where length is the only parameter you need to know. For an OffsetArray you switch to a mental model involving location, and so specifying just the length is insufficient. In this case it seems the ideal syntax would really be resize!(a, -2:0), i.e., specifying the complete set of indices for the result. However, since OffsetArrays are immutable (and should remain so), we can't actually change the offset. Hence the interface here is the only one that can actually be implemented. For that reason I think this is merge-worthy, but it does bother me just a bit.

CC @mbauman and @andyferris to see whether they have any thoughts on this.

[andyferris]

There's so many options here with offset arrays. If you pushfirst! should the first index decrement? If you popfirst! should the first index increment?

I see a few distinct options

• You can't resize! an offset array.
• An offset array's first index is the thing that always stays constant.
• The user must always specify the new axes rather than the new size (not sure how this relates to the deque interface).

I'm not certain what is best.

[timholy]

@andyferris thanks for chiming in. You may be amused by https://github.com/JuliaArrays/CatIndices.jl which contains BidirectionalVector which I think covers your lead-off questions.

Of your options, I think the third is the best but unfortunately it's not achievable without serious sacrifices elsewhere (so it's off the table as far as I am concerned). I think we should choose between the first two.

[andyferris]

Cool, yes it makes sense that it's been done :) I guess the question I have is - do you find it useful?

[andyferris]

From CatIndices.jl

deleteat! and insert! are not supported, since it is unclear whether it should shrink/grow from the beginning or end.

I've come to start thinking that certain interfaces are somewhat distinct and not really compatible with each other. The "list" interface (what we often call the deque interface, I assume because of the implemention (not interface) of Vector) isn't that compatible with applying a semantic to the values of indices, except for "there's an order". Of course, OffsetArrays are for when you do care about the values of the indices, kind-of like a dictionary does. An insertable dictionary cares about index value, but not necessarily insertion order.

I've started thinking of three categories

• Containers with immuable keys
• Containers with mutable keys via a "list" interface
• Containers with mutable keys via an "insertable dictionary" interface.

(Further, as far as I can tell, cat/vcat/hcat seem to be a functional interface for appending (multi-dimensional) lists. merge is a functional interface for taking the union of dictionary keys)

There may be more, but this seems to be what exists in Base. It would seem to me that you could replace en mass the keys of a OffsetArray with other keys of semantic importance, which is basically some subset of the third functionality. Or you could have a zero-based array that is a "list", which is some intersection of the second option and OffsetArrays. BiDirectionalVector is a different take on how to combine the list interface with the concept of offset arrays.

I think the third is the best but unfortunately it's not achievable without serious sacrifices elsewhere

What are the main sacrifices?

[timholy]

I guess the question I have is - do you find it useful?

In specific contexts, yes. It's a dependency of ImageFiltering (useful for implementing the various padding rules).

What are the main sacrifices?

mutable struct OffsetArray. Not going to happen.

[andyferris]

Not going to happen

Fair enough.

(This is where a trailing ! is not quite subtle enough... we need a "functional" resize that mutates the parent array).

[timholy]

Barring objections I'll merge this shortly.