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 <malm...@gmail.com> 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 <gabrielgell...@gmail.com > > 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. >>>> >>> >
