Adopting a Object-Oriented way of printing the ufloats [Enhancement]

[Xyhlon]

Is it possible to convert the current api to an object oriented approach, like sympy see here.

This could allow people to write their own printers and lets them customize every aspect of the representation of the nominal value and the standard deviation.

Reasons:
The current implementation of Shorthand is incorrect see nist and for a better explanation the corresponding physics stackexchange post.
eg.
4.5(1.3)e6 should be 4.5(13)e6
or 11.7(1.7) should be 11.7(17)

Furthermore the possibility of printing the nominal value separated by a delimiter would be great. This would allow people to export uarrays to csv, tex_formatted tables and databases with fiddling with afterwards with the outputted string from ufloat.format("")
(nom_val+/-std_dev)common_exp ---> nom_val common_exp delimiter std_dev common_exp
eg.
11.7+/-1.7 --> 11.7,1.7
(4.5+-1.3)e6 --> 4.5e6,1.3e6

At last the current behaviour of printing doens't need to change it could still produce the same output by default, yet make the process more flexible

[jagerber48]

I'm also interested in somewhat of a modernization of the string formatting code but have some thoughts on what you say.

• I'm curious for more details about what you mean about an "object oriented approach" to the printing api. It sounds like you would like to have access to function which convert values + uncertainties into strings which have function inputs to configure the options as opposed to always having to specify options through the format specification string? I think this would be valuable.
• The issue with shorthand can probably be easily corrected IF a standard format is agreed on. Your links don't thoroughly convince me that NIST recommends 4.5(13)e6 over 4.5(1.3)e6. The wording is "where it understood that the number in parentheses is the numerical value of the standard uncertainty referred to the corresponding last digits of the quoted result." If I had to guess I would say this language prefers 4.5(13)e6, but it's not 100% unambiguous. An example in the NIST documentation addressing this specific example would be helpful. That said, in practice, this notation is typically used when (1) using scientific or engineering notation so that value has 1-3 digits before the decimal point and (2) the uncertainty is many orders of magnitude (at least more than 3) smaller than the value so there is no danger of collision with the decimal point in the uncertainty string. With the point being, this package may be treading new ground in establishing a convention here since NIST isn't extremely clear on it.
• I'm not so sure I see value in comma delimited values and uncertainties. If the user wants to write value/uncertainty into a csv or something it seems like they should split the value and uncertainty (as floats, not strings) out into two python variables and handle those separately. That is, formatting data to be put into a csv feels a little out of scope for this package.