Skip to content

Axes with more than one dimension #213

Open

Description

@SimonHeybrock

For our application (neutron scattering) we frequently deal with axis-arrays that have more than one dimension. To my understanding this mainly occurs when one of the dimensions is not a continuous variable but rather a discrete set of values, such as a label.

As an example, consider measuring a series of values at a number of points in in space:

auto v =
    variable(data,
             xf::coordinate({{"position", xf::axis({pos1, pos2, pos3, pos4})},
                             {"time", xf::axis({1ms, 2ms, 3ms})}}),
             xf::dimension({"position", "time"}));

// "time" can be converted into other related physical quantities, e.g., wavelength
auto v2 = convert(v, "time", "wavelength");

For illustration, consider also this figure: http://docs.mantidproject.org/v3.11.0/_images/MBC_Ragged.png.

  • The conversion from "time" to "wavelength" depends on the position (in the linked figure, every spectrum is measured at a different position). Therefore, the "wavelength" axis in v2 must have different values for every "position" index.
  • We may later rebin the data onto a common axis, but for intermediate steps the non-aligned axis is required.
  • I think only one of the coordinates can have more than one dimension. For example, "position" cannot depend on "wavelength".
  • If an axis is multi-dimensional many operations operate without changes, but some are not possible. For example, indexing slices is only possible with an index, but not with the label provided by the axis.

In general, I think similar types of a multi-dimensional axis would be required by many adjustments or conversions that depend on one of the other axes.

Activity

  1. JohanMabille commented on Feb 6, 2019

    @JohanMabille
    Member

    That's something we have not thought about yet. The current architecture is flexible enough so we can plug different implementations of coordinates, however whether such a coordinate object could fit in xframe must be studied.

  2. kunaltyagi commented on May 21, 2021

    @kunaltyagi

    Any updates on this?

  3. SimonHeybrock commented on May 21, 2021

    @SimonHeybrock
    Author

    From our side, we have since chosen a different mechanism, relying on type erasure to build a library (https://scipp.github.io/) that supports this and other features in a Python-like manner. From my point of view this issue could thus be closed.

  4. JohanMabille commented on May 21, 2021

    @JohanMabille
    Member

    Unfortunately no, I didn't have the time to improve xframe during the past year.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions