Input-dependant significant amount of digits.

[Wendelstein7]

Different input prompts may find different amount of significant digits relevant. A measurement of whole feet typically doesn't need up to three significant digits. While 3 feet gets corrected to 0.914 m, perhaps 0.9 m or 0.91 m would suffice.

Perhaps the significance of the input could be taken into account: prompt 3.00 feet or 12.54 stone would result in more significant digits than 3 feet and 12 stone would.

[Randall-Scharpf]

Since we're actually considering significant figures, it seems like a good time to mention that the roundsignificant function is actually broken -- whenever it should result in trailing zeroes, it does not provide these zeroes. For example, if I wanted to take a value of exactly 8 and express it with three significant digits, I would have 8.00. However, the roundsignificant function would fail to provide these trailing zeroes and instead just give 8.

Leaving the option flag set to the default of SIGNIFICANTFIGURES = 3 I can demonstrate this behavior:

The same issue exists for large numbers:

Further complicating the issue is the following case:

It seems that the roundsignificant function only works in a certain, relatively narrow range of cases, and that its shortcomings simply are not typically observed because of the context in which the function is called. Just wanted to make sure you were aware, since fixing the main problem requires fixing the behavior of this roundsignificant function.

[Randall-Scharpf]

I have some partially-functional code for this feature in a fork. I believe it works for almost all cases, however, I would like this to be tested. I've already uncovered the following issues/limitations during my debugging:

• When a number is very large, the behavior has been to convert to scientific notation. This is evident in the second set of test cases. In typical practice, a number that is large enough to trigger scientific notation will not be significant to decimal places (that is, the significant form is an integer). In this extremely frequent case, no conversion to scientific notation occurs. I intend to fix this before I pull request.
• When a conversion results in fewer non-zero digits in the result than the problem and the result gives trailing zeroes, significant figures can only be expressed by converting to scientific notation. For example, consider 401 * 25.0 = 1002.5, which has 3 sig figs in the measurement and conversion factor, so gives 3 sig figs in the result. however, 1000. and 1000, although equivalent to the correct result in value, both express the wrong number of sig figs. Using the structure for scientific notation standard to outputs in the current state of the bot, the only correct answer to our sample problem is 1.00e+3. As alluded to in the last bullet, a major issue with the bot is the new inability to construct scientific notation, and as a result, this remains a bug. I intend to fix this before I pull request.
• While dealing with values with larger numbers of sig figs, I discovered two sources of conversion error in the bot. Firstly, only some of the conversion factors are exact values - others are simply truncated with fewer significant figures than can possibly be provided. Secondly, because all of the conversions occur in floating point arithmetic, which unlike python integer arithmetic has fixed precision, a user can input a number with copious numbers of significant figures and wait for it to undergo conversion with a constant that has an exact value and still receive a result that is not correct in the last many significant figures, due to floaitng point rounding errors. It is worth noting that few measurements truly have such a degree of accuracy, so the arithmetic errors may in almost all cases be ignored. I do not intend to fix this bug before I pull request, as the fix would require significant changes to the conversion system and complex data restructuring to satisfy the correctness of what are likely to be edge cases of use.

Cheers!

[Randall-Scharpf]

I have created a pull request and I believe this fix causes the generator to give the correct number of significant figures for every input, however, third-party verification is always appreciated. If this is in fact true, I would like to request that it be merged. Thanks!