Should the spec make some statement about bad maths?

[MichaelClerx]

Couple of cases:

Simple overdefinedness:

x = 0
x has initial value 1

or

x = 0
x = 1

Complex overdefinedness:

x + y = 1
x - y = 3
x * y = 12

Redundant info

x = 1
x = 1
x = 1

Underdefinedness (OK, because we want to connect models)

x = y + z

Unsolvable models / bad maths

x = 1 / 0

Some of these seem definitely out of scope, e.g. x = 1 / 0 is just one of many silly models you can make, and CellML can't/won't stop you. But in that case there's 1 interpretation of the model only (and that interpretation is rubbish).

In cases like

x = 1
x has initial value 2

most current software ignores the initial value in favour of x, and there are several files that do this in PMR (even ones that have been validated) Is this correct? Who knows! But is the file valid? Yes!

So could we add some message to the spec saying "If you do this then the result is undefined?" At the moment it's unclear for me whether I should (1) deal with the above case to make my software accept more models, or if (2) I should raise an exception. Option 1 feels wrong, because I'm ignoring a blatant issue in the file, but if I go for option 2 I have to raise an exception that says "this file is excellent CellML but my software doesn't like it" Would be much happier to raise an exception saying "The CellML spec says this file has an undefined interpretation, please fix."

[hsorby]

Are you looking at making the spec. aware of these particular cases or all cases where the maths is invalid. The latter would make validation almost impossible I think.

[agarny]

Most of these should be handled when determining whether a model makes sense, e.g. prior to generating code. As far as I am concerned, it has nothing to do with the specs. When it comes to MathML (and therefore CellML), there is nothing wrong with models that would contain "bad" math.

x = 0
x has initial value 1

Such a model should result in an error about x being both a constant and an algebraic variable.

x = 0
x = 1

Such a model should be considered overconstrained.

x + y = 1
x - y = 3
x * y = 12

Sure, it's unnecessarily "complex", but nothing wrong with that in principle.

x = 1
x = 1
x = 1

By default, it would be considered overconstrained although a "good" model analyser could ignore the redundant equations.

x = y + z

Such a model would be considered underconstrained.

x = 1 / 0

Indeed, nothing wrong with that. You are basically saying that x = inf.

In cases like

x = 1
x has initial value 2

most current software ignores the initial value in favour of x, and there are several files that do this in PMR (even ones that have been validated) Is this correct? Who knows!

No, it's not.

But is the file valid? Yes!

Indeed, it is.

So could we add some message to the spec saying "If you do this then the result is undefined?" At the moment it's unclear for me whether I should (1) deal with the above case to make my software accept more models, or if (2) I should raise an exception. Option 1 feels wrong, because I'm ignoring a blatant issue in the file, but if I go for option 2 I have to raise an exception that says "this file is excellent CellML but my software doesn't like it" Would be much happier to raise an exception saying "The CellML spec says this file has an undefined interpretation, please fix."

Although I am not happy with it, I would go with option 2. To go with option 1 might be very tricky, if not impossible.

[hsorby]

I can't see the CellML spec. being responsible for the validation of the math. So that leaves you with any options that don't require the CellML spec. to define math validation. You could go for either option 1 or option 2 but the spec. won't be telling you that the mathematical model described is ill-defined.

[MichaelClerx]

But what are implementers supposed to do with the above cases? I agree with most of the resolutions given by @agarny, so why not ratify them? I still don't know whether a CellML validator should allow these cases or not. Or even more practically, should I raise a "BadCellMLError" if I find these, or a "MySoftwareDoesntLikeYourModelError" ?

[hsorby]

I think that this shows a case for having another spec. that starts to define 'bad math'. At this stage implementers are going to have to go with "YourMathInYourModelIsBad" but I'm not saying it's against any spec.

[MichaelClerx]

@kerimoyle do we have some statement about this in the informative spec? If so I'm happy to close this

[kerimoyle]

Not specifically, though there are examples around the place which are valid-but-nonsense. I have the chapter 3 maths issue next on my list to write, so suggestions welcome :)

On Fri, 3 Apr 2020 at 05:17, Michael Clerx notifications@github.com wrote:

@kerimoyle https://github.com/kerimoyle do we have some statement about this in the informative spec? If so I'm happy to close this

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cellml/cellml-specification/issues/23#issuecomment-607945269, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALFXCNANJBLA6Y223C3M3ILRKS3AXANCNFSM4J2QTKYA .

[MichaelClerx]

You could re-use the examples above as things that are allowed in CellML, and won't invalidate a CellML document, but which might cause trouble if you try to use the model in simulations?

[MichaelClerx]

@kerimoyle maybe another section after "Dimensional consistency (or, how to write nonsense maths)"? (Although that bit is relevant to <cn> elements, I suppose). Could show an overdefined example x = 1; x = 2 which is valid but rubbish, or x = 1 / 0 which is valid but typically not useful

[kerimoyle]

But what are implementers supposed to do with the above cases? I agree with most of the resolutions given by @agarny, so why not ratify them? I still don't know whether a CellML validator should allow these cases or not. Or even more practically, should I raise a "BadCellMLError" if I find these, or a "MySoftwareDoesntLikeYourModelError" ?

I think implementers should follow what we're doing in libcellml with the Issues ... so enabling "validation"/checking/debugging processes to report on true-spec-violating validation errors as well as well as errors which are not validation related (like all of those above), mismatched units, etc.

I can certainly add some sections which make this more explicit in the informative sections. If anyone has any other examples beyond what's already listed in this thread, let me know :)

[kerimoyle]

In cases like

x = 1
x has initial value 2

most current software ignores the initial value in favour of x, and there are several files that do >> this in PMR (even ones that have been validated) Is this correct? Who knows!

No, it's not.

@agarny ... how is it not valid? Your code generation might pick it up, but does the spec?

@MichaelClerx " ... most current software ignores the initial value in favour of x" ... but are we really leaving room for differences here? So I can have a sentence which says "It is not invalid CellML, but may not result in the same interpretation between software implementations" ... ?!?

[agarny]

@agarny ... how is it not valid? Your code generation might pick it up, but does the spec?

As I mentioned, but not clearly I guess, is that it's valid CellML, but when it comes to code generation it's not: the model is overconstrained.

[kerimoyle]

OK, that's what I understood, just checking :)

[MichaelClerx]

The spec is only concerned with validity though, so the informative spec should be clear that the correct way to handle the above cases in e.g. code generation is undefined!

[MichaelClerx]

@MichaelClerx " ... most current software ignores the initial value in favour of x" ... but are we really leaving room for differences here? So I can have a sentence which says "It is not invalid CellML, but may not result in the same interpretation between software implementations" ... ?!?

I would say it's undefined! (Which usually implies it could cause differences between implementations, yes)

[kerimoyle]

But ... doesn't that mean that it need to be in the spec properly? We shouldn't have this kind of ambiguity in any valid model?

[MichaelClerx]

Apparently we should :man_shrugging:

I'm not sure I like it either. From a tool point of view, we've got three levels or errors now:

1. This file is invalid CellML
2. This file is valid but meaningless CellML (e.g. x=0 and x=1)
3. This is valid and possibly meaningful CellML but this tool doesn't support it (e.g. DAEs, PDEs, resets)

From a CellML test suite point of view I guess I need to now write tests that say "x= 1 and also x = 2 and x(t0) = 10" and then tools that complain get a bad mark because they reject a valid file

[MichaelClerx]

But from a spec point of view some degree of "level 2 errors" are very desirable, otherwise we have to be able to tell whether any given mathematical statement is sensible or not, which is a bit beyond our scope, although Gödel probably didn't anticipate CellML

[MichaelClerx]

Closed in #23