libsbml
libsbml copied to clipboard
2.12199579145934e-314 'not a double' in online validator
The SBML online validator fails for:
<parameter id="a" value="2.12199579145934e-314" constant="true"/>
because the value is too small, I guess? It works on my local copy of libsbml, though.
Error[ Line 6](https://sbml.bioquant.uni-heidelberg.de/validator_servlet/section-print-result.jsp#line-6) Column 6: (XML Error #1016) Data type mismatch for the value of an attribute. The http://www.sbml.org/sbml/level3/version2/core parameter value attribute must be a double (decimal number). To represent infinity use "INF", negative infinity use "-INF", and not-a-number use "NaN". For more information, see: http://www.w3.org/TR/xmlschema-2/#double.
this could be parse dependent? wikipedia lists 2.23e-308 as min value:
checking this in c++ this morning,
#include <iostream>
#include <iomanip>
#include <limits>
#include <string>
#include <cstdlib>
#include <cerrno>
int main()
{
std::cout << "double\t│ "
<< std::numeric_limits<double>::lowest() << "\t│ "
<< std::numeric_limits<double>::min() << "\t│ "
<< std::numeric_limits<double>::max() << '\n';
std::string val = "2.12199579145934e-314";
errno = 0;
char* endptr = NULL;
const char* nptr = val.c_str();
double result = strtod(nptr, &endptr);
std::cout << "errno == ERANGE: " << (errno == ERANGE ? "true" : "false");
return 0;
}
yields:
double │ -1.79769e+308 │ 2.22507e-308 │ 1.79769e+308
errno == ERANGE: true
so this is really a subnormal number that will be treated differently by different compilers / processors. so i think the flag is filed correctly.
Can we change libsbml's setter so it doesn't write numbers smaller/larger than double min/max? I can use Antimony to create SBML models with e-314 numbers, and NEWT also did the same (I presume) with 'x' and 'y' values in layout. We won't be able to prevent SBML models created by hand, but we could at least cut things off on our end.
That'd be literally every setXXXX function that takes a double. And will be quite the undertaking and not something i would find time for anytime soon. How about a flag on the XMLOutputStream, so that subnormal values will be written as 0, that at least would fix it quickly if someone encountered it?
If you would get around to doing the commit that'd be fine. It would have for each number check first whether any number other than nan, inf, 0, is std::isnormal(number), and only then do the setting.
Sure, I'll put this on my to-do list. I think I would set sub-min values to min instead of 0, just on the theory that if the user wanted zero, they would have used it already? It's hard to say, though; you could make an argument either way.