Forums

Hi,

I know that the unit stuff has been discussed a lot, but the more I
think about it, the more I am convinced that the current way units are
to be interpreted is very broken. I think the way it was in the original
L2V1 spec was OK to work with, but that after the change that was made
to the formula I think units are unusable.
I am not talking about units in SBML files per se, but about the formula
that states how units are to be interpreted.
In the old spec, the fomula was given as:

multiplier * 10^scale * u^exponent

after the change, then formula is supposed to be:

(multiplier * 10^scale * u)^exponent

For the sake of simplicity, I will just ignore the offset.

When you wanted to represent one (U.S.) gallon with the old formula you
could specify it as

3.785411784 * 10^0 * liter^1

which when you convert it to meter^3 would be

3.785411784 * 10^-3 * m^3

which I think is intuitive.

After the change, this is different. While the gallon would now be
represented as

(3.785411784 * 10^0 * liter)^1

which is not that awfully different, you get

(1.55849128 * 10^-1 * m)^3

after converting it to m^3. Where 1.55849128 is now the cubic root of
3.785411784.

Now would anybody have been able to see that this represents one gallon?

I know, SBML files are not for the user to look at but for programs to
interpret, but even if you let a program do the calculations, you will
soon get rounding errors doing all those conversion with roots back and
forth. This is a lot of work, it is error prone and totally unnecessary.

It gets even worse if you try to multiply units which is necessary in
order to check unit consistency.

Lets assume you want to multiply 2.0 * 10^-3 m^2 with 3.0 * 10^-5 m^3.
The result should be 6.0 * 10^-8 m^5.
With the formula as it was in the beginning, this is intuitive:

2.0 * 10^-3 * m^2 * 3.0 * 10^-5 * m^3 = 6.0 * 10^-8 * m^5

Now try it with the new formula:

(1.414213562 * 10^-1.5 *m)^2 * (1.44224957 * 10^-1.666666667 * m)^3

Since the spec says that the scale of a unit can only be an integer, we
have to normalize this to get valid SBML units.

(0.44721359555 *10^-1 * m)^2 * (0.3107232506 * 10^-1 * m)^3


= (pow(0.4472135955^2*0.3107232506^3,0.2)*10^((-1*2+-1*3)/5)
* m)^5

= (pow(0.1999999996*0.02999999983,0.2) * 10^((-2+-3)/5) * m)^5

= (pow(0.006,0.2) * 10^(-5/5) * m)^5

= (0.3594431819 * 10^-1 * m)^5

OK, I probably made a mistake along the way since I tried to do this
manually just with a calculator, but the result if a try to get rid of
the exponent around the parenthesis would be:

0.3594431819^5 * 10^-5 * m^5 = 0.006 * 10^-5 * m^5 = 6 * 10^-8 * m^5.

The answer now seems to be right, although I ignored some rounding
errors from the calculator but in order to get the correct answer, I had
to recalculate the whole thing three times. I know that this is mostly
due to my inability to do the calculation right, but this specification
is a pain if you manually want to verify your algorithms.

So this is exactly one of the points I wanted to make. If you want to
test the implementation, you spent a lot of time looking for errors in
the calculations.

Another issue is that you also have to take care of
rounding errors you get during the calculation. If you now want to
compare two units that have been calculated like this, you will have to
take those into account and work with an epsilon value that tells the
program the margin of error you are willing to accept when comparing units.

Again, this is totally unnecessary because with the old formula you
wouldn't have to calculate the roots of multipliers or divide scales all
the time.

I am sorry, but I think we were far better of with the unit formula as
it was defined in L2V1. I don't know why it has been changed, but I
think this was the worst mistake with respect to units and I think we
should really consider changing it back.
Having the old formula back would make working with units so much easier
and writing and testing code so much faster. Also displaying the units
to users in an intuitive way would be a lot easier.

Maybe I am misunderstanding the current spec and it is not as bad as I
have outlined here (I seriously hope so), but if it is, we should change
it as fast as possible before people start implementing unit support.

Or has anyone besides Sarah seriously looked into unit support?

Ralph












____________________________________________________________
To manage your sbml-discuss list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss

For a web interface to the sbml-discuss mailing list, visit
http://sbml.org/forums/

For questions or feedback about the sbml-discuss list,
contact sbml-team@caltech.edu.