[boost] Re: pqs-1-00-00 is up at yahoo

From: Andy Little (andy_at_[hidden])
Date: 2003-12-10 20:39:33

"Daniel Frey" <d.frey_at_[hidden]> wrote in message
news:br6kbh$941$1_at_sea.gmane.org...

>Once I have finished the main parts of the documentation, I'd like to
> have a closer look at quantity libraries and how they play together
> with the constant library.

In Paul Bristows intro he does make the point that physical
quantities constants are different animals than mathematical ones.
they're not precise and they have dimensions... hence dimensional analysis.
e.g gravity constant... an acceleration and units 32 ft/sec, 9.8 m/s

It might also make sense to use the interval
> library for physical quantities, I don't know yet.

I have had a look at the intervals library and can see it being useful in
principle,...One problem with intervals is that (according to the docs)
 it will not work with complex...not sure why. My understanding of complex
as a mathematical animal is vague but I may need
something like it for representing e.g.  sine Voltage/Current waveforms,
something which the physical-quantities type had better be able to deal
with. A major problem overall  with user-defined types is there is/can be?
no
standardised way that they can be fitted into the POD promotion hierarchy .
For custom code that is simple, but generically maybe hard
to achieve ... unless they are all restricted to living within their own
worlds.
BTW The POD type is of course merely a subset of the physical-quantity
type... which I find extremely arrogant and kind of neat :-).

> But all this won't
> happen in a few days so don't hold your breath, just keep up working on
> it.

Yep.From  the start I have had to defend  it rather too vigorously.
Docs are a slog and the implementation I put up wasnt going to
stand up to that very well, so I was setting myself up as an easy target on
the implementation,(
(hence ignoring the concept.. which is the point I am making)
... and I was relieved to pull it. Lesson is I need a good impl too.
(Thanks though to Jan Langer whose observations on the result of operations
has been very useful.)

The relaxation of not having to defend my code on boost has meant that I
have finally started to be able to use it in its original application.
Modelling using strongly typed physical quantities rather than PODs
standing in, is now adding a nice dimension to my coding on this app, like
moving from assembler to
C... not quite as dramatic... but thats the gist of it.
There may be no increase from a  code performance point of view...
     (otoh.. I believe that in some situations pqs-1-00-01, the current
version
actually does provide a possible performance increase over inbuilt types...
how this
is achieved I hope to explain at some stage in my docs. ...
 pqs-1-00-01 is much,much more accurate than pqs-00-00)
.... but thats not the point. Purely from the point of visualising the
object...ie the dimensions and shape of the turbine rotor (my app) from
reading the code, the
concept is working quite nicely.

Also added some electronics types. heres a simple example:
point is
1) Its easy to use, no "smart stuff" required, no special framework
2) self documenting
3) does your unit conversions. eg. to change your capacitance to nF just
change the units and its done etc
4) traps d.a. errors etc

#include "../pqs.hpp"  //all types i/o etc
#include <iostream>
#include<cmath>
using namespace physical_quantities;
int main()
{
    // calculate voltage curve for capacitor
    q_capacitance::uF   const C(0.47);     //capacitor
    q_voltage::V        const V0(5);  //starting voltage across capacitor
    q_resistance::kR    const R(4.7);   // resistance between terminals

    for ( q_time::ms t(0) ; t <= q_time::ms(50); t += q_time::ms(1) ){
        q_voltage::V const  Vt = V0 * std::exp(-t /(C * R));
        std::cout << "at " << t << " voltage is " ;
        //format
        if     (Vt >= q_voltage::V(1.0))    std::cout << Vt ;
        else if(Vt >= q_voltage::mV(1))      std::cout << q_voltage::mV(Vt);
        else if(Vt >= q_voltage::uV(1))      std::cout << q_voltage::uV(Vt);
        else if(Vt >= q_voltage::nV(1))      std::cout << q_voltage::nV(Vt);
        else                                std::cout << q_voltage::pV(Vt);
        std::cout <<'\n';
    }
}

regards
Andy little