[boost] Re: runtime unit-modifiable physical-quantitiesusingpqs1-00-01

From: Andy Little (andy_at_[hidden])
Date: 2004-01-03 16:26:39

"Deane Yang" <deane_yang_at_[hidden]> wrote in message
news:bt6oh4$3b2$1_at_sea.gmane.org...
> Andy Little wrote:
> solutions need to be found...
> >
> > However "arbitrary-physical-quantities-like-widgetty-things-that
> > do-something-configurably" is much too loose a specification.
> >  I cant take any of this too seriously without a tighter definition of
what
> > you guys are actually talkng about.
>
> I did provide in a much earlier posting a precise abstract mathematical
> definition of what is needed, but I guess it was a little hard to
> follow. (1-dimensional vector spaces, their duals and tensor products)
>

Point me in the direction and I'll happily pass judgement. :-)

> And I have yet to see anyone give a precise definition of what a
> "physical dimension" is.

Is this on boost or just in general?

>
> And people have already provided any number of specific examples. I've
> done work in finance, where the following quantities are quite useful:
> calendar time (dates, days, months, years)
> periodic time (coupon periods)
> derived units (per-year, per-period, years-squared, periods-squared,
>                 square-root-of-years, per-square-root-of-years)

I hope to look into calender time and conversion to (maybe even from :-) )
physical_quantities time
at some stage... maybe will look at Date class conversions. (BTW doesnt Date
use implicit conversions ? :
If I remember does something like:

 using namespace boost::posix_time;
     date d(2002,Feb,1); //an arbitrary date
     ptime t1(d, hours(5)+nanosec(100));//date + time of day offset
     ptime t2 = t1 - minutes(4)+seconds(2);

How on earth did that survive the review :-)

I dont know what a coupon period is.. if its a time can do it, can do years
squared, cant do root of years though.

>
> Notice that conversions between the different units are not clear-cut
> and need to be controllable by the user. In fact, what is more important
> than the conversion between different fundamental units but the
> automatic checking of arithmetic expressions involving derived units
> (allow per-period * period but not per-period * years).
>
> In fact, my vote is to have no automatic conversion of units at all.
> I just want the compiler to throw up an error message every time
> it finds an inconsistent use of units. I find that within any given
> module, I always want to use a consistent set of units, even if in
> theory I could use a units library to convert everything automatically
> into a consistent set of units. The use of inconsistent units in
> a single line of code for me is a signal that I have poorly organized
> and error-prone code. Am I the only one that feels this way?

Guess not :-) .
Seriously (Hope this answers Dan Ts later post too) ... I am looking in to
non-implicit conversions. I dont like 'explicit' everywhere... basically I
am using that in a value ctor where it feels right (like in Date above)
... using it for unit conversions does not feel right... will probably
settle on unit_cast<T>(s)
I personally like the implicit unit conversion syntax... for short
programs... however I have noted the concerns.
I hope to get the boost::numeric::converter running on VC7.1 (one day) with
the aim of using that for value_type conversions.
I am toying with the idea of just building my own as I dont know when a
patch on the converter will be available.
Meanwhile I am a bit stuck on that issue.
The converter docs provide some ideas for unit conversions too...( Thanks
Fernando Cacciola.)
I hope to provide a switch either as a macro or preferably in a more subtle
form (if I can figure that out) to enable only 'visible' conversions.
However as you note below time is limited. Others on boost have expressed a
requirement for run-time modifiable units, in a physical-quantity
I hope that I have shown that it is possible to use the physical-quantities
type to facilitate that... I am pleased with the result which only took a
couple of hours start to finish... the physical-quantities type provides all
the background... ie it does what it is designed for quite well.

>
> By the way, referring to an earlier message by Andy, what are the ground
> rules for people being allowed to express opinions?
> Am I only allowed to
> say something, if I am trying to build my own version of the library?
> I sure wish I had the time to, but I simply don't.

I dont know what the rules are, but The general thrust of your post(s) is
that you dont want my physical-quantities lib... you want something else.
as far as I can see anything else... believe me you are not alone... Lets
see...generally

1) I am not using MPL     (nothing agin it ... just waiting for the book)
2) I have criticised SI units
3) I'm not doing kumquats.

I am happy to accept your views and any feedback positive or negative,
however criticism from someone who has ' been there' is usually much more
useful than casual comments.(no pain no gain) If you really needed the lib
you are talking about... you would have no choice... if not available you
would need to build it.

>
> I am, in fact, using a primitive version that I built myself and,
> despite its many limitations, have found extremely helpful.

Voila...  :-)

> I would also say that on the basis of what I've read here, Matthias's
> approach looks closest to what I'm looking for.

Yep  Matthias...

1) Is using MPL
2) uses SI units syntax
3) Is doing kumquats

my views on Yanl have been voiced... I shall say no more.

regards
Andy Little