There is plenty of reason and little downside to enforce explicit unit calculation rather than doing it implicitly in an uncontrolled way:
return dimensional quantities from calls like twiss
the association between field name and unit can be looked up in a table (see this preliminary prototype)
routines dealing with input (like match) can also make use of units.
Code that only performs simple operations on the returned data (and performs no explicit type-checking) will not need to be changed. However, before using functions like math.log the data needs to be explicitly casted to the desired unit first (which is a necessity IMO, since many mathematical functions don't make sense on dimensional quantities).
This could also be made an optional feature (e.g. via inheritance) if we don't want to break user code.
There is plenty of reason and little downside to enforce explicit unit calculation rather than doing it implicitly in an uncontrolled way:
twissmatch) can also make use of units.Code that only performs simple operations on the returned data (and performs no explicit type-checking) will not need to be changed. However, before using functions like
math.logthe data needs to be explicitly casted to the desired unit first (which is a necessity IMO, since many mathematical functions don't make sense on dimensional quantities).This could also be made an optional feature (e.g. via inheritance) if we don't want to break user code.
There are several python modules for this task:
Among them I have found unum to be a reasonable candidate regarding the following issues:
floatafter multiplication (inconsistent return types can break lots of code/add much complexity)float(would defy the type-safety otherwise)floatpossible for quantities of dimension 1 (math.sqrt(2*units.m/units.m)succeeds)I think this would be really nice to have at some point.