I think the point is this: rather than implementing it for arrays, with the risk of performance problems that Stefan highlighted, why not implement it for array views? If we do it through views (which don't modify the underlying memory), we can give users this behavior and guarantee that we won't impinge on the performance of arrays.
It will take someone sufficiently motivated (hint, hint) to actually generate an implementation of operations like A[:,![3,5]], but all the necessary infrastructure for that should be in place shortly (one hopes). --Tim On Monday, September 29, 2014 03:25:45 PM Art Kuo wrote: > 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.
