[boost] Re: Physical Quantity- boostified

From: Andy Little (andy_at_[hidden])
Date: 2003-11-06 20:33:53

"Deane Yang" <deane_yang_at_[hidden]> wrote in message
news:boekps$3rl$1_at_sea.gmane.org...
> Andy Little wrote:
>
> >...  but could someone explain exactly why
> >>something like:
> >>
> >>inferred_type add_units(units_type first, other_units_type second)
> >>
> >>is useful?
> >
> >
> > operators      ..... !    :-)
>
> Great! Could you elaborate by what you mean by this?
>
> The only operator+ I ever want to see in a units library
> is one that adds two quantities with the same units.
> But that's just my personal quirk.

 BTW I'm coding a "physical quantity user defined type". To me " units
library" is a derogatory word for it :-).
If  a units library is what you are after there are plenty of units
libraries in the files section of boost.... :-)

Addressing your point.
As you say its your view.
Of course if I didnt do conversions someone else would soon be asking why
not. :-)

If the facilities are there you can decide whether or not to use them.
I see this as a policy thing. If it is your company policy not to convert
there is nothing to stop you
commenting out all the conversion functions in the headers :-)

>
> I want to know why it is useful to be able to add two
> quantities with different units and have the operator+
> do the unit conversion inside of it. I'm sure there's
> an obvious answer that will make me feel very dumb.

There is a very obvious answer:
from , random book close at hand:
Ross Garrett  "The symmettry of sailing ,1987 Appendix B"
Length                    m        km        inch                foot
nautical mile
1 metre         =         1        10-3    39.37            3.281    5.4
x10-4
1 kilometre     =       ......
etc.

The = sign says it all.
1 metre is equal to 1000mm
is equal to etc...
They are all different ways of saying the same thing.
Its an everyday thing, a commonly understood concept.
 If you have =, you soon need +, * ... etc

However
The different units have evolved because ,when dealing with big lengths it
is easier to use a bigger unit.
There are just less zeros to stick on there. Its easier to deal with.
That goes for Floating Point too. If you only need big lengths you want them
at the scale of the unit.

 Presumably one will usually be dealing with a relatively close range of
units,
(Although I did use the physical_quantities class
 to calculate My Uncles age for him in nanoseconds :-)  )
but at the boundaries between two consecutive units you must convert.

>
> I guess I'm just a very risk averse person and prefer the safety
> of strong type-checking and explicit casting to
> the convenience of an operator+ that allows two different units.

I agree on the type checking, A major aim of the class is to provide an
alternative to
hand coded conversions which must abound. Hence I would say it is "strongly
typed".
If you dont provide conversions, then anyone who needs them must  exit the
type checking.
There is an argument for making conversions explicit, but it is tiresome to
code that stuff for every case:

Not every program has to be 100th decimal place accurate, not every program
must work at assembler speed.
But coding time is always critical.
At one level it is nice to just let the phyiscal_quantities type do all the
drudgery.
I slapped this up ---> ,
 output gave  4.21869e+006 mm.
Note that each unit here is different, and there are I guess  5 conversions.
To the purist of course this is an appalling program .
Huge accuracy has been lost in those conversions.
He would prefer to spend a couple of weeks optimising it into assembler  :-)

Feel free to do the calc by hand .... :-)

*note
Please dont do this in the real world. Its just a demo !.... :-)

#include <iostream>
#include "physical_quantities.hpp"
#include "physical_quantities_demo_util.hpp"

using namespace physical_quantities;

pq_length<float>::m  some_func(
           pq_length<float>::m const& L1,
           pq_length<float>::feet const& L2)
{
        return L1 + L2;
}
int main()
{
    pq_length<float>::km  L1(1);
    pq_length<float>::miles L2(2);

    pq_length<float>::mm  result = some_func(L1,L2);
    std::cout << result <<'\n';
}
// output 4.21869e+006 mm

>
> (I do agree that what you're trying to do is an interesting programming
> challenge.)

I think so too. I have a lot of problems ahead yet though, which is why it
is lucky that I hit boost just now
There is a lot of boost stuff that I am going to need yet to get it to do
what I want.

BTW, And at one level  I really like  the fact that I am "creating" a new
type
when I add two types. Its slightly subversive :-)

Andy Little