Re: units in sbml l2v3
04 Jun '07 15:38
Hello Nicolas, hello all,
On Monday 04 June 2007 22:58:41 Nicolas Le Novere wrote:
> > I don´t see why the "old way" should not allow a correct calculation. I
> > understand that square inches look nicer with the "new way" but that does
> > not
> > make the "old way" incorrect.
> > in = 2.54 * 10^-2 * m
> > old way : sqin = 2.54^2 * 10^-4 * m^2
> Sven, here is the misunderstanding. In the old way, you do not have the
> first exponent. Your example is too simple.
Sorry, I was just lazy. I didn´ t want to actually calculate 2.54^2. I know
that I should have written :
old way: sqin = 6.4516 * 10^4 *m^2
And as I said I see that this one looks nicer with the "new way".
> Let's take another one, more
> explicit (I hope): a density of molecule expressed in micromole per square
> <unitDefinition id="umolPerSqIn">
> <unit kind="mole" scale="-6" />
> <unit kind="metre" multiplier="0.254" exponent="-2" />
> old way:
> mole x 10E-6 x 0.254 x (metre)^(-2)
> new way:
> mole x 10E-6 x (0.254 x metre)^(-2)
> The first one is wrong. The second is right.
(minor correction: it should be 0.0254, not 0.254, but that is not the
It is quite obvious that if you encode a unit in sbml using the "new way" and
then interprete it the "old way", as you did, the result will be wrong. If
you encode the old way, and then interprete the old way, it will be correct:
sbml code old way:
<unit kind="mole" scale="-6" />
<unit kind="metre" multiplier="0.00064516" exponent="-2" />
old interpretation: mole x 1e-6 x 0.00064516 m^(-2)
new interpretation: mole x 1e-6 x (0.00064516 m)^(-2)
The first is right, the second is wrong. Which is understandable, since it was
encoded the old way. And I can see that in this example the new way looks
What I really do not get at all is: Why do you consider the old
interpretation "wrong"? It´s just a mathematical definition.
Both are valid definitions. May be one is more convenient, may be one is more
fit for calculations, may be one is more adapted to what people expect.
Perhaps one is more appropriate for manual calculations, the other for
automatic handling. But certainly non of them is "wrong".
You know which definition I prefer. But I´ll try to be fair:
I think the new definition is definitely better for displaying units that
involve areas or volumes defined in imperial length units. And (after reading
the postings) it seems it matches the expectations of some sbml experts
(which is a strong argument).
I think the old way was better actually doing calculations without loosing
accuracy due to floating point operations, and for easier software
Bioquant, Universität Heidelberg
To manage your sbml-discuss list subscription, visit
For a web interface to the sbml-discuss mailing list, visit
For questions or feedback about the sbml-discuss list,
Powered by FUDforum. (Copyright Advanced Internet Designs Inc.)