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). 
>
>

Reply via email to