From: Steven Watanabe (steven_at_[hidden])
Date: 2007-02-15 15:33:17
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?
> Yes, there is an overhead to the unit but it is localized to the places
> where conversion is necessary. The library user does have to use some
> care, and I haven't thought of a way to allow them to use this stuff
> willy nilly in something needing extreem performance, but I don't think
> that is too much to expect.
I'm afraid that I am still unconvinced that runtime
units are useful. Here are the basic scenarios
and solutions. Perhaps I forgot something?
1) The dimensions are known at compile time but
the unit system depends on user input.
a) Losing a few bits of precision doesn't hurt.
Do all internal calculations in SI (e.g.) and
track the units to print separately. The
printed units need never appear anywhere
outside of the IO code. It is cleaner to
keep them there rather than having them possibly
propogate out, only to be translated immediately
into SI anyway.
b) Every bit of precision matters.
Track everything at runtime using sorted
vectors of fundamental units. If perfomance
also matters then there is not much that a
library can do to help.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk