Changes between Initial Version and Version 1 of CommentsSoftwareDeveloperNorway

Nov 13, 2007, 8:35:30 PM (13 years ago)
Gunther Schadow



  • CommentsSoftwareDeveloperNorway

    v1 v1  
     3> ... I work as a software developer ...,
     4> creating a new modelling tool with extensive support for
     5> measurement units.
     7> I found your paper "The Unified Code for Units of Measure" on
     8> the Internet. If is very useful.
     10> I wonder if I may come with a few suggestions:
     12> 1) The introduction of month as base unit (it should really be
     13> part of SI).
     15Month is not introduced as a "base unit", that would not make sense.
     16There are several different months, lunar, average calendar, etc.
     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.
     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.
     29I've made attempts at specifying an abstract calendar which can map
     30physical time to calendar time. So I am interested in seeing your
     31work too. It has no direct bearing on UCUM though because we only
     32deal with physical time, and there, month is at best imprecise and
     33at worst ambiguous. Although UCUM takes all ambiguity out, it is
     34not clear whether people will be always using units exactly as defined.
     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.
     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.
     48> Examples:
     50>     10 @C is the temperatur equal to 273.15+10 kevin, i.e. 283.15 @K
     52>     10 C is a temperature difference equal to 10 kelvin, i.e. 10 K.
     54>     2000 @year is the year 2000, measured in month-time. It is equal to
     55> date(2000).
     57>     100 year is one hundred years of time, measured in month-time, i.e.
     58> the same as 1200 months.
     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).
     64We have "special units" that use conversion functions. I agree that this
     65might be a feature for an implementation, I'd be concerned at how people
     66would use this. The calendar examples you give seem to be out of the scope
     67of a units of measure standard. We have other standards for expressing
     68points in time on a calendar.
     70> Rules for the use of units can be checked by the software. They are:
     72>     point + normal = point
     74>     normal + normal = normal
     76>     point - normal = point
     78>     normal - normal = normal
     80>     point - point = normal
     82>     point + point is illegal
     84I agree to those rules, but I think that these point measures are outside
     85the scope of units. Units do not replace the need to specifying the property
     86that is being measured. And these distinctions seem to be in the properties.
     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.
     92> A unit is defined like this:
     94> 1) Units with origin = zero:
     96> name = normal unit expression
     98> Example: cm = 0.001 m
     100> 2) Units with origin <> zero
     102> name = @(scale, origin)
     104> Where origin must be a point unit expression, and scale a normal unit
     105> expression.
     107> Examples:
     109>     C = @(1K, 273.15@K)
     111>     F = @(5/9*C, (5/9*32)@C)
     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.
     117I don't know if this syntax is relevant for the *use* of UCUM unit
     118rather than for their *definition*. For defining Cel and degF we
     119are applying a similar, yet more general approach using the conversion
     120function pair. Your proposal suggets to add a special case for these
     121linear conversions.
     123> There are some minor mistakes in the document, that you may want to
     124> correct. In particular, horse power is defined as:
     126> [ft_i].[lbf_av]/s
     128> However, lbf_av does not exist. It is called lb_av.
     130But [lbf_av] is defined. It is
     132pound force     force           1 [lbf_av] = 1 [lb_av].[g]
     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).
     139I fixed this immediately to include international foot lining up the
     140respective items. Thanks.