#278 Units of Converted Booleans and Unitless Numbers

[Lucian Smith]

The conversion of Booleans to doubles, and the reverse, has been accepted in https://sourceforge.net/p/sbml/sbml-specifications/273/

This is a followup issue: what should we say about the units of these converted values?

When we convert a number to a Boolean, everyone agrees that the numbers simply lose their units: no matter the unit system '0' is always '0', and 'non-zero' is always 'non-zero', so conversion of anything in any unit system to 'false' and 'true' (respectively) is lossless.

Converting the other way around is potentially trickier. Here are some options, and the reasoning/arguments behind them:

Option 1: 'true' and 'false' become '1 undeclared' and '0 undeclared', respectively.
* This is consistent with 'raw numbers' (CN elements) in SBML that don't have the sbml:units attribute.
* Modelers who want to use the construct will be more annoyed if they get unit validation warnings for these conversions than they will be if they get 'cannot validate units' warnings for these conversions.
* [Sarah, if there are other arguments I missed, feel free to edit them in here.]

Option 2: 'true' and 'false' become '1 dimensionless' and '0 dimensionless', respectively.
* This is the only way that people can have completely consistent units in their model--unlike the 'sbml:units' attribute for CN elements, it is not possible to declare units on Boolean construct otherwise.
* This does not impose undue hardship on models that ignore units: The construct in general is not allowed at all right now; anything we allow in L3v2 will be an expansion and not a restriction.
* Math of the form "2 seconds + true" is likely to be incorrect, while math of the form "2 dimensionless + true" is likely to be correct: this is the exact situation that unit checking is supposed to cover.
* Math of the form "2 seconds + (true)*3 seconds" is the form most likely to be used, but is only unit-validatable if 'true' has units of dimensionless.
* While 'false' can be translated losslessly to any unit system as '0', the same cannot be said of 'true', which will not mean the same thing in different unit systems as '1'.
* Modelers who want to use the construct will be more annoyed if they get 'cannot validate units' warnings for these conversions than they will be if they get unit validation warnings for these conversions.

Option 3: We provide a way for '1 undeclared' to become '1 dimensionless' in SBML L3v2, and this will 'grandfather' in the Boolean conversions.
* Without something explicit, this is a default, which we have to avoid in SBML L3. But nothing says we can't add an attribute to Model something like 'cnUnits="dimensionless"' or 'cnUnitsAreDimensionless="true"'
* This would allow a single place to declare units for things that otherwise it would be awkward to declare units for, but also allow the existing pattern to remain.

[Frank Bergmann]

For the boolean issue, i still prefer Option #2, just because it is locally constraint.

While I'm the one that would like to have numerical constants in math expression to be dealt with as dimensionless, i do think that this is different from adding an attribute undeclaredUnitsAreDimensionless. If i have an expression

a*b

with a of unknown units and b of defined units, I'm not arguing for a to be dimensionless I think that would be too much of a stretch. However, if we had:

2 * b

I want to argue that the 2 would be dimensionless.

Cheers
Frank

[Chris Myers]

Option 3 seems kind of appealing. Seems the best balance.

Chris

[Lucian Smith]

Sure; I agree that if you don't want to declare the units of all otherwise-undeclared parameters, then 'undeclaredUnitsAreDimensionless' is the wrong name for the attribute. Perhaps 'cnUnits="dimensionless"' or 'cnUnitsAreDimensionless="true"'?

[Frank Bergmann]

I still think, the attributes are kind of wordy, but I can live with them.

Oh ... and I am accepting this issue as valid.

[Lucian Smith]

OK, updated description to use 'cn' instead of 'undeclared'. Other suggestions for names welcome, but the point should be clear regardless.

[Sarah Keating]

In terms of saying things like:

• Math of the form "2 seconds + true" is likely to be incorrect, while math of the form "2 dimensionless + true" is likely to be correct: this is the exact situation that unit checking is supposed to cover.
• Math of the form "2 seconds + (true)*3 seconds" is the form most likely to be used, but is only unit-validatable if 'true' has units of dimensionless.

It is a huge mistake to ever anticipate what modellers think is correct or incorrect or indeed suggest how they are likely to use things.

[Lucian Smith]

It sounds like you are saying it's a huge mistake to have unit validation, because you can't tell if the user thinks "1 second + 2 seconds" is correct and "1 second + 1 meter" is a mistake. I know you're not actually saying that, but I honestly believe there is no difference here.

[Sarah Keating]

No I am saying that when we discussed units on numbers (back in 2007) people came up with use cases where you could not assume that a number given with no units was dimensionless. So we cannot say

2 metres + 1 is right or wrong - we can only say 'I cannot check this'

My argument is that we should not say '2 seconds + true' is likely to be incorrect because there may be a use case where it is not. Making assumptions about what modellers want to do has a history of biting us :-)

[Michael Hucka]

I favor option 3. This would actually solve two problems in one go (what to do about Booleans, and how to let people encode the assumption that all raw numbers found in a model are "dimensionless").

I tend to prefer the version where the attribute indicates the units, although I confess I don't like "cn" as part of the name. How about one of these alternatives?

• pureNumberUnits
• bareNumberUnits

The version where the attribute has a unit name as a value is IMHO more flexible and preferable to the one that is a Boolean value ("cnUnitsAreDimensionless"). Also, it leads to reasonable behavior if the attribute is absent: it means the units of pure numbers are undeclared (which is the assumption in L3v1). By contrast, the other attribute would always have to be present (because it's a Boolean attribute).

[Lucian Smith]

By common consent at the 2015 SBML Editors' meeting, option 2 was selected, with the additional validation rule that in order to convert a number to a boolean, it should have units of 'dimensionless' as well.

[Lucian Smith]

This change is now listed as a l3v2 design change http://sbml.org/Documents/Specifications/SBML_Level_3/Version_1/Core/Design_changes_planned_for_the_Level_3_Version_2_Core_Specification, the spec has been changed in a wide variety of places in SVN, and it will be incorporated into the upcoming L3v2 release.