fit_report
table: use tabulate
and consistent value/uncertainty formatting?
#938
jagerber48
started this conversation in
Ideas
Replies: 1 comment 3 replies
-
I am not a fan of any of the suggested changes here. Admittedly I haven't spend the time to read the linked thread completely - too long 😉. Nothing shown here looks more readable to me than what we have now, but of course that's my personal opinion. Sure, one should use a reasonable number of significant digits when reporting fitted parameters in any "official" report. However, an enduser should be able to so her/himself. Also, if there is no need to depend in an external dependency as is the case here,we (or at least I) would rather not. |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Note that this discussion is related to the overall-width-formatting sciform issue but it is different. That issue is about if
sciform
should expose fixed width formatting functionality for users. This discussion is mainly about my recommendation forlmfit
to usetabulate
and standardized value/uncertainty formatting when generating fit reports.Consider the
example_fit_with_bounds.py
example script. It outputs a fit report that looks like:Here is the generating code. I see two issues with this table
13.8904759 +/- 0.24410753
should instead be displayed as13.89 +/- 0.24
. I argue the additional significant digits clutter the display and make it hard for the reader to quickly glean the important information from the table. For examples and some more info see BIPM guide to the expression of uncertainty in measurement section 7.2.2.printfuncs.py
, it is clear thatlmfit
is going through pains to get the whitespace and numeric widths right so that the resulting fit report table comes out aligned. However, even with those pains we see misalignment in the later columns of the variables table. The issues here are (a) the source code is complex because it needs to handle whitespace and (b) there are still remaining alignment issues.The issues in point 2 can be easily solved by using the tabulate package which is designed to address exactly this issue.
tabulate
will handle all the white space and table construction (including row and column separators etc.) under the hood. The user only needs to provide an array of the input data to be displayed. I don't see a downside to adopting tabulate forlmfit
reports.The issues in point 1 can be addressed by using
ufloat
formatting from theuncertainties
package (already a dependency oflmfit
) or by using value/uncertainty formatting from thesciform
package. I think either of these would be a net win for thelmfit
fit report. However, there would be changes to how the numbers are displayed. First off, less significant figures would be shown for both the value and the uncertainty. Second, the widths of the numerical parts of the strings (that is excluding prepended/appended white space) would no longer exactly match. In my personal opinion these objections are not problematic, but I think this is a matter of personal taste so I'm open to other views.Here is how the fit report would look using
tabulate
+uncertainties
and still usinggformat
:The effect of
gformat
is to keep the final 4 floats in the Fit Statistics section to be the same character length.Here is how the table might look using
tabulate
+sciform
(and not usinggformat
):Here
sciform
is used to present the last 4 floats in the Fit Statistics section to 4 significant figures. Note that each one has 4 significant figures but the overall character lengths of the numbers vary.For both
sciform
anduncertainties
, the value/uncertainty pair formatting could be adjusted using the various options available in the package. For examplesciform
can be used withparen_uncertainty=True
andsuperscript=True
to yieldOne could imagine the user passing in configuration options into the
lmfit
report_fit()
function to control this display. e.g. foruncertainties
the user could provide anuncertainties
compatible format specifier and forsciform
the user could provide asciform
Formatter
(orsciform
**kwargs
that can be used to build aFormatter
).@newville or others: Are these two suggestions (consistent value/uncertainty formatting or
tabulate
adoption) of interest tolmfit
? If so I would be happy to help make some of these changes. On my fork oflmfit
I have a PR with a preliminary version of thetabulate
+uncertainties
+gformat
version of the code: jagerber48#1. I also have a branch with thetabulate
+sciform
version.I haven't yet checked if there are other places
lmfit
might benefit fromtabulate
.Beta Was this translation helpful? Give feedback.
All reactions