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.
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. 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 >
