Julia: Slightly confusing DimensionMismatch error

[quinnj]

Getting a DimensionMismatch error is confusing here since my arrays are the same dimension, just different lengths

julia> a = [1,2,3]
3-element Array{Int64,1}:
 1
 2
 3

julia> b = [1,2,3,4]
4-element Array{Int64,1}:
 1
 2
 3
 4

julia> a .== b
ERROR: DimensionMismatch("arrays could not be broadcast to a common size")
 in broadcast_shape(::Array{Int64,1}, ::Vararg{Array{Int64,1},N}) at ./broadcast.jl:39
 in bitbroadcast at ./broadcast.jl:222 [inlined]
 in .==(::Array{Int64,1}, ::Array{Int64,1}) at ./broadcast.jl:317
 in eval(::Module, ::Any) at ./boot.jl:225
 in macro expansion at ./REPL.jl:92 [inlined]
 in (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at ./event.jl:46

[eschnett]

Your arrays have the same number of dimensions (each 1), but these dimensions themselves differ (3 vs. 4). So technically, while confusing, the exception name is correct.

The Julia function to obtain the dimensions is size, so an exception name SizeMismatch would be cleaner, and would also be unambiguous.

[StefanKarpinski]

+1 to the name SizeMismatch.

[StefanKarpinski]

Either that or ShapeMismatch although we don't have a function called shape.

[timholy]

16260 would argue for IndicesMismatch.

[eschnett]

IndicesMismatch sounds as if specific indices had been given, which is not the case. It's rather the whole index spaces that don't match, hence IndexSpaceMismatch. Or IndexRangeMismatch. Not sure, maybe IndicesMismatch is good after all.

[quinnj]

+1 for SizeMismatch; I feel like it's the clearest because I immediately relate it to the fact that size(A) must be different than size(B).

[timholy]

I agree that SizeMismatch is the most immediately interpretable name, but very soon we will have this:

a = OffsetArray{Int}(0:3)  # creates an array indexed by 0, 1, 2, 3
fill!(a, 2)
b = Array{Int}(4)
copy!(b, a)   # this should throw IndicesMismatch

Those arrays have the same size but different indices, and so they aren't in correspondence.

Maybe we should have both SizeMismatch and IndicesMismatch, but SizeMismatch is a strict subset of IndicesMismatch: all of these errors basically indicate that one array has elements that are not present in the other, and for arrays the elements are "named" via their indices.

[StefanKarpinski]

I feel like ShapeMismatch would cover both situations and seems pretty clear.

[eschnett]

For me, the shape is what Julia's size function returns; it doesn't take the bounds into account. What about ArrayBoundsMismatch?

[StefanKarpinski]

This is a hypothetical function, but one could imagine a shape function which behaves like this:

julia> a = OffsetArray{Int}(0:3,-2:2);

julia> size(a)
(4,5)

julia> shape(a)
(0:3,-2:2)

In that case, calling this a ShapeMismatch would be just right. But figuring out how to program generically to arrays with more general indexing schemes like OffsetArray remains an open problem, so perhaps that indicates that we should wait to rename this exception until we've figured that out.

[eschnett]

I think this function will exist, and will be called indices, since it might return a representation that is not based on ranges e.g. for sparse vectors or matrices.

[StefanKarpinski]

The name "indices" indicates to me something like findn or findnz that returns index tuples where values are stored, whereas "shape" indices the shape of the domain of valid indices – which even for sparse matrices with non-one-based indexing in various dimensions is still a large rectangle indicated by step-one ranges. At some point we need to draw the line about what kind of an interface we consider to still be an "array" in some sense. Things where the valid set of indices is given by a tuple of unit-step ranges seems like a very broad category that may well be a good place to stop.

[timholy]

As @eschnett says, over at #16260 that's exactly indices, thought I'd be fine with changing it to shape. The findn-like alternative you describe is essentially keys implemented for arrays.

But figuring out how to program generically to arrays with more general indexing schemes like OffsetArray remains an open problem, so perhaps that indicates that we should wait to rename this exception until we've figured that out.

16260 is pretty far along in implementing this already; there don't seem to be many missing API holes, mostly just "applications" (meaning, converting existing algorithms to be generic). Though of course the latter exercise always informs the former.