
Boost : 
From: Reece Dunn (msclrhd_at_[hidden])
Date: 20060607 17:04:20
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 nonmetric) 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.62607554e34 ± 3.97565e40;
const physics::unit::eV plank_eV = 4.135669212e15 ± 1.2407e21;
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.616051e35 ± 1.03427e39;
(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.616051e35 ± 1.03427e39;
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
constantbased 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.clickurl.com/go/onm00200471ave/direct/01/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk