Jonathan M Davis <jmdavisp...@gmx.com> 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.
After a little more thinking I'm wondering if I'm targeting a different use case than other people are thinking about. The case I'm designing for, is where you have a relatively small number of inputs (that may be in a mishmash of units and systems), a relatively large number of computations and a relatively small number of outputs. The systems that Andrei is arguing for may be more desirable if there are relatively less computation (thus less internal rounding) or if all or most of the inputs are in a consistent system of units (resulting in very few necessary conversions). I'm primarily interested in the first use case because it is the kind of problem I have dealt with the most (particularly the mishmash of units bit) and for that, the two proposals are almost equivalent from a perf and accuracy standpoint because each should convert the inputs to a consistent system, do all the math in it, and then convert to the output units (I'm not even assuming the outputs form a consistent system). The only difference is that the current arrangement picks the consistent system for you where the alternative allows (and forces) you to select it.
