hgrecco / pint / 1730 / 2
91%
master: 91%

DEFAULT BRANCH: master
Ran
Files 0
Run time 0s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 0.0%. Remained the same
PKGS="python=3.7 ipython matplotlib nbsphinx numpy pandas jupyter_client ipykernel python-graphviz graphviz xarray sparse dask[complete] sphinx Pygments==2.3.1 docutils==0.14 alabaster commonmark==0.8.1 recommonmark==0.5.0"

push

travis-ci

web-flow 
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)

0 of 0 relevant lines covered (NaN%)

0.0 hits per line

Source Files on job 1730.2 (PKGS="python=3.7 ipython matplotlib nbsphinx numpy pandas jupyter_client ipykernel python-graphviz graphviz xarray sparse dask[complete] sphinx Pygments==2.3.1 docutils==0.14 alabaster commonmark==0.8.1 recommonmark==0.5.0")