4 ms·
This is why I dislike NumPy, sizes (100,) and (100,1) are different. I understand conceptually representing it as a “slice” but this is in contrast to somethin
by _kulang 4y ago
This is why I dislike NumPy, sizes (100,) and (100,1) are different.
I understand conceptually representing it as a “slice” but this is in contrast to something like MATLAB where slicing a 100x100 for a column gives you (sensibly) a 100x1 array
- layer8 4y agoOne difficulty is, if (100,) and (100,1) are the same, then (100,1) and (1,100) arguably are also the same, as well as (1,100,1), etc. (They all have the same shape, a “stick” of size 100.) You could disallow dimensions of size 1, but then why disallow (100,1) and (1,100) being different if (2,100) and (100,2) are allowed and different? One way to see it is that you always have infinitely many dimensions, almost all of which have size 1, and you just choose which index positions you use for those that are not size 1. Hence (100,) is really (100,1,1,1,1,1,…), and so is (100,1), while (1,100) is really (1,100,1,1,1,1,…), same as (1,100,1), but different from (1,1,100), and so on. But it’s not entirely intuitive, because (1,100) and (100,1) have still the same shape. It’s just that, as soon as you have two non-singular dimensions, there’s the incidental necessity that you have to choose a defined order for the dimensions somehow, because [1,2] is a different element from [2,1]. The problem arguably falls away if the dimensions are named instead of numbered.