Boost logo

Boost :

From: Steven Watanabe (steven_at_[hidden])
Date: 2007-02-15 23:12:55


Noah Roberts <roberts.noah <at>> writes:

> Steven Watanabe wrote:
> > AMDG
> >
> > Noah Roberts <roberts.noah <at>> writes:
> >
> >> Steven Watanabe wrote:
> >>> std::cout << (x + y) << std::endl;
> >> Nothing good would probably come of it the way I see things; but since
> >> mcs does magic unit label stuff it could just output that. Without,
> >> allowing for the user to override certain behavior this could be more
> >> well behaved:
> >>
> >> std::cout << ((x + y) * unit) << std::endl;
> >>
> >> You're probably not too worried about the moderate overhead of the extra
> >> work there when I/O is going to be bottlenecking anyway.
> >>
> >> Except in debugging, the developer is going to have a pretty strong idea
> >> of what units need labels and create them. Other units and dimensions
> >> are of no consequence.
> >
> > Agreed. If you have to specify the unit at
> > this point, what is the purpose of tracking
> > it dynamically at all, though?
> I hadn't really considered this use case. For most purposes I think x +
> y will be assigned to something and stored and most, if not all,
> calculations would be done in functions working in fundamental units.
> However, it is a legitimate use. Why track units at all at this point?
> Well theoretically you could have the unit selected at some earlier
> point and stored in a variable so that you might do:
> std::cout << ((x + y) * user_selected_unit) << std::endl;
> The alternative to requiring this notation would be to pick one or the
> other...probably the left operand. In my opinion that isn't verbose
> enough and is rather arbitrary.
> My intended use is more akin to:
> quantity<pressure> dp(psi);
> dp = x - y;
> std::cout << dp << std::endl;
> with lots of stuff going on in between.

My question was: Why should x and y store the
unit, when that information is just going to
be thrown away and replaced by user_selected_unit?
Is this converted value going to be used for
any other purpose than to output it or convert
it back to the base system for more calculation?

> There are a few things I am concerned about. First, a user entered
> value is a value that has a set unit. It makes sense for these to be
> together. Since these should be kept together it makes sense for them
> to be also held with a static dimension to coincide with their future
> use in calculations. That being the case it makes sense for this to bi
> similar and compatible with a static dimension quantity. Second, I
> don't like the idea of having two separate unit for the
> static quantity and one for the dynamic. Optimally a psi unit would be
> used in both of the following:

A few clarifications are in order. I have
assumed that the only use for a dynamic
unit system is to read and write quantities
in units to be determined at runtime. If
This assumption is wrong then I will accept
the utility of runtime units. Even then,
I don't really like to add them to Units.
If it is possible to cleanly implement
it as a separate library on top of Units
then that would be my first choice.

The dimension code can be used wholesale.
A runtime quantity can be constructed
from a static quantity. Adding two
runtime quantities yields a static
quantity. A static quantity should
be constructible fro a runtime quantity too.
That is the only hitch I see.

There is one ugliness in your proposal.

quantity<pressure> p1(psi);
quantity<pressure> p2(pascals);
p1 = whatever;
p2 = p1;

Now, what should the unit of p2 be?

> quantity<pressure> dp(psi);
> and inside a pressure calculation function:
> stat_quantity<pressure> calc_whatever()
> {
> static stat_quantity<pressure> const C = 5.43 * psi;
> ...
> }
> The second is because often times equations are written with a given set
> of units and contain constants in units possibly not in the base.
> Allows you to keep the code in line with the domain it models.
> It would be especially nice if that same psi could be used in static
> conversions but that's a heavy feature for minor benefit.

> I also don't
> believe static conversions to new base systems are going to be that
> common in most applications.

I agree with you there. However, static conversions
are common enough to warrent consideration and can be
cleanly integrated into the rest of the library.

In Christ,
Steven Watanabe

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