Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ones(3) != ones(3)'' #2686

Closed
StefanKarpinski opened this issue Mar 26, 2013 · 18 comments
Closed

ones(3) != ones(3)'' #2686

StefanKarpinski opened this issue Mar 26, 2013 · 18 comments
Labels
breaking This change will break code needs decision A decision on this change is needed
Milestone

Comments

@StefanKarpinski
Copy link
Member

This might need to be thought through a bit since it's a breaking change.

@StefanKarpinski
Copy link
Member Author

@toivoh
Copy link
Contributor

toivoh commented Mar 27, 2013

Which is the change?

@Staross
Copy link

Staross commented Mar 27, 2013

I think I would forbid transposition on vectors, transposition is fundamentally a matrix operation, so it would be a conceptual mistake for the user to try to apply it one a one-dimensional object in the first place.

@wlbksy
Copy link
Contributor

wlbksy commented Mar 27, 2013

If people think a "1 x N" matrix row_vec is a vector, they should apply vec(row_vec) by themselves.
We should put this straight forward in doc

@milktrader
Copy link
Contributor

If you forbid transpose of ones() vectors then you lose some nice, elegant solutions. Here is one that solves the global min variance portfolio

 port   = (invsig * onevec) / (onevec' * invsig * onevec)

(invsig is the inverse of the covariance matrix of returns)

@StefanKarpinski
Copy link
Member Author

We're not going to forbid transposing vectors. We try to make vectors and column matrices as behaviorally similar as possible. This is just a matter of making == behave a little differently: in particular, I would propose that == should ignore trailing singleton dimensions.

@toivoh
Copy link
Contributor

toivoh commented Mar 27, 2013

I'm not sure about that one. Vectors and column matrices will behave differently often enough that I think that it would be pretty misleading. I would much rather like if double transposition could be made an actual noop.

@Staross
Copy link

Staross commented Mar 28, 2013

A very similar problem:

a = ones(3,3)

julia> a[:,1] == a[1,:]'

false

In this case the only options I see are to change the behavior of '==' or to make a[:,1] produce or 3x1 matrix instead of a vector.

@goszlanyi
Copy link

The more I think, the more I support the suggestion of Staross.
This is conceptually clean and does not prompt for special hacks.
Furthermore, it corresponds well to Fortran's convention, where
vectors are true vectors and the transpose function works only for rank-two arrays.

@pao
Copy link
Member

pao commented Mar 29, 2013

Please indicate how a literal will indicate one way or another, and explain why we should annoy people for whom there is no distinction (which is to say, everyone in my office, and a great many other MATLAB users.)

@StefanKarpinski
Copy link
Member Author

While I don't think disallowing taking the transpose of a vector is reasonable, I also think that ignoring trailing singleton dimensions when checking == is problematic the more I think about it. The main concern I have is that it implies that a zero-tensor containing a single value should be == to a 1-vector or 1x1 matrix containing only that same value. We've generally decided that zero-tensors should behave equivalently to scalars, which would imply that 1 == [1] should be true, which seems pretty sketchy. Perhaps == is a case where the equivalence of scalars and zero-tensors should be broken, instead.

@goszlanyi
Copy link

@pao
Having both some Matlab and Fortran background
I see that Fortran's good choices are often underrepresented in such discussions.
Hardcore Matlab users will always stick to it, and ANY change will annoy them.

@StefanKarpinski
There are three type of "vectors" from day one: true vectors and the pair of nx1 / 1xn matrices.
I feel that however hard you work to make column matrices behave like true vectors,
there will always remain some corner cases, as the subject of the present discussion.

@pao
Copy link
Member

pao commented Mar 29, 2013

Fortran certainly isn't the only language which draws that distinction.

But I don't think that slices with exactly one non-singleton dimension losing their shape (by becoming distinct vectors) is a good plan, either. That can cause less of generality when inputs happen to have a particular number of dimensions. But if they don't become vectors, certain versions of this problem still exist as highlighted above.

@tshort
Copy link
Contributor

tshort commented Mar 29, 2013

I actually like it the way it is and find x'' to be a handy shortcut to create a one-column matrix from a vector.

@StefanKarpinski
Copy link
Member Author

You like that v != v'' also?

@tshort
Copy link
Contributor

tshort commented Mar 30, 2013

I don't really think of them as being the same. I'm an engineer, not a
mathematician:)

Obviously, I can adapt to something else if this changes (and it's not
needed very often).

On Fri, Mar 29, 2013 at 5:49 PM, Stefan Karpinski
notifications@github.comwrote:

You like that v != v'' also?


Reply to this email directly or view it on GitHubhttps://github.com//issues/2686#issuecomment-15662330
.

@andreasnoack
Copy link
Member

MATLAB's vector-is-a-matrix view might be convenient in some situations but if you plan to transpose your vector you could just write randn(10,1) instead of randn(10) like you would do in MATLAB. Issues like this and #2472 will continue to show up I guess. #2472 wouldn't have been an issue if the vector transpose wasn't there.

@tshort The timings are tiny but still

julia> a=randn(100000);

julia> min([@elapsed a'' for i = 1:10])
0.000925552

julia> min([@elapsed reshape(a, length(a), 1) for i = 1:10])
6.67e-7

@JeffBezanson
Copy link
Member

subsumed by JuliaLang/LinearAlgebra.jl#42 and #3262.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking This change will break code needs decision A decision on this change is needed
Projects
None yet
Development

No branches or pull requests

10 participants