First of all thank everyone for dealing with me! I find this discussion really interesting ... though I hope it is not rehashing to much basic stuff, I am trying my best to get up to speed with the Julian way. I am new to Julia, but have programmed a lot in other languages ... hence my random feelings.
Re: turning an arbitrary array into an iterator -> I guess you could simply bind the element generator a la pythons __iter__ so for sin(linspace(0, 0.5, 10)) I would simply have to store the sin function then have this call sin(getitem(_stored<LogSpace | or other iterable)) for each getitem call -- that is calls to functions that take iterables would store chained iterators. At the lamest level you could simply store the full array and return the __iter__ like interface. You get none of the benefits of memory/space savings but you preserve the "interface". I guess in general it would be some weird kind of lazy evaluation on a whole bunch of indexable types. But this is a distraction, and clearly stupid for performance reasons. What I really meant is that having the implementation details of having a convenient/compact linear indexing object from what many users would believe to be an array creation function feels bad to me. What is worse is that sometimes it is there (some functions might never convert out of the LinSpace as it preserves the representation) but others will instead return an Array instead. Some feeling the type system would of course be solved by having the special printing behavior that people have mentioned is in the works for later Julia versions. If when I have a LinSpace object it looks and feels exactly like an Array (currently we at best have the latter) than it might not come to my attention. My issue is that it currently feels like having an implementation detail/optimization bleed into the user space. When I use linspace it can be strange vs just using logspace, zero etc. I guess it feels magical currently. Also it is a bug magnet for using other, less idiomatic, libraries. Yes good Julia code I get now should work on AbstractArrays, but my experience is that that is not always the case. I have used ODE.jl at times where the deep levels of type generality they go for causes very difficult error messages to understand for the end user as the calls to convert etc are chained ... LinSpace objects definitely cropped up on this, and what lead me to post. This is not likely a fault with ODE.jl, but rather as a new user sending the wrong information in the wrong way I was presented with a real drop in what I understood for what was happening. Maybe all this is just transitional that soon LinSpace objects will always work like Arrays in all code I might use as an end user. Currently as a new user I have not had this experience. I have noticed that LinSpaces where returned, and had to learn what they were and at times run `collect` to make them into what I wanted. I have not felt this abstraction bleed yet in other areas of Julia. On Wednesday, 21 October 2015 13:24:17 UTC-7, Jonathan Malmaud 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. >>>> >>> >
