UncertainQtty unexpected result
yumengch opened this issue · comments
Bug Description:
Motivated by the output in test_example_2.py
, using 7.7676 ±1.2464 as input:
>>> from dapper.tools.rounding import UncertainQtty
>>> uq = UncertainQtty(7.7676, 1.2464)
>>> print(uq)
UncertainQtty(val=8, prec=1.0)
This is in contrast to the expected UncertainQtty(val=8.0, prec=1.0)
or UncertainQtty(val=8, prec=1)
. I think the latter is preferred.
Cause of the bug:
Class UncertainQtty
prints the first significant figure of the prec
with the following code:
>>> np.round(1.2464 ,0)
1.0
>>> np.round(0.2464 ,0)
0.0
Possible Solutions:
Turn float
to int
if the first significant figure is ahead of the decimal separator.
Note
This issue is related to an old version TODO, which speculates the use of uq
in the xps.tabulate_avrgs
and xpSpace.print
.
The difficulty is that, uq
cannot be used directly for the output because it does not allow the designated decimals
for its output. test_example_2.py
has examples for decimals = 4
.
Any comments?
I agree, your second expected output is the right one.
Possible Solutions:
Turn
float
toint
if the first significant figure is ahead of the decimal separator.
I would say "...if the precision's decimal order is non-negative, i.e. if n>=0
in the __str__
method."
I believe the mentioned TODO was fixed by the previous update to rounding
/UncertainQtty
, except for this issue here which you found (very good attention to detail BTW). Is there something else I'm missing?
I would say "...if the precision's decimal order is non-negative, i.e. if n>=0 in the str method."
Good point. I will add it.
I believe the mentioned TODO was fixed by the previous update to rounding/UncertainQtty, except for this issue here which you found (very good attention to detail BTW). Is there something else I'm missing?
I thought you planned to have 0.030 ±0.005
instead of 0.03±0.005
. This requires padding 0
to the end of the string.
I thought you planned to have
0.030 ±0.005
instead of0.03±0.005
. This requires padding0
to the end of the string.
Yes, you're right. I had forgotten that printing in the table does not yield the same nice result as printing individual UncertainQtty
. Seeing as this was already complicated, I think it might get even more complicated. I suppose instead of
this one would have to call uq.__str__
and thereafter manually split(whitespace)
and align on the point...
I suppose instead of this one would have to call
uq.__str__
and thereafter manuallysplit(whitespace)
and align on the point...
Yes. I am trying to add some code in the unpack_uqs
and align_col
to pad 0
s as I feel the problem is not entirely in the UncertainQtty
and I am just not sure if it is a good idea to give the option of deciding output decimals in UncertainQtty
, which is decided automatically by prec
at the moment. I just hope things won't get too ugly afterwards...
I feel the problem is not entirely in the
UncertainQtty
I would say the problem is now not at all in UncertainQtty
, which works fine (after casting to int).
I think the mult
kwarg can be eliminated from UncertainQtty
. It does not make much sense to keep it there. Any formatting not entirely determined by prec
should be done elsewhere. Similarly UncertainQtty
should not print to a requested number of decimals. That should be the job of the table formatter.
So if you want to revise the table formatting, remember these aspects:
- The default printing should be that of individual
UncertainQtty.__str__
. This would be better thanUncertainQtty.round
which is currently being used. - However, the printouts must then be split, because there should be one column for val, and one for prec.
- Each column should be aligned on the point.
- The non-default printing alternative would be: a specific number of decimals. I'm not sure if this is really necessary though. I just thought it was an easy way to avoid having to change the test data each time I revised the rounding algorithm.
All in all, not a very easy problem I think