Jonathan M Davis wrote:
On Wednesday, January 05, 2011 15:40:37 BCS wrote:
Andrei Alexandrescu <seewebsiteforem...@erdani.org> wrote:
(c) Numeric issues as I described (and no amount of rhetoric will set
that straight; FWIW given the obvious question of scaling you need to
prove it works, not me to prove it doesn't)
(d) Unrealized potential (if we approve this, backward compatibility
will prevent more comprehensive libraries having the same aim but a
different design). This argument is to be taken with a grain of salt as
in general it can be easily abused. What I'm saying is that once this
library is in we may as well forget about scaled units a la boost units
(which are the kind I'd want to use).
We have both said our piece on these, what do others think? I'd be
particularly interested in what Don has to say on the numeric issues. Does
an extra layer or two of FP rounding really mater.
Personally, I tend to cringe when I see much in the way of floating points in
anything that needs precision, but it's not like you can avoid it in this case.
Regardless, I agree with pretty much everything that Andrei has said. I
particularly don't like that the values are all in meters internal -
_especially_ when dealing with floating point values. I'd be very worried about
precision issues. The Boost solution seems like a solid one me. However, I'm not
likely the sort of person who's going to be using a unit library very often. I
just don't deal with code that cares about that sort of thing very often.
One thing we learned in engineering school was to never do premature rounding.
Always defer such to the final calculation.
My experience with "round trip" rounding, where X=>Y=>X is that the result
"drifts". You can see with the mouse sometimes, as it can slowly drift to one
corner of the screen.
