I've found it very useful, even if it is O(n) complexity to get the n-th
element, to allow indexing.
For a database, if you have a packed record (for example, like SQLite's row
format), and you only need to access a single field, it's better to be able
to do just that,
and *not* have to unpack
On Fri, 2016-06-24 at 05:26, Rafael Fourquet wrote:
>> My recollection is that part of the indexing interface in Julia (just by
>> convention) is that indexing should be of O(1) (or close to that)
>> complexity.
>
> As the OP suggested, this could still be the case, the
My recollection is that part of the indexing interface in Julia (just by
convention) is that indexing should be of O(1) (or close to that)
complexity. Iterable things, in general, have O(n) complexity to access
the n-th element, because you have to traverse the data to get there
(the classic
Hi Jacob,
In my view, in principle, all "iterators" should be indexable, (at least
read-only), *unless *the underlying data is not indexable by nature, e.g.
with data that comes from a stream... Doing `zip([1, 2], [2, 3])[1]`
should probably just work.
I also think that for `Zip`s if the
Sorry, to clarify a little:
The things you're zipping are not necessarily indexable (i.e. other
iterators), so it's not safe to assume you can always index a Zip.
On Thu, Jun 23, 2016 at 2:21 PM, Jacob Quinn wrote:
> Most "iterator" types are not indexable, AFAIK. The
Most "iterator" types are not indexable, AFAIK. The typical
recommendation/idiom is to just call `collect(itr)` if you need to
specifically index.
-Jacob
On Thu, Jun 23, 2016 at 2:18 PM, Davide Lasagna
wrote:
> Is there any particular reason why `Zip` objects are
Is there any particular reason why `Zip` objects are iterable but not
indexable? Python allows that.
>From previous discussion on the topic (2014 topic
at https://groups.google.com/forum/#!topic/julia-dev/5bgMvzJveWA) it seems
that it has not been implemented yet.
Thanks,