From: Steven Watanabe (steven_at_[hidden])
Date: 2007-02-15 23:12:55
AMDG
Noah Roberts <roberts.noah <at> gmail.com> writes:
>
> Steven Watanabe wrote:
> > AMDG
> >
> > Noah Roberts <roberts.noah <at> gmail.com> 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 systems...one 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