Le mercredi 21 octobre 2015 à 16:22 -0400, Spencer Russell a écrit :
> On Wed, Oct 21, 2015, at 04:07 PM, Gabriel Gellner 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.
>
> Can you clarify with an example of when you lose the iterator? IMO
> that would be an example of breaking the AbstractArray contract and
> worthy of fixing.
>
> I see your point that there are other functions that return array
> -like objects that could also be implemented without fully
> constructing the array, e.g. `zeros(20)` could return a `Zeros{20}`
> object that acts like a length-20 array full of zeros. As far as I
> know there's no compelling design reason that's a bad idea, it's just
> that nobody has done it.
A related discussion is about a special Ones type representing an array
of 1, which would allow efficient generic implementations of
(non-)weighted statistical functions:
https://github.com/JuliaStats/StatsBase.jl/issues/135
But regarding zeros(), there might not be any compelling use case to
return a special type. Anyway, if arrays are changed to initialize to
zero [1], that function go could away entirely.
Regards
1: https://github.com/JuliaLang/julia/issues/9147
> The nice thing is that as long as people don't over-specify their
> type annotations that change can be done under-the-hood and it
> shouldn't break code. From a pedagogical standpoint I see how these
> sorts of things can add confusion and cause new folks to question
> their understanding, and more consistency reduces that conceptual
> friction.
>
> -s
