| | 1 | {{{ |
| | 2 | |
| | 3 | > ... I work as a software developer ..., |
| | 4 | > creating a new modelling tool with extensive support for |
| | 5 | > measurement units. |
| | 6 | > |
| | 7 | > I found your paper "The Unified Code for Units of Measure" on |
| | 8 | > the Internet. If is very useful. |
| | 9 | > |
| | 10 | > I wonder if I may come with a few suggestions: |
| | 11 | > |
| | 12 | > 1) The introduction of month as base unit (it should really be |
| | 13 | > part of SI). |
| | 14 | |
| | 15 | Month is not introduced as a "base unit", that would not make sense. |
| | 16 | There are several different months, lunar, average calendar, etc. |
| | 17 | |
| | 18 | > Reason - month-based time and second-based time are not compatible |
| | 19 | > from a mathematical point of view, as a month is not a multiple of |
| | 20 | > seconds. |
| | 21 | |
| | 22 | agree |
| | 23 | |
| | 24 | > However, conversions can be made using a calendar as an |
| | 25 | > intermediate step. I have implemented this in our new software, and it |
| | 26 | > is very elegant to use, and it removes the burden from the modeller to |
| | 27 | > make sure that time is correctly handled. |
| | 28 | |
| | 29 | I've made attempts at specifying an abstract calendar which can map |
| | 30 | physical time to calendar time. So I am interested in seeing your |
| | 31 | work too. It has no direct bearing on UCUM though because we only |
| | 32 | deal with physical time, and there, month is at best imprecise and |
| | 33 | at worst ambiguous. Although UCUM takes all ambiguity out, it is |
| | 34 | not clear whether people will be always using units exactly as defined. |
| | 35 | |
| | 36 | > 2) The introduction of a point-unit concept in your standard. A point |
| | 37 | > unit has an origin and a scale. Point units are most useful with |
| | 38 | > temperatures and time (dates). Point units can also make sense in other |
| | 39 | > situations, for example meter above (or below) ocean level. A point unit |
| | 40 | > has an origin, a non-point unit does not. |
| | 41 | > |
| | 42 | > I am sure this distinction has been made before, but maybe you would be |
| | 43 | > interested in looking into how we have solved it. In shrt, all units |
| | 44 | > have the capability of being point units. When using the unit, a @ sign |
| | 45 | > is put in front of the name when the unit is treated as a point unit. If |
| | 46 | > the @ is omitted, the unit is treated as a normal unit. |
| | 47 | > |
| | 48 | > Examples: |
| | 49 | > |
| | 50 | > 10 @C is the temperatur equal to 273.15+10 kevin, i.e. 283.15 @K |
| | 51 | > |
| | 52 | > 10 C is a temperature difference equal to 10 kelvin, i.e. 10 K. |
| | 53 | > |
| | 54 | > 2000 @year is the year 2000, measured in month-time. It is equal to |
| | 55 | > date(2000). |
| | 56 | > |
| | 57 | > 100 year is one hundred years of time, measured in month-time, i.e. |
| | 58 | > the same as 1200 months. |
| | 59 | > |
| | 60 | > 1 @s is the point-in-time one second after the origin of time, as |
| | 61 | > defined for the second-unit. In our implementation it is set to |
| | 62 | > 1.1.2000. The value is the same as date(2000, Jan, 1, 0, 0, 1). |
| | 63 | |
| | 64 | We have "special units" that use conversion functions. I agree that this |
| | 65 | might be a feature for an implementation, I'd be concerned at how people |
| | 66 | would use this. The calendar examples you give seem to be out of the scope |
| | 67 | of a units of measure standard. We have other standards for expressing |
| | 68 | points in time on a calendar. |
| | 69 | |
| | 70 | > Rules for the use of units can be checked by the software. They are: |
| | 71 | > |
| | 72 | > point + normal = point |
| | 73 | > |
| | 74 | > normal + normal = normal |
| | 75 | > |
| | 76 | > point - normal = point |
| | 77 | > |
| | 78 | > normal - normal = normal |
| | 79 | > |
| | 80 | > point - point = normal |
| | 81 | > |
| | 82 | > point + point is illegal |
| | 83 | |
| | 84 | I agree to those rules, but I think that these point measures are outside |
| | 85 | the scope of units. Units do not replace the need to specifying the property |
| | 86 | that is being measured. And these distinctions seem to be in the properties. |
| | 87 | |
| | 88 | > The symbol ° can be used as an alternative to @. This means that 10 °K |
| | 89 | > is the temperature 10 kelvin, whereas 10 K is a temperature difference |
| | 90 | > (delta) of 10 kelvin. |
| | 91 | > |
| | 92 | > A unit is defined like this: |
| | 93 | > |
| | 94 | > 1) Units with origin = zero: |
| | 95 | > |
| | 96 | > name = normal unit expression |
| | 97 | > |
| | 98 | > Example: cm = 0.001 m |
| | 99 | > |
| | 100 | > 2) Units with origin <> zero |
| | 101 | > |
| | 102 | > name = @(scale, origin) |
| | 103 | > |
| | 104 | > Where origin must be a point unit expression, and scale a normal unit |
| | 105 | > expression. |
| | 106 | > |
| | 107 | > Examples: |
| | 108 | > |
| | 109 | > C = @(1K, 273.15@K) |
| | 110 | > |
| | 111 | > F = @(5/9*C, (5/9*32)@C) |
| | 112 | > |
| | 113 | > The syntax @(scale,origin) is easy to read for humans and easy to parse |
| | 114 | > for software. Maybe you can consider it for your Unified Code for Units |
| | 115 | > of Measure. |
| | 116 | |
| | 117 | I don't know if this syntax is relevant for the *use* of UCUM unit |
| | 118 | rather than for their *definition*. For defining Cel and degF we |
| | 119 | are applying a similar, yet more general approach using the conversion |
| | 120 | function pair. Your proposal suggets to add a special case for these |
| | 121 | linear conversions. |
| | 122 | |
| | 123 | > There are some minor mistakes in the document, that you may want to |
| | 124 | > correct. In particular, horse power is defined as: |
| | 125 | > |
| | 126 | > [ft_i].[lbf_av]/s |
| | 127 | > |
| | 128 | > However, lbf_av does not exist. It is called lb_av. |
| | 129 | |
| | 130 | But [lbf_av] is defined. It is |
| | 131 | |
| | 132 | pound force force 1 [lbf_av] = 1 [lb_av].[g] |
| | 133 | |
| | 134 | > Here is a sentence that you should look more closely at: "Hence, the |
| | 135 | > symbols for the U.S. survey foot and the British Imperial foot are |
| | 136 | > defined as “|[ft_i]|,” “|[ft_us]|,” and “|[ft_br]|” respectively." (ch. |
| | 137 | > 4.4). |
| | 138 | |
| | 139 | I fixed this immediately to include international foot lining up the |
| | 140 | respective items. Thanks. |
| | 141 | |
| | 142 | }}} |
