Model 955: time^time should be indeterminate

[luciansmith]

In Model 955, parameter P26 is provided as time^time which is an indeterminate expression and not 1 (as the reference result seem to indicate)

Reported by: *anonymous

[luciansmith]

(I assume you mean 'when time is 0'.)

While 0^0 may indeed be defined as indeterminate, there are reasons to define it as '1', cf http://mathforum.org/dr.math/faq/faq.0.to.0.power.html

It seems to me that since most programming languages have adopted this convention (of 0^0=1), and all simulators we have tested thus far successfully pass model 955, it is actually helpful to have this test in there, as it ensures that all simulators actually interpret this same admittedly ambiguous construction in the same way: if someone were to define a model with 0^0 in it, and move that model from one simulator to another, they would want to end up with the same results.

If we did not do this, there would be two possibilities. One, we could require all simulators to define 0^0 as indeterminate, and stop simulating or crash or something. This behavior would be difficult for the test suite to capture, and is similar to the problem of testing constraints. It is also of questionable value--is 'the simulator stops' actually desired behavior for anyone who writes a model like this? Certainly it was not the behavior I expected when writing the model in the first place, though obviously I was creating it simply to test edge cases. It would also be difficult (I imagine) for simulator writers to write special code for this particular case, and most would rather (I assume) merely accept the behavior of whatever math library they are using.

The other option would be to not test the construct at all, which also seems incorrect: again, the purpose of the test suite is to ensure compatibility between simulators, and this is another behavior that should be consistent.

If it turns out that there is a math library out there which does not return '1' for this construct, and furthermore cannot be made to do so, and if there is a simulator that otherwise passes this test that cannot produce '1' for that construct, I would be willing to reconsider taking the test out of the suite (modifying 'time^time' to '(time+1e-20)^time', for example). But it looks to me that on the contrary, all math libraries that have been used thus far for SBML simulators all define 0^0=1.

Original comment by: luciansmith

[luciansmith]

Thank you for your elaborate comment, I am using Mathematica which treats 0^0 (correctly) as Indeterminate (without further explicit assumptions). I can live with defining it as 0^0 = 1 in the context of SBML models , So you don't have to remove the test. I believe 0^0 = 1 should be mentioned somewhere in the SBML spec though. Thanks, Niko

Original comment by: *anonymous

[luciansmith]

• status: open --> closed

Original comment by: luciansmith

[luciansmith]

Closing the issue; it doesn't seem to have become a problem for other simulators, and this one was resolved satisfactorily.

Original comment by: luciansmith