[boost] Re: physical quantities/dimensional analysis

From: Deane Yang (deane_yang_at_[hidden])
Date: 2004-01-11 14:46:24

Phil Richards wrote:

> On Fri, 09 Jan 2004 16:13:18 -0500, Dan W. wrote:
> [in reply to me]
> 
>>And what percentage of C++ programmers are actually using those
>>physics-only libraries?
> 
> 
> What percentage of C++ programmers are doing dimensional analysis of other
> types?  What other problem domains are there?  Please, give some examples.
> 
> To drive a generic design we need use-cases - so far we have "physical
> quantities" and lots of people saying "you need generic support for
> others".  But as yet I haven't seen any other use-cases shown. 
> *Every* example so far has been in terms of physical quantities.  (Of
> course, I might have missed some :-)
> 

Two examples that already exist in boost:
a) boost date-time library (please note that calendar time does
NOT work the same as physical time, even if they come from the same
underlying physical concept)
b) boost iterator adaptors library (iterators are an absolute dimension
and the difference between two iterators is a relative dimension)
c) I consider the boost operators library as kind of a proto-dimensions
library. I would wager that many of the use-cases of this library really
need a dimensions library.

Working application from finance:
When doing mathematical finance, the following dimensions are quite 
important:
calendar time (absolute dimension)
calendar time difference (in days, weeks, months, years, coupon-periods)
time computed with respect to a daycount convention (in days or years)
1/time-difference (for interest rates)
time-difference-squared (for convexity of a bond)
1/square-root-of-time-difference (for option volatility)
(this is a real example, Andy Little's skepticism notwithstanding)

Note the the following:
a) There are really (at least) two different time dimensions: true 
calendar time-difference (which is important in volatility computations) 
and daycount-calendar-time-difference (which is important in computing 
bond cashflows). A common error is to confuse these two. A "god" 
dimensions library would help prevent this.

b) It is important to control the unit conversions. In true calendar
time, conversion from days to years is ill-defined. In 
daycount-calendar-time, the convention defines how to do it.

Also, I really, really do not want a library that allows conversion of 
to minutes, seconds, or milliseconds or stores time internally in these 
units. It would definitely add to my debugging headaches (as it is,
representing a date in Julian days is bad enough).

As I have mentioned before, I have already implemented a rudimentary 
dimensions library of my own and have found it absolutely invaluable in
writing financial software.

I have never written financial software involving multiple assets
(foreign currency being the obvious example), but
believe me if I did, I would definitely be using the dimensions library
to represent the different asset amounts.

Is this really not enough for you?