> > Sure, but it should be one way or the other, not half way between. > +100
On Wednesday, December 2, 2015 at 6:51:35 PM UTC+1, Cedric St-Jean wrote: > > There's also > > x = [1 2; 3 4] > x[:,[1]] # returns 2D array > x[:, 1] # returns 1D array > x[1, :] # AFAIK, returns 2D under Julia 0.4 and 1D under 0.5 > > I like the 0.5 behaviour a lot better. > > On Wednesday, December 2, 2015 at 12:21:34 PM UTC-5, Tim Holy wrote: >> >> Glen, that's a great list of bugs. Have you considered filing them as >> issue(s)? >> >> Some immediate thoughts: >> >> On Wednesday, December 02, 2015 06:17:06 AM Glen O wrote: >> > As an example, reshape(1,1) throws an error >> >> I'm not sure that's a real problem, although indeed implementing reshape >> on >> numbers would be more efficient than reshape([1], (1,1,1)) because in the >> latter >> you're creating two arrays. So possibly this is something we should >> implement. >> >> > , and squeeze(1,(1,)) gets stuck >> > in an infinite loop. >> >> That's definitely a bug. It's surely a very slow stack overflow (infinite >> recursion). >> >> > vec(1) >> >> Similar to reshape...maybe/maybe not. >> >> > throws an error, as does cumsum(1). >> >> Since sum(1) works, this should too. Bug. >> >> > And of >> > course there's the issue with getindex involving colon, arrays or >> ranges >> > for indexing (you'd think that, just as a[[1,1]] gives the value of >> a[1] >> > twice for an array, that it would do the same for a scalar, but it >> doesn't). >> >> Bug >> >> > I can understand the desire not to have them be identical (since there >> are >> > cases where a function should do a different thing for a number than it >> > does for an array), yet allow partial compatibility... it's just a >> little >> > arbitrary which cases work and which don't. >> >> Reports would help---not everyone hits these (I'm not sure I ever have). >> >>
