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
The output of many of the tuning procedures is dependent on the units used for the axes involved: from spacing as in nm/wn conversion to the smoothness factor on splines being different for different absolute (e.g. fs vs ps).
Currently, we assume in a few places that the "setpoint" is energy units, and that we wish to do the computation in "wn"
What I propose is that we have the ability to pass "unit system" to these mehods, with a sane default. This will convert relevant parts of data objects (axes and channels with units [looking at workup.setpoint]) as well as the relevant curve parts (setpoints, subcurve_setpoints, dependents) into these units.
We could have a separate plot "unit system" if we want, but not sure how that would work, especially in cases where the plot generated is in differential space.
As for what these "unit system" objects look like:
We could do dictionary: {kind: unit} (e.g. `{"energy": "wn", "delay": "ps"})
pro: very explicit, cannot accidentally over specify
con: dicts are mutable, and would be harder to specify a default (could use None, but I would lean towards None being "don't convert", though not sure that makes sense)
We could use any iterable, e.g. sets/tuples/lists
pro: easy and clean, both tuples and frozenset satisfy immutability
con: can lead to ("ps", "fs") both being called for, and not being sure which to use.
This may also be a good use for namedtuple come to think of it
These unit systems could be defined here in attune, or in WT, if we wish to fully implement this idea.
I would have convert accept this units sytem object directly (in addition to current behavior where a single unit is passed)
The text was updated successfully, but these errors were encountered:
What this also does is enable processes which are additive in wavelength space to use curve objects, and the tuning procedures herein without fuss, while still keeping default behavior of ensuring adding is normally done in energy space
The output of many of the tuning procedures is dependent on the units used for the axes involved: from spacing as in nm/wn conversion to the smoothness factor on splines being different for different absolute (e.g. fs vs ps).
Currently, we assume in a few places that the "setpoint" is energy units, and that we wish to do the computation in "wn"
What I propose is that we have the ability to pass "unit system" to these mehods, with a sane default. This will convert relevant parts of data objects (axes and channels with units [looking at
workup.setpoint
]) as well as the relevant curve parts (setpoints, subcurve_setpoints, dependents) into these units.We could have a separate plot "unit system" if we want, but not sure how that would work, especially in cases where the plot generated is in differential space.
As for what these "unit system" objects look like:
We could do dictionary:
{kind: unit}
(e.g. `{"energy": "wn", "delay": "ps"})pro: very explicit, cannot accidentally over specify
con: dicts are mutable, and would be harder to specify a default (could use None, but I would lean towards None being "don't convert", though not sure that makes sense)
We could use any iterable, e.g. sets/tuples/lists
pro: easy and clean, both tuples and frozenset satisfy immutability
con: can lead to
("ps", "fs")
both being called for, and not being sure which to use.This may also be a good use for
namedtuple
come to think of itThese unit systems could be defined here in attune, or in WT, if we wish to fully implement this idea.
I would have
convert
accept this units sytem object directly (in addition to current behavior where a single unit is passed)The text was updated successfully, but these errors were encountered: