nholthaus
commented
7 years ago Can you also post a snippet of code (or test case) that generates a difficult-to-read error, and the error itself (and compiler version)?
I think it will be easier to simplify the errors (and probably even get better results because no base units are returned) by just making the base units have an actual type instead of a typedef, but even that's easier said than done (e.g possibly a full library refactor).
I guarantee you making it more boost::units-like or trying to force a unit system will make the library much less powerful and will worsen the error messages.
As to your suggestion... I don't know. I like the syntax, I agree that it would be much more readable. But take a look under the hood at something simple like base_unit_multiply:
template<class, class> struct base_unit_multiply_impl;
template<class... Exponents1, class... Exponents2>
struct base_unit_multiply_impl<base_unit<Exponents1...>, base_unit<Exponents2...>> {
using type = base_unit<std::ratio_add<Exponents1, Exponents2>...>;
};
<class U1, class U2>
using base_unit_multiply = typename base_unit_multiply_impl<U1, U2>::type;Notice that its basically a simple variadic wrapper around std::ratio_add. Everything would have to be a lot more complicated from the ground up... I'm guessing a complete rewrite.
Actually your syntax looks a lot like a previous incarnation of units which never really got off the ground due to this fatal flaw:
How do you determine the type equivalence? C++ will see the following two types as being incompatible even though they aren't (logically):
// velocity #1
units::base_unit<
units::dimension_whole<dimensions::length, 1>,
units::dimension_whole<dimensions::time, -1>>
// velocity #2
units::base_unit<
units::dimension_whole<dimensions::time, -1>,
units::dimension_whole<dimensions::length, 1>>And that's for two parameters. You can't canonicalize the order because then you'd just end up with my library. The whole thing with the implied tag-dispatching seems off the top of my head like it would suffer badly from combinatorial explosion. Reference this SO question where I asked about basically the same thing. After a lot of thought and initial refusal to believe that I had to create canonical units, I eventually came around and was able to implement much more in the current library iteration than in the previous due to its design limitations. But were the error messages better before? Yes.
I'd definitely encourage you to try though if you have the inclination. You might have more luck than I did, and if you come up with a proof of concept that shows it can work, I'd be a lot more open to the refactor. As it is I think it would be going down a road I've already been on and abandoned.
Slightly off-topic, but possibly helpful is the new feature which might help you solve your dimensional analysis debugging headaches, which is that unknown unit types will now print dimensions to cout. E.x.
meter_t a = // something that isn't a meter
// refactor to find the error
auto a = // something that isn't a meter
std::cout << a; // shows "1 m s^-1", oops, you have a velocity!Sometimes I also use the trick
std::cout << decltype(a) << std::endl;
This also produces a compile error, but it tends to be much more readable.
EvanBalster
This units library generates many complicated templates during compilation, which can greatly slow compilation (notably under Clang) and produces excessively verbose error messages. The latter is especially concerning, because the main reason to use the units library is its ability to report errors in dimensional analysis to the user.
At the root of the problem is a template design that uses an exhaustive set of parameters to describe a unit. This set comprises, among other things, a rational scale, and eight rational exponents which corresponding to a fixed list of approved base dimensions — subject to expansion as new options demonstrate their utility. The lengthy error messages describing these templates must be carefully examined to determine the fault in the user's dimensional analysis, taking into account the standard order of approved base dimensions.
In my frustration I have contemplated making a branch of the library that uses integers instead of ratios as dimensional exponents, to improve error readability and compile time (and because I foresee no use for fractional dimensions in my math).
I have also seen that boost::units tackles another part of this problem by allowing the user to define different "systems" comprising chosen subsets of library- and user-defined units. Both of these are only partial solutions to the wider problem.
What I'm curious about is whether, with the latest C++ facilities, it's possible to implement base_unit such that any transformations thereof are consolidated to a simplified representation that associates base units with their exponents. That is, something like the following:
or,
Two types of simplification could be considered;
Obviously this is all hypothetical, would require a rewrite of the library, and may be prohibitively difficult or impossible under the current C++ spec. I'm interested in understanding the barriers involved and what improvements might be feasible on this front. I won't rule out trying my own hand at some of these improvements.