astropy units and Quantity is useful because it keeps track of the units for you and works pretty well with Numpy arrays (except for some known issues). Things like trapezoid_fit (see also #14) could benefit from it.
Pros:
Automatic units bookkeeping. For example, we can get rid of warnings like "must pass in value as hours, not days" and reduce to risk of wrong calculations due to user error. You would be able to pass in either hours or days (or anything that can convert to them for that matter) and not have to worry about wrong results.
Works well with Numpy arrays.
Cons:
Extra computation overhead. There are some performance tips but some overhead is unavoidable. Units bookkeeping does not come for free.
Risk of introducing new bugs during refactoring. Some existing magic numbers need to be well understood and/or eliminated. For example, is that 1.0e6 used to convert units or for something else?
scipy.optimize cannot understand astropy units and Quantity, so the units still need to be stripped before that is called and then re-applied. It is important that we convert the Quantity to expected units before stripping the units.
astropy units and Quantity is useful because it keeps track of the units for you and works pretty well with Numpy arrays (except for some known issues). Things like
trapezoid_fit(see also #14) could benefit from it.Pros:
Cons:
1.0e6used to convert units or for something else?scipy.optimizecannot understand astropy units and Quantity, so the units still need to be stripped before that is called and then re-applied. It is important that we convert the Quantity to expected units before stripping the units.Do the benefits outweigh the costs?