Pretty printing of quantity with uncertainty about measurements.jl

[adamslc]

I've started working on this a little bit, but I'm not sure how we should handle this when the user provides more than two significant digits. I think it would be very confusing and frustrating for a new user if they entered 1.234 ± 0.05678, and the REPL responded with 1.234 ± 0.057 (regardless of the statistical validity of using that precise of an uncertainty). One option would be to leave show() alone, and instead rewrite showcompact() to round the error at two significant figures, but this would still leave a lot of undesirably long output.

[giordano]

Actually I'm also unsure how to handle this feature and I'd like suggestions from users on this.

A possibility could be not to overload show but rather provide a new function to pretty print the object according to user needs. This may be useful when one wants to form a string out of the result of calculations.

[ggggggggg]

I think it would be reasonable to show 2 digits of uncertainty, and same rounding on the value in all cases. Just be sure to explain in the documentation.

MATLAB truncates floating point number for display by default. This will be much less confusing that MATLAB's behavior.You have a well principled choice to guide your truncation. http://www.mathworks.com/help/matlab/ref/format.html

You could provide ways to get the full set of digits Then provide a way to get the full representation easily. Maybe a function showfull that prints all the digits. Or a Module level setting Measurements.set_show_format(Measurements.ALLDIGITS).

[JulienKluge]

So, to relive the conversation on that, the next Mathematica will come out with inbuilt uncertainty propagation and Stephen Wolframs livestreams some of its design decisions. So, let's learn from the big players. You can view this streams:
here: https://www.youtube.com/watch?v=a1UZ07e8-s8
and some of it here: https://www.youtube.com/watch?v=--iBBCklEIQ

They went with a convention often used in physics which is rounding to the first significant digit except it being 1 or 2, then round to two significant digits.
I'd propose we also go with this although i share the worries of @adamslc . However, we can address this with two things:

• Provide a "Measurement-Rounding" function which supports full precision and other styles (I could write one and make a pull request)
• Make this fact (especially how to get full precision) a prominent example in the Readme and the docs.

[JulienKluge]

btw. this would mean that:
(1.2 ± 0.3) + (4.5 ± 0.6) ==> (5.7 ± 0.7)
but
(1.2 ± 0.15) + (4.5 ± 0.2) ==> (5.70 ± 0.25)
and especially the edge case:
(1.2 ± 0.16) + (4.5 ± 0.25) ==> (5.70 ± 0.30)

[giordano]

Thanks for reviving this issue and sharing the videos! I didn't know mathematica was going to introduce this feature. I'd like to know more about how they implemented this, is this covered in those videos?

I can see the point of the 2-digits-only-with-1-and-2 convention, but I've never been sold on it, I usually prefer to always read 2 digits on the uncertainty.

I also want to stress that this is just for printing the number, which will actually retain the full information about the uncertainty.

[JulienKluge]

Well there is an even earlier stream (which i currently can't find) where they discuss it a bit. But this was all preliminary as far as I can tell so take this with a grain of salt. They went with standard operations always being independent. The way of tracking all covariances, like this package does, was discussed but discarded due to the cluttering issue when many variables come into play.
So they went with introducing an auxiliary function for doing depended error propagations. This plays nicely with Mathematica since it can be done symbolically. This isn't as easy to use as Measurements.jl but introduces the nice ability to propagate whole covariance matrices.

Well, I've seen the always-2-digits convention too, although more rarely (often in physical constants with the "brace-notation" like (5.70 ± 0.25) => 5.70(25) ).
However, I'd be fine with this since it allows for easy converting to the 1-digit form in my head anyways and isn't unusual or so.

[giordano]

The way of tracking all covariances, like this package does, was discussed but discarded due to the cluttering issue when many variables come into play.

Yes, I'm aware of this issue. With few variables this package is really fast, it comes into troubles with many of them as the cost of computation is O(n^2)

[BeastyBlacksmith]

As far as I understood the canonical way would be to have

print( IOContext(io, :compact => false), number ) # gives all digits
print( IOContext(io, :compact => true), number ) # gives rounded/ truncated result

I'll make a PR where one can explore this feature.

[giordano]

Ok, this should be fixed by 0a44e6f...95087d7. Thanks to @BeastyBlacksmith for starting this!