bracket flag

[ep12]

I wonder if it would be possible to add a b (bracket) flag as a format specifier to always have enclosing brackets (force!) with a common factor (optionally). This would be heavily useful for stuff with units:
The correct format is (0.8265±0.0735)×10⁻³ m = (0.8265±0.0735) mm, not 0.8265±0.0735 mm.
The right place to check for the common factor / enclosing brackets is this package I think, not in the user's module.

[lebigot]

Do you have a reference about the correct format having parentheses? (This vaguely reminds me of a discussion one of my colleagues at the National Institute of Standards and Technology had, one day, arguing that the part before "±" should have explicit units!)

I do agree that if you want to ensure that the printed value does have parenthesis, this should be handled by the uncertainties package as a way of formatting numbers with uncertainty.

[ep12]

No, I don't have a written reference about the correct format, but it is obvious that parens are needed when having non-1 units. It simply does not make sense if the uncertainty has a different unit (e. g. 1) than the n value. That is equivalent to the addition (subtraction) of two values with different units. What is a second added to a meter? What the sum of 5 lux and 6 degrees?
If we have x = 5 m +/- 0.2 m everything works and we can factor: x = (5 +/- 0.2) m. x = 5 m +/- 2 might be intuitively interpreted right, but it is formally wrong. Another similar example: What is the sum of a vector x ∈ ℝ⁴ and another vector x ∈ ℝ⁵? The sum +: ℝ⁴×ℝ⁵ → ?? simply is not defined! You can think of units as something quite similar to the imaginary unit 𝚤 (just the unit properties, without the special properties, e.g. 𝚤²=-1): 5 + 3𝚤 is just 5 + 3𝚤. I hope you get my point why the parentheses are absolutely required for formal reasons...?

[ep12]

The pull request (#116) I created is ready for review, I think.

• add b and B format flags
• add tests
• add a simple check for surrounding parenthesis to ufloat_fromstr
• add documentation
• minor changes (mostly unicode related, one TypeError, a python2 error) to make the builds pass
  I know it's not good to have those CI test fixes in a pr with a different topic, however the only commits needed to implement the flags are 053ae8e, 1600fa7 and 81a9594.

[lebigot]

Thanks for the pull request. The number formatting code is probably the most complex in the whole library!

I must say that I fail to see the relationship between not being able to add quantities with incompatible units and the need for parentheses. In fact, I do read "1±0.2 m" as "(1±0.2) m", precisely for the reason that you quote: any other interpretation would not make sense, so here we're obviously adding adding 1 meter and ±0.2 meter.

Now, since you feel the need for this and since an additional format does not really complicate the API, I will have a look at the pull request and consider it for inclusion. I want to first handle the ongoing move to wheels, that impacts a couple of other programs (#112), though.

Codes "b" and "B" are however not my favorites:

• "b" is indeed already taken by standard Python.
• The word bracket refers by default to "[" and "]" (in American English, which is the language used in the project—and by Python, if I remember correctly).

What about using "p" instead, like in "parenthesis"? ("P" is already used by uncertainties for pretty-printing.)

[ep12]

Thanks a lot for accepting that without you feeling that need alike! I am quite used to the parenthesis, since the siunitx latex package automatically adds parens when a unit is specified (and leaves them out if not). You are right that b is not the best choice, but a strong and weak version of the flag are reasonable: for most applications (e. g. units) the weak flag is enough, but if someone wants to have parens surrounding everything and does print('Some text ({:p})'), he or she might end up with Some text ((2.46±0.12)) on the screen...
Since P is already in use and b is a standard formatting option, I now suggest r and R for round bracket. I have no clue if there are any other synonyms for "parenthesis" because English is not my first language...

[lebigot]

r and R might be the best option we have. "Round bracket" being a British English expression, it doesn't fully fit in uncertainties (or Python, if I remember correctly), but this is a good candidate.

What behavior do you have in mind exactly with the weak and strong versions of the flag that you are proposing? Don't hesitate to give examples. Thanks!

PS: here is what I understand from the tests you added:

• The weak version does not add parentheses if there is an exponent—because there are already parentheses before as in (1.0±0.1)e3.
• In all other cases (strong version, or original expression without an exponent), parentheses are added around the whole expression.

PPS: I therefore have a question: the strong version can always be obtained with the standard ({…}) format, right? In this case we don't need it, and we can provide only a p format for intelligent parentheses, that are not added around the expression if it already contains parentheses. What do you think?

[ep12]

Yes, that is what the flags should do, exactly!

PPS: I therefore have a question: the strong version can always be obtained with the standard ({…}) format, right? In this case we don't need it, and we can provide only a p format for intelligent parentheses, that are not added around the expression if it already contains parentheses. What do you think?

You are right! But if you prefer to write f'{x:RL}' rather than f'\\left({x:rL}\\right)', the strong version makes it very easy to switch from :L to :P, let's say. I think the first variant is more readable, concise and pythonic, because we do not have to deal with the low level stuff that makes things pretty in our document / browser. If you prefer to only have a weak flag, I'll change stuff and I guess that in this case you would prefer :p...?
Also, it would be interesting to know if the output of uncertainties is fully compatible with the siunitx latex package (#117). I basically want to have numbers with units (and with uncertainties). I might try some stuff out in search for a function that reliably outputs valid siunitx latex code... As always, I wish I had more free time... (I am trying to create a package that is for units what uncertainties is for uncertainties. Most unit system implementations (e. g. pint) can be easily tricked into outputting complete garbage or they cancel units out as expected but then they cannot express what they've got in composed units (N, Pa, V, T, H, ...). My mess of a playground is the physikpraktikum repo, a better version will hopefully be in my dataviz repo...)

However, tell me what you think is best!

[lebigot]

Good point, about the special LaTeX parentheses. A library is here to help people, and letting people write convenient code instead of reimplementing the same thing independently over and over is part of this. I am thus good with having a strong form of the new parentheses flag.

r and R for "round bracket" is the best option so far, so I'm good with it.

Let me have a look at the implementation (and documentation of the flag behaviors).

My conclusion about the SIunitx package (#117) is that it is best that it learn how to parse uncertainties with a decimal point, as in 123.4(5.6): this is the convention used in a major reference (the definition of fundamental constants).

[ep12]

@lebigot The builds are passing, should I try to implement this feature now?

[lebigot]

Ah, yes, good point, that would be great! Now is a good time.

[ep12]

The pull request passes the tests. Without the bugfixes that my previous attempt had, it is only +42 -4 lines (22 lines of documentation).

[lebigot]

Thanks a lot!

My weekends are taken by two children, and my evenings by some other project that I would like to finish, currently, but when my evenings clear up, I'll review this. I am sorry for the delay.

[lebigot]

I am checking the documentation updated in pull request #128.

I am sorry to come back to a point that we have discussed above, but I am not seeing anymore how forcing parentheses (with R) is useful. In a comment above, I got somehow carried away by the following example:

But if you prefer to write f'{x:RL}' rather than f'\left({x:rL}\right)', the strong version makes it very easy to switch from :L to :P, let's say. I think the first variant is more readable, concise and pythonic, because we do not have to deal with the low level stuff that makes things pretty in our document / browser.

I agreed that it is nice to let the user switch from pure text to LaTeX easily, and the idea of having uncertainties produce the \leftand \right looked good. Howeer, I can't see how forcing these parentheses can be useful in the first place. For example, in what circumstances can the the form ((2.0+/-0.10)e-01) (or its prettyfied LaTeX equivalent) be useful?

To summarize, I am wondering how relevant it is to have the strong flag (R). I understand that you were open to not having it, but before removing it I wanted to check with you.

[ep12]

Since this issue is 10 months old, I had to think a moment about that, to be honest.
It might be useful for having the values in parens in normal inline text:

f'Although our result ${result:RL)$ was close to the expected value, the uncertainty of it is relatively high....'

would produce (GitHub sadly does not support TeX, so it looks as if produced with {:RP})

Although our result ((1.60±0.23)×10⁻¹⁹) was close to the expected value, the uncertainty of it is relatively high....

(Of course, ... our result $\left({result:rL}\right)$ was ... would be relatively ugly...)

This could be used when the result was calculated elsewhere and this is the final conclusion let's say...

That is the only case I could come up with at this moment. There might be other ones or maybe not, I don't know.
It is so easy to implement that this could be left intact so that whenever someone needs it, it is there and can be used or the strong version could be removed to make the source code less bloated (~5 lines I suppose?).

It is totally up to you...

[lebigot]

Thanks for the feedback. These were precisely my thoughts (including the potentially larger parentheses in the LaTeX output). It's useful to know we think the same. I am more concerned about making the API more bloated, as this is what most people see, so I'll remove the unconditional flag (R).

This means that the "weak" parentheses can now be requested with a p flag, which is nicer.

I'll update the pull request as needed.

[lebigot]

Pull request updated and integrated in https://github.com/lebigot/uncertainties/releases/tag/3.1.5. Thanks!