That doesn't feel like a reason that they can't be iterators, rather that they might be slow ;) a la python. My point is not about speed but the consistency of the language. Are there many cases in Julia where there is a special type like this because it is convenient/elegant to implement? This feels like a recipe for madness, my guess is that this would be crazy rare.
People wondered why people might mind that we get a LinSpace object vs an Array. For me it is this strange feeling that I am getting a special case that doesn't feel well motivated other than there is a nice way to implement it (and that people, again, assumed that it would largely be used for looping). If not all things can be made consistently iterators when they are vector-like then why not have a special function that returns this special type (like your aforementioned linrange)? The fact that I lose my iterator when I use certain functions but not others is a way that this polymorphism that everyone is describing doesn't feel as nice to me, since it will not compose in cases where it likely should, outside of implementation details. On Wednesday, 21 October 2015 12:55:35 UTC-7, DNF wrote: > > The reason why not all arrays can be iterators is that in general arrays > can not be 'compressed' like that. A linear range can be compressed to: a > start value, an increment, and a length, making it incredibly lightweight. > Doing this for sin() is not that easy. Doing it for rand() is simply > Impossible. > > On Wednesday, October 21, 2015 at 9:38:07 PM UTC+2, Gabriel Gellner wrote: >> >> 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. >> >
