From: Matthias Schabel (boost_at_[hidden])
Date: 2003-11-19 14:50:28
> ( change to this and it works :
> SI<double>::Velocity v3 =
Right - I forgot that the assignment form is not the same as
the normal constructor...
>> so that you can distinguish between raw
>> values and
>> types which result from evaluation of expressions containing
>> dimensioned quantities...
> Yep There is an argument for that, but the problem is that you then
> have two
> types which
> represent exactly the same thing. My monolithic mind tells me that is
> not a
> good thing.
Hmmm...I would argue that the dimensionless result of a unit
fundamentally different than a normal POD value - for example, units of
measure are technically dimensionless, but there is clear value in
keeping track of
> The logical extension of your scheme which strips the Power_of_0
> is to return one with none when its dimensionless...is all I'm saying
> You either choose:
> A) some-pq<000..> = result of division between two dimensionally
> equivalent pqs
> B) inbuilt-type = result of division between two dimensionally
> equivalent pqs
If you're representing your dimensions as a fixed length list, this
works fine, since you
can catch dimension<0,0,0,0,0,0,0>. However, you run into a problem
it as I have as a variable length list of tagged dimensions:
are both dimensionless, but would not be recognized as equivalent if I
didn't reduce them to a
> Because a 'dimless pq' is exactly like an inbuilt type you should be
> able to
> both in exactly the same way. If you get a situation where you can
> only use
> one or the other
> trouble will soon follow. And it is difficult to predict every
The library allows implicit conversion of dimensionless quantities to
their underlying value
type. You need to bear in mind that the dimension code can exist on
top of arbitrary value
types, though - it's not just restricted to PODs :
tags a fixed length array of 5 elements with a length dimension,
allowing you to perform normal,
dimension-checked arithmetic on the vectors :
v1+v2 -> length tagged array
v1*v2 -> length^2 tagged array
> There is no way to find out the value of a or b from c alone.
> If there was you would end up with a 'snowball' effect where the pq
> more and more attributes or history
> as it went through calcs. That is a recipe for diaster in a big
> approximation loop I think
> If physicists needed such a beast it would have evolved that way.
I was actually talking about developing a simple way of extending an
unit system with a set of dimension tags to add others, but the whole
pretty much a tangent...
> This is an extension of the argument on dimless pqs in a way.
> ie a dimless pq is a scalar and it seems futile/impossible to try to
> what it actually represents to the user.
> mass_pq a(1),b(2);
> angle_pq alpha = a / b ; // perverse but dimensionally
> correct I
> flag no error
If anything, I think your example is a point in favor of disallowing
from dimensionless types - at least then it would be clear that the
intended to do something strange...
Matthias Schabel, Ph.D.
Utah Center for Advanced Imaging Research
729 Arapeen Drive
Salt Lake City, UT 84108
mschabel at ucair med utah edu
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk