I am interpreting this to mean that LLVM can't optimize as well if it doesn't know the size of the array. I would be tempted to say that arrays should ideally be kept fast when people aren't resizing, but nevertheless allow resizing with perhaps a sizable performance penalty when it is used. As slow as Matlab is, my bottleneck is usually myself and my algorithms, not juggling memory. In the long run, I would hope that a lint could let users know of the downsides of the less performant bits. People who work with huge data should indeed be able to work quickly and would probably happily avoid deleteat and others like it.
As another illustration of a use case, consider the following Mathematica snippet <http://mathworld.wolfram.com/Minor.html> from Mathworld to evaluate the minor of a matrix : Minor[m_List?MatrixQ, {i_Integer, j_Integer}] := Det[Drop[Transpose[Drop[Transpose[m], {j}]], {i}]] where this is actually the older version of Drop before they made it column-friendly (hence Drop[Transpose[]]), Mathematica being row/list-oriented. I can't remember the timeline, but it took a good decade or so for them to Drop or even reference columns easily. These were hugely requested features for years, and Minor shows how nice it is to have some syntactic sugar. Using modern Drop, the code above would be even simpler. On Monday, September 29, 2014 1:28:47 PM UTC-4, Stefan Karpinski wrote: > > 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] <javascript:>> > 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. > > 1. 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. > 2. 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) > 3. 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. > >
