[WIP] Display/return quantities with units #30
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Internally, all values are unitless, but now values that are returned to the user are displayed with units. This affects:
Fitter.fit
andFitter.refine
Fitter.best_params
andFitter.best_error
Fitter.results
(except when usingdataframe
, since it doesn't support units)This of course might break some existing scripts (or give weird results if they multiply things with units again). You can create your
Fitter
withuse_units=False
to switch back to the previous behaviour. I think that given that the package is still "beta" and not widely used (I guess), it is still ok to break things this way. I prefer doing this now and havinguse_units=True
as the default instead of having to tell users to add an option to get the nicer behaviour.There's one thing that still needs to be fixed: the callback gets the normalized error value, but the callback does not know about this and will display it wrong. I'm not quite sure what's the best solution here. Would it be more natural for the callback to show the error normalized without units (e.g. if the actual error is 2mV and your normalization is 1mV, it would be displayed as 2), or should it revert the normalization, i.e. always show the same error independent of normalization? @romainbrette any thoughts?
Closes #18, closes #19