Open sagitta42 opened 1 year ago
@gipert suggestion from @oschulz : gain_ADC_per_eV
. What do you think? At least for variables with divisions in units
Well I would like to hear a complete proposal :)
If we use the /
, *
, etc. characters then units autoparsing will work out of the box, but the strings will not be valid variable names anymore. If we instead go for valid variable names, we'll need to write more code to parse units.
I would very very strongly advocate to use only names that are valid variable names in common programming languages.
I think we all agree that /
is not a choice.
As for other options:
ADC_per_eV
is parseable and valid, and human understandable. Corresponding multiplication keyword could be by
.ADC_eV
(similar to current 1e9e_cm3
) is not parseable (might as well stand for multiplication) and not human understandable. Thus better to have distinct keywords for division or multiplication. Alternatively division could have a keyword, and multiplication just units separated by _
, but that's less "symmetric". However, if there are many units multiplied, it could be too much to have by
between each.1e9e_cm3
could be parseable in this format (if number follows units = power)
In several cases already we have units with divisions e.g. in crystal metadata for impurity concentration in 1e9 e/cm^3, or in the preamplifier gain parameter in ADC/eV.
Currently in the crystal metadata, the impurity values are saved under
value_in_1e9e_cm3
. For now, I follow similar format for gaingain_ADC_eV
.What would be the best solution for these cases and others with complex parameters that involve divisions, powers, or multiplications?