Re: [boost] Re: Units (and operators.hpp, too)

From: Corwin Joy (cjoy_at_[hidden])
Date: 2001-07-01 13:23:03

----- Original Message ----- 
From: <Deane_Yang_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, June 30, 2001 8:54 PM
Subject: [boost] Re: Units (and operators.hpp, too)

> --- 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.)

Fair enough, I think we can agree to disagree (all I was saying
was that the discount factor exp(-r*t) in BS has currency and NPV
ratio units that are implied by the units of r (and t)).
Anyway, we can perhaps agree on two points:
(tho' you're less likely to agree on #2)
1. Users will disagree as to how far they want to use the units
library - but ultimately it is up to them.
2. Units treatment for exp and log would be nice but would
likely not be an initial requirement.

> 
> 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.

Here I'm kind of into this distinction.  I'm hoping to propose
a time/date library to boost which makes a big point about these
distinctinctions (business day difference, versus calendar day difference
versus TAI time difference etc.)

> 
> 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.
> 
There used a lot & very powerful when appropriate which I
think would be the case for runtime type checks.  To say more,
however, I would need to see what you are saying.  (Hint - you
could perhaps upload a preliminary submission to boost).

> 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
> 
1-3 sound reasonable to me.  I would be interested in seeing what
you have done.