The reason for "special cases" is that arrays in Julia really serve two very different purposes: a highly flexible array/stack/dequeue data structure and tensors of arbitrary dimension for linear algebra. The array/stack/dequeue use case requires the ability to grow and shrink and remove elements from the middle but requires only one dimension. The tensor use case does not require growing or shrinking but does require N dimensions. Vectors are just the intersection of the two use cases. It's tempting to have two entirely separate data types for these two use cases, but try explaining that to people (R has this problem in spades with vectors, lists, matrices and data frames). Sure, you can grow and shrink an n-dimensional array too, but it's not really like growing and shrinking a 1-d array. For example, you can't generally add a single element – you have to add an entire column or row. Does it require a new pushdim! function that adds a new slice? Is this even a good idea? Pushing a column is fairly efficient, whereas pushing a new row is quite slow – should they be equally easy to do from the programmer's perspective?
On Wed, Feb 12, 2014 at 12:33 PM, Iain Dunning <[email protected]>wrote: > I'm sure you know this, but I think you are failing to acknowledge in this > discussion is that everything is a tradeoff when dealing with memory > representations of tensors. The reality is always going to be that the > machine organizes everything internally one way, and languages paper over > that to different degrees. Deleting _anything_ from the middle of a > datastructure is always going to be a nontrivial operation unless that > datastructure is designed for it - arrays are certainly not one of those > datastructures. The issues are worse for anything 2D or higher, e.g. > deleting a row of a column-wise-storage matrix. > > > On Wednesday, February 12, 2014 11:35:47 AM UTC-5, Don Gateley wrote: >> >> >> >> On Wednesday, February 12, 2014 8:32:42 AM UTC-8, Stefan Karpinski wrote: >>> >>> On Wed, Feb 12, 2014 at 3:28 AM, Don Gateley <[email protected]> wrote: >>> >>>> Nonsense. >>>> >>> >>> It would be much more helpful (not to mention polite) to make an actual >>> counter argument. Given a convincing argument for a feature like this, it >>> may very well get implemented and included in the language. Given >>> "Nonsense", I for one am inclined to do nothing. >>> >> >> In general I think it a real language plus if operation is uniform across >> data geometries. APL stands as a model of this kind of design. Having to >> special case code based on how an array is organized just seems wrong to >> me. Or nonsensical. :-) >> >
