Comments (9)
I added formatting support to uncertainties. You can have a look at it in the GitHub version (https://github.com/lebigot/uncertainties/). The documentation is at https://github.com/lebigot/uncertainties/blob/master/doc/user_guide.rst#printing. I am ready to make adjustment to the formatting internals so that they can be used by Pint in a convenient way (I'm thinking of how parentheses are handled, here, as you may want to print like "(1.00±0.01)e+10 s", for instance, with no external parentheses, but also like "(1.00±0.01) s", with parentheses).
from pint.
It looks really good. How about if we try to agree on the formatting codes?
Pint uses:
s
for stringr
for reprl
for latexp
for prettyh
for html (to be added soon)
Additionally, I use the modifier ~
to specify the short form of the units.
For what I can see, your u
code is equivalent to what I propose to be s
in this issue. s
was not a good choice, I will happily change to u
.
On the other hand, I like p
more than C
, because pretty print can be more than the plus/minus sign.
from pint.
Thanks. We can try to make the format specifications closer. :)
Yeah, s
in your proposal mostly does what u
does in uncertainties. s
is indeed not perfect because it is used for string pre-formatting, not formatting ('{!s:10}'.format(1.23)
).
Similarly, the usual notation for the representation is better as the usual '{!r}'
, I think.
I like p
(pretty: ±) better than my C
(character), so I will change C
to P
.
Now, I would like to raise the question of using uppercase letters for some options. I like the idea of interfering as little as possible with the usual float formatting, so I decided to use uppercase letters for the formatting options (L for LaTeX, P [now] for pretty-print and S for the shorthand notation). I kept the lowercase u for defining the number of significant digits on the uncertainty because it can appear before the float f/g/e format type, so that I find it natural to keep the first part of the format specification in lowercase, and have the options in uppercase. I take options to be anything that goes beyond what float formatting does (precision, total width, etc.).
What do you think about this uppercase question?
from pint.
Great!
In uppercase, there is also E
, F
and G
. But I actually like L
(uppercase) because l
(lowercase) can be misread as I
(uppercase i
) depending on the font. So I am fine to change that.
I was playing a little bit with the representation of uncertainties. What do you think of this?
>>> '{}'.format(x)
0.200+/-0.010
>>> '{}'.format(x*1e7)
(2.00+/-0.10)e+06
>>> '{:.3u}'.format(x)
0.2000+/-0.0100
>>> '{:.3uP}'.format(x)
0.2000±0.0100
>>> '{:.3uL}'.format(x)
0.2000\pm0.0100
>>> '{:.3uP}'.format(x*1e7)
(0.2000±0.0100) 10⁶
>>> '{:.3uL}'.format(x*1e7)
\right(0.2000\pm0.0100\left) \times 10^{6}
>>> '{:(u)}'.format(x)
0.20(1)
>>> '{:(.3u)}'.format(x)
0.2000(0100)
>>> '{:(.3u)P}'.format(x)
0.2000(0100)
>>> '{:(.3u)L}'.format(x)
0.2000\left(0100\right)
>>> '{:(.3u)P}'.format(x*1e7)
0.2000(0100) 10⁶
>>> '{:(.3u)L}'.format(x*1e7)
0.2000\left(0100\right) \times 10^{6}
from pint.
The idea of using small exponent digits for the pretty-printing is interesting. I will probably include it in uncertainties. The only reservation I have now is that they might be printed too small in a terminal to be legible, but they do make sense. What do you think?
I think that the multiplication symbol should be added, in this case:
>>> '{:.3uP}'.format(x*1e7)
(0.2000±0.0100)×10⁶
no? This would be consistent with the current LaTeX mode too.
Note that '{:(.3u)}'.format(x)
should print 0.2000(100) not 0.2000(0100): only the affected digits are written.
If I remember correctly "|eft(" and "\right)" is equivalent to "(" and ")", since what is inside the parenthese is small, so I believe that there is no need for \left and \right.
The '{:(u)}'
is interesting, but it is also unusual (since it uses two symbol for a single formatting option), so I prefer something like for instance the current "S" (shorthand) option of uncertainties.
What do you think?
from pint.
Hi,
I like your version of pretty print with ×
, and I agree with you about the S
.
Regarding LaTeX, I use \left(
and \right)
because it forms a group. This is useful to prevent that is broken automatically into two lines when is near the end of one.
Ps.- You are of course right about the significant digits!
from pint.
I will start implementing this.
from pint.
I would suggest that you piggyback on uncertainties as much as possible: writing its formatting code was much more difficult and subtle than I initially thought… I will implement the new pretty-print (exponent digits, multiplication symbol) at some point, but I can't set a timeline, for now…
from pint.
Indeed it is. Most of the logic was implemented in Pint 0.2. I need to fix a few things and then dispatch to uncertainties the call. Do not worry about the timeline, I am really glad that we agreed on the specs.
from pint.
Related Issues (20)
- Could not define System from lines HOT 1
- Use `usedforsecurity=False` when calling `hashlib.blake2b` to avoid crashing on FIPS enabled systems HOT 3
- unit dB not hashable when using decimal as non_int_type when numpy is installed
- In place numpy array operations causing issues with dimensionality of quantities HOT 1
- Listing possible units based on dimensionality
- Adding vs multiplying quantities in different units
- floating point arithmetic errors HOT 3
- mypy error: ureg.m annotation is expected to be Quantity instead of Unit
- mypy error: defining a Quantity as multiplication of list and unit raises an error
- Units with offsets raise DimensionalityError in 0.23 HOT 2
- TypeError when calling `to_base_units()` for temperature.
- Check dimensions in given context HOT 1
- Warnings when using `ruff`
- `PlainQuantity.ndim` stringifys `magnitude`, which is expensive for arrays
- How to get type hinting to work? HOT 1
- Loading Quantity from PyQt6 QSettings not working
- `{:L~}` can generate `\mathrm{μ}` which becomes blank when latex compiled
- Suggestion: Add permille ratio HOT 2
- How to convert kNm to custom unit Nmm? HOT 7
- Nm definition
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pint.