You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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., wavelengthauto v2 = convert(v, "time", "wavelength");
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.
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.
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.
Activity
JohanMabille commentedon Feb 6, 2019
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
xframemust be studied.kunaltyagi commentedon May 21, 2021
Any updates on this?
SimonHeybrock commentedon May 21, 2021
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.
JohanMabille commentedon May 21, 2021
Unfortunately no, I didn't have the time to improve xframe during the past year.