# Status of AxisArrays.jl

**URL:** <https://discourse.julialang.org/t/status-of-axisarrays-jl/28682>\
**Category:** General Usage\
**Tags:** question\
**Created:** [September 12, 2019, 8:22am UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682 "2019-09-12T08:22:31Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [September 12, 2019, 8:22am UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/1 "2019-09-12T08:22:31Z")

</div>

Hello,  
What is the status of this package?  
Even though there was some activity lately it looks as if it lacks a little bit of love an care…  
Can it already be used in a production system, or are a lot of hidden bugs to be expected?  
Uwe

---

<div class="post-metadata">

**Author:** ![mauro3](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mauro3/32/292_2.png) [@mauro3](https://discourse.julialang.org/u/mauro3)\
**Post date:** [September 12, 2019, 8:41am UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/2 "2019-09-12T08:41:45Z")

</div>

There is also the new DimensionalData.jl, announced recently [ANN: DimensionalData.jl and GeoData.jl](https://discourse.julialang.org/t/ann-dimensionaldata-jl-and-geodata-jl/28492).

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [September 12, 2019, 9:10am UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/3 "2019-09-12T09:10:47Z")

</div>

Thanks for the hint!

---

<div class="post-metadata">

**Author:** ![tobias.knopp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tobias.knopp/32/7551_2.png) [@tobias.knopp](https://discourse.julialang.org/u/tobias.knopp)\
**Post date:** [September 12, 2019, 9:15am UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/4 "2019-09-12T09:15:20Z")

</div>

Is somebody aware of a package that does not encode the axes in its type?

---

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [September 12, 2019, 9:20am UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/5 "2019-09-12T09:20:47Z")

</div>

See also [WIP: The Plan · Issue #1 · JuliaCollections/AxisArraysFuture · GitHub](https://github.com/JuliaCollections/AxisArraysFuture/issues/1)  
and the two packages that do each of the main halves and are designed around being composable:

- [https://github.com/invenia/IndexedDims.jl/blob/master/src/IndexedDims.jl](https://github.com/invenia/IndexedDims.jl/blob/master/src/IndexedDims.jl) (WIP)
- [GitHub - invenia/NamedDims.jl: For working with dimensions of arrays by name](https://github.com/invenia/NamedDims.jl) (less WIP, but still not fully happy. Am using in production though)

There is a lot going on in the area, and I think that is great.  
Many options/parts to shake out the best way.

> [@tobias.knopp](#):
>
> Is somebody aware of a package that does not encode the axes in its type?

@davidanthoff’s [GitHub - davidavdav/NamedArrays.jl: Julia type that implements a drop-in replacement of Array with named dimensions](https://github.com/davidavdav/NamedArrays.jl)

Note that if you want zero overhead at runtime (like NamedDims does),  
you basically need to encode the axes in the type, so that they can be compiled out of existance,  
during specialization.

---

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [September 12, 2019, 9:27am UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/6 "2019-09-12T09:27:06Z")

</div>

> [@ufechner7](#):
>
> Can it already be used in a production system, or are a lot of hidden bugs to be expected?

You can use AxisArrays in production, Invenia does.  
But they are very touchy and so can be frustrating to work with.

Any production system should have good enough integration tests that your confident that you are not hitting bugs (of course you are wrong, there are always bugs, but you want to minimize how often that happens)  
As such any package can be used in production, the question is how frustrating will it be.

AxisArrays does not have hidden bugs that will sneak past you tests.  
It has obvious bugs (/missing features),  
like a ton of operations dropping the axes,  
and missing overloads,  
and confusing notation for how to work with things that are indexed with different Int ranges.  
Which will easily be caught by your tests.

And it itself does still prevent certain categories of coding mistakes

---

<div class="post-metadata">

**Author:** ![tobias.knopp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tobias.knopp/32/7551_2.png) [@tobias.knopp](https://discourse.julialang.org/u/tobias.knopp)\
**Post date:** [September 12, 2019, 9:38am UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/7 "2019-09-12T09:38:15Z")

</div>

> [@oxinabox](#):
>
> Note that if you want zero overhead at runtime (like NamedDims does),

Its not fully clear to me, why this needs to be like that. The axis are just metadata and indexing could be done on the raw array. Its clear that `permutedims` and slicing require some additional things but things can keep type stable as long as one uses traditional indexing.

What I am looking for is a way to represent a tomographic data (3D) that has some center, some pixelspacing, and some rotation matrix in space.

My issue with AxisArrays is that I, for instance, cannot change the center, or the rotation matrix without creating a new type.

---

<div class="post-metadata">

**Author:** ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)\
**Post date:** [September 12, 2019, 10:54am UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/8 "2019-09-12T10:54:35Z")

</div>

DimensionalData.jl will definitely have more bugs than AxisArrays.jl, its only at 0.1.0! But they will also be fixed promptly if you post an issue.

@tobias.knopp I’m wondering what the negative consequences are for you of “creating a new type”? do you mean you have problem with creating a new struct instance with a different type than the original?

DimensionalData.jl is mostly functional so the objects are frequently rebuilt. The compiler can elide the allocations most of the time anyway.

---

<div class="post-metadata">

**Author:** ![tobias.knopp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tobias.knopp/32/7551_2.png) [@tobias.knopp](https://discourse.julialang.org/u/tobias.knopp)\
**Post date:** [September 12, 2019, 11:39am UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/9 "2019-09-12T11:39:48Z")

</div>

For instance I have written a Gtk based data viewer that can display 4D tomographic data. It looks something like:

```julia
  struct DataViewer
    data:: ???
  end

```

With a simple Array, I can do

```julia
  struct DataViewer
    data::Array{Float32,4}
  end

```

With an AxisArray this is much more complicated. And no,

```julia
  struct DataViewer{T}
    data::T
  end

```

is not an option, because data can be changed at runtime.

---

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [September 12, 2019, 11:42am UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/10 "2019-09-12T11:42:16Z")

</div>

> [@tobias.knopp](#):
>
> With an AxisArray this is much more complicated. And no,
> 
> ```julia
> struct DataViewer{T}
> data::T
> end
> 
> ```
> 
> is not an option, because data can be changed at runtime.

You could just do:

```julia
mutable struct DataViewer
    data::AbstractArray
end

```

The performance implictations are not as bad as you might think,  
and are kinda similar to the ones that one avoids by putting the axes into the types.

---

<div class="post-metadata">

**Author:** ![tobias.knopp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tobias.knopp/32/7551_2.png) [@tobias.knopp](https://discourse.julialang.org/u/tobias.knopp)\
**Post date:** [September 12, 2019, 11:42am UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/11 "2019-09-12T11:42:40Z")

</div>

To get somewhat more concrete, here is the type that I am using

```julia
ImageMeta{Float32,5,AxisArray{Float32,5,Array{Float32,5},Tuple{Axis{:color,UnitRange{Int64}},Axis{:x,StepRangeLen{Quantity{Float64,𝐋,Unitful.FreeUnits{(mm,),𝐋,nothing}},Base.TwicePrecision{Quantity{Float64,𝐋,Unitful.FreeUnits{(mm,),𝐋,nothing}}},Base.TwicePrecision{Quantity{Float64,𝐋,Unitful.FreeUnits{(mm,),𝐋,nothing}}}}},Axis{:y,StepRangeLen{Quantity{Float64,𝐋,Unitful.FreeUnits{(mm,),𝐋,nothing}},Base.TwicePrecision{Quantity{Float64,𝐋,Unitful.FreeUnits{(mm,),𝐋,nothing}}},Base.TwicePrecision{Quantity{Float64,𝐋,Unitful.FreeUnits{(mm,),𝐋,nothing}}}}},Axis{:z,StepRangeLen{Quantity{Float64,𝐋,Unitful.FreeUnits{(mm,),𝐋,nothing}},Base.TwicePrecision{Quantity{Float64,𝐋,Unitful.FreeUnits{(mm,),𝐋,nothing}}},Base.TwicePrecision{Quantity{Float64,𝐋,Unitful.FreeUnits{(mm,),𝐋,nothing}}}}},Axis{:time,StepRangeLen{Quantity{Float64,𝐓,Unitful.FreeUnits{(s,),𝐓,nothing}},Base.TwicePrecision{Quantity{Float64,𝐓,Unitful.FreeUnits{(s,),𝐓,nothing}}},Base.TwicePrecision{Quantity{Float64,𝐓,Unitful.FreeUnits{(s,),𝐓,nothing}}}}}}},Dict{String,Any}}

```

---

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [September 12, 2019, 11:43am UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/12 "2019-09-12T11:43:15Z")

</div>

what a glorious type.  
Godlike and powerful.  
Huge like a mountain.

😂

---

<div class="post-metadata">

**Author:** ![tobias.knopp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tobias.knopp/32/7551_2.png) [@tobias.knopp](https://discourse.julialang.org/u/tobias.knopp)\
**Post date:** [September 12, 2019, 11:47am UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/13 "2019-09-12T11:47:42Z")

</div>

`AbstractArray` is, what I am currently doing. My issue is that my data viewer has a compile time of more than 16 seconds. second call is 0.2 s. Therefore my hope is that making data `DataViewer` concrete will make compile time (seems to be basically inference) smaller.

---

<div class="post-metadata">

**Author:** ![tobias.knopp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tobias.knopp/32/7551_2.png) [@tobias.knopp](https://discourse.julialang.org/u/tobias.knopp)\
**Post date:** [September 12, 2019, 11:50am UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/14 "2019-09-12T11:50:12Z")

</div>

> [@oxinabox](#):
>
> what a glorious type.  
> Godlike and powerful.  
> Huge like a mountain.

Powerful it is, and I like AxisArrays design actually. But then, please write a simple function that changes the center of an `AxisArray` that has spatial dimensions in the first three dims. Not obvious how to do that.

---

<div class="post-metadata">

**Author:** ![tobias.knopp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tobias.knopp/32/7551_2.png) [@tobias.knopp](https://discourse.julialang.org/u/tobias.knopp)\
**Post date:** [September 12, 2019, 12:20pm UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/15 "2019-09-12T12:20:45Z")

</div>

> [@oxinabox](#):
>
> what a glorious type.  
> Godlike and powerful.  
> Huge like a mountain.

By the way: Is there an easy way for stripping the units from my type, while first converting things to SI of course (e.g. convert `ms` to `s` and so on). This would make the type much shorter in many cases.

---

<div class="post-metadata">

**Author:** ![Zach\_Christensen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zach_christensen/32/7220_2.png) [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)\
**Post date:** [September 12, 2019, 12:41pm UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/16 "2019-09-12T12:41:14Z")

</div>

For those who are working on these new array interfaces I’ve been working on a `AbstractIndices.jl` package. I don’t know if it will ever make it out the door though because I have a lot of other obligations. The heart of it is this file [https://github.com/Tokazama/AbstractIndices.jl/blob/master/src/abstractindex.jl](https://github.com/Tokazama/AbstractIndices.jl/blob/master/src/abstractindex.jl). The goal was to make something that relied on very little unique internal behavior so that any changes to performance in base (in terms of sorting, indexing, and maybe even multithreading) would just come along with it.

The idea is that the only obstacle to making any `AbstractVector` into an index is knowing how to transform the user input into the index for the `to_index` function in base. Once that’s done most indexing behavior is taken care of by `to_axes` in base.

The basic idea of how it works can be seen in the examples found here [https://github.com/Tokazama/AbstractIndices.jl/blob/master/src/asindex.jl](https://github.com/Tokazama/AbstractIndices.jl/blob/master/src/asindex.jl). It isn’t currently optimized for performance and I haven’t figured out the `show` method. Feel free to take whatever you want or let me know if you want some help implementing it in one of your packages. My only goal here is to have something that’s very flexible and maintainable.

---

<div class="post-metadata">

**Author:** ![tobias.knopp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tobias.knopp/32/7551_2.png) [@tobias.knopp](https://discourse.julialang.org/u/tobias.knopp)\
**Post date:** [September 12, 2019, 12:50pm UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/17 "2019-09-12T12:50:04Z")

</div>

I should mention that coordination across packages is extremely important here. In the end, all what I want is

```julia
A = load("myimage.nii")
B = load("mydicomdata.dcm")
DataViewer(A)
DataViewer(B)

```

---

<div class="post-metadata">

**Author:** ![Zach\_Christensen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zach_christensen/32/7220_2.png) [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)\
**Post date:** [September 12, 2019, 12:55pm UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/18 "2019-09-12T12:55:07Z")

</div>

I can almost guarantee that this won’t be too much of an issue for the images interface as I have been specifically concerned with this very issue while rewriting the NIfTI package. If you take a look at some of the recent additions to `ImageCore.jl`, you’ll see that I’ve started implementing a minimal trait based interface that will hopefully allow compatibility across different array paradigms. It basically comes down to returning a `NamedTuple` for the image based traits. I imagine this would be possible no matter what the community converges on.

---

<div class="post-metadata">

**Author:** ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)\
**Post date:** [September 12, 2019, 1:06pm UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/19 "2019-09-12T13:06:49Z")

</div>

So the problem is using a fixed-type mutable container of an immutable, functionally updated object that may change type in some of those updates. It would be interesting to see how using `::AbstractArray` works to know how much of a problem this really is.

---

<div class="post-metadata">

**Author:** ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)\
**Post date:** [September 12, 2019, 1:29pm UTC](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682/20 "2019-09-12T13:29:19Z")

</div>

AbstractIndices looks interesting, funny how many of us have been writing similar things at the same time. I wonder if it’s possible to end up with one package that fits all of our requirements.

[Next page](https://discourse.julialang.org/t/status-of-axisarrays-jl/28682.md?page=2)