Forums

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.