Calculations for formatting metrics with & without uncertainty value on UI

This is a detailed explanation for determining the number of significant figures of the simulation metric based on the uncertainty value obtained.

---

Formatting metrics without uncertainty value

The method formatNumber is used for the normal metric that we have (not the one with uncertainty shown after the training has ended).

It is an existing method with the requirements listed here.

It is based on the number of significant figures rather than the number of decimal that's why DecimalFormat was not used.

Formatting metrics with uncertainty value

The new method setSigFigBasedOnAnotherDouble(Double originalNumber, Double refNumber, int refNumberSigFig) is for setting the number of significant figures for the metric value which shows at the end of the training along with the uncertainty.

The number of significant figures of the metric value (original number) depends on the position of the final significant figure of the uncertainty value (ref number).

I think it might be easier to understand it with the unit tests as reference:
https://github.com/SkymindIO/pathmind-webapp/pull/1929/files/0b8cb756fa4ce56d8f33b17b589e559f72acd577#diff-cea0df3aab1325e5af770843eed90755R21

As the big decimal would remove the final zero in the value, i.e. double 12.40 would become BigDecimal 12.4, in order to ensure we will get 4 instead of 3 as the number of significant figure for a double 12.40 passed in that has become BigDecimal 12.4, the final param refNumberSigFig is to indicate how many significant figures the ref number has. For the uncertainty value, it's always 2 sig. fig.

Let me explain what the variables do.

Example	Original Number	Ref Number	Ref Number Sig. Fig.
Ex 1	0.9992	0.13	2
Ex 2	145.134	0.20	2
Ex 3	1254.5	110	2

Variable	Description	Ex 1	Ex 2	Ex 3
originalNumberNonDecimalDigits	Get the number of non-decimal digits in original number	0	3	4
refNumber.scale()	Get the number of decimal digits in ref number	2	2	0
refNumberInsignificantPrecision	Get the number of non-significant figure within the apparent number of significant figures in ref number	0	0	1
originalNumberPrecision	Get the number of significant figures in the original number	4	6	5
originalNumberScale	Get the number of decimal digits in original number	4	3	1

In order to get the number of significant figures for the original number, we'll have to ->

1. know how many significant figures the ref number has refNumberSigFig
2. know how many decimal digits the ref number has refNumber.scale()
3. know how many non-decimal digits the original number has originalNumberNonDecimalDigits
4. know whether our ref number has any insignificant figure in the number because of type conversion between String and double/BigDecimal in Java refNumberInsignificantPrecision

The position of the final digit of the original number will always be the same as that of the final digit of its uncertainty value. It means that the number of non-decimal digits between the original number and the ref number may be different (where that of the original number may be more than / equal to / less than that of the ref number), but the number of decimal digits of the original number can only be equal to that of the ref number.

The number of significant figures for the original number is thus calculated by

int sigFig = originalNumberNonDecimalDigits + refNumber.scale() - refNumberInsignificantPrecision;

The following calculation is to determine whether we need to strip any (both decimal and non-decimal) digit out of the original number in its current format.

int newScale = sigFig - originalNumberPrecision + originalNumberScale;

It can be written as

int newScale = sigFig - (originalNumberPrecision - originalNumberScale);

where the bracketed part is to calculate the number of non-decimal digits in the original number.

Finally, after formatting the number with the new scale, .toPlainString() is used to convert the exponent part from scientific notation to normal presentation of the number (1.23 x 10^3 --> 1230 if that ever happens due to shifting of the scale to the left hand side).

---

Original explanation was posted on the PR#1929