Drasil: SWHS: De-hardcode C_tol

[samm82]

The following requirement is missing a reference to the Props of Cor Sol section:

It should be:

Also, the 0.001 should not be hardcoded. An ε should be added to the Values of Aux Constants.

As mentioned in #1492, it is also missing the percent sign.

[smiths]

Agreed. Good catch @samm82. @bmaclach has also noticed that 0.001 should not be hard-coded into the requirement. Someone should own this issue, so I'll assign you @samm82. :smile:

[samm82]

As mentioned in #1428, an ε should be added to the Values of Aux Constants, correct? @smiths

[smiths]

Yes.

[bmaclach]

@samm82 The ε in this case is a symbol we've already defined called cons_tol (symbol is C_tol). Currently it is an input to SWHS/NoPCM but we want to change it to a constant. This was all discussed in #1501, which I will close since you are handling it with this issue.

[bmaclach]

@samm82 I ended up working on SWHS inputs as part of #1502, so I left out cons_tol from the inputs list. So you don't need to worry about that part. It still remains to make it a constant and use it to de-hardcode 0.001% in places, though.

[JacquesCarette]

The reason I added the Paper label is that I think the discussion on this issue is interesting because it is happening at a higher level than the typical software implementation discussion.

[smiths]

@JacquesCarette, great idea to add the label Paper. I'll watch for instances where that label makes sense. Too bad we can't generate papers from GitHub just through the Paper label. :smile:

[samm82]

Do we have a facility to represent % as a unit? Or should I enter the value into the table as 0.00001?

[JacquesCarette]

I don't remember! Look through the examples, there are definitely uses of % in there.

[samm82]

The only place that % is used in the examples is in the Uncertainty column of the input data constraints table. For adding consTol, there is an explicit unit column. Would the tolerance value be unitless, and have a value of 0.001%? I'm not sure how to represent a percent as a quantity semantically. @JacquesCarette @smiths

[JacquesCarette]

I don't think we currently have a proper 'semantic' representation for percentages.

[samm82]

Any thoughts on how they should be represented? I think having them unitless makes sense. If we defined the value as a decimal number, I could make a decToPerc util to add a percent sign to the value multiplied by 100 (which is pretty much implicitly used with typUncr right now) whenever we want to show it as a percentage.

[samm82]

@JacquesCarette @smiths What are your thoughts about the decToPerc proposal?

[smiths]

@samm82, I agree that percentages should be unitless. A percent symbol is not a unit. Percentages comes from fractions and I can't think of a case where the numerator and the denominator wouldn't have the same units. This makes percentages unitless. (There might be an exception to this, but if we needed units for a given quantity, they shouldn't come through the fact that it is a percentage.)

It seems to me that this is another case where we want the notion of types. The type of some numbers is they are percentages. Since we don't have types, we are left to add the percentage symbol "manually." @samm82, I like your idea of doing this with a function, instead of by hard-coding in a percentage symbol. We should wait before implementing though to see if @JacquesCarette has a better idea.

[JacquesCarette]

For now, it might make sense to add a "Percent" constructor to Expr that represents percentages. The 'payload' should probably be two non-negative integers (a,b) that basically mean (a/10^b).

[smiths]

Interesting idea @JacquesCarette. I like that your proposed constructor is more general than just a/100, but can't we have a negative a? If I calculate the percentage change in a quantity, the change could be negative (the quantity decreases).

[samm82]

@JacquesCarette Why couldn't the percentage just be represented by a Double so that Percent 0.2 displays "20%"?

[JacquesCarette]

Indeed, it can be. Ok, a can be negative.

@samm82 because in floating point, lots of numbers don't represent exactly, so 0.2 might come out as 19.99999568% instead!

[samm82]

True, true