On Sunday, 25 October 2015 11:06:14 UTC-7, Stefan Karpinski wrote: > > This is still an option but I'm yet to be convinced that we want to have > that many things exported: linrange, LinRange, and linspace which just does > collect on linrange? Seems like one too many.
Personally I think that `linspace` should not be exported/deprecated. Just have `linrange` which returns the current `LinRange` (updated name ...) and have the user use collect(linrange) when needed. I just don't like the name linspace anymore as it makes me think about the function in Matlab/NumPy which caused my original discontent. (I even tried make a quick package for this, but sadly linrange is a deprecated name so I abandoned the attempt). Really the name linspace feels like Matlab baggage, it is not a name like rand or ones which are a perfect match to the idea, regardless of the implementation. Instead it is a strange name for returning an equally spaced, dense, float array. linrange is really more descriptive in my mind. I also prefer having the nice naming consistency with UnitRange, FloatRange. Makes me feel like these are a suite of types (like the filename linspace is defined in "ranges.jl" ;). If this is done I think logspace -> logrange as well even though it returns an array at the moment. Similarly if a special name is really wanted for collect(linrange) I think it should be alinrange, similarly you would then want aunitrange, afloatrange -- this to me would be similar to the seye like exports for getting different sparse types. That being said I currently wouldn't vote for this as I have seen the light on AbstractArray and the current linrange behavior. Outside of being a little slower, at the moment, in vectorized cases I like having this and seems to work fine for what I use it for most often (parameters for time series like functions or ODE solvers). But this is pure bike shedding aesthetics. I have used R and Matlab enough to learn to deal with strange inconsistencies like this.
