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