#273 Allow mixed boolean/numeric math

[Lucian Smith]

I hate to introduce this so late in the proceedings, but hey, if not now, then never...

There are many simulators (if not all of them) that will accept SBML with mixed-type math, that is, mathematical functions that return booleans being used in a numeric context, with 'true' meaning '1' and 'false' meaning '0'. As an example, every time Herbert writes an equation for a wave, he always writes something like:

squareWave = amplitude(gt(sin(2pi*time/period),0)) + center

Now, it's perfectly possible to re-write this equation using the 'piecewise' function, but it's more awkward, and no simulator that we could find seems to mind. (Copasi will warn you that there's an error, but will still simulate it, for example, and both Frank's roadrunner and the new libroadrunner accept it without comment.)

This would also allow mixed type parameters. I have often, in my own simple modeling, found myself wanting a parameter to be a boolean, but cannot actually say things like:

Event: at (time>3): isOn=true;

Instead, I have to set 'isOn' to '1', and then check 'if(isOn==1)' later, which is a bit awkward (though again, not insurmountable).

A change like this might benefit the 'qual' package as well, since it can have non-numeric elements with discrete values (including boolean values, unless I'm mistaken).

If accepted, I would want to say something explicit in the spec, like, "A boolean value of 'true' takes the value of '1' in a numeric context, and 'false' takes the value of '0'. If a boolean value is being assigned to, '0' implies 'false', and all other values (positive and negative) imply 'true'."

(I don't know if we have any contexts where you can assign a value to a boolean number--perhaps not.)

[Frank Bergmann]

I accept the issue as valid, and agree with the proposed change.

I frequently encounter the same issue, for example with analytic volumes in the spatial package, where it is very convenient to write expressions like: 10gt(x,10)lt(x,20), rather than the corresponding piecewise expression.

Admittedly, you loose some error checking, but i have yet to encounter a situation, where that warning would have helped.

[Chris Myers]

In iBioSim, I actually implemented a lot of very complicated code to support Booleans. In our tool, we can declare Boolean parameters which when used in expressions get converted into the appropriate math (namely, if x is a Boolean, then in math it is automatically translated into x==1). For assignments to a Boolean parameter, we must automatically wrap the math in piecewise. While this works, I agree it would have been much simpler if true would become 1 and false 0 AND when a parameter is used in a logical expression like x&y gets interpreted as (x==1)&(y==1). So, I would be happy with this change. However, this is a big change as many validation rules would need to be removed which require Booleans/Numbers in particular places.

Chris

[Brett Olivier]

I accept the issue as valid, and agree with the proposed change.

I'm doing quite a bit of modelling with mixed integer linear programming and having a Boolean might eventually prove useful.

[Michael Hucka]

If we do this for L3v2, it would make sense to also do it for L2v5. I will introduce a tracker issue for that.

[Chris Myers]

Would we go as far as having parameters of Boolean type? This would be really handy. Right now, we fake this. We add an SBO term that indicates a parameter is to be interpreted as a Boolean. Our editors then do the appropriate piecewise math mangling to make this work. It is pretty ugly, but we got it to work. However, it would be much nicer if there just was a Boolean parameter type.

Note that qualitative species is not ideal in this use case as the parameter may not actually represent a species.

Chris

[Frank Bergmann]

No, I would not go as far as changing the type of a parameter to Boolean
(with new validation rules and type checking). All we agreed on here would
be to allow the Booleans to be automatically converted to doubles for
convenience sake. So it would be a relaxation rather than the changing of a
type.

To Mike's question: I would be all for allowing it in L2V5 as well.

Cheers

Frank

[Chris Myers]

Actually, this should be fine. If one wants to consider a parameter as Boolean and have it only take the values 1 and 0, then having logical expressions being automatically converted to 1 and 0 should be sufficient to accomplish this. The only thing missing though will be some sort of type checking, but I suppose that is okay and can be done by a tool, if so desired.

Chris

[Lucian Smith]

On the assumption that this will be accepted, I am working on writing this into the specifications. One question: as far as units go, I am claiming that boolean values used in a numeric context always have the unit 'dimensionless', and that numerical values used in a boolean context should be 'dimensionless' to start with. The latter would be a rule that would fall into the general unit checking scheme of SBML. Does this seem reasonable?

[Chris Myers]

I think so.

Chris

[Lucian Smith]

Other issues of note in the changes I'm making:

• The math child of a Constraint and a Trigger no longer must be of type boolean, but will be interpreted as a boolean.
• Validation rules 10209, 10210, 10211, and 10213 are removed; 10212 changed to be a warning instead of an error ('should' vs. 'must'). (This actually matches the original text in the section in question--it probably always should have been a warning.)
• Noted in the Parameter write-up that it is possible to have a Parameter that is essentially a boolean, if you only assign boolean values to it, and use it in boolean contexts.

[Chris Myers]

It might be nice to indicate a best practice of giving a parameter used as a Boolean the appropriate SBO term (LOGICAL = 602).

Chris

[Michael Hucka]

On issue #274, Nicolas Le Novère stated a preference for this issue as well. I'm copying what he wrote here:

I vote for including that in L3V2 but not on L2V5

[Sarah Keating]

Just adding to this thread in terms of removing rules.

I would argue that we do not remove them; rather reword them to say that when things are encountered in a particular place they should be interpreted as boolean/numeric as appropriate.

For example:

The arguments to 'and, not, or and xor' must be boolean.

would rephrase as

When a numerical argument to 'and, or, not and xor' is encountered it should be interpreted as a boolean.

[Lucian Smith]

For the record, and in case you have a different solution: I went ahead and removed the relevant validation rules entirely, since 'should be interpreted as boolean' is not something that happens upon validation, but upon interpretation. And indeed, I can think of no context where you would validate a model and be given that validation error/warning/whatever. The main text of the specification does indeed now say that numerical arguments in boolean contexts should be interpreted as boolean. And unit validation still applies: the units of that numerical value should be 'dimensionless'. I could put that in as a brand new validation rule to emphasize that fact, but like all the other unit validation rules of this type, it currently falls under the general auspices of rule 10501.

[Sven Sahle]

I find it ugly but I agree that it can be done since people desire it.
So I accept the change

[Dagmar Waltemath]

Second Sven: I find it ugly but I agree that it can be done since people desire it. I accept the change.

[Lucian Smith]

By common consent (though with token resistance from Sven) at the 2015 SBML Editors' meeting at HARMONY, this issue has been accepted.

[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.

[Sarah Keating]

Just reopening this to clear up an anaomaly I found whilst implementing this.

We have removed the rules that say a Trigger/Constraint must return boolean

BUT

we have not removed the rule (10217) that other things must yield a numeric result.

"The MathML formulas in the following elements must yield numeric values (that is, MathML real, integer or \e-notation" numbers, or the time, delay, avogadro, or rateOf csymbol): math in KineticLaw, math in InitialAssignment, math in AssignmentRule, math in RateRule, math in AlgebraicRule, math in Event Delay, and math in EventAssignment."

Is this an anomaly ??

[Lucian Smith]

If the only options are 'numeric' and 'boolean', then yes, we should remove that validation rule, too.