[boost] Re: runtime unit-modifiablephysical-quantitiesusingpqs1-00-01

From: Andy Little (andy_at_[hidden])
Date: 2004-01-04 07:31:12

"Deane Yang" <deane_yang_at_[hidden]> wrote in message
news:bt7egh$723$1_at_sea.gmane.org...
> Andy Little wrote:

> >>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?
> >
>
> I was only talking about on boost, but I actually have
> never understood any explanation ever given to me.
> Could you or someone else please try? By private e-mail
> if it's off-topic? Or is there a web page I can stare at?

try google:  physical quantities dimensional analysis    ... etc.

>
> In any case, physical dimensions are completely consistent
> with the purely mathematical description referred to above.

I think you will get a linker error here... judging from your statements
two/three paragraphs up :-)

> BUT the purely mathematical description is universally useful
> anytime one has a linear measure of quantity of any kinds
> (oranges, coupon periods, bytes, etc.). Physical dimensions
> provide just one particular set of examples.

Again ... might I suggest spending  some time finding out about the subject
:-)

>
> Since, as far as I can tell [snip],
> virtually every use of a "double" corresponds to a measurement
> of some quantity, I've sometimes been tempted to assert that one
> should never write code with bare doubles and that every one should
> be replaced by the appropriate unit class.

Yep..The ramifications of  using physical-quantities in all situations where
they are represented by inbuilt types ( and IF some tight rules could be
found 'quantities') are pretty big. Simply put using a double to represent a
(say) length is weakly typed. The units are not explicit and every unit
conversion must be applied manually.
Using a type designed specifically to represent a length is analogous
(perhaps less dramatic)  to moving from assembler to C. Assembler might use
a(say) 4 byte variable... C enforces(more or less :-) ) an int. In the move
from assembler to C  many assembler coders probably complained bitterly that
their freedom to hack wa being removed, but(slower... first thing the
assembler coders pointed out), but more correct and portable code was the
result of providing strong type checking.

The effects of putting a physical quantity type in your software..., Put one
in and (to be strict)  you will need to apply D.A. (dimensional analysis) to
any variable involved with it ... pretty soon you will find numeric types
falling like dominos. In most cases it is probably not a serious option.
I am not too concerned whether my type is taken seriously. What I have found
so far is that it is a lot of fun. say like going to those old 3d movies...
the type just models 'the real thing' in a much more satisfying way than
boring old doubles do. I am quite happy to accept that what I have is a'toy'
type.
I am currently at the stage where unfortunately the fun may have to stop (
explicit conversions :-(   )

> This, in fact, is what I now
> do in my own code. The compiler now catches coding errors, where I've
> either used inconsistent units or written an arithmetic formula that
> makes no logical sense.

Yep its fun :-)

>
> > 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 ? :
>
> But but but....I think the point I am trying to make (unsuccessfully) is
> that a properly designed units library should not actually define any
> units itself. The units should be created only by the user of the
> library. Then there should be libraries derived from the units library,
> like the physical dimensions library.

An interesting observation about boost devel is that things often tend to be
considered first from a developers point of view... why not start from a
users point of view?
std::string ... I dont want to spend time fiddling and making a string of
char or whatever every time I want to use it. I just want to use it. it
always 'does what it says on the tin'.Its an interface ...  Usually I dont
want/need to know anything about the implementation.
Top down designs Can, all to often, end up doing amazing things that nobody
actually wants or needs by the time they are completed.
Bottom up designs evolve from user demand. Perhaps one day physical-quantity
will be an interface to something more generic... but currently it is at the
'need a string of char 'stage.

>
> I see nothing wrong with focusing on a particular use case when
> designing the library, but if you want a truly useful C++ library,
> you want to design its guts so that they can be used by the library
> user to define whatever units the user happens to need.

Hope above answers this... Its a bottom up top down neverending argument.

> I think it
> is an error for the library writer to try to predict what units
> the library user needs.

OTOH everyone is being 'encouraged' by government edict to use SI. Having
looked into it I am happy to agree.. for physical-quantities Its sweet :-)
Now if we could figure out one universal worldwide currency... Ooops you and
Dan W  would be out of a job I guess :-)

>
> >
> > 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.
> >
>
> I am surprised. Fractional powers are useful even for physicists.

I keep asking for real world examples... what are these secret formulas?
Usually they are 'rules of thumb' (ie baloney) not proofs.
(OK physicists can see an open goal... I am talking general purpose
engineering style physics)
To some extent this is trivial... its not  a great problem to add IF  there
is a need.

> In fact, it arises in finance because finance uses Brownian motion,
> which of course is originally a physical concept.

 Would need to see the proofs... but The WARNING BELLs are deafening :-)

>
> A coupon period is an unspecified amount of time; how long it really
> is will be specified by the library user.

hmm... how about a variable ?

The point is that the library
> writer is not and should not be able to anticipate exactly what units
> the user needs.

Except when its SI units :-)

> When I cite Matthias's library, I mean its core, where no physical units
> are defined at all. I can't speak to the physical dimensions part.

I am  probably going in direction of making units into a type param... One
reason is that it may be useful for a configurable conversion policy.
However the implementation I shall concentrate on will be SI based.... with
ability to use non-SI physical-quantities of course
I originally tried the  separate concept and implementation approach... but
it has some interesting and unexpected Gotchas :-)

>
> I have only admired MPL from afar and have never used it, but it would
> appear to be ideally suited for an abstract units library, as both
> David Abrahams and Hugo Duncan demonstrated a while back.

I repeat what is now my mantra. I am making a physical_quantities lib.
OTOH I suspect that the underlying principles could be used in a wider
context.
It is up to someone else to investigate that.Currently I have enough
problems just with the physics.

regards
Andy Little