Gerhard Wesp wrote:
On Wed, Jun 07, 2006 at 03:16:47PM +0100, Paul Giaccone wrote:
Reece Dunn wrote:
However, if you are working in *pounds*, and you want the *result* in pounds (e.g. how many pounds of flour do I need to order?) then you are going to end up with the result in kg!!
mass flour = x * pounds; // Do some computation std::cout << "You need " << flour / pounds << " pounds of flour\n";
Yes, if there is no other computation involved, we have an extra division and multiplication here. But as I wrote, I would like to encourage the users of a physical quantities library to actually use SI units.
This could lead to errors (re: Mars lander) if people forget that they are working in one unit (SI meters) when they should be working in another (e.g. miles). For example, it would be easy to write: std::cout << "You need " << flour << " pounds of flour\n"; and not realise that flour is not in pounds!
So including imperial (or even just non-metric) units is, I would say, quite important, not least because these are the official standard in
I agree. But let them be themselves in SI, e.g.
const length foot = .3048 ; const mass pound = .4535924;
Ok, but if you are working in atomic/theoretical physics, you have: // pseodo C++ for plank's constant (h) const physics::units::J plank_J = 6.62607554e-34 ± 3.97565e-40; const physics::unit::eV plank_eV = 4.135669212e-15 ± 1.2407e-21; so, which value is correct? The one in Joules (sp?) or the one in electron volts? It all depends on which units you are working with. Converting between the J and eV values for the sole purpose of using SI units, where you *need* eV would introduce (1) rounding errors due to the inaccuracies of floating point math and (2) the errors introduced when you take the intervals into account. So having 2h and converting from eV -> J -> eV will not give you 2h! As well as this, if you are working on the level of plank length: const si::units::meters plank_length = 1.616051e-35 ± 1.03427e-39; (and yes, plank length is in meters!) it would be easier, faster, more acurate ... to do the calculations with plank_length as the base unit so you do not use interval arithmetic! Is it not easier to say: const physics::units::l_p plank( 2 ); // 2 * plank length std::cout << plank << std::endl; // output: 2.l_p rather than: const si::units::meters plank_length = 1.616051e-35 ± 1.03427e-39; const si::units::meters plank = 2 * plank_length; std::cout << plank << std::endl; // 3.2... +/- ... std::cout << ( plank / plank_length ) << std::endl; // 2.0 +/- ... Q: Would the last one give 2.0 +/- 2.0?! I don't know that much about interval arithmetic. Another thought: if you are loading/saving data to/from a database that keeps say the fundamental particle masses as eV, will these not degrade over time due to rounding errors when converting to/from SI units? What happens as the value of the eV changes as physical constants do?! What happens with the interval value that you need to convert back to a float? Do you take the average, where you *will* have greater value precision degredation!! Using eV as a base unit for these calculations will ease most of these and lessen others. The disadvantage to your idea of doing value / unit_desired when you need to output it is that: (1) it complicates matters -- doing that should only be required when conversions are needed (making the places where those conversions are explicit); (2) people are lazy and can get distracted, so they will not always use the above where needed; (3) it will have greater runtime penalties, especially if used in a loop; (4) can have inacuracies when dealing with large or small physical constant-based values; (5) is bad if those constants are changing! (6) can penalize you if intervals come into play. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/