Input Data Constraints Table | Significant Digits and Units

[samm82]

Significant Digits

• Change Uncertainties in Drasil to 10% Specifying Precision #1258
• Update significant digits in caseStudies - wait until Differences in Table of Symbols in GlassBR SRS #824
• Change TNT typical value to 1.0 in caseStudies
• Change TNT typical value to 1.0 in Drasil

Units

(Related to discussion in #824) In Drasil, a and b are given in metres, and in millimetres in caseStudies.

[smiths]

Yes, propagating the number of significant digits sounds fine. Since you brought it up, we should actually change the Drasil version to 10% for the uncertainty. 10.0% implies a precision that we don't have.

For TNT, I agree that 1.0 makes sense for both options.

@elwazana is currently working on fixing the units so that they are consistent. (Discussed in #824.) This means first checking the units in Drasil and then propagating these corrections to the case study version. In all likelihood the mm units in the case study version will be changed to m.

[samm82]

My current fix to the 10.0% vs 10% discrepancy rounds the uncertainty to an integer if it is equal (approximately because of floats) and leaves it as a float otherwise. Is this desired @JacquesCarette @smiths? This also propagates through all examples and assumes the precision of all 10% uncertainties to be the same.

EDIT: If so, since we aren't maintaining caseStudies anymore, this issue can be closed with the merge of glassImprovements.

[smiths]

@samm82, I don't love the solution of casting a float to an integer. It would be better if we rounded the float to zero decimal places, but still considered it a float. I could see a day where we keep track of the number of significant digits and propagate that through calculations, but that is down the road.

The rounding should happen at display time. We shouldn't actually change the value, just how it is displayed.

[samm82]

I found a better solution in (2cb16c6) that involves using the Decimal package - would that be acceptable if I added it to the build-depends in the cabal file? Decimals are floats with a set precision, and I think function perfectly for this purpose, especially since the float is converted straight to a Sentence in the found function. However, the current solution involves setting the precision to 0 if the uncertainty is 10% and setting it to 1 otherwise; this could be automated later.

[smiths]

The Decimal package sounds good, although @JacquesCarette should weigh in on the use of external packages. I like the idea that we can restrict the precision, but basing that on the value of the uncertainty seems like a hack we don't want to do. @JacquesCarette will likely know the right way to design this, but I think we need to have an option for display precision somewhere. If precision isn't specified, the default should be full precision, not 1 decimal place.

[samm82]

What do you think about leaving it for now, as it technically fixes this issue, closing this issue, and creating another for generalizing the precision? @smiths

[smiths]

I think we should get the opinion of @JacquesCarette before proceeding with the proposed temporary solution. This might be a case where the fix is worse than the original problem. 😄 My concern is that we are introducing something that sets a bad precedent.

[samm82]

That's why I proposed a separate issue to deal with it, just so we can close this, and so the conversation doesn't drift from the original intention (as it usually does with my issues 😁). This might be a good thing to discuss in the meeting tomorrow.

[JacquesCarette]

As long as the external package seems 'alive', I am fine with using more external resources. And it does seem like a better solution as I completely agree that this is a display-only issue and that internally there should be no casting.

[samm82]

This is more of a design question - how should we decide the precision of an uncertainty (or any value, potentially)? Should it be passed in explicitly? Should we define an Uncertainty type that takes a Maybe Double (uncertainty) and Maybe Integer (precision)?

[samm82]

I've created a new issue for precision (#1258) so I'm closing this issue.

[smiths]

Yes, good idea to create a new issue.