Haven't looked into the code since then.
One disadvantage of the implementation is that it only works with sorted tuples. But there is not nice way of sorting tuples at the moment so I'm not quite sure how to tackle this best

@mkitti had a great solution which has slightly differently semantics

julia>functioninsertdims(A; dims)           idx=ntuple(ndims(A)+length(dims))do iif i∈ dims                   [CartesianIndex()]else                   (:)endend@view A[idx...]endinsertdims (genericfunction with1 method)julia> A=zeros(5,4,3);julia>size(insertdims(A; dims= (1,3,6)))(1,5,1,4,3,1)julia>dropdims(b, dims=(1,2))2×2 Matrix{Int64}:1234julia> b=insertdims(a, dims=(1,2))1×1×2×2 Array{Int64,4}:[:, :,1,1]=1[:, :,2,1]=3[:, :,1,2]=2[:, :,2,2]=4julia>dropdims(b, dims=(1,2))2×2 Matrix{Int64}:1234julia> b=insertdims(a, dims=(1,2))1×1×2×2 Array{Int64,4}:[:, :,1,1]=1[:, :,2,1]=3[:, :,1,2]=2[:, :,2,2]=4

Not to discourage/criticize this PR, but: such functionality is available with a nice, consistent, and general syntax in a package:

julia>using Accessorsjulia> A=zeros(5,4,3);# insert singleton dimensionjulia> B=@insertsize(A)[1]=1;julia>size(B)(1,5,4,3)# delete singleton dimension:julia> C=@deletesize(B)[1];julia>size(C)(5,4,3)

Multidim insert/delete not implemented, but can potentially be added as well.

That looks really cool!!

I like that it is implemented but I think it still would be nice to haveinsertdims sincedropdims is already existing.

That looks really cool!!

Yeah, and the best part - it's all totally composable!

julia> A=zeros(5,4,3,1);# drop singleton dimension, wherever it is:julia> B=@deletesize(A)|> _[findfirst(==(1), _)];julia>size(B)(5,4,3)# insert singleton dimension last:julia> C=@insertlast(size(A))=1);julia>size(C)(5,4,3,1,1)

@mkitti had a great solution which has slightly differently semantics

julia>functioninsertdims(A; dims)           idx=ntuple(ndims(A)+length(dims))do iif i∈ dims                   [CartesianIndex()]else                   (:)endend@view A[idx...]endinsertdims (genericfunction with1 method)

One thing I like about the semantics of my implementation is that the following is mostly true:

julia> A = rand(3,4,5); dims = (1,4,6);julia> dropdims(insertdims(A; dims); dims) == Atrue

There might be a flaw though:

julia> size(insertdims(A; dims=7))(3, 4, 5, 1)

Perhaps we need the following

julia>functioninsertdims(A; dims)           idx=ntuple(maximum((ndims(A)+length(dims), dims...)))do iif i∈ dims                   [CartesianIndex()]else                   (:)endend@view A[idx...]endinsertdims (genericfunction with1 method)julia>size(insertdims(A; dims=7))(3,4,5,1,1,1,1)

From triage, WWMBD: what would@mbauman do?

Thetraditional answer is just spellinsertdims in the following way:

const newaxis = [CartesianIndex()]@view array[:, newaxis, :, ...]

An alternative to this pull request would be document the above better and/or define the above constant. Has any thinking changed?

Perhaps we need the following

julia>functioninsertdims(A; dims)           idx=ntuple(maximum((ndims(A)+length(dims), dims...)))do iif i∈ dims                   [CartesianIndex()]else                   (:)endend@view A[idx...]endinsertdims (genericfunction with1 method)julia>size(insertdims(A; dims=7))(3,4,5,1,1,1,1)

That's not type stable, is it?

Perhaps we need the following

julia>functioninsertdims(A; dims)           idx=ntuple(maximum((ndims(A)+length(dims), dims...)))do iif i∈ dims                   [CartesianIndex()]else                   (:)endend@view A[idx...]endinsertdims (genericfunction with1 method)julia>size(insertdims(A; dims=7))(3,4,5,1,1,1,1)

That's not type stable, is it?

We could consider a type stable version in some circumstances, such as providingdims as aVal.

I think doing this as a reshape operation as initially proposed here makes far more sense than an indexing one. The reshape is going to besignificantly easier on both type stability and preserving strided-ness... and it really is more reshape-y than index-y.

The only reason to use indexing operations is to match thesurface of numpy'snp.newaxis idioms. But I thinkinsertdims is a better API in any case — and then its implementation can just be whatever makes the most sense.

The only issue in my implementation was that it required a sorted input for the inserted dims.
Is there a way to sort tuples with Julia Bases in the meantime?

Is there a way to sort tuples with Julia Bases in the meantime?

If someone (could it be you?) reviews#54494 there will be

If@mbauman thinks that requiring sorted tuples as input is fine, we could lift that requirement also later.

In NumPy the convention is different:

>>>x=np.array([[1,2], [3,4]])>>>np.expand_dims(x,axis=(0,1,3)).shape(1,1,2,1,2)

Personally I find this a bit confusing since it counts the inserted dims too.

Numpy seems to match the semantics I proposed earlier. I understand this in terms of where I want the singleton dimensions to be in the final result.

The doc string should be included into the docs:

diff --git a/doc/src/base/arrays.md b/doc/src/base/arrays.mdindex ccfb237..66fe5c7 100644--- a/doc/src/base/arrays.md+++ b/doc/src/base/arrays.md@@ -138,6 +138,7 @@ Base.parentindices Base.selectdim Base.reinterpret Base.reshape+Base.insertdims Base.dropdims Base.vec Base.SubArray

It also claims to be the inverse ofdropdims but looking at these examples it clearly isn't.

I thought in the following way:insertdims insert singleton dimensions,dropdims removes them.

The other way of doing it, would be

julia>size(dropdims(ones((1,1,2,3,1,4)), dims=(1,2,5)))(2,3,4)julia>insertdims2(ones((2,3,4)), dims=(1,2,5))(1,1,2,3,1,4)

For me this requires some acrobatics, where the dimension with size 4 ends up, because I need to insert thedims virtually in my head. Would it be before or after the singleton dimension?
On the other hand with my convention, it's immediately clear where the singleton dimensions are (with respect to the input dimensions).

Does it make sense?

The way it works right now, it inserts singleton dimensions at the position of the dims indicated with respect to the initial input array dimensions.

Hmm, I see... That definitely wasn't my first intuition :)
Maybe, if keeping this semantics, it's cleaner to say "add singleton dimensions before dimensions numberdims in the original array" or something...

But also, maybe the "inverse todropdims" semantics is cleaner? Whenever possible.
This corresponds to interpretingdims as indices in the resulting array dimensions.
Also, nicely meshes with potential extensions by various "named arrays":dims=:mynewdim clearly corresponds to the resulting array.

@LilithHafner thanks for your suggestions. To be consistent withpermutedims, I changed it.

I also included your docstring and your tests.

Triage is happy with adding this new function and exporting it because it mirrors dropdims.

ok 🆒
Let me know if I can do more.

Thank you@roflmaostc! I appreciate your commitment and follow-through.