Re: Units (and operators.hpp, too)

From: Deane_Yang_at_[hidden]
Date: 2001-06-30 20:54:39

--- In boost_at_y..., "Corwin Joy" <cjoy_at_h...> wrote:
> (discussion about using units in finance omitted)

You make some good points (especially the dynamic units
and the idea of tying daycounts to both interest rates
and time untis), but I think the discussion is
getting too arcane for this list. (And I still don't
agree on the option formulas. If you look
at the Black-Scholes formula, you'll see that there
is a factor in each term (namely the strike or the spot price)
that already carries the proper unit, so that the exponential
itself should not have any units at all.)

I would only say that although I implemented my unit classes
specifically for financial applications, I decided to make
them as simple as possible (so no virtual functions) and
free of finance. I also wanted "date2 - date1"
to have a consistent meaning and not to be dependent on
a daycount convention.

The need for virtual operators seems unusual to me. The only
example I know of is the one you've cited. So I'm
not sure I would want them built into the unit classes.
I use them in numerical calculations, where I wouldn't want
the overhead of virtual functions.

Also, I brought up the whole issue of unit classes in response to a 
comment about operators.hpp, because it seems to me (but I could be 
wrong) that

1) Unit classes are easily implemented in terms of operators.hpp

2) Most uses of operators.hpp are really just defining an affine
unit class, along with an associated linear unit class. An iterator 
is a particular example.

So I have found the concepts of linear and affine units to be
good guides to what operators should be allowed and which shouldn't.
(For example, one reasonable question asked was why would there be T 
operator-(T, S) but not T operator-(S, T)?)

Deane