An important but non-obvious consideration is that resizeability of arrays makes it much harder to eliminate bounds checks. As it is, there are cases where code for vectors is slower than code for arrays with any other dimensionality because only vectors can change size. Adding this one feature has the potential to make all code that uses arrays slower. Is it worth it?
> On Sep 29, 2014, at 1:00 PM, Art Kuo <[email protected]> wrote: > > I would like to revive this discussion. I understand that it's not terribly > efficient to add/delete a row from a matrix, but this is a case where some > syntactic sugar could really help. Here are a couple arguments for it. > Control systems people use this feature in Matlab a lot. This is a group that > works with matrices often and does a lot of rearranging. It is true that by > carrying indexing lists around, it's possible to avoid dropping rows/columns, > but it is often cleaner for thinking if you can just work with the result of > a drop. This is also a group that is highly wedded to Matlab, and has been > slow to switch to Python due to some of Matlab's features like A(1,:) = []; > Syntactic sugar is very helpful. > Plenty of demand. I did a quick search for "X delete row in matrix" where X > was: Matlab (153,000), Mathematica (column 139,000, row 111,000), Python > (282,000), Fortran (272,000), Julia DataFrame (11,500). So clearly people > want to do it. Why not give them an easy and consistent want to do it, even > if it's N^2 cost? (Still less expensive than inv) > People will do it anyway, but inconsistently. Given the demand, it will be > met by users, but inconsistently. There will be multiple solutions on > StackOverflow, people will write their own little 3-liners, but with a > variety of different names and usages. Why not provide a consistent way to do > it, and harmonize a lot of useless reinventing of the wheel? > I would propose a few solutions. First, provide something like deleteat! or > drop for multi-dimensional arrays. Second, provide sugar like A[1,:] = [] or > whatever doesn't break other language features. Third, consider implementing > A[:, ![3,5]] if possible. Note that people will still ask how to do it, so > the idea is not to reduce the searches above, but at least to provide a > simple, consistent solution or set of features.
