[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Measurement conversion concepts
From: |
Busser, Jim |
Subject: |
Re: [Gnumed-devel] Measurement conversion concepts |
Date: |
Sun, 1 Dec 2013 19:34:51 +0000 |
Further on this, I was wondering about the method of lookup / linkage to a
conversion table… I gather these involve
public.basic_unit (name_short, name_long)
public.unit (fk, name_short, name_long, factor, shift)
Is it intended that
public.basic_unit involves only these:
http://www.unc.edu/~rowlett/units/sifundam.html
?? and what of things like prefix handling?
Here are some scenarios:
(1) involving shift -- I can think only of Fahrenheit and Celsius which would,
in public.unit (not ref?) be
(fk to F) C Celsius 1.8 32
(fk to C) F Fahrenheit 0.55 -32
but noting that while the first conversion depends on a natural order of
operations
C ---> F = C x 1.8 + 32
going the other way, one must do
F ---> C = (F - 32) x 0.55 requiring parentheses
i.e. they are not symmetric. This case maybe has to be individually provided
for in whatever is the converting function. Is this an isolated case, or is
anyone aware of any other biological measurements that involve (require) a
shift?
(2) general cases where the measurements are what I will call "substrate
independent", for example in expressing a length … in the following example of
row population, I have omitted long names:
(fk to cm) m 100 0
(fk to cm) mm 0.1 0
(fk to cm) in 2.54 0
(fk to cm) ft 30.48 0
… these can all share the same conversion factors without any need for each of
test_type.conversion_unit (where name = height)
test_type.conversion_unit (where name = abdominal circumference)
test_type.conversion_unit (where name = aortic aneurism dimension)
but do we require multiple sets of such rows, one set of 4 values where we
rotate in
public.basic_unit in {mm, cm, m, in, ft) keyed from a set of 4 rows in
public.unit {one row each for the other 4 among mm, cm, m, in, ft}
??
and also do we need each item in public.basic_unit to *also* appear in
public_unit with a conversion of 1 ("unity")?
(3) in the case of derived units, consider
hemoglobin (mg / dL --> g/L)
… should there be a value in public.basic_unit
g/L
with matching values in public.unit {g/L, mg/dL}
… or should each component in the expression
mg and dL
have to resolve to components in public.basic_unit
mg to g
dL to L
and then be multiplied through by the component factors?
(4) what about when the units in question are substrate-dependent and involving
things like molecular weights and valences
mg/dL vs umol/L Calcium vs 1 mEq
http://sitemaker.umich.edu/tutorial/files/handout_milliequiv.pdf
http://www.unc.edu/~rowlett/units/index.html
-- JIm
- Re: [Gnumed-devel] Measurement conversion concepts,
Busser, Jim <=
- Re: [Gnumed-devel] Measurement conversion concepts, Karsten Hilbert, 2013/12/01
- Re: [Gnumed-devel] Measurement conversion concepts, Busser, Jim, 2013/12/01
- Re: [Gnumed-devel] Measurement conversion concepts, Busser, Jim, 2013/12/02
- Re: [Gnumed-devel] Measurement conversion concepts, Busser, Jim, 2013/12/02
- Re: [Gnumed-devel] Measurement conversion concepts, Karsten Hilbert, 2013/12/02
- Re: [Gnumed-devel] Measurement conversion concepts, Busser, Jim, 2013/12/02
- Re: [Gnumed-devel] Measurement conversion concepts, Busser, Jim, 2013/12/05
- Re: [Gnumed-devel] Measurement conversion concepts, Busser, Jim, 2013/12/06
Re: [Gnumed-devel] Measurement conversion concepts, Karsten Hilbert, 2013/12/02