Open timbrisc opened 7 years ago
l and L are synonyms, yes. The Europeans tend to write l and the Americans tend to write L. The standard we were based on allowed both, so we kept with that.
But semantically there is no difference. So, saying that the UCUM considers l and L to be "two different distinct units" in case-sensitive mode. is really not quite true. The semantic equality is l # L including in all derived units. mg/lmg/L, l/min = L/min, etc.
At the semantic level, 1 L or 1 l are both 10^-3^ m2.
The equivalence of units is determined by implementing the semantics of the factor and vector of exponents. Then you know they are the same. Because remember that 1 cm3 = 1 mL as well.
I'm not sure what you mean by "synonyms". I understand that the units are equivalent, that is, if you use either you get the same quantity of something. But are they really the same unit?
At first I thought that UCUM made
L
andl
the same unit. But then I took look at some of the other UCUM units. In UCUM a "Maxwell" (Mx
) is defined as1 Wb
, and a "weber" (Wb
) is defined as1 V.s
. But we don't think thatMx
andWb
are the same units. They are equivalent in that if I convert1 Mx
toWb
then I get1 Wb
and not23 Wb
. But they are distinct units.Analogously I'm forced to read the UCUM as saying that if I (in case-sensitive mode) convert
1 L
tol
then I will get1 l
, but thatL
andl
are nonetheless distinct units.So would you say that
Mx
andWb
are "synonyms"? What I'm trying to get at is, are they the same unit? If someone records in a file23 Mx
and I parse that in, can I turn around and save back to the file23 Wb
? Didn't I lose some semantics by switching units? Or are you saying thatMx
andWb
are the same unit, and UCUM doesn't care if a processor mixes and matches them on a whim? Because it seems that whatever answer you give forMx
andWb
, you would have to use the same logic forL
andl
, respectively (and vice-versa).
Also analogously, think of "stere" (
st
). This also has an equivalence to liters. In fact in a "bug" we ran into inuom-systems
Issue 96 [https://github.com/unitsofmeasurement/uom-systems/issues/96]. The implementation read inuL
, but then it printed outnst
.Nanostere is apparently a "synonym" of
uL
according to your definition. But is it really OK to arbitrarily switch units like that? Surely you would agree that thatnst
anduL
are "distinct units", even though they are "semantically equivalent", don't you? And according to the UCUM definitions, it seems to me that I am forced to conclude thatl
andL
are "distinct units" as well, even though they are "semantically equivalent".I would be happy if you could show me where my logic went awry, as I don't really like the conclusion. But logically I don't see any other way, unless you try to convince me that
Mx
andWb
are the same units, and thatuL
andnst
are the same units. (We all agree that they indicate the same quantity for some measurement value; the issue is whether they are distinct units.)
Of course a "stere" is nothing else than a cubic meter or a thousand liters. There is no difference. If you can write 1 st = 1000 L in a physical equation and it is correct, then it is correct for UCUM to say that they are equivalent units.
Any further discussion needs to be based on the precise definition of the ideas we are using.
In UCUM we say the 1 mst is equal to a 1 l just like 1 L is equal to 1 l.
The symbolic expressions of these units are different, but the meaning is exactly the same and no further difference should be made. If you like to use "mst" be my guest, while I use "L" and Françoise Bourdon over there may use "l". Through UCUM knowing about the physics of units, we all understand each other.
First of all thank you for the discussion. And I can understand where you are coming from: you're saying that analogously it doesn't matter if a user records
1234.56
and the system later shows1.23456e+3
--- they are both the same value, and no one should ever care.Yet from a practical standpoint it could be less than satisfactory for some users if a doctor entered
3 uL
for some medication and later the system displayed3 nst
. This representation could be confusing to humans who, within a particular domain, are used to working with liters but not with steres. It seems to me that distinguishing between distinct units still has some utility. (But perhaps you would say that "display to humans" is outside the scope of the UCUM.)The Europeans tend to write l and the Americans tend to write L. The standard we were based on allowed both, so we kept with that.
I think that the problem here stems from the decision you indicated above. I had hoped that the UCUM would be a standard that provides a single, unambiguous syntactical representation for each unit. In most cases this is true, but it seems that for "liter" UCUM made a special case and tried to make this symbol case-insensitive even in case-sensitive mode.
As such if a processor wants to remember the units entered by a user, for example, it will need special processing logic to remember that
l
andL
are really different ways to write the same unit (even in case-sensitive mode), whileMx
andWb
are really different units and shouldn't be mixed. That is, in order to follow user intention, if we want to give the value back to the user in the same units as the user gave them the processor has to know thatl
andL
are the same (even in case-sensitive mode), but thatMx
andWb
are not. This extra logic is a special case for liter and does not apply to any other unit.
Yes, AKAIK Litre (Liter) is a special case in UCUM, in which two different codes are the case-sensitive code for units with identical definitions. This is a historical quirk. There are plenty of historical quirks in units, and on the whole UCUM has done a brilliant job cleaning up. In another life maybe a different decision could have been made, but this has been in UCUM for many years and I think we must live with it now. The only cost is that one of the symbols (either 'l' or 'L') is now sterilized from being used for something else.
Propose to close with status 'wontfix'.
Issue migrated from trac ticket # 195
component: help | priority: major
2017-03-13 13:37:44: garret@globalmentor.com created the issue