Re: A slightly different take on the quantity library

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2001-09-03 02:14:47

>   From: Deane_Yang_at_[hidden]
>
>The quantity library that is being discussed here is a much
>more ambitious effort that does not do what I need. I would
>like to see a smaller, simpler library broken out of it that I think
>would be much more useful to more people. After all, how many 
>people really need to work with all these different physical units?
>I'm willing to bet that even in most physics-oriented software only 
>a limited number of units are really needed.

It is true that only a few units at a time are used, but this does not
make it any more complex. Or rather, removing them does not necessarily
make anything any simpler.

A quantity library essentially has two layers: the layer that defines
the quantities and their operations (which are templated), and another
facility layer above it that defines the common constants in the
appropriate units. I believe that you will find that you will end up
putting back much of what you remove, because the core of the library is
not that large.

>I want a small library that does not associate units with specific 
>physical or geometric concepts (like distance, mass, time).

In which case, I believe that you are saying they are non-combinable.
How do you intend to support common usage of multiplication and
division, eg velocity = distance / time? Or have I misunderstood what
your intent?

>In particular, I do not want the library to assume that different 
>units measuring the same "quantity" are necessarily convertible 
>into each other. I do want explicit casts required to convert one 
>unit into another.

Hmm, what benefit do you believe this has? Just because we humans aren't
that good at converting between different unit systems, I'm not sure
that our programs should suffer the same limitations!

>My main example are the calendar units of time: days, weeks, 
>months, years. These are all "units" of time, but only a few 
>conversions should be allowed. Conversion between days and 
>years should simply be forbidden. Not that you never do it, but if 
>you do, you better do it explicitly yourself and clearly document 
>how you are doing it (is it 360, 365 or 365.25 days per year?).
>But conversions of days to weeks or months to years should be 
>allowed (still, I prefer an explicit cast).

Ah, but calendar time is a slightly different kettle of fish to what we
have been talking about. I believe that you need to differentiate a few
issues here: an absolute point in time (ie a date) and an interval of
time (ie a duration); presentation and representation. And you also need
to introduce a context: astronomy, accounting or...? This will bound a
few of the open ended questions that normally pop up when dealing with
dates. Eg a solar year is a well defined value that should be freely
convertible to days (solar or sidereal).

>And, as for the question of mixing units of different orders of 
>magnitude in one application, how about a program that uses
>calendar units for time, but also wants to measure, say, 
>execution time in milliseconds?

Yes, this is more like the question I raised about different orders of
magnitude.

>The other thing is that even if there is an obvious conversion, I 
>don't necessarily want the quantity library to do it implicitly,
>because there is a good chance that it is a sign of a design
>or implementation error. A library that allows implicit conversion 
>should be built as a wrapper around a library that does not.

Most of the design errors I have ever come across are related to
dimensions rather than units. And, in the cases that units have mattered
(eg Mars) a quantity library that supported free conversion would have
prevented the problem in the first place -- if someone has the perverse
desire to use feet per second to measure the velocity of an
interplanetary object, then it has to say so in the code!

>The library I have in mind is much, much smaller than the 
>quantity library and therefore maybe not worth the time and 
>attention. Some day I hope to find the time to present my feeble 
>efforts in this direction in more detail. 

I wouldn't consider them feeble at all! And I would consider these
directions interesting, and would like to know more of your thinking on
the matter. However, I am not sure that what you are proposing is
necessarily smaller than the quantity library designs we are discussing.

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  mailto:kevlin_at_[hidden]     mobile: [phone]
  http://www.curbralan.com        fax:    [phone]
  Curbralan: Consultancy + Training + Development + Review
____________________________________________________________