Boost logo

Boost :

From: Andy Little (andy_at_[hidden])
Date: 2004-01-03 06:13:25

"Dan W." <danw_at_[hidden]> wrote in message
> Andy Little wrote:
> > Hi to all at boost,
> > Continuing experiments with the physical-quantities type have shown
> > to be very suitable as the basis for a runtime modifiable unit physical
> > quantity type, which I know is something that has been requested quite a
> > times
> > Sample code/use for a runtime modifiable type based on the
> > type below.--->
> BRAVO! That looks like a great improvement.

Ok..:-) The rt_quantity is pretty basic.. but is partly designed to show
how the physical_quantity type can be used as a basis for other things.
On this subject... to Clarify what this is about... most libs emphasise
generality. The point of the physical-quantity is the exact opposite.
ie its a concrete type not a generic one. Reiterating... the precursor of
the physical_quantity type is the inbuilt type... ie concrete type...
the physical_quantity type is a building block... the rt-quantity shows one
thing that can be built from it.

> However I must say that one
> issue for me, which has been discussed already, is the ability to define
> one's own quantities and units.

I am not sure that defining quantities/units is a trivial matter...
According to SI it is not.
I am happy to stay within their results.... as far as possible. (However
extracting the generic rules from SI might be useful)
in the physical-quantities -type-family ,you can define any
physical-quantity comprised from any powers of the 7 physical dimensions.
In that context you can also define any units you like. The SI units are
all based on powers of 10 of the SI base units.
In pqs-1-00-01 The powers of 10 are carried through the system at compile
time in many calcs so the lib is optimised for those.
Other non SI physical-quantities types(which BTW the physical_quantities
class Can represent) e.g kilograms-force cannot be broken down directly into
their base dimensions.
These I have called incoherent-physical-quantities in the docs. I deal with
those by scaling them to SI style quantities for calcs.
IOW raw output from (nearly) every calc is an SI base unit to any power of
BTW *incoherent-physical-quantities* are called that for very good reasons

> I admit this is lame and inelegant, but
> in real life coding I would probably use actual *physical* units maybe
> 10% of the time, and absurd units 90%. Example: Being able to declare,
> q_bytes byte_count = 0;
> q_MSmilliseconds = q_Second / 1024;
> q_MSmilliseconds mm_time; //MS's Multi-Media timer ticks..

The physical_quantities lib *might* handle this like this :
int byte_count = 0; // dimensionless number... is a physical-quantity
q_time::s t0(in());
q_time::s t1( in());
q_time::MSms msms = (t1-t0); // current version does implicit
conversions(scaling). However later will add switchable conversion functions
for more robustness
// whatever...
q_frequency::bytes_div_us = byte_count / msms; // ok bytes_div_us == MHz
dimensionally correct

having said this the SI units powers of 10 could be replaced by binary/hex
ones in a version of the physical-quantities type.
This might give more accurate results in unit conversions I think.
Perhaps there is scope for a computing SI units system :-)

The scope of the library is physical-quantities. My rationale is to stick
to what I know.
For goodness sake there is enough controversy over angles :-)
Bear in mind that it has taken 100 years to get agreement over the seven
base dimensions and their units!

e.g How do you define a valid dimension, maths its relation to other
*dimensions* etc.
(This is what it has taken SI a very long time to achieve)
The techniques may be applicable to mixing in other *dimensions*.
But I dont wish to go there... at least until I have come to conclusions
about how things should work for known dimensions.

My ultimate guiding principle is simple | complicated ---> simple , known |
unknown --> known.

> Something of the sort, and then, say, have a quantity for byte-flow rate
> defined as bytes per Microsoft millisecond. Not to speak of currencies,
> probabilities, fractional freckles, and the like.
> Where I would *really* use real physical quantities 90% of the time is
> in my old virtual reality engine, if I get back to work on it again, one
> of these days, as I was planning to model realistic physics at a very
> low level. But for most applications, I would probably benefit more
> from totally ridiculous and insulting quantities like the ones I just
> mentioned.

A great achievement of SI is to provide a coherent framework for math on
physical quantities... they are all interlinked.
The methods may be applicable to other things. Maybe from building a basic
lib(which is my limited goal) some generic things can be extracted
That would be some time down the road.

Andy Little

Boost list run by bdawes at, gregod at, cpdaniel at, john at