# Why isn't keys defined on SparseAxisArray?

**URL:** https://discourse.julialang.org/t/why-isnt-keys-defined-on-sparseaxisarray/29667
**Category:** Optimization (Mathematical)
**Created:** [October 8, 2019, 11:54pm UTC](https://discourse.julialang.org/t/why-isnt-keys-defined-on-sparseaxisarray/29667 "2019-10-08T23:54:09Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![dourouc05](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dourouc05/32/2646_2.png) [@dourouc05](https://discourse.julialang.org/u/dourouc05)
#### Post date: [October 8, 2019, 11:54pm UTC](https://discourse.julialang.org/t/why-isnt-keys-defined-on-sparseaxisarray/29667/1 "2019-10-08T23:54:09Z")

</div>

In my code, I mostly use SparseAxisArray as an equivalent for dictionaries, except that it’s returned by JuMP. Thus, I’m trying to use `keys` on a SparseAxisArray, but it’s not behaving as expected, returning a DenseAxisArrayKeys. Actually, the most annoying part in this is when I’m using the `in` operator: `idx in keys(container)`, which always yields false, even though the index is valid for the container.

`eachindex` is not really a solution, as it returns a series of CartesianIndex, which I’m not using (I prefer indexing with concrete things that make sense for my optimisation problem, such as an edge in a graph). Using the `container.data` field is neither clean nor working; I have to use the original container I used to define the variable (which is sometimes problematic, as it must then get passed around in my code along with JuMP’s container, even though JuMP’s container is supposed to have this information somewhere).

Is there a design decision I missed or a quality-of-life improvement needed?

---

<div class="post-metadata">

### Author: ![odow](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/odow/32/28685_2.png) [@odow](https://discourse.julialang.org/u/odow)
#### Post date: [October 8, 2019, 11:58pm UTC](https://discourse.julialang.org/t/why-isnt-keys-defined-on-sparseaxisarray/29667/2 "2019-10-08T23:58:40Z")

</div>

There’s an open issue: [Unify treatment of `keys` on JuMP containers. · Issue #1988 · jump-dev/JuMP.jl · GitHub](https://github.com/JuliaOpt/JuMP.jl/issues/1988)

---

<div class="post-metadata">

### Author: ![dourouc05](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dourouc05/32/2646_2.png) [@dourouc05](https://discourse.julialang.org/u/dourouc05)
#### Post date: [October 9, 2019, 12:05am UTC](https://discourse.julialang.org/t/why-isnt-keys-defined-on-sparseaxisarray/29667/3 "2019-10-09T00:05:10Z")

</div>

Thanks, I did not see that issue!

Is there any consensus about what to do about it?

---

<div class="post-metadata">

### Author: ![odow](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/odow/32/28685_2.png) [@odow](https://discourse.julialang.org/u/odow)
#### Post date: [October 9, 2019, 12:22am UTC](https://discourse.julialang.org/t/why-isnt-keys-defined-on-sparseaxisarray/29667/4 "2019-10-09T00:22:48Z")

</div>

I don’t think anyone has worked on it. If you want to investigate and propose/implement a. PR, help would be appreciated!

---

<div class="post-metadata">

### Author: ![blegat](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/blegat/32/217090_2.png) [@blegat](https://discourse.julialang.org/u/blegat)
#### Post date: [October 9, 2019, 9:26am UTC](https://discourse.julialang.org/t/why-isnt-keys-defined-on-sparseaxisarray/29667/5 "2019-10-09T09:26:19Z")

</div>

We just developed in `SparseAxisArray` enough features so that there is not regression between JuMP v0.18 and JuMP v0.19.

> I mostly use SparseAxisArray as an equivalent for dictionaries

The goal is for the user code to work seemlessly with either of the 3 containers (`Array`, `DenseAxisArray` or `SparseAxisArray`) so that it’s possible to not worry about which one is picked. So it’s not supposed to act like a dictionary. If it’s possible to add features that are provided by dictionaries without creating inconsistent behaviors with other containers then the feature is welcome of course.
