slices of matrices should be vectors

[StefanKarpinski]

julia> X = [ i^2 - j | i=1:10, j=1:10 ];

julia> typeof(X)
Array{Int64,2}

julia> X[:,1]
10x1 Int64 Array
0 
3 
8 
15 
24 
35 
48 
63 
80 
99 

[JeffBezanson]

This is fairly significant. Is this the rule we originally wanted way back when: "the rank of the result is the sum of the ranks of the indexes"? Or is it squeezing singleton dimensions? Or just trimming trailing singleton dimensions?
Interestingly we have this for SubArray. sub is the same as our current ref, and slice removes dimensions indexed by scalars.

[StefanKarpinski]

As in it's a significant question as to how this should behave, or that it's a significant bug?

[JeffBezanson]

I think the current behavior is intentional, and settling this question is a big deal.

[StefanKarpinski]

Yes, that's why I assigned this to Viral — I think it's intentional too. I don't care for it, however, but I guess let's have that discussion again now.

[ViralBShah]

We need a consistent rule. Usually, when you do that, you do want a vector.

-viral

On Oct 17, 2011, at 6:53 PM, Stefan Karpinski wrote:

Yes, that's why I assigned this to Viral — I think it's intentional too. I don't care for it, however, but I guess let's have that discussion again now.

Reply to this email directly or view it on GitHub:
#231 (comment)

[JeffBezanson]

For X[:,1] a vector seems right, but do you want something 2d from X[:,1,:]?

[StefanKarpinski]

For X[:,1] a vector seems right, but do you want something 2d from X[:,1,:]?

Yes. What else would it be? Another 3-tensor? Keep in mind that if you want that, you can still do X[:,1:1,:].

[JeffBezanson]

We have to beware the type inference implications of this. I'm not sure how to deal with a tuple (or integer) whose length depends on the types of a sequence of values. It seems possible, but it's probably at the outer edge of what we're capable of. We might even need to add a special feature like ranksum().

Here's how slice for SubArrays does it:

n = 0
for j = i; if !isa(j, Index); n += 1; end; end

It's not too realistic to expect to run that whole loop at compile time.

[StefanKarpinski]

Would it help if we were stricter about indexing behaviors? As in you can only index into an array with the number of indices equal to the number of dimensions of the array. In other words, would eliminating linear indexing help?

[JeffBezanson]

No, because even if you have the right number of indexes, you still need something like that rank-counting loop above.

[StefanKarpinski]

Hmm. So what are you thinking? If slices of tensors are always the same rank as the tensor being sliced, then how do you get a vector from a matrix? Or a matrix from a 3-tensor?

[StefanKarpinski]

I guess one approach could be that slicing always preserves the rank, making inference easy since it's completely stable. But then you need a compress function that can discard dimensions with a size of one. I'm not sure if that actually simplifies anything, however.

[JeffBezanson]

We have squeeze to do that, but then it's based on singleton dimensions rather than ranks of indexes, so A[:,1:1,:] would also be 2d. So far the only thing I can think of is a special function that type inference knows computes the sum of the ranks of its arguments.

[StefanKarpinski]

That seems like a reasonable thing to have. It's special case, but we know those are necessary to make things like this work.

[JeffBezanson]

Maybe the rule we want is to drop dimensions for trailing scalars? So A[:,1] is 1-d, but A[1,:] is still 2-d? A little wonky perhaps.
The other thing we might have settled on is to keep indexing the way it is, but ignore trailing singleton dimensions when comparing shapes. And/or use promote to add trailing singleton dimensions where needed.

[StefanKarpinski]

That might actually work but it does feel like a bit of a hack.

[pao]

Here's another case to cover which can come up when range indexing with a variable:

julia> [1 2; 3 4][1,1]
1

julia> [1 2; 3 4][1,1:1]
1x1 Int32 Array:
 1

The problem is that a 1x1 array isn't dimensionally compatible with anything, even though it should be--it's really a scalar. There's not really a good workaround, as squeeze()ing leaves you with a 0-dimensional Array, which is even less useful.

[JeffBezanson]

That probably can't change, since in general you might do A[1:m,1:n] and
expect a mxn array as the result.
On Mar 1, 2012 9:04 PM, "pao" <
reply@reply.github.com>
wrote:

Here's another case to cover which can come up when range indexing with a
variable:

julia> [1 2; 3 4][1,1]
1

julia> [1 2; 3 4][1,1:1]
1x1 Int32 Array:
 1

The problem is that a 1x1 array isn't dimensionally compatible with
anything, even though it should be--it's really a scalar. There's not
really a good workaround, as squeeze()ing leaves you with a 0-dimensional
Array, which is even less useful.

---

Reply to this email directly or view it on GitHub:
#231 (comment)

[pao]

In general, yes. The situation I was working with had the end of the range set by a variable and this hit on the first iteration. On further review I needed to fix indexing on the other side of the operation--I got screwed up when converting to preallocating the other array. I still think the behavior of squeeze() is wrong here. I'll file a separate issue for that.

[JeffBezanson]

We now consistently treat arrays so that trailing singletons don't matter, so we should be ok here.