# Forums

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

Posts: 27
Registered:
September 2003

Posts: 961
Registered:
October 2003
 Re: units in sbml l2v3 01 Jun '07 14:07 Hi Ralph, Thanks for delving deeply into SBML units. The editors have been trying to get the SBML spec out today, so I hope I'm not too brain-drained to avoid mistakes in this reply, but here it goes: RG> In the old spec, the fomula was given as: RG> multiplier * 10^scale * u^exponent RG> after the change, then formula is supposed to be: RG> (multiplier * 10^scale * u)^exponent Yes. Here's a simple example to illustrate: if 1 foot = 0.3048 metres, how much is 1 square foot in metres? unitDefinition id="sq_foot" unit kind="metre" multiplier="0.3048" exponent="2" scale="0" This SBMLish unit expression means (0.3048 * metre)^2 = 0.0929 metres^2 I think we will agree this is correct? Note that the exponent has to encompass the multiplier in this case. OK, now to the gallon-to-cubic-metres case you gave: 1 gallon = 3.785411784 litres 1 litre = 1 cubic decimetre = 0.001 metre^3 To see how to turn this into SBML's units, first let's do the litres-to-metres one for illustration (even though litre is predefined in SBML): unitDefinition id="litre" unit kind="metre" multiplier="0.1" exponent="3" which is to say, (0.1 * metre)^3 = 0.001 metres^3 This also checks out. Now, for the gallon case, it may seem as though you want to define one big unit with 3.785411784 as the multiplier, but it is not so. The reason is if you want to define a gallon directly in terms of a length measurement, the unit definition must be in terms of the length of a cube that holds a gallon. This is not the same as the defining a gallon in terms of another volume measurement (which is what using 3.785411784 as a multiplier would be). The former would indeed require a cube root somewhere along the way. Thus, I would argue that this case calls for two "unit" objects inside one unitDefinition: unitDefinition id="gallon" unit kind="dimensionless" multiplier="3.785411784" unit kind="metre" multiplier="0.1" exponent="3" This seems pretty clean and straightforward, although I have to admit, now that I look at the spec, the spec doesn't make this approach immediately obvious. One of your other examples confused me, however: RG> Lets assume you want to multiply 2.0 * 10^-3 m^2 with RG> 3.0 * 10^-5 m^3. The result should be 6.0 * 10^-8 RG> m^5. I don't understand which is the unit and which is the quantity. E.g., In the case of the "2.0 * 10^-3 m^2", are you trying trying to define a single unit equal to "two square millimetres"? (10^-3 m^2 would be square millimetres, I think?) If you do indeed mean to use strange multipliers, I think here again you would pull out the part that's the actual unit of measurement from the part that's the fraction of the measurement, and use the unit-composition trick to define the fraction separately from the unit of measurement, as in the following: unitDefinition id="funky_new_unit" unit kind="dimensionless" multiplier=".002" unit kind="metre" exponent="2" or something along those lines. But I think I'm not understand the intended units in that example. In any case, I hope this clarifies a little bit of the thinking behind the unit definition scheme and provides a method for outright avoiding some of the complicated fractions and roots. What do you think about this? MH ____________________________________________________________ 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.

Posts: 82
Registered:
September 2003
 Re: units in sbml l2v3 01 Jun '07 16:36 Hello Michael, hello all, On Friday 01 June 2007 23:07:29 Michael Hucka wrote: > RG> Lets assume you want to multiply 2.0 * 10^-3 m^2 with > RG> 3.0 * 10^-5 m^3. The result should be 6.0 * 10^-8 > RG> m^5. > > I don't understand which is the unit and which is the > quantity. E.g., In the case of the "2.0 * 10^-3 m^2", are > you trying trying to define a single unit equal to "two > square millimetres"? (10^-3 m^2 would be square > millimetres, I think?) Yes, I think Ralph was only talking about units, no values involved. Actually the units Ralph used as an example are quite arbitrary and would not reallistically be used. 2*10^-3 m^2 is not 2 square mm but rather 0.002 sqare meters. Your example about square feet is valid: I you want to express square feet with meter as base unit, the new way is more intuitive. On the other side, if you want to express gallons with meter as base unit, the old way was more intuitive. Ralph´s point (as I understand it) is that with the old unit definition the multiplication of two units is almost trivial. (Multiplication of units is an operation that occurs frequently when checking/converting/handling units). With the new unit definition (from the errata) multiplication of units is more complicated, less efficient, and probably looses more accuracy. As far as I can see, in principle both ways to handle units can do everything that is needed. I just cannot see why the old way was wrong, and I agree with Ralph that the old way is probably easier to handle. To illustrate: Multiplication of two unit definitions (base on the same base unit) in the old schema: (a * 10^b *u^c) * (d * 10^e * u^f) = (a*d) * 10^(b+e) * u^(c+f) In the new schema the solution would be: (a * 10^b *u)^c * (d * 10^e * u)^f = [ (a^c*d^f)^(1/(c+f)) * 10^((b*c+e*f)/(c+f)) * u ]^(c+f), and this is not yet normalized (the scale part needs to be integer), so another step is needed. In some cases this will not be a problem. a and d will often be 1.0, and ((b*c+e*f)/(c+f)) will quite often be an integer, in which case evrything is fine. In the general case, however, we may have to use floating point operations for exponents, which looses accuracy and makes the exact comparison of units difficult, or, we should use exact rational numbers as exponents, which is much more complicated from a developers point of view. > If you do indeed mean to use strange multipliers, I think > here again you would pull out the part that's the actual > unit of measurement from the part that's the fraction of the > measurement, and use the unit-composition trick to define > the fraction separately from the unit of measurement, as in > the following: > > unitDefinition id="funky_new_unit" > unit kind="dimensionless" multiplier=".002" > unit kind="metre" exponent="2" > > or something along those lines. But I think I'm not > understand the intended units in that example. OK. I see. Using this trick you can force to more or less use the old way of handling units. I didn´t think of this. 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.

Posts: 961
Registered:
October 2003
 Re: units in sbml l2v3 03 Jun '07 11:46 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. 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. 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. 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) (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. In any case, I believe there is no problem here, only a subtle misunderstanding of how to express the units definitions. MH ____________________________________________________________ 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.

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.

Posts: 170
Registered:
December 2006
 Re: units in sbml l2v3 04 Jun '07 11:28 Hello All, I would like to make an attempt to look at his problem more from an XML standpoint and hopefully reduce the confusion. Let us look at two equivalent and valid definitions of the unit dezimetre: A) or B) Let us now define a unit liter (Note, not litre as this is a base unit) Up to this point I think everyone agrees. Please note that the exponent 3 in the above definition of liter can be replaced by the following equivalent definition: Replacing in this last definition dm with its definition leads A) or B) Now we are coming to the problem which is the root of this discussion. Let us make an attempt to reintroduce the exponent 3. I naively (not looking at the SBML specifications) would have written: A) or B) This makes obvious that scale and multiplier should be treated equally. There is also another more abstract way to look at it. The whole scheme works perfectly fine without the scale attribute since the multiplier is a double and thus treating them differently would create an obvious inconsistency. Another confusion stems from the interpretation. Above I have defined liter in terms of metre. If I want to define it in terms of cubic meters I again have two choices: A) or B) With the definition of cubic meters being: Note here I am not able to apply the simple replace mechanism used before. The reason for this is that m3 is metre to the power 3. This becomes more clear if I rewrite the definition of cubic meter in the following way: Thus to rewrite liter in metre^3 I have to take the 3rd root of either the scale or the multiplier yielding: A) or B) My conclusion from the above examples is that the current interpretation and rules given in the specification are correct. They are simple and straight forward. I do not see the possibility to treat multiplier and scale differently especially because of the reason that every scale can be rewritten as a multiplier thus leading to a different result. Thanks, Stefan -- Stefan Hoops, Ph.D. Senior Project Associate Virginia Bioinformatics Institute - 0477 Virginia Tech Bioinformatics Facility I Blacksburg, Va 24061, USA Phone: (540) 231-1799 Fax: (540) 231-2606 Email: shoops@vbi.vt.edu ____________________________________________________________ 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.

Posts: 82
Registered:
September 2003
 Re: units in sbml l2v3 04 Jun '07 13:06 Hello Stefan, hello all, I don´t quite understand this. The old definition was: unit = multiplier * 10^scale * baseunit^exponent The new definition (from the errata) is: unit = (multiplier * 10^scale *baseunit)^exponent In both cases the multiplier is handled the same as 10^scale. Originally the exponent applied to none of them, now it applies to both. You are completely right that in principle multiplier*10^scale could be replaced by one number. On Monday 04 June 2007 20:28:15 Stefan Hoops wrote: > Hello All, > > I would like to make an attempt to look at his problem more from an XML > standpoint and hopefully reduce the confusion. Let us look at two > equivalent and valid definitions of the unit dezimetre: > A) > > > > > > or B) > > > > > > > Let us now define a unit liter (Note, not litre as this is a base unit) > > > > > "dm" is a valid value for kind? > > Up to this point I think everyone agrees. Please note that the exponent > 3 in the above definition of liter can be replaced by the following > equivalent definition: > > > > > > > > > Replacing in this last definition dm with its definition leads > A) > > > > > > > > or B) > > > > > > > > > Now we are coming to the problem which is the root of this discussion. > Let us make an attempt to reintroduce the exponent 3. I naively (not > looking at the SBML specifications) would have written: > A) > > > > > > or B) > > > > > > This is correct with the current specification. > This makes obvious that scale and multiplier should be treated equally. > There is also another more abstract way to look at it. The whole scheme > works perfectly fine without the scale attribute since the multiplier is > a double and thus treating them differently would create an obvious > inconsistency. > > Another confusion stems from the interpretation. Above I have defined > liter in terms of metre. If I want to define it in terms of cubic meters > I again have two choices: > A) > > > > > > or B) > > > > > I think nested unit definitions are not allowed in sbml. > With the definition of cubic meters being: > > > > > > > Note here I am not able to apply the simple replace mechanism used > before. The reason for this is that m3 is metre to the power 3. This > becomes more clear if I rewrite the definition of cubic meter in the > following way: > > > > > > > > > Thus to rewrite liter in metre^3 I have to take the 3rd root of either > the scale or the multiplier yielding: > A) > > > > > > or B) > > > > > > > My conclusion from the above examples is that the current > interpretation and rules given in the specification are correct. They > are simple and straight forward. I do not see the possibility to treat > multiplier and scale differently especially because of the reason that > every scale can be rewritten as a multiplier thus leading to a different > result. > Yes, the current interpretation is certainly correct. As was the old one. Both treat 10^scale and multiplier the same. From the two possible choices I still prefer the old definition. A new example (I know it will hopefully never occur in a kinetic function, but as a software developer I need to be prepared for this): I want to multiply two units. New definition: (1*10^1*mol)^2 * (1*10^0*mol) = 1*10^2*mol^3. Now I have to do an additional step to convert this to sbml compatible structure: 1*10^2*mol^3 = (1*10^(2/3)*mol)^3. I am now forced to put the result of the multiplication of the scales (10^(2/3)) into the multiplier because it is not anymore an integer scale. This is of course possible, just not convenient. Now the same in the original definition: (1*10^2*mol^2) * (1*10^0*mol) = 1 * 10^2 * mol^3 This is straight forward, looses no accuracy at all (no need to calculate a root, actually no lossy floating point operations at all, if I asume that 1.0*1.0 can be calculated exactly). > Thanks, > Stefan 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.

Posts: 92
Registered:
May 2004

Posts: 469
Registered:
October 2003
 Re: units in sbml l2v3 04 Jun '07 13:58 > 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. Let's take another one, more explicit (I hope): a density of molecule expressed in micromole per square inches: 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. -- Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK Tel: +44(0)1223494521, Fax: +44(0)1223494468, Mob: +44(0)7833147074 http://www.ebi.ac.uk/~lenov, AIM:nlenovere, MSN:nlenovere@hotmail.com ____________________________________________________________ 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.

Posts: 469
Registered:
October 2003
 Re: units in sbml l2v3 04 Jun '07 14:42 > Sven, here is the misunderstanding. In the old way, you do not have the > first exponent. Your example is too simple. Let's take another one, more > explicit (I hope): a density of molecule expressed in micromole per square > inches: > > > > > > > > > OK, wrong one. Here it is again (actually this is even better than I thought): 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. -- Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK Tel: +44(0)1223494521, Fax: +44(0)1223494468, Mob: +44(0)7833147074 http://www.ebi.ac.uk/~lenov, AIM:nlenovere, MSN:nlenovere@hotmail.com ____________________________________________________________ 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.

Posts: 82
Registered:
September 2003
 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 > inches: > > > > > > > > > > > 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 problem) 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: 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 more intuitive. What I really do not get at all is: Why do you consider the old interpretation "wrong"? It´s just a mathematical definition. Old: Unit=multiplier*10^scale*baseunit^exponent New: Unit=(multiplier*10^scale*baseunit)^exponent 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 development. -- 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.

Posts: 469
Registered:
October 2003
 Re: units in sbml l2v3 05 Jun '07 00:47 On Tue, 5 Jun 2007, Sven Sahle wrote: > 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: > > > > > > > > > > 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 > more intuitive. > > What I really do not get at all is: Why do you consider the old > interpretation "wrong"? It´s just a mathematical definition. > > Old: Unit=multiplier*10^scale*baseunit^exponent > New: Unit=(multiplier*10^scale*baseunit)^exponent Sven, you are right of course. But a little unfair. To be honest, at the time of L2V1 release I don't think the majority of people writting unit conversion software would have considered as the correct way to encode for "per square inch". This is what we would write now after all the discussions we had, in order to tweak the broken unit system to nevertheless get the result right. I may be wrong, so I'll stop here. It seems we all agree anyway :-) -- Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK Tel: +44(0)1223494521, Fax: 468, Mob: +44(0)7833147074 Skype:n.lenovere http://www.ebi.ac.uk/~lenov, AIM: nlenovere, MSN: nlenovere@hotmail.com

Posts: 82
Registered:
September 2003
 Re: units in sbml l2v3 05 Jun '07 03:59 Hello all, On Tuesday 05 June 2007 09:47:50 Nicolas Le Novere wrote: > Sven, you are right of course. But a little unfair. To be honest, at the > time of L2V1 release I don't think the majority of people writting unit > conversion software would have considered > > > > as the correct way to encode for "per square inch". This is what we would > write now after all the discussions we had, in order to tweak the broken > unit system to nevertheless get the result right. > > I may be wrong, so I'll stop here. It seems we all agree anyway :-) I also think we agree on this. But the remaining question is: Now (before the release of the new libsbml) would be the last opportunity to revert the unit interpretation to the original form. Should we do this? I personally (thinking of some things I want to implement) like the old way better. 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.

Posts: 961
Registered:
October 2003
 Re: units in sbml l2v3 06 Jun '07 23:19 >>>>> On 5 Jun 2007, Sven Sahle wrote: SS> Hello all, On Tuesday 05 June 2007 09:47:50 Nicolas Le Novere wrote: >> I may be wrong, so I'll stop here. It seems we all >> agree anyway :-) SS> I also think we agree on this. I think there is misunderstanding about what is being agreed upon :-). I'm pretty sure Nicolas was *not* saying there is agreement is about reverting to the "old" way.... MH ____________________________________________________________ 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.

Posts: 961
Registered:
October 2003
 Re: units in sbml l2v3 06 Jun '07 23:42 SS> I don´t see why the "old way" should not allow a SS> correct calculation. I understand that square inches SS> look nicer with the "new way" but that does not make SS> the "old way" incorrect. SS> SS> in = 2.54 * 10^-2 * m SS> SS> old way : sqin = 2.54^2 * 10^-4 * m^2 SS> new way : sqin = (2.54 * 10^-2 * m)^2 Sven, This must be getting close to the root of the problem, because I don't understand how you are getting the "old way" answer above. The L2v1 definition of the unit formula is: scale exponent u = multiplier * 10 * u new original How did you end up applying the exponent to both 2.54 and 10^-2 in the input unit of your example? 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) = (a*d) * 10^(b+e) SS> * 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 SS> ]^(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) SS> SS> Yes, that´s correct, but that is not written in the SS> "new" format, this is actually the "old" unit SS> description, not having the scale and multiplier SS> inside the parantheses. I am baffled. The expression (a * 10^b *u)^c * (d * 10^e * u)^f is precisely the "new way" formula. It has the multiplier and scale inside the parentheses. Perhaps I should have written it as (m_1 * 10^s1 * u)^e1 * (m_2 * 10^s2 * u)^e2 Now, assuming that m_1 and m_2 are real numbers, couldn't the result of this expression be written as (m_1^e1 * m_2^e2) * 10^(s1*e1 + s2*e2) * u^(e1+e2) ? Maybe I'm the one doing this wrong. If not, then I submit to you that this expression is the new way, not the old way. SS> I think the unit conversion in single steps is what SS> you would do manually. OK, but here I disagree; I always have to bring it to the separate steps, otherwise I confuse myself (which for me is not hard to do ;-)). SS> I have a value x in units u1. I want to know how to SS> convert to unit u2. so: x * u1 = x * (u1 / u2) * u2 = SS> x*factor*u2, where factor = u1*u2^(-1). This is a small point, but again, I must be missing something. If you are converting a quantity x in units u1 to a quantity y in units u2, you have to put x1 on the *right-hand* side, not the left-hand side, like this: u2 y * u2 = x * u1 * ---- u1 Is this a bad way to think about it? (In this case it doesn't make a big difference because the factor is simply the reciprocal of your version.) MH ____________________________________________________________ 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.
 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