I have no issue with the LinSpace object, I simply do not see why it is the special case for this kind of object (I imagine the choice was made since it was seen to be used mainly for looping vs being used for array creation like similar functions logspace, zeros, ones, etc). If the iterator version is so good I don't see why all Vectors are not returned as this type for all the reasons you mention. In the current state where only linspace returns this kind of special polymorphic type it simply breaks any feeling of consistency in the language. I so something like x = zeros(10) and I get an array great. the next line I do y = linspace(0, 5, 10) I get a new fangled iterator object. They work the same but how do I get an iterator version of zeros? etc. It is a pedantic point but so is special casing this super common function to mean something that is not consistent with all other languages that use it. Which would be fine if when I did something like sin(linspace(0, 5, 100)) I got back an iterator but I don't. This abstraction is not percolated thru other functions, further giving the feeling of a needless special case in the language writ large. They simply get converted to concrete types for many common functions, when if this is done will vary from function to function, with little semantic reasoning. My feeling is that if what people say is true than why is the default numeric array not have the iterator semantics. As it is linspace is made special for no reason other than it is assumed it will be used for looping.
People want to argue that it is more elegant and takes advantage of what makes Julia powerful, which I get, but then why not go all in on this? Mathematica does this. Everything is basically a List which nice behavior for vectors matrices etc. I have no issue with this kind of elegance, but it is rough when the abstraction is inconsistent (the type is not truly perserved in most functions). As people have mentioned clearly logspace should be a special object ... but when does this stop? I dislike that this feels so arbitrary ... and as a result it is jarring when it turns up. The fact that it is polymorphic is only one kind of consistency. On Wednesday, 21 October 2015 12:09:29 UTC-7, Jonathan Malmaud wrote: > > It’s still hard for me to understanding what the value of returning an > array is by default. > > By getting a structured LinSpace object, it enables things like having the > REPL print it in a special way, to optimize arithmetic operations on it (so > that adding a scalar to a LinSpace is O(1) instead of O(N) in the length of > the space), to inspect its properties by accessing its fields, etc. And on > top of that, it can be used transparently in virtually all expressions > where a concrete array can be used. It’s not like Python where iterators > are generally going to be much slower and clunkier to work with than a > reified Numpy array. > > The only downside really is if your arguments are explicitly and > unnecessarily typed to expect an Array, which is not a great habit to get > into no matter what linspace returns. > > Not trying to be argumentative or dismissive here- just trying to > understand. I would think that if one of your motivations for getting into > Julia is the rich type system compared to Matlab, you’d be happy that Julia > isn’t forced to discard semantic information from operations like linspace > as a result of only only raw numeric vectors being first-class constructs > in the language (as in Matlab and Numpy). > > On Oct 21, 2015, at 2:38 PM, Gabriel Gellner <[email protected] > <javascript:>> wrote: > > Wow! Thanks everyone for all the advice!!! Super helpful. I now see that > it is super easy to deal with the LinSpace objects. > > That being said I guess I get scared when the docs tell me to use concrete > types for performance ;) Most of the code I write for myself is working > with Float64 arrays a la Matlab. I am comfortable with duck typing and what > not but one of the things that drew me to Julia (vs lets say Mathematica) > is how in general the type system feels easy to reason about. All the > layers of indirection can scare me as it makes it harder for me to > understand the kinds of performance problems I might face. I like sending > concrete array types for my own code as it often catches bugs (when I maybe > used an int literal and this accidentally created a int array when i really > wanted a float, potentially leading to horrible performance cascades as all > my generic code starts doing the wrong thing...). > > I guess really what this comes down to is the point made by DNF that > changing linspace to an iterator when that name means an array in Matlab > and python is not the path of least surprise. It feels to me like this is a > strange inconsistency as we could just as easily return other common > functions, like `rand` to be an AbstractArray like type, but this would > suck as it does in this case. I guess it all comes down to wishing that, > like DNF suggested, we had a proper name for linspace and the iterator > version was a new name. I guess my way forward will likely be to define my > own linarray() function, sadly this will make my code a bit confusing to my > matlab friends ;) > > Again thanks though. I really have learned a crazy bunch about the generic > type system. > > On Wednesday, 21 October 2015 08:50:32 UTC-7, Spencer Russell wrote: >> >> On Wed, Oct 21, 2015, at 11:38 AM, Gabriel Gellner wrote: >> >> No that is a good point. Often you can use an iterator where an explicit >> array would also work. The issue I guess is that this puts the burden on >> the developer to always write generic code that when you would want to >> accept an Array you also need to accept a iterator like LinSpace. >> >> Maybe this is easier to do than I currently understand? >> >> >> In general you can just make your function accept an AbstractVector (or >> more generally AbstractArray) and things will just work. If there are >> places where Ranges, LinSpaces, etc. aren't behaving as proper arrays >> then I think those are generally good candidates for Issues (or even >> better, PRs). >> >> As a related aside: >> For efficiency you'll still want to use a concrete Vector field if >> you're defining your own types, but luckily there seems to be a convert >> method defined so you can do: >> >> type MyArr{T} >> x::Vector{T} >> end >> >> a = MyArr{Int64}(1:4) >> >> And it will auto-convert the range to an array for storage in your type. >> >> -s >> > >
