Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make KeyIterator and ValueIterator more array-like #10092

Open
StefanKarpinski opened this issue Feb 5, 2015 · 9 comments
Open

make KeyIterator and ValueIterator more array-like #10092

StefanKarpinski opened this issue Feb 5, 2015 · 9 comments
Labels
status:help wanted Indicates that a maintainer wants help on an issue or pull request

Comments

@StefanKarpinski
Copy link
Sponsor Member

When have d = Dict(:foo => 12.34, "bar" => 567) and you write keys(d) you get a Base.KeyIterator object, which is fast and cheap to construct from the dictionary d. You can write collect(keys(d)) to get an array of keys, but you have to do this unfortunately often. It would be a good self-contained project to add more array-like behaviors to KeyIterator and the corresponding ValueIterator types so that things like keys(d)[1] and values(d)[end] work as expected.

@StefanKarpinski StefanKarpinski added the status:help wanted Indicates that a maintainer wants help on an issue or pull request label Feb 5, 2015
@JeffBezanson
Copy link
Sponsor Member

The problem is that this indexing would be O(n).

@jakebolewski
Copy link
Member

I feel that the Iterator name itself is a bit unfortunate as the iterator could possibly be infinite so iterator(n)[end] would not really be meaningful.

@StefanKarpinski
Copy link
Sponsor Member Author

@StefanKarpinski
Copy link
Sponsor Member Author

In the case of dictionaries, these iterators can't be infinite...

@jakebolewski
Copy link
Member

Of course, but I feel that there is a component of API predictability. If I get an *Iterator object back, I would expect O(n) cost at getting the nth element and no guarantee that the iterator has a finite number of elements.

@bicycle1885
Copy link
Member

Should we have a kind of an iterator class hierarchy like C++?

@JeffBezanson
Copy link
Sponsor Member

Although we might ultimately want ordered dictionaries, I don't think it's good to set the expectation that a type like KeyIterator should implement indexing. For many data structures you can only efficiently iterate the keys, and not index them.

@garrison
Copy link
Sponsor Member

I think there are really two distinct things here: being able to index these objects, and getting broadcast to work as expected (which is really what #19577 is about).

I think broadcast should perhaps be the higher priority. While indexing is missing functionality that would require data structure changes to be efficient, broadcast currently behaves in an unexpected way. For instance,

julia> a = Dict(1=>2, 2=>2)
Dict{Int64,Int64} with 2 entries:
  2 => 2
  1 => 2

julia> all(collect(values(a)) .== 2)
true

julia> all(values(a) .== 2)
false

@JeffBezanson
Copy link
Sponsor Member

Also #18618

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status:help wanted Indicates that a maintainer wants help on an issue or pull request
Projects
None yet
Development

No branches or pull requests

5 participants