Isn't the situation actually similar to functions like `eye` which returns a dense array (which doesn't feel intuitive for what an eye or diagonal matrix actually is) whereas we have to call the special version seye to get a sparse array. For most users linspace is like `eye` by default suggesting the dense version (ie from reasoning about other languages), whereas the other names I have heard would be like seye, ie linrange. What we currently lack is top level functions that let us choose which version we want like what we have for the sparse vs dense arrays. The current situation is actually exposing less of the type diversity you mention. It feels like following the dense vs sparse array stuff we would want a similar symmetry for LinSpace vs Array creation.
On Wednesday, 21 October 2015 14:20:25 UTC-7, Stefan Karpinski wrote: > > The whole notion of always using a single dense array type is simply a > non-starter. Do we just scrap the whole sparse array thing? There goes half > of the stuff you might want to do in linear algebra or machine learning. > Special matrix types like Diagonal or UpperTriangular, etc.? Toss those out > too. Various types of ranges are just a different form of compactly > representing arrays with special structure. How come no one is complaining > that 1:n is not a dense vector? > > On Wed, Oct 21, 2015 at 4:23 PM, Jonathan Malmaud <mal...@gmail.com > <javascript:>> wrote: > >> You're making good points for sure - logspace and linspace are >> inconsistent wrt return types. >> >> But I just having trouble seeing how it impacts you as a user of the >> language; it's essentially an implementation detail that allows for some >> optimizations when performing arithmetic on array-like values known to have >> a certain exploitable structure (eg, uniform element spacing). >> >> Your own code will virtually never make explicit references to Vector or >> LinSpace types (except perhaps in specifying the types of fields in new >> types you define). If tomorrow logspace was changed to return a special >> type or linspace to return a plain array, your code would remain identical >> if function arguments were typed as AbstractVector instead of Vector. >> >> So I can see how it could bother someone's aesthetic knowing that under >> the hood these inconsistencies exist (it bothers me a bit). And I can see >> how if you're counting on certain optimizations happening, like scalar >> multiplication on spaces being O(1), it would be frustrating that it will >> depend on if the space was generated by linspace or logspace. But is that >> really leading to 'madness'? >> >> There are other examples of these light-weight wrapper types being used, >> especially in the linear algebra routines. The matrix factorization >> functions, like qrfact, return special types, for one thing. >> >> On Wed, Oct 21, 2015 at 4:07 PM, Gabriel Gellner <gabriel...@gmail.com >> <javascript:>> wrote: >> >>> 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. >>>>> >>>> >> >
