Use sciform as a formatting backend for uncertainties

[jagerber48]

I use the uncertainties package for two things.

• Intaking value/uncertainty pairs that come from my data and performing algebraic manipulations on the value/uncertainty pair while having error propagation work on the numbers involved.
• Printing out those results, taking advantage of the uncertainties formatting options.

The former strikes me as the core functionality of the package. From the short description of the package:

Transparent calculations with uncertainties on the quantities involved (aka "error propagation"); calculation of derivatives.

The former functionality is also a mathematically and computationally challenging problem to get done well.

The latter regarding the display of value uncertainty pairs strikes me as useful nice-to-have feature while working with value/uncertainty pairs. The code to realize value/uncertainty formatting is not as algorithmically demanding as the core error propagation code. Rather, the formatting code is sprinkled with parsing many user options, doing various rounding, string manipulations, etc., adherence to published standards, and watching out for various edge cases like nan, or rounding changing the number of significant figures etc.

In short, I view the error propagation code and the formatting code as being very different types of codes. My general suggestion is that the formatting code should be moved out of uncertainties and delegated to a separate package which can be dedicated to implementing scientific formatting according to published standards and uncertainties. I suggest that this is a better separation of responsibilities.

---

Heavily motivated/inspired by uncertainties formatting, I wrote the sciform package. sciform is a package dedicated to formatting values and value/uncertainty pairs according to published scientific standards. It provides many relevant formatting options and a few workflows for implementing those options to format numbers into strings. Some relevant features for uncertainties

• sciform support ± formatting like 123.45 ± 0.67 and parentheses uncertainty like 123.45(0.67) or 123.45(67).
• sciform supports explicit control over the number of significant figures of uncertainty to display and formats the corresponding value accordingly. sciform can do this both for value/uncertainty pairs (like can be done with the ufloat now) but also for values alone.
• sciform supports engineering notation in which the exponent in scientific notation is coerced to be a multiple of 3. This is valuable for presenting data more compatibly with SI standards and can improve readability.
• sciform exposes a format specification mini-language (FSML) similar to the built-in FSML and similar to the uncertainties FSML.
• Automatic conversion to SI prefixes. A value/uncertainty pair like 0.000_012_345 ± 0.000_000_012 can be formatted as (12.345 ± 0.012)e-06, but sciform can also present it as (12.345 ± 0.012) μ. Users can then easily append relevant units for simple dimensional quantities to make μm or μs etc.
• Thorough documentation and testing to showcase the functionality and give confidence that sciform will behave as desired.

Many more features can be found in the documentation.

---

I would like to explore the idea of if uncertainties should migrate to using sciform as a formatting backend. Right now the ufloat object, at format time, calls a formatting functions that appear in core.py in uncertainties See AffineScalarFunc.__format__(). The suggestion would be that instead of calling internal uncertainties code the ufloat or AffineScalarFunc would import and call sciform code. A simple example implementation taking advantage of the sciform FSML would look like

from sciform import SciNum
...
class AffineScalarFunc(object):
    ...
    def __format__(self, format_spec):
        value = self.nominal_value
        uncertainty = self.std_dev
        return format(SciNum(value, uncertainty), format_spec)

where format_spec is a valid sciform format specification string. A quick reference example to demonstrate how this might work is

from sciform import SciNum

value = 0.0123456
uncertainty = 0.00012
print(format(SciNum(value, uncertainty), "!3r()"))
# 12.346(120)e-03

---

In addition, sciform allows global configuration of formatting settings to allow users to modify setting not accessible through the FSML (like upper/lower/decimal separator characters). uncertainties could expose something like set_uncertainties_formatting_options to allow users even more flexible formatting control if desired. Under-the-hood uncertainties would use a local sciform context or Formatter object to implement the user selected global options. Note that the global options apply for any options not explicitly specified by the user's format specification string. Any options selected by the format specification string overwrite the corresponding option in the global configuration.

---

The main caveat I will point is the following. I imagine the main way users will access formatting will be via f-string formatting on the ufloat object. If uncertainties were to migrate to the scinum FSML I have to point out that there are some backwards incompatible differences. See this section for a comparison between the sciform and python built-in FSMLs. The main points I will highlight:

• sciform always opts towards positive explicit control of all formatting parameters. For this reason sciform opted to not support e.g. the g formatting option which does some automatic work in the background to select exactly what options will be used when formatting numbers.
• sciform ONLY supports presenting value/uncertainty pairs by specifying the number of significant digits to display on the uncertainty. The value and uncertainty are always rounded to the same least-significant decimal place. Specifying digits-past-the-decimal-point is not supported because that sort of formatted is not recommended by official standards such as NIST or BIPM. sciform does support formatting individual numbers according to a number of digits-past-the-decimal-point but that is less relevant for uncertainties.
• sciform supports left padding either zeros or spaces between the most significant digit and the sign symbol so that a number is left-padded up to a certain user-specified decimal place (e.g. the millions place). sciform does not support padding by arbitrary symbols, and sciform does not support left, right, or center padding. sciform takes the view that these types of formatting can be applied to sciform output strings afterwards if the user has some need for the string to be a certain length or justified a certain way. sciform only takes responsibility for the numerical and scientific parts of the formatting, whereas sciform considers left/right/center padding to be a task generic to all python string objects and not specific to scientific/numeric string objects.
• There are other minor differences involving things like trailing decimal symbols, handling of 0, nan or inf inputs.

Adoption of the sciform FSML would likely mean breaking changes for uncertainties formatting so probably would not be suitable for an uncertainties 3.x release and would need to wait for a 4.x release.

That said, there is another way uncertainties could use sciform that is not just directly inheriting the sciform FSML. uncertainties could retain its same FSML and instead of using the format string to fully format the string, the format string would be parsed and used to construct a sciform Formatter object with the appropriate options which could in the end used to format the string using sciform. In this case there would still be breaking changes or uncertainties would still need to do a lot of the formatting leg work to cover cases which are impossible for sciform to handle.

All of this said, I was intentional about excluding features from the sciform FSML. If a feature isn't included it is probably because it goes against scientific formatting best practices and should probably be avoided anyways. So, despite the differences, if uncertainties can bear backwards incompatible changes to formatting, I think it would be a net benefit to uncertainties to outsource formatting to sciform.

Two final notes:

• sciform only supports python >= 3.9 right now because it internally uses some modern typing features. If it is important for sciform to support lower python versions this can likely be done pretty easy.
• If it would greatly benefit uncertainties, I am perfectly happy/open to discussing modifications to sciform for better compatibility.

Please let me know what you think or if you have any questions about sciform or how it could be used with uncertainties.

[lebigot]

The subject is interesting.

As a matter of principle, I'm for avoiding duplication of efforts (in this case, maintaining and possibly extended the formatting of numbers with uncertainty).

Formatting obviously belongs in a library that manipulates numbers with uncertainty, because users will often want to print them at some point. Now, how formatting is implemented can indeed be delegated to another library (with the advantage cited above).

Back around 2009, I did check best scientific practices in terms of number printing (including NIST's and the Particle Data Group's) and took them into account while writing the formatting code, so the situation shouldn't be too bad. Now, I fully appreciate that some users might want additional options, and again, being able to maintain the formatting of numbers with uncertainty in a single place will help with that.

Now, at this stage, it looks to me like a better option is to offer sciform formatting as a global formatting option in uncertainties:

1. There are some incompatibilities between the two FSML. This would hurt users of uncertainties (which are currently way more numerous than those of the much younger sciform).
2. uncertainties has all the listed features, except for the engineering formatting and unit prefixes (and global formatting options), so maybe importing these (through sciform) would be useful.
3. What about features like LaTeX output? I'm not sure if sciform offers the automatic selection of the number of digits to be displayed (e.g., there is not much need to print 1.23456789 for 1.23±0.11), which follows the recommendations of the Particle Data Group), but this is also a convenient feature.

And for reference: the formatting code was actually much harder to write than the rest! There are in fact many corner cases, that come from the interaction between formatting options (LaTeX, uncertainties in parentheses, the handling of NaN and inf, all within the constraints of padding, etc.). This makes the code also probably the hardest part of the package to read. This is where avoiding effort duplication can pay off, if it can be put in place.

Again, I feel that this is not so hard to do, for the reasons above. At this stage, offering sciform formatting as an option seems to be a good way of offering the best of both worlds to users, with minimal efforts. What do you think?

[jagerber48]

@lebigot, thanks for your thoughtful responses. I've been working out how to respond. I'll try to mainly focus on proposed paths forward. Note, I'm assuming these changes would be implemented on a 3.x -> 4.x changeover so that breaking changes are considered acceptable.

But first, yes, sciform supports things like PDG sig figs, LaTeX formatting, and other ways of selecting the number of digits to be shown. There are also some other features that may be of interest, but rather than list them out here, I'll direct you or anyone interested to the sciform docs for now. I can list them out in more detail here if desired.

Trying to figure out exactly what you mean by:

Now, at this stage, it looks to me like a better option is to offer sciform formatting as a global formatting option in uncertainties:

At this stage, offering sciform formatting as an option seems to be a good way of offering the best of both worlds to users, with minimal efforts.

By this do you mean there would be some package-wide global flag that selects either existing uncertainties style formatting or alternatively sciform style formatting? I agree this would be easy to implement, but it seems like it would require users to learn, or at least review, two different FSML/formatting tools?

Here's what I consider to be my favorite idea after brainstroming for a little. Rather than importing the sciform FSML directly, uncertainties continues to define its own FMSL but uses the FSML to construct a sciform Formatter object on the backend which is used to do the formatting. Basically the uncertainties __format__ function would serve as a translator between an uncertainties specified FSML and sciform formatting options. This idea would be a re-implementation of the fsml.py code in sciform but for an uncertainties specified FSML.

One big advantage of this is that the uncertainties FSML is decoupled from the sciform FSML. If the sciform FSML changes, the uncertainties FSML doesn't have to. uncertainties would only rely, on the backend, on the sciform Formatter.

The other big advantage is that uncertainties could make its own decisions about what options are important to include in the FSML. For example, sciform doesn't expose an options for the unicode superscript exponent mode, but uncertainties could if it wanted to.

That said, this approach wouldn't be fully backwards compatible without a lot of custom formatting still happening in uncertainties. This is because

• sciform doesn't support left/right/center padding based on overall string width. sciform tries to focus only on the numerical parts of formatting and not the string parts (like left/right/center padding)
• sciform doesn't support the g format mode, that is, autoselection of scientific or fixed point format mode
• sciform ONLY supports rounding by sig figs on the uncertainty. This means sciform only supports the uncertainties u mode, so in this proposal the u flag would probably become meaningless.
• sciform doesn't support the p flag which adds parentheses around (123+/-4).

---

One more point I'll make. It looks like uncertainties FSML was originally made to be compatible with the built-in FSML. However, it doesn't seem like it's fully compatible because (1) the built-in FSML just has some confusing edge case behaviors that are hard to duplicate and (2) some new built-in features have been added like # and z.

For existing incompatibilities see:

print(f'{123:.4g}')
# 123

print(f'{ufloat(123, 1):.4g}')
# 123.0+/-1.0

For the latter I would have expected 123+/-1 for compatibility with the built-in behavior, even though I consider 123.0+/-1.0 to be more sensible scientifically.

Since the existing FSML isn't fully compatible with the built-in FSML, and because I consider the built-in FSML to not have made the best choices for scientific formatting, I suggest uncertainties==4.0 breaks ties with the built-in FSML to make formatting configuration easier. I would suggest a regex like

r'''
            (?P<sign>[-+ ]?)
            (?P<comma>,?)
            (?:\.(?P<num_sig_figs>\d+))?
            (?P<type>[eEfFrR%]??) 
            (?P<options>[PSLp]*)  # uncertainties-specific flags
            $'''

or

r'''
            (?:(?P<left_pad_char>[ 0])=)?
            (?P<sign>[-+ ]?)
            (?P<left_pad_dec_place>\d+)?
            (?P<comma>,?)
            (?:\.(?P<num_sig_figs>\d+))?
            (?P<type>[eEfFrR%]??)  # n not supported
            (?P<options>[PSLp]*)  # uncertainties-specific flags
            $'''

If you want to include left padding by " " or "0" between the sign symbol and the most significant digit up to a user-specified decimal place like sciform does.

[jagerber48]

Some other comments:

1. sciform is still very young and doesn't have any users. I am still making breaking changes. So if uncertainties has some request that would make it easier to adopt sciform I'm more than happy to discuss that. One thing that comes to mind would be supporting decimal-past-the-digits place for formatting value/uncertainty pairs. Personally I don't like that option so I like to discourage it, but I can see where some users might expect it, especially given how the built-in FSML works.
2. For me the big question is, for uncertainties==4.0 will it be ok to make breaking changes.

• If no then I agree that some sort of sciform as an alternative but fully parallel formatting method seems viable, but this will require users learning or at least choosing between two things which is sort of an additional burden. Maybe better to just make improvements to the existing uncertainties formatting.
• If yes then the question is what can be broken? How should uncertainties formatting be redesigned?

I'm hoping the answer to "can we make breaking changes" is "yes". If that's the case then maybe a more productive direction for this conversation is "How should formatting be updated/redesigned for uncertainties==4.0" and then secondarily "can sciform be helpful with those updates".

I would be interested in the latter discussion I mentioned and I could list out some ideas I have.

[lebigot]

Yes, I was suggesting that users could set a global option in uncertainties and get sciform formatting (or the original unceratinties formatting). I think this would not really require users to learn two different formats: they would likely have a look at both options and choose one format and stick to it (like we do for many libraries).

I still like your favorite idea (uncertainties using sciform as a backend), but I was wondering (1) how easy it would be to do, especially given that (2) incompatibilities prevent a full transfer of responsibilities in the code. But I understand that you are aware of both. :)

As for some of the formatting behavior choices:

• uncertainties applies it to the nominal value and the uncertainty separately: this cannot be replaced by another step of string formatting. The idea is to more easily create "table-like" outputs of lists of numbers with uncertainty, with the ± sign is always positioned in the same place (if I correctly remember the final result). Some people might rely on this.
• Some people might also rely on the g format mode, of course. That said, I rarely if at all see this mode being used, though.
• The p flag for parentheses is definitely useful to some people.

Good point, about the g formatting incompatibility. If the g formatting type is kept, your example should be a unit test!

I personally don't mind breaking changes, but only as long as they can be mostly painless to users. This is a relevant point, for uncertainties, because of its sizable number of users.

Concretely, one can, in this case:

1. Print a warning (when a users uses formatting), 6–12 months in advance of any breaking change, indicating that the formatting will be updated to sciform (in the case we are discussing) in version xxx, and that support for the old formatting will be dropped.
2. Offer a relatively painless option to keep using the old formatting (such as a global flag).

How does this sound?

[jagerber48]

uncertainties applies it to the nominal value and the uncertainty separately: this cannot be replaced by another step of string formatting. The idea is to more easily create "table-like" outputs of lists of numbers with uncertainty, with the ± sign is always positioned in the same place (if I correctly remember the final result). Some people might rely on this.

This will be the trickiest to support with sciform. Here is how sciform approaches that issue. First of all, I've noticed a lot of effort is spent padding numbers so that they are easy to put in tables. To that end I highly recommend using a tool like tabulate which is designed to put numbers/strings into nicely formatted visual tables. It handles all of the padding and some other options so users don't have to do that themselves.

But, about getting the ± to always appear in the same position. I think this is the thing that sciform can't support since it doesn't allow digits-past-the-decimal formatting on value/uncertainty pairs. If it did then users could use a combination of digits-past-the-decimal formatting and left_pad_dec_place (essentially digits-before-the-decimal padding) to get strings of fixed length. It sounds like even in that case there may be limitations relative to what uncertainties can do. I'm interested to discuss this further. I'm open to adding digits-past-the-decimal formatting for value/uncertainty pairs in sciform. I'm still pretty reluctant to add left/right/center padding to the overall sciform output or to the value/uncertainty separately. I need to be convinced by use cases that aren't better solved by e.g. tabulate.

Some people might also rely on the g format mode, of course. That said, I rarely if at all see this mode being used, though.

This would also be challenging to support with sciform. Basically it would require a lot of lifting on the uncertainties to resolve how the formatting should happen. But again, there are a lot of quirks with the g formatting mode (like trailing zeros and decimal symbols) that I think are just better avoided. I would prefer that uncertainties not try to support the g mode and to encourage users to explicitly select fixed point or scientific notation (and number of sig figs or the sig fig resolution algorithm) for their formatting.

The p flag for parentheses is definitely #113.

It would be very easy to support this the way I'm imagining. it.

---

I personally don't mind breaking changes, but only as long as they can be mostly painless to users. This is a relevant point, for uncertainties, because of its sizable number of users.

Concretely, one can, in this case:

1. Print a warning (when a users uses formatting), 6–12 months in advance of any breaking change, indicating that the formatting will be updated to sciform (in the case we are discussing) in version xxx, and that support for the old formatting will be dropped.
2. Offer a relatively painless option to keep using the old formatting (such as a global flag).

How does this sound?

This seems fine for a transition involving breaking changes. The only thing I would add is to have a deprecation schedule even for the painless option to use the old formatting. The only reason we'd make a breaking change to the current formatting is we think we've designed something that is improved. If it really is improved I think the goal should be for all users to move to it eventually with enough warning.

[lebigot]

What is an example of "sciform doesn't allow digits-past-the-decimal formatting on value/uncertainty pairs"? I'm curious how it would affect users (who might rely on such a feature in uncertainties).

Also, would tabulate be able to offer both a nice formatting of numbers with uncertainties with a fixed location for the ± and the clean equal number of digits after the decimal point (as in 3.14±0.01) that uncertainties provides? This is the main reason why uncertainties offers padding too.

[jagerber48]

What is an example of "sciform doesn't allow digits-past-the-decimal formatting on value/uncertainty pairs"?

In uncertainties one can do

from uncertainties import ufloat

u = ufloat(123.456, 0.00789)
print(format(u, ".4f")
# 123.4560+/-0.0079
print(format(u, ".4uf")
# 123.456000+/-0.007980

In the first case the formatting rounds and displays to 4 "digits past the decimal point". In the second case the formatting rounds and displays to 4 sig figs.

In sciform we only have

from sciform import Scinum

s = SciNum(123.456, 0.00789)
print(format(s, "!4f"))
# 123.456000 ± 0.007890
print(format(s, ".4f")
# UserWarning: Precision round mode not available for value/uncertainty formatting. Rounding is always applied as significant figures for the uncertainty.
# 123.456000 ± 0.007890

In the first example the ! indicates that the following number is the number of sig figs to display. By contrast . indicates "digits past the decimal" or "precision" formatting (to use pythons nomenclature). These are two distinct options for doing value only (no uncertainty) formatting. However, sciform only allows sig fig rounding when doing value/uncertainty formatting. This is because scientific formatting is always based on sig figs. Where the decimal point falls is a quirk of whatever exponent happens to be chosen. I also don't want to allow

print(format(u, ".1f"))
123.5+/-0.0

Now all information has been lost about the uncertainty. Is it 0.01? or 0.000001?

All of that said, I think digits-past-the-decimal-point formatting is an expected feature and it has come up a couple of times as an oddity of sciform to not have it for value/uncertainties formatting. When I get time I'll link a sciform issue or PR where I've been working on it. digits-past-the-decimal formatting is also important for the next part of this comment.

---

So what tabulate can do is it can take a set of strings that appear in a column together, figure out the widest one, and then pad all of the strings to be the same width, and also have some whitespace, so they fit nicely in an ASCII/unicode table. If you are passing in floats it can, if requested, intelligently line up the decimal symbols. I don't know if it has the ability to line up against an arbitrary character like ±.

I'm not sure what you mean by "the clean equal number of digits after the decimal point". sciform ALWAYS rounds and formats the value and uncertainty to the same number of digits after the decimal point (unless the least significant digit of the uncertainty selected is greater than unity). The difference is that, right now, sciform only allows you to select the number of digits based on the number of sig figs requested. You can't explicitly select a number of digits past the decimal point to display.

But yeah, what sciform can't provide is the ability to line up the ± symbols of different value/uncertainty pairs. To do that you need to control the number of decimal points to the left and right of the decimal point. sciform allows control over the number of digits to the left of the decimal point, and the number of digits to the right of the most significant digit of the uncertainty. So, this is the main mark in the "pros" column for allowing digits-past-the-decimal-point formatting.

Part of me wonders how valuable it is to line up the ± symbols for numbers that have varying orders of magnitude or precision. I think I want to mock up some examples to see.

I would really like a response to the 123.5+/-0.0 issue.

[lebigot]

Thanks for giving an example of what you meant by "digits-past-the-decimal formatting": things are clear, now!

I'm not sure how many people need to set a specific number of digits past the decimal point, for numbers with uncertainties. I mostly offered support for the f format so that existing code can also run with numbers with uncertainties (and not only floats). In practice, now that uncertainties is a well-established package, most code is probably designed to work directly with uncertainties: this makes keeping the semantics of the f format (fixed number of digits after the decimal point) less important.

I guess that not many people use uncertainties' separate padding of the nominal value and uncertainty. At worst, users could approximate the same effect by using the tabulate module… if they can individually access the formatted nominal value and uncertainty (which is not something uncertainties provides yet, but that could in principle be added: (nom_val_str, uncert_str) = formatted_parts(x, format)).

As for your point about "±0.0" (if I understand it correctly): in order to distinguish between a strictly 0 uncertainty and an uncertainty displayed as "0.0", uncertainties officially prints 0 for uncertainties that are exactly zero:

>>> print(f"{ufloat(12.34567, 0):.1f}")
12.3+/-0
>>> print(f"{ufloat(12.34567, 0.01):.1f}")
12.3+/-0.0

That's the best convention I could find that gives a hint about the real value of the uncertainty.

Now, if uncertainties always show at least 1 digit (like in sciform I guess?), then ±0.0 always means that the uncertainty is zero. However, this relies on the knowledge that it was printed with sciform and that this is how sciform behaves, which readers of the final output might not know.

[jagerber48]

That's the best convention I could find that gives a hint about the real value of the uncertainty.

Now, if uncertainties always show at least 1 digit (like in sciform I guess?), then ±0.0 always means that the uncertainty is zero. However, this relies on the knowledge that it was printed with sciform and that this is how sciform behaves, which readers of the final output might not know.

Right, I think with sciform I was uncomfortable with this convention that 0.0 means the uncertainty was truncated where as 0 means actually 0. Thinking about your point about "However, this relies on knowledge that it was printed with...". I would say the current uncertainties convention requires knowledge that it was printed with uncertainties. That is, a scientist who knows nothing about python or uncertainties would read 12.3+/-0.0 as there being exactly zero uncertainty. They would wonder how a number has zero uncertainty, maybe it is a defined number rather than measured. Or maybe it's a mistake. This is because the scientific convention doesn't allow for truncating the uncertainty above the most significant digit of the uncertainty for any reason.

So yes, switching to 0.0 always means zero might be a change for those familiar with uncertaintys existing conventions, but I think it's a move towards a more standard convention.

But I'll re-emphasize, the downside of accepting what I call the "science convention" is that digits-past-the-decimal formatting doesn't really make sense anymore. I argue that this is ok, because in science we should be thinking about sig figs, not digits-past-the-decimal. But it's a downside because python users are likely very familiar with using formatting like .2f to control the display of their floats.

Another point worth mentioning is how rounding/truncation of the value should be handled when the uncertainty is invalid. For example, suppose a user has something like 123.456 +/- 0.023. That is, displayed with two significant figures of uncertainty. Then say they have another value like 234.82937432 +/- nan. How should the latter be formatted? Should the formatting revert to now displaying two significant figures of the value so that we get 230 +/- nan? When using digits-past-the-decimal formatting this is a non-issue because the value and uncertainty are both formatted to the same digit past the decimal regardless of the magnitude of either.

[jagerber48]

However, with everything said, I would like to shift this discussion from "how can sciform be used as a formatting backend for uncertainties" to "in what ways can uncertainties formatting be improved". Once we answer that latter question I think we can start to think about how sciform fits in.

So for my next post I'll try to make a list of improvements I would like to see for uncertainties formatting. In the meantime, I would like to see some use cases where string widths matter. I think I can imagine them so I'll try to make some myself if I don't see any otherwise.

[jagerber48]

How can uncertainties formatting be improved? Obviously these suggestions are picked from features sciform has available, but I think it's a good framing for figuring out how to move forward with improving uncertainties formatting.

Note that this conversation is irrelevant if uncertainties decides to eventually accept sciform formatting wholesale. In that case we would just have

from sciform import SciNum

class UFloat(...)
    ...
    def __format__(self, format_spec):
        return f'{SciNum(self.nominal_value, self.std_dev):{format_spec}}'

probably also exposing something like sciform.set_global_options as well. In that case uncertainties just makes all the same decisions that sciform makes.

But, in the likely event uncertainties doesn't want to make all the same decisions that sciform makes, here are some of my suggestions for what decisions/improvements could be made.

---

First some features I consider to be relatively important

1. Support engineering notation. Possibly "shifted" engineering notation as well.
2. Support explicit setting of the exponent value.
3. Support upper/lower/decimal separator configuration.
4. Support parentheses uncertainty notation like 123.456(0.023) (this format appears in the BIPM guide).
5. Abandon the goal that the uncertainties FSML is a conservative extension of the python built-in FSML. There are examples today where (1) uncertainties gives different results than the python built-in FSML or (2) uncertainties doesn't support various python built-in format specification strings.
6. In line with 5. above, drop support for the awkward g formatting mode.
7. Support for numbers with precision beyond that of floats (~15-16 digits of precision) by using Decimal in some places. (This goal may extend out beyond the scope of just formatting). This is relevant for e.g. precision measurement folks who are pushing the limits of measurement and who care very much about uncertainty.

Next some features I could take or leave

8. Support SI prefixes (this may or may not be of interest, I'm on the fence about if this is a nice feature or not).
9. Support HTML output format.
10. Support latex and HTML hooks for ipython

---

Then there's a question that concerns a few possible changes (don't know if they're improvements or not).

sciform is pretty unfriendly to users trying to "align things" while formatting numbers. sciform takes the point of view that a scientific formatter should worry about formatting a value or a value/uncertainty pair according to published standards and that it should not worry about the relative alignment of characters within the resulting string. This bias shows up in a few places:

• sciform always has a preference for significant figure rounding. For value formatting it is the default and for value/uncertainty formatting it is the only option. Significant figure rounding means that it is basically random, depending on the order of magnitude of the number being formatted, where the decimal will line up in the string. Contrast this with "digits-past-the-decimal" formatting (which python built-in FSML seems to prefer) which strictly controls the number of digits after the decimal place. This means the number of characters between the decimal symbol and the end of the string is probably well-controlled. sciform takes this bias towards significant figure rounding because I think that the number of significant figures is likely more scientifically meaningful than the number of digits that are incidentally past the decimal point (due to the order of magnitude of the number and the exponent/units it happens to be expressed in).
• sciform does not provide any functionality to pad its results to a specified character width. The only padding it provides is the ability to left pad between the sign symbol and the most significant digit up to a specified decimal position. Again, it focuses on numerical aspects of the formatting, not string/alignment aspects of the formatting. There is an option to pad both the value and the uncertainty to the same decimal position.

If users really want alignment then sciform urges them to use other tools after the fact. For example tabulate can put numbers in a table regardless of their width. If users really want decimal or plus/minus symbols aligned then they could write a function that calculates the position of alignment symbols within a list of formatted number strings and left/right pads the strings accordingly so the symbols line up. They could also, if they are doing value formatting, align things manually by specifying how many digits past the decimal point to display and what decimal place to pad up to. This option currently isn't available for uncertainty formatting without digits-past-the-decimal rounding, but I'm considering adding it (#170).

If uncertainties were to take these points of view then I would suggest:

11. Make the uncertainties u formatting mode (which applies rounding based on sig figs on the uncertainty) either the default formatting mode (and have another flag to re-enable digits-past-the-decimal rounding mode) or only available formatting mode. This would probably end up in the u flag being removed. I'm a little sad about this because the u flag is, for me, part of the "brand" of the uncertainties package.
12. Drop support for character-width formatting that was inherited from the python built-in FSML.

[jagerber48]

Note that one reason sciform currently disallows digits-past-the-decimal rounding is because it could result in a printed output of 0 uncertainty even when the uncertainty is non-zero. e.g. if digits-past-the-decimal rounding was allowed I would expect

from sciform import Formatter

formatter = Formatter(round_mode="dec_place", ndigits=3)

print(formatter(123, 0.00002))
# 123.000 ± 0.000

Instead of (in "sig_fig" round mode)

from sciform import Formatter

formatter = Formatter(round_mode="sig_fig", ndigits=3)

print(formatter(123, 0.00002))
# 123.0000000 ± 0.0000200

[andrewgsavage]

Support for numbers with precision beyond that of floats (~15-16 digits of precision) by using Decimal in some places. (This goal may extend out beyond the scope of just formatting). This is relevant for e.g. precision measurement folks who are pushing the limits of measurement and who care very much about uncertainty.

I'm still unsure on the value of implementing Decimal. Searching decimal in this repo suggests it hasn't been requested by anyone so far. I also wonder whether people interested in 15 digits should be using this library; from the user guide

More precise uncertainty estimates can be obtained, if necessary, with the soerp and mcerp packages. The soerp package performs second-order error propagation: this is still quite fast, but the standard deviation of higher-order functions like f(x) = x3 for x = 0±0.1 is calculated as being exactly zero (as with uncertainties). The mcerp package performs Monte-Carlo calculations, and can in principle yield very precise results, but calculations are much slower than with approximation schemes.

there is another approach I saw that used ML libraries, I'll have to find it again as it would be good to add to the docs here.

[jagerber48]

I’m not sure if that comment in the docs is refereeing to the literal precision of the uncertainty (I.e. how many digits are necessary) or just more statistically accurate uncertainties calculations.

Nonetheless, I agree that we should not “eagerly” implement ‘Decimal’ support in uncertainties. We should only even consider implementing it if someone ever requests it. My field is close to the precision metrology fields so I’m just aware that there is at least a set of people who care a lot about uncertainty and need a lot digits so I could see the need arising one day.

Anyways, all of that said, my proposal 7 should be demoted from relatively important to a feature I could take or leave.

[lebigot]

Side note: f'{SciNum(self.nominal_value, self.std_dev):{format_spec}}' is arguably more directly implemented as format(SciNum(…), format_spec), as this is the raison d'être of format(), which should therefore be the one in "There should be one—and preferably only one—obvious way to do it." 😉

[lebigot]

About the quote from the uncertainties User Guide cited by @andrewgsavage: it refers to more accurate values of the uncertainty (for example, $x^2$ for $x = 0±…$ gives 0±0, with uncertainties, which is an imperfect approximation of the true result).

[newville]

@jagerber48 @lebigot Sorry that I have not had time to keep up with this detailed conversation. I agree with @jagerber48 when in saying in the original post:

In short, I view the error propagation code and the formatting code as being very different types of codes. My general suggestion is that the formatting code should be moved out of uncertainties and delegated to a separate package which can be dedicated to implementing scientific formatting according to published standards and uncertainties. I suggest that this is a better separation of responsibilities.

sciform seems to be doing the formatting part well and appears active and moving in the right direction, and uncertainties might do well to either focus on the more mathematical aspects, leaving more detailed formatting options to the user (and recommending sciform).

There is sort of a lot of code in uncertainties/core.py about formatting values to strings. It is clearly well thought out, and I do not have any complaints about its results. But, maybe moving that code to a separate file, say formatting.py would be better, and also allow for alternative formatting approaches, say sciform if available (perhaps: don't require, but use if available?).

Aside from how to best express precision and the number of significant digits in the printed form, there is a related question of what should __repr__ methods of Variable/AffineScalarFunc/UFloat should give. According to the official docs (https://docs.python.org/3.8/library/functions.html#repr):

Return a string containing a printable representation of an object. For many types, this function makes an attempt to return a string that would yield an object with the same value when passed to eval(), otherwise the representation is a string enclosed in angle brackets that contains the name of the type of the object together with additional information often including the name and address of the object. A class can control what this function returns for its instances by defining a repr() method.

That suggests that

>>> from uncertatinties import ufloat
>>> x = ufloat(3, 0.2)
>>> repr(x)
'3.0+/-0.2'

could return ufloat(3.0, 0.2) instead (regardless of precision used). That is, a ufloat is an object that can be expressed well by a string that will re-create it.

I don't think anyone is complaining about the current rendering, but it is worth re-deciding whether repr for this should be nominal+/-std_dev or ufloat(nominal, std_dev). I think both have merit.

With repr(x) giving nominal+/-std_dev, it is also somewhat curious that ufloat('3.0+/-0.2') gives a deprecation warning about support for that syntax is going away. If nominal+/-std_dev is the representation of the ufloat, shouldn't that "round trip" work?

[jagerber48]

although, maybe we can have that {self.class.name} just be ufloat, or UFloat, but not Variable or AffineScalarFunc ;)

Sure, we can do whatever makes sense here. I haven't had time to familiarize myself with the compare/contrast on those 4 classes.

FWIW, I have no opinion between 3.0+/-2.0, 3.0 ± 2.0, or 3 ± 2. I am okay with adding a trailing '.0' when the input was an integer.

Generally, in programming it seems floats are displayed with a trailing zero or a trailing decimal point to distinguish them from ints. However, scientifically, we don't distinguish between ints and floats. Rather, in science, we expect our measurement outcome (estimator) to be a real number with a real number uncertainty. In this case there is no value in leaving trailing decimal symbols or trailing zeros to indicate a number is a float/int, that is a programming/computing detail, not a detail relevant for the science. The right thing to do here (according to scientific formatting standards like those published by BIPM) is to round the uncertainty to typically one or two sig figs, round the value to the same number of sig figs and display both the value/uncertainty to the rounded digit. This is one of a few points where the built-in FSML seems targeted more towards programming and less towards science and is one a few things that contributed to my breaking with the built-in FSML when writing sciform and the sciform FSML.

The question remains, when the user doesn't specify how many significant digits of the uncertainty to show (or how many digits-past-the-decimal to show), where should the formatter round to? One option would be to round to 1 significant digit of uncertainty in this case. A more verbose option, and the option I took in sciform would be to round the float to exactly as many digits as needed for the float to round trip to a string and back. For the float 3.0 this means we only need to display 3. I go into some more detail about this here.

And then more minor points: In sciform I made the decision to use ± all the time unless the user uses a certain exposed post-formatting method to convert it to the ASCII +/-. I would recommend uncertainties similarly prefer ±. Finally, I'm 80% sure it is standard to include spaces around the plus/minus symbol. The examples in NIST/BIPM documentation include them, I could dig to see if this detail is explicitly called out anywhere. These are minor details, but I'm just including them here for completeness.

I would be +1 on aiming to handle higher precision than 64-bit floats when possible, but casting ints to doubles on input by default seems completely reasonable too.

Perhaps we need a separate discussion on handling higher precision than 64-bit floats. There are two questions. First, should the core math support higher precision? That may or may not require large changes to the codebase and it likely has major performance considerations. I've never benchmarked it, but I understand math with Decimal is much slower than math with float. The second question is should the formatting support higher precision? Having the formatting support higher precision but the math not support higher precision might be a little bit strange and the use cases would be slim. I guess if a user had a high precision number in hand they could manually input it to the formatting to take advantage of the formatting (similar to if they were just using sciform directly instead of uncertainties), but we'd need to give a warning or NotImplementedError or something if they tried to do math on it that they will lose precision. I guess I'm +0 on this one, it would be nice but there are higher priorities.

With that basic repr, I would be much more comfortable (and supportive!) with adding formatters so that users could do something like from uncertainties.formatting import formatter, latex_formatter, html_formatter, and so forth to nicely render variables with uncertainties with a variety of formatting choices, including using sciform if it was available.

Good to know. Yes, this approach of importing a formatter (like in sciform) as opposed to strictly using the FSML would be easy to implement with sciform totally in parallel with the existing formatting. This is the same as one of the options lebigot suggested above.

[lebigot]

That's an interesting discussion.

@newville: ufloat('3.0+/-0.2') gives a deprecation warning because it is not anymore supposed to accept strings: I find strongly variable argument types (such as allowing both a string and calling ufloat(3, 2)) to be confusing for users, especially in a language dynamically-typed language like Python: knowing whether ufloat(x) is an error requires parsing some indefinite amount of code, so I preferred only recognizing ufloat(x, y).

@newville: about repr() giving x±y or ufloat(x, y):

• It looks to me like the current documentation should be updated: the representation should give the same value when passed to uncertainties.ufloat_fromstr() (not eval()).
• While using ufloat(…) for the representation is fine in terms of round-trip parsing with eval(), a downside is that printing objects that contain numbers with uncertainties regularly involves their Python representation: for users, ufloat(x, y) is less directly legible than x±y.
• In conclusion, I vote for:
  1. Updating the documentation so that it mentions that repr() strives to be compatible as much as possible with uncertainties.ufloat_fromstr() instead of eval().
  2. Keeping x+/-y (or the breaking x±y, at some point) for the representation.

@jagerber48: some warnings:

• A warning: the format string {self.__class__.__name__}(…) doesn't work: one cannot create an AffineScalarFunc (or UFloat) this way, as the uncertainty of a number with uncertainty is not represented internally as a number (instead, the number with uncertainty is represented as an affine scalar function of its variables, which is needed for keeping track of all the dependencies in these variables, during a calculation).
• Using repr(self.nominal_value) is actually necessary when printing the repr() of a number with uncertainties: otherwise you print the string representation, which is equivalent to the g format, which itself truncates digits (which goes against the spirit of the representation of an object as opposed to its string form: as much information as possible should be preserved by repr()).

Number of digits in 3±2 vs 3.0±2.0:

• 3±2 is fine in my eyes if the two values are exactly integers. This should rarely happen, so I'm not sure it's worth making an exception to the usual format 3.0±2.0 (which should clearly indicate that some digits are hidden): this can make, say, printed arrays a bit strange (irregular in their formatting).
• Maybe it's also a recommendation of the Particle Data Group (which I followed)?

@jagerber48: about the more general question of the default number of digits to print:

• This was given a notable and very clear response by the scientific community through the Particle Data Group (typically, show the minimum number of digits required by the uncertainty, and maybe 1 more so as to display some more precision on the uncertainty, based on some precise rules). This is what I implemented in uncertainties—because I had scientists in mind (not programmers).
• I think that this is a very sensible choice, so I'm not sure to see what should be changed in the default printing behavior of uncertainties (which required investigating best scientific practices, and carefully deciding about edge cases: this was not an quick and easy task, so there is value in the current behavior).
• As a side note: I would expect the automatic (default) choice of the number of digits to print to be the most commonly used display feature of uncetainties (since it is the default when printing, and is arguably the most practical in the context of numbers with uncertainties): changes should be considered with care!
• @jagerber48, how does the above mesh with "round the uncertainty to typically one or two sig figs", for example in cases like 123456±7890, or 0.120±0.019, or 0.12±0.01?

@jagerber48As for spaces around ±, for what it's worth, the AMA Manual of Style recommends thin spaces around ±, but can't fine any consensus on the question. For the sake of conciseness, and also more importantly for visually grouping together values when printing in Python, I personally prefer the no-space variant (e.g., in a list of numbers with uncertainty, you isolate these numbers much more easily, with x±y: [1 ± 2, 2 ± 3…] vs [1±2, 2±3…]).

@jagerber48: As for supporting alternative (scalar) numbers to float (like Decimal), I'm guessing that most of the code should work as is. The formatting code of uncertainties might too, I guess (depending on how these other scalar numbers are displayed with the usual formatting mini-language). I believe that semantics of the current uncertainties formatting mini-language should work directly with numbers with a higher precision.

@newville, @jagerber48: maybe I'm not understanding properly, but from uncertainties.formatting import formatter, latex_formatter, html_formatter seems very heavy compared to using a formatting mini-language (as is doable with sciform and uncertainties)? I'd be curious to see better what you are suggesting.

[jagerber48]

@lebigot interesting. A lot to think about here. Ok, I had naively been thinking ufloat was a class but I now realize ufloat is actually a function, so yes, it's questionable if ufloat(x, y) makes sense for repr. I need to study more the relationship between ufloat, Variable and AffineScalarFunc and UFloat for my own understanding before I can comment further. Maybe just UFloat(x, y) like newville suggested is exactly the right move. Nonetheless, the point I do want to drive home is that, based on my understanding __repr__ is supposed to give an unambiguous string representation of the object (so that if two instances of the object are unequal their reprs will be unequal) where round tripping with eval is nice but not required, whereas __str__ is meant to give a human-readable representation. So I would suggest that __repr__ should include all of the gory digits stored in the value/uncertainty. That way repr(ufloat(3.1, 0.1)) and repr(ufloat(3.1, 0.1000001)) are different while str(ufloat(3.1, 0.1)) and str(ufloat(3.1, 0.1000001)) might be the same depending on the rounding rules we want to use for the default formatting (e.g. they would be the same if we used PDG rounding rules as the default).

Using repr(self.nominal_value) is actually necessary when printing the repr() of a number with uncertainties: otherwise you print the string representation, which is equivalent to the g format, which itself truncates digits (which goes against the spirit of the representation of an object as opposed to its string form: as much information as possible should be preserved by repr()).

Ah, yes, exactly. Good point. Ok that helps explain my subconscious desire to reach for repr(nominal_value). Thank you.

---

Number of digits in 3±2 vs 3.0±2.0:

• 3±2 is fine in my eyes if the two values are exactly integers. This should rarely happen, so I'm not sure it's worth making an exception to the usual format 3.0±2.0 (which should clearly indicate that some digits are hidden): this can make, say, printed arrays a bit strange (irregular in their formatting).
• Maybe it's also a recommendation of the Particle Data Group (which I followed)?

Under scientific formatting, I don't like the idea that "3.0±2.0 (which should clearly indicate that some digits are hidden)". Under scientific formatting it is understood that the uncertainty has been rounded to some position (typically 1 or 2 sig figs), the value has been rounded to the same position, the numbers are displayed to that decimal place. If I say "3±2" is the result of my measurement that doesn't mean I was measuring an integer, it just means that in the units selected the uncertainty has a magnitude of 2.0 and I am choosing to display the uncertainty to one significant figure. It is a programming convention that integers are always shown without a decimal point and floats are always shown with a decimal point to delineate the difference. But I fairly strongly think that a scientific formatting algorithm should NOT inherit this programming convention.

So under the PDG convention as the default formatting we would have

print(str(ufloat(12.34567, 2.345))) #  12±2 PDG says to keep 1 sig fig
print(str(ufloat(12.34567, 4.321))) #  12.0±4.0 PDG says to keep 2 sig figs
print(str(ufloat(12.34567, 9.876))) #  12±10  PDG says to round then keep 2 sig figs, this is different than just round to two sig figs

So in some cases the trailing decimal/zero will be present and in some cases not, depending on the magnitude of the uncertainty. I'm fine with this approach because the rounding is driven by scientific standards, not programming conventions. I would also be fine with always rounding to one digit of uncertainty for simplicity so

print(str(ufloat(12.34567, 2.345))) #  12±2
print(str(ufloat(12.34567, 4.321))) #  12±4
print(str(ufloat(12.34567, 9.876))) #  10±10  Note that one sig fig of uncertainty here means we are rounding to the 10s place

Or always retaining enough digits of uncertainty so that the uncertainty round trips (as a float) to string and back and rounding the value to the same place:

print(str(ufloat(12.34567, 2.345))) #  12.346±2.345
print(str(ufloat(12.34567, 4.321))) #  12.346±4.321
print(str(ufloat(12.34567, 9.876))) #  10.346±9.876

I actually have no preference between these three options. sciform uses the last option but I don't necessarily think that is the best default.

---

@jagerber48: about the more general question of the default number of digits to print:

Addressing the points below this. As I said above, I think in my previous I might have suggested showing all digits as the default but like I said in this post, I'm just as happy to use the PDG convention to select the default number of digits to display (at least when the uncertainty is non-zero and finite). It sounds like that is your preference and how uncertainties has been previously, so let's keep it that way.

---

@jagerber48 As for spaces around ±,

Interesting about the AMA recommendation. My opinions here are not strong. The BIPM examples seem to include a thin space around the ± symbol also, so in sciform I opted to have a space by default. I would be happy to have this be a configurable option that defaults however you like. If you prefer no space it can default to no space. A crazier idea is we could actually use the unicode thin space character rather than regular spaces, either by default or optionally. I personally think this is overkill though and would be confusing. My vote is to have a user-configurable option for no space or full space. If your preference is for it to default to no space that is fine with me.

---

@jagerber48: As for supporting alternative (scalar) numbers to float (like Decimal), I'm guessing that most of the code should work as is.

That's good to know. Still I think this is pretty low priority until there is actually demand for it or we get through a long list of other higher priority tasks.

---

@newville, @jagerber48: maybe I'm not understanding properly, but from uncertainties.formatting import formatter, latex_formatter, html_formatter seems very heavy compared to using a formatting mini-language (as is doable with sciform and uncertainties)? I'd be curious to see better what you are suggesting.

So when I originally wrote sciform, inspired by uncertainties, I tried to basically write a new FSML that

• was an extension of the built in FSML like the uncertainties FSML,
• had the same features as the uncertainties FSML,
• and had even more features (like engineering format at the time).

However, as I was working I realized that (1) for scientific formatting I didn't actually want all of the features of the built-in FSML, and that, in my opinion, some of those features get in the way of simple scientific formatting and (2) I wanted more features than could be succinctly captured in an FSML. Actually that second idea was prompted by this post from Mark Dickinson who is, I think, one of the maintainers of authors of the python built-in FSML.

So the point is, if there get to be very many formatting options it is better to break it into a function call that can accept many options. Or, another strategy, is to have a slim FSML that controls some options, but to have a global configuration context that can be used to control options that couldn't fit into the FSML. For example, in sciform the SciNum FSML can not control the separator characters but these can be controlled by setting global options or entering a global options context. For uncertainties I think I would recommend this second approach. There is a slim FSML with the possibility of modifying further options in a global context. No need for formatter objects. If users want to use a full-blown Formatter object then at that point they could just reach for sciform...

[lebigot]

About the number of displayed digits in string (not representation) form:

• I did my best to implement the PDG convention, so I'm surprised that 12.34567±2.345 should be represented as 12±2 (print(ufloat(12.34567, 2.345)) gives 12.3+/-2.3). Since you have looked at this more recently than me, maybe you can quote the relevant part of the recommendation? That would inform unit tests for formatting.
• Side note: I don't mind printing a decimal point for all numbers with uncertainties (mostly because integers should be rare), but the argument about integers without decimal points being for programmers is not fully correct: that's an extremely common convention both in mathematics and everyday life. Concretely, I think it's best to use other arguments. 😉
• Python side note: print(str(…)) should really be print(…), since print() converts to strings automatically.

About spaces around ±: I'll let you guys choose what you prefer. I agree that using thin spaces is not the best idea: this is not obvious, in a terminal, and people will scratch their head if they try to parse printed numbers with uncertainties with regular spaces (and I'm saying this as someone who does use thin spaces!). Since I can vote: I like having a global variable AROUND_PLUS_MINUS or something like this, with a sensible default (probably a regular space).

[jagerber48]

@lebigot

I did my best to implement the PDG convention, so I'm surprised that 12.34567±2.345 should be represented as 12±2 (print(ufloat(12.34567, 2.345)) gives 12.3+/-2.3). Since you have looked at this more recently than me, maybe you can quote the relevant part of the recommendation? That would inform unit tests for formatting.

It looks I got the rules for PDG formatting backward in at least a couple spots in my post above. I agree that 12.34567±2.345 should show up as 12.3±2.3 since the rounded top three digits of the uncertainty are 234 (round to even) which is between 100 and 354. Thanks for pointing out my mistake.

But anyways, the main point of that whole section was that I see three possible default formats for displaying UFloats as strings.

• Using PDG uncertainties rules on the uncertainty
• Showing a fixed number of sig figs of the uncertainty (e.g. 1 or 2)
• Showing as many digits of the uncertainty as necessary so that the uncertainty string round trips to a float and back.

I'm curious for opinions as to which of these three options should be preferred. My opinions are very weak. If I had to choose I would vote for showing 2 sig figs of uncertainty by default, but with e default option user-configurable. I think PDG sig figs can be valuable but I find always using a fixed number of sig figs to be less surprising, especially for someone unfamiliar with the PDG convention. It's also not clear to me, mathematically, what is really the advantage of the PDG convention over choosing a fixed number of sig figs. But if anyone has a stronger opinion towards any of these three options I'm happy to go with that.

Side note: I don't mind printing a decimal point for all numbers with uncertainties (mostly because integers should be rare), but the argument about integers without decimal points being for programmers is not fully correct: that's an extremely common convention both in mathematics and everyday life. Concretely, I think it's best to use other arguments. 😉

Do you mean that 9±5 should be reformatted as 9.0±5.0 or that it should be reformatted as 9.±5.? I'm pretty strongly against the latter. I can't find explicit official guidance against including a "hanging" trailing decimal point. The closest I find is NIST guide to the SI, sec 10.5.2 which recommends against a hanging leading decimal point. That is it encourages 0.25 over .25. But no example I've seen in any BIPM, NIST, or PDG documentation includes a hanging trailing decimal point, so I don't think uncertainties should either.

As for 9.0±5.0. I'm also opposed to arbitrarily adding the extra sig fig just to have a decimal symbol appear. For example, doing so in this case breaks the PDG sig fig rules which recommend one sig fig for a last three digits of 355 <= 500 <= 949.

Adding the rule "a decimal point is printed for all numbers with uncertainties" necessarily complicates any other rules we impose so I recommend against it. Science quantities don't distinguish between reals/floats and integers. There are just numbers with uncertainties expressed with some exponent, and we just show an appropriate number of sig figs and add other formatting symbols (like decimal points) as necessary.

Since I can vote: I like having a global variable AROUND_PLUS_MINUS or something like this, with a sensible default (probably a regular space).

Seems fine to me. Seems no opinions here are strong. We can take this as the tentative agreed upon opinion for spaces for now.

[andrewgsavage]

But, maybe moving that code to a separate file, say formatting.py would be better, and also allow for alternative formatting approaches, say sciform if available (perhaps: don't require, but use if available?).

This is something I'd like to do too, unrelated to sciform, as it reduces file size somewhat

[jagerber48]

Yes, this is straightforward and will make editing the other code in the core module (and breaking that into more modules) more pleasant. I can open a PR for this when I get the chance.

I also want to highlight this old issue #162 and PR #167 where (1) not all of the formatting tests were actually getting run and (2) some of the "secret" tests, when they do run, actually fail or it is isn't clear what their result should be.

I think the two issues are orthogonal though and the test issue doesn't need to block moving the code. As long as the same tests run and pass after the move it should be fine, and the tests can be handled separately.

[jagerber48]

See #198 for moving formatting code into its own module. Something similar should be done for input parsing code but I haven't looked as closely at that code yet. I'll have it on my radar.