# Forums

 SBML Discussions » sbml-discuss » units in sbml l2v3Show: Today's Posts  :: Message Navigator| Subscribe to topic
AuthorTopic

Posts: 82
Registered:
September 2003
 Re: units in sbml l2v3 04 Jun '07 08:36 Hello Michael, hello all, On Sunday 03 June 2007 20:46:32 Michael Hucka wrote: > SS> On the other side, if you want to express gallons with > SS> meter as base unit, the old way was more intuitive. > > I have to disagree; first, the "old way" was actually > erroneous, and second, the example is misleading. > > The example is misleading because it is not being done in > elementary steps. In the usual definitions of unit > conversions, one writes individual terms like along the > following lines: > > 3.785411784 L 1 dm^3 / 0.1 m \3 > N {gal.} = N * ------------- * ------ * ( ------- ) > 1 gal. 1 L \ 1 dm / > > This is actually a 3 step conversion, not the one-step > definition that Ralph originally had. You can see from the > formula above that the multiplier and scaling factor have to > go inside the exponent, not outside of it, otherwise you get > the wrong answer. Your calculation is certainly correct. When you simplify it you get: gallon = 3.758 (10^-1 m)^3, which is fine. If you want to express this as an sbml unit you will have to take the third root of 3.758 however: gallon = (3.758^(1/3) * 10^-1*m)^3. This is of course possible. The original point was just that with the original units (before the errata) this was not necessary, making this specific conversion simpler. And definitely not "erroneous". (I see there are other conversions that are simpler with the new way, see below) > What was happening with Ralph's example is simply that steps > were being left out. SBML's unit system is more elementary, > and the steps need to be made explicit to allow the > transformations to work. > > The proper position of the multiplier is not obvious when > using only SI units, which often only involve scaling > factors. As you know, when dealing with Imperial units, you > need the multipliers. The problem with the "old way" is > that if the multiplier is outside of the exponent, such > things as 12 inches to the foot do not get properly treated > when squares and cubes are involved. This is why the "old > way" was actually incorrect, and an erratum was issued back > in the days of L2v1. 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 new way : sqin = (2.54 * 10^-2 * m)^2 Now in this example the "new way" in more convenient, but both are correct. > > SS> Ralph´s point (as I understand it) is that with the > SS> old unit definition the multiplication of two units is > SS> almost trivial. (Multiplication of units is an > SS> operation that occurs frequently when > SS> checking/converting/handling units). > > Yes, multiplication is definitely a frequent need, and this > is exactly the purpose for which the "new" unit system is > designed! In fact, the offset term was removed exactly > because you could *not* use only multiplication when units > involve offsets. The decision was to simplify the unit > system exactly in the direction of making multiplication > straightforward. > I very much like that the offset is gone. > SS> unit definition (from the errata) multiplication of > SS> units is more complicated, less efficient, and > SS> probably looses more accuracy. > > I repeat my assertion: the reason it may *appear* more > complicated is because the examples Ralph and you are using > are simply incorrectly constructed :-(. The unit > conversions must break out the elementary steps (or at least > all the steps that don't result simply in a factor of 1.) > > SS> To illustrate: > SS> > SS> Multiplication of two unit definitions (base on the > SS> same base unit) in the old schema: > SS> > SS> (a * 10^b *u^c) * (d * 10^e * u^f) > SS> = (a*d) * 10^(b+e) * u^(c+f) > SS> > SS> In the new schema the solution would be: > SS> > SS> (a * 10^b *u)^c * (d * 10^e * u)^f > SS> = [ (a^c*d^f)^(1/(c+f)) * 10^((b*c+e*f)/(c+f)) * u ]^(c+f), > SS> > SS> and this is not yet normalized (the scale part needs > SS> to be integer), so another step is needed. > > Hmm. I'm missing something here. If I take > > (a * 10^b *u)^c * (d * 10^e * u)^f > > I get the following: > > (a^c * 10^{b*c} * u^c) * (d^f * 10^{e*f} * u^f) > = (a^c * d^f) * 10^(b*c + e*f) * u^(c+f) Yes, that´s correct, but that is not written in the "new" format, this is actually the "old" unit description, not having the scale and multiplier inside the parantheses. When you convert it you should get the expression I gave (unless I have done an error in calculation). > > (This is shown as formulas 3 and 4 in section 4.4.2 of the > L2v3 prerelease specification.) This term you could then > use to multiply some quantity in a first unit to convert it > to the second unit. I must be being dense here and missing > the point of the more complicated expression you have > written above. I think the unit conversion in single steps is what you would do manually. If I would program an algorithm for unit conversion I would take a more abstract view (for simplicity I am only talking about units with a single or compatible base unit): I have a value x in units u1. I want to know how to convert to unit u2. so: x * u1 = x * (u1 / u2) * u2 = x*factor*u2, where factor = u1*u2^(-1). If u1 and u2 are convertible, factor should be a dimensioless number (the unit conversion factor). To calculate the factor I need to do just one multiplication of units (and an inversion, but that´s trivial). Similarly checking unit consistency mainly requires doing multiplications of unit definitions (as far as I have figured out. Sarah probably knows more...). So Ralph´s original point was that multiplication of units is the most important thing you have to do with them, and it was simpler in the "old" (pre-errata) scheme. > In any case, I believe there is no problem here, only a > subtle misunderstanding of how to express the units > definitions. I´m sure if there is a problem at least it can be solved with software :) - Regarding how the units are displayed: This can transparently be handled by the software. It is a matter of preference if you want to look at litre as dm^3 or as 0.001m^3 - Regarding the handling and calculations regarding units: I still think they can be done more efficiently and accurately with the old scheme. But in principle you could always convert them to the "old way" before doing calculations and convert back afterwards. I think by now you can guess whether I would prefer to actually do it this way. Indeed, if all the involved units are "reasonable" (scales and exponents compatible, multipliers=1.0, SI or compatible base units) the problem is not that bad. Sven -- Sven Sahle Bioquant, Universität Heidelberg ____________________________________________________________ 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.

SubjectPosterDate
units in sbml l2v3 Ralph Gauges30 May '07 06:21
Re: units in sbml l2v3 Mike Hucka01 Jun '07 14:07
Re: units in sbml l2v3 Sven Sahle01 Jun '07 16:36
Re: units in sbml l2v3 Mike Hucka03 Jun '07 11:46
Re: units in sbml l2v3  Sven Sahle04 Jun '07 08:36
Re: units in sbml l2v3 Stefan.Hoops04 Jun '07 11:28
Re: units in sbml l2v3 Sven Sahle04 Jun '07 13:06
Re: units in sbml l2v3 Ralph.Gauges04 Jun '07 13:27
Re: units in sbml l2v3 Nicolas Le Novere04 Jun '07 13:58
Re: units in sbml l2v3 Nicolas Le Novere04 Jun '07 14:42
Re: units in sbml l2v3 Sven Sahle04 Jun '07 15:38
Re: units in sbml l2v3 Nicolas Le Novere05 Jun '07 00:47
Re: units in sbml l2v3 Sven Sahle05 Jun '07 03:59
Re: units in sbml l2v3 Mike Hucka06 Jun '07 23:19
Re: units in sbml l2v3 Mike Hucka06 Jun '07 23:42
 Previous Topic: DSMTS for SBML L2v3 Next Topic: Re: [Biomodels] Eight release of BioModels Database
 Go to forum: SBML Discussions    sbml-discuss    sbml-interoperability    sbml-announce    libsbml-development    jsbml-development