hgrecco / pint / 1729

92%

master: 91%

push

travis-ci

Merge #1070

1070: Make 'Lx' safe for use with uncertainties r=hgrecco a=PorcelainMouse

- [x] Pertains to issue # 814
- [x] Executed ``black -t py36 . && isort -rc . && flake8`` with no errors
- [x] The change is fully covered by automated unit tests
- [x] Documented in docs/ as appropriate
- [x] Added an entry to the CHANGES file

Here is my suggested patch related to issue #814. After working on it for a while, I considered several solutions and this seemed the best, immediately available option.
This patch set avoids a compilation error thrown by LaTeX when SIunitx is given uncertainty value containing a decimal place, i.e. "\SI{123.4(1.2)}{\meter}%wrong!".

I think a better solution would be to work with 'uncertainties' to implement a fully compatible string format type implementation, as the current implementation for 'S' is not compatible and, as best I can tell, incorrect. (See NIST "concise" form for representing uncertain values in a single figure, which is what SIunitx is expecting.) If this is fixed, I think 'pint' could go back to the original code and achieve even more compatibility.

As part of this patch set, I removed the hard-coded SIunitx option "separate-uncertainty=true". It wasn't clear why this option was hard set and it did not appear to be necessary to pass any tests, nor any additional use case I tried.  Also, I could not think of a good way to reverse this option for the user of pint; it is not configurable.  It could be added back without much trouble, if required.

An alternative solution would be to check for '.' in the () part of the "concise" uncertainty value and just remove it. I did not do this because it requires that 'uncertainties' always produces nominal and unc values aligned with the same least significant digit, which I think is the case, but I wasn't confident.

However, '.1Lx' still produces invalid LaTeX code. Such a format spec may be invalid, though; I'm not sure. This is a separate issue a... (continued)

9 of 9 new or added lines in 1 file covered. (100.0%)

3589 of 3992 relevant lines covered (89.9%)

11.85 hits per line