The types Vector, Matrix and Tensor were abstract originally <https://github.com/JuliaLang/julia/commit/826f630a43ae5ad54a3eeec3c13190e8ba6f889a>. The Array type was the concrete implementation of Tensor. Later on we introduced <https://github.com/JuliaLang/julia/commit/4386460d637a216a0011310ea0a76fcc220c7fc1> DenseVector and DenseMatrix as aliases for Array{T,1} and Array{T,2}. This arrangement ended up being kind of confusing (by which I mean that Viral kept using the wrong one), so we eventually just changed the names <https://github.com/JuliaLang/julia/compare/337bb20f5ba6f791f146f02e7372c976ad8f0357...eafcbd8f451cb8b98ce86208ee5ab944d7c87177> so that it did what he was expecting.
[That first commit is pretty trippy – that is some ancient proto-Julia right there.] Fundamentally, I think there's a tension between dispatch, where you want to use the most abstract type you can, and locations (element and field types of containers and types), where you want to use the most concrete type you can. AbstractArray does seem to long to type for dispatch, but having Array be an abstract type seems like a terrible gotcha for locations. One possible naming scheme could be to follow the example of Int and Integer and have Vec, Mat, Arr be the concrete types and Vector, Matrix and Array be the abstract types. I'm really not sure this would be worth the trouble at this point or if we really want the AbstractArray names to be any shorter. Back when I made the above rename and introduced AbstractArray, et al., part of the reasoning was that if you're going to be writing generic code, you should probably stop and think a little about how generic your code really is and what abstractions it applies to. Is it applicable any kind of abstract vector? Or is it actually applicable to anything iterable? Or should it really only be used with arrays that support fast linear indexing. I think that line of reasoning is as valid as ever: writing generic code is not easy and you have to think a bit about it. That burden seems acceptable for the library writer, but in that case the burden of typing the prefix "Abstract" here and there seems acceptable as well. On Wed, Oct 21, 2015 at 3:29 PM, Jonathan Malmaud <malm...@gmail.com> wrote: > > On Oct 21, 2015, at 3:19 PM, Gabriel Gellner <gabrielgell...@gmail.com> > wrote: > > Continuing to think about all the ideas presented in this thread. It seems > that the general advice is that almost all functions should at first pass > be of "Abstract" or untyped (duck typed) versions. If this is the case why > is Abstract not the default meaning for Array? Is this just a historical > issue? This feels like the language design is sort of fighting this advice > and instead it should have been that we have Array meaning AbstractArray > and Array meaning something like ConcreteArray to put the incentive/most > natural way to add types. Similar for Vector, Matrix etc. > > Yes, that’s a historical thing. I too wish the names had been Array and > ConcreteArray. Possibly (fingers crossed) by the time of 1.0 something like > that will happen. > > > I guess I find this idea that full genericity is the correct way to do > things to be a bit at odds with how the language coaxes you to do things > (and the general discussion of performance in Julia). Is this a more recent > feeling? Did Julia start out being more about concrete types and template > like generic types? This would explain the linspace vs logspace and all > other basic array creating functions (ones, zeros, rand etc) and the > default names for many types vs the "Abstract" prefixed ones. > > On the contrary - if you ever have some time, Jeff (one of the Julia > creators)’s thesis ( > https://github.com/JeffBezanson/phdthesis/blob/master/main.pdf) is > surprisingly accessible and explains Julia’s motivations was about generic > programming from the beginning. > > But the notion specifically that the functions inherited from Matlab > should return special types instead of arrays which retain some semantic > knowledge of the operation that created them is recent and made possible by > advances in the initial Julia compiler (especially the introduction of > immutable types) that allow for use of lightweight types with zero > performance or memory overhead. > > > Thanks for all the insight. > > On Wednesday, 21 October 2015 00:11:44 UTC-7, Gabriel Gellner wrote: >> >> I find the way that you need to use `linspace` and `range` objects a bit >> jarring for when you want to write vectorized code, or when I want to pass >> an array to a function that requires an Array. I get how nice the iterators >> are when writing loops and that you can use `collect(iter)` to get a array >> (and that it is possible to write polymorphic code that takes LinSpace >> types and uses them like Arrays … but this hurts my small brain). But I >> find I that I often want to write code that uses an actual array and having >> to use `collect` all the time seems like a serious wart for an otherwise >> stunning language for science. ( >> https://github.com/JuliaLang/julia/issues/9637 gives the evolution I >> think of making these iterators) >> >> >> For example recently the following code was posted/refined on this >> mailing list: >> >> >> function Jakes_Flat( fd, Ts, Ns, t0 = 0, E0 = 1, phi_N = 0 ) >> # Inputs: >> # >> # Outputs: >> N0 = 8; # As suggested by Jakes >> N = 4*N0+2; # An accurate approximation >> wd = 2*pi*fd; # Maximum Doppler frequency >> t = t0 + [0:Ns-1;]*Ts; >> tf = t[end] + Ts; >> coswt = [ sqrt(2)*cos(wd*t'); 2*cos(wd*cos(2*pi/N*[1:N0;])*t') ] >> temp = zeros(1,N0+1) >> temp[1,2:end] = pi/(N0+1)*[1:N0;]' >> temp[1,1] = phi_N >> h = E0/sqrt(2*N0+1)*exp(im*temp ) * coswt >> return h, tf; >> end >> >> >> From <https://groups.google.com/forum/#!topic/julia-users/_lIVpV0e_WI> >> >> >> Notice all the horrible [<blah>;] notations to make these arrays … and it >> seems like the devs want to get rid of this notation as well (which they >> should it is way too subtle in my opinion). So imagine the above code with >> `collect` statements. Is this the way people work? I find the `collect` >> statements in mathematical expressions to really break me out of the >> abstraction (that I am just writing math). >> >> >> I get that this could be written as an explicit loop, and this would >> likely make it faster as well (man I love looping in Julia). That being >> said in this case I don't find the vectorized version a performance issue, >> rather I prefer how this reads as it feels closer to the math to me. >> >> >> So my question: what is the Juilan way of making explicit arrays using >> either `range (:)` or `linspace`? Is it to pollute everything with >> `collect`? Would it be worth having versions of linspace that return an >> actual array? (something like alinspace or whatnot) >> >> Thanks for any tips, comments etc >> > >
