Decide what to do about the definition of min() and max() with zero arguments.

[sbmlsecretary]

In implementing support for the new min() and max() functions we have added to the allowed MathML subset in core, I discovered a missing piece of information: both min() and max() are defined as 'n-ary', meaning they can take 0 or more arguments. However, the MathML spec does not say anything about what their definition is with no arguments.

In contrast, it does declare what the definition is for zero arguments of other n-ary functions such as plus(), times(), and and(), namely, that these functions return the identity value for those functions. For plus() this is 0, because plus(a,b,c) == plus(a,b,c,0). Similarly, times(a,b,c) == times(a,b,c,1), and and(a,b,c) == and(a,b,c,TRUE).

From this, we can infer identity values for min() and max(): min(a,b,c) == min(a,b,c,INF), and max(a,b,c) == max(a,b,c,-INF), therefore min() == min(INF) == INF, and max() == max(-INF) == -INF.

This is, for example, what is done here: https://tc39.github.io/ecma262/#sec-math.min

On the other hand, when Sarah and Frank first thought about it, their instinct was to return 0 for both min() and max().

So, I think we have a few options:

1) State in the spec that min() and max() are undefined. Implementations are allowed to define them however they want, whether INF/-INF, 0, 3.2, or whatever. 2) State in the spec that min() and max() are illegal. We allow only a subset of MathML anyway; it would be perfectly reasonable to allow min and max with 1+ arguments, and leave out 0 arguments. A future 'mathML expansion' package for sets could then define min()==max()=='the empty set', for example. 3) State in the spec that min()==INF and that max()==-INF. 4) State in the spec that min()==max()==0

Reported by: luciansmith

Original Ticket: sbml/sbml-specifications//327

[sbmlsecretary]

Option 3 seems fine.

Original comment by: ccmyers

[sbmlsecretary]

Do I get a vote? I'm not sure what my voting rights are currently. Anyway, I would also go for #3.

Original comment by: mhucka

[sbmlsecretary]

In the interest of not imposing our views on the world I would go with #1.

Original comment by: sarahkeating

[sbmlsecretary]

In my view, not staking some claim is worse than claiming that anything goes--if we go with #1, models with this construct are literally unexchangeable. If you really don't want to make a decision, I would strongly argue for #2. (My non-voting preference, for the record, is #3.)

Original comment by: luciansmith

[sbmlsecretary]

I vote for #3.

Original comment by: andreas-draeger

[sbmlsecretary]

3 (confidence value == low :-))

Original comment by: dagwa

[sbmlsecretary]

I vote for #1. #3 looks logical in surface, but is arbitrary. The max of nothing is undefined.

Original comment by: lenov

[sbmlsecretary]

With a 2:2 split, and an earlier stated desire to try for 4:1 votes, we could either discuss more here, or take the issue to sbml-discuss, either for more discussion or for an actual poll. Does anyone have an opinion? Brett, are you going to chime in and push things one way or the other?

Original comment by: luciansmith

[sbmlsecretary]

After a quick search it looks like Javascript is the only language that uses the -inf/inf return value for empty min/max. Therefore defining it as #3 in SBML means a non-native behaviour in, potentially, all other language implementations. In addition I agree with Nicolas that this is an arbitrary solution.

I vote for #1

Original comment by: bgoli

[sbmlsecretary]

OK, that makes it 3:2 amongst the editors, with one of the 2's having a 'confidence value==low' caveat ;-) Dagmar and Andreas, would either of you like to change your vote, discuss things more, or bring the issue to the community at large?

Looking things up for C++, I found http://www.cplusplus.com/reference/valarray/valarray/max/ which states, "If the valarray has a size of zero, the value returned is unspecified (depends on the particular library implementation)," which would also support Brett's assertion that we should leave it unspecified in SBML as well.

Original comment by: luciansmith

[sbmlsecretary]

I continue to vote for #3 as other solutions aren't convincing for me.

Original comment by: andreas-draeger

[sbmlsecretary]

I would also like to stick to #3. I could well live with #1. And I am still not very confident.

Original comment by: dagwa

[sbmlsecretary]

Hmmm. So in some discussion, we relax the spec, and in other we define arbitrary default ... hmm... ;-)

Original comment by: lenov

[sbmlsecretary]

I agree with Nicolas - if the policy is no defaults; then we cannot set a default.

Original comment by: sarahkeating

[sbmlsecretary]

I don't see it as a default, though I can understand that perspective. Remember that MathMl already defined values for 'the sum of the empty set' (0), 'the product of the empty set' (1), and other n-ary functions. It simply neglected to do this for 'min' and 'max', leaving it to us (and everyone else) to discover the results of those mathematical functions. We need to decide whether 'the minimum of the empty set' has a value at all for us, or whether we should disallow the construct, or whether we should simply say that it remains undefined in SBML, and people are allowed to reject it or come up with their own definitions.

This is perhaps a bit of an overly-pragmatic perspective, but do remember that if we say that it has a definition and that we know what it is, we can put it in the SBML test suite, so all simulators must code for this situation and agree in the end. This will increase exchangeability, though of course we don't expect to see 'min()' or 'max()' much in the first place. Similarly, if we disallow it, we can create a validation rule for it, so anyone's model with this present won't be valid.

Original comment by: luciansmith

[sbmlsecretary]

Under our new proposed system, in a 3:2 split, any editor may now request that we gather more information (such as polling sbml-discuss), or more editors can agree to do a formal sbml-discuss poll, or to table the item until a specific date.

If nobody wants to do any of that, the decision is made in favor of the majority. If anyone would like to request more input from somewhere, mention that here and I can draft a message to that effect.

Original comment by: luciansmith

[sbmlsecretary]

I think we should look for input from tool developers - since in a way they will be more affected by what is decided. Some tools already support min and max (outside of SBML) and I cannot imagine them having one interpretation for using the function in one place and a different one if they encounter it in an SBML model.

So maybe a post to sbml-interoperability rather than sbml-discuss ? but I'm not tied to that.

Original comment by: sarahkeating

[sbmlsecretary]

Hi everyone,

I am not sure whether or not I am allowed to change my mind, but ... I spoke to Brett during HARMONY and I read through the comments again - confidence value is raising.

Lucian said: From this, we can infer identity values for min() and max(): min(a,b,c) == min(a,b,c,INF), and max(a,b,c) == max(a,b,c,-INF), therefore min() == min(INF) == INF, and max() == max(-INF) == -INF. But also: the MathML spec does not say anything about what their definition is with no arguments.

This made me think that we should probably not define it either, to stay MathML-compliant, so to speak.

Also, Brett seems to have investigated in this issue quite a bit, and he convinced me that there are not many reference implementations that we could justify another decision with,

than saying that the value remains undefined.

That said, I cite Nicolas:" #3 looks logical [in surface], but is arbitrary. The max of nothing is undefined."

If I am allowed to change minds now, I change vote to

1,

but I am also fine with involving the community, if need still be.

(and I do not know why the font size keeps on changing :D)

Original comment by: dagwa

[sbmlsecretary]

I just want to add that I would also be ok if this went out for wider community comment. The example I mentioned to Dagmar was that of Python/Numpy where:

sum([]) --> 0 min([]) --> Error max([]) --> Error

Original comment by: bgoli

[sbmlsecretary]

I still think some input for tool developers might eb appropriate - particularly tools that already support max/min.

Original comment by: sarahkeating

[sbmlsecretary]

Brett, what does Python/Numpy do for plus(), times(), and(), and or()?

Original comment by: luciansmith

[sbmlsecretary]

It depends,what I was showing above is the built in functions whereas for your questions looking at the AST's is probably more relevant. I need to check that.

Original comment by: bgoli

[sbmlsecretary]

I would be inclined to vote for #2 because I suspect that a no argument call to min and max is indicative of an error condition, and finding those errors would be hard if these functions returned something computable like a numeric or even +/-INF.

For what its worth, MATLAB returns [] for both min([]) and max([]). That itself seems arbitrary to me but at least trying to compute on the [] is likely to result in an error that will be easy to find.

Original comment by: paxsonpaez

[sbmlsecretary]

supporting #3

Original comment by: matthiaskoenig

[sbmlsecretary]

• status: open --> closed
• Group: Reported-Proposed --> Accept-conformance-implications

Original comment by: luciansmith

[sbmlsecretary]

This issue was included in a poll to sbml-discuss, where the conclusion was to leave min() and max() as undefined. This has been checked into SVN, and added to the list of design changes (http://sbml.org/Documents/Specifications/SBML_Level_3/Version_1/Core/Design_changes_planned_for_the_Level_3_Version_2_Core_Specification), and will be part of the forthcoming l3v2 release.

Original comment by: luciansmith