From: Andy Little (andy_at_[hidden])
Date: 2004-01-03 06:13:25
"Dan W." <danw_at_[hidden]> wrote in message
news:bt4lo6$i4k$1_at_sea.gmane.org...
> Andy Little wrote:
> > Hi to all at boost,
> > Continuing experiments with the physical-quantities type have shown
it
> > 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
few
> > times
> > Sample code/use for a runtime modifiable type based on the
physical-quantity
> > 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
10.
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.
regards
Andy Little