Ahh this is pretty much just compile time dimensional analysis and I'm loving it

44:26 Update: Au now has this feature! It was added in version 0.3.4, which happened to be released about a week and a half before this video came out.

Nice exposition, thanks.

Very nice!

Excited ❤

This is awesome, I love this. I can imagine this library becoming part of the stl and being used in every second or third C++ project moving forward. Units and unit conversions are everywhere. I have a hobby C++ where I use AU (astronomical units), kg, tonnes, km and solar masses among other units. The question shouldn't be "should this be part of the STL", but "why wasn't it part of the STL from its inception".

@CharlesHogg

5 ай бұрын

Thank you! It sure would have been great to have unit support for as long as we've had chrono support. That said, a big silver lining for the delay is all of the advances and new ideas in units libraries: the "C++ standard units" we end up getting will be much better than what we would have had. Some of the things we can expect that we wouldn't have had with a C++11 or C++14 standard units library include: - Unit-safe interfaces: the concept hadn't been articulated yet. - Vector space magnitudes (`std::ratio` doesn't work well outside of a time-only library) - Opaque unit typedefs (a huge advance for keeping compiler errors short and readable) - Composable typenames (e.g., `quantity`). Au doesn't have this because it requires C++20's expanded NTTP support, but mp-units does and it's awesome! I'm collaborating right now on active proposals to make a standard units library. It'll use the best ideas from all the units libraries on the market today. We're using mp-units as the home for implementing these ideas, because it's got a C++20 minimum requirement, so we can use interfaces that have more bleeding edge C++ features. It won't be easy, but I think it's an idea whose time has surely come!

We wrote a type safe unit library in house about 10 years ago. Then we realized that it completely fails the case where you want to display that unit in a UI widget. (that is format into a string) There are two problems: first, nobody wants to put hundreds of function overrides into their widget library interface. Second business logic should always operate on the same metric units. However when you have something in meters the user might want to see kilometers, milers, or even something likes feet and inches. We ended up with a runtime type library which tracks the type and gives a runtime failure on invalid things - business logic fails in unit tests (just after compiling) so they don't lose much, while UI logic can ask what the type is and have conversions to display as the user wants.

43:35 Given the inclusion of the "Black Sabbath" unit error, they really should have added the "SpinalTap" 6 feet vs 6 inches catastrophe.

Thanks for the talk! I was not aware of the AU library, having used boost units and MP units before. I just see one tag in the GitHub repo, where are the other releases? Small nitpick: all of "au" "au units" and "aurora" are really hard to Google for

@CharlesHogg

5 ай бұрын

Incidentally, "au c++" seems to find the library really well... but I also tried "au units", and yeah: it's very far down in the results.

@CharlesHogg

5 ай бұрын

@petermuller608 Looks like there's no answer to your actual question! It's weird --- I submitted a response multiple times, but KZread ate it every time. The releases are in the "Releases" section which can be found on the right hand side of the main repo page. As of right now, there are seven of them, with 0.3.4 being the latest.

@petermuller608

5 ай бұрын

@@CharlesHogg thank you!

Very interesting, thanks for the talk! I'm in the computer vision / robotics space, and have been thinking about introducing explicit units to our code base for some time. In that field, there's several complications that come up that weren't addressed in this talk: 1. Support for basic linear algebra, e.g. with Eigen (I see that this is addressed on the Au 'alternatives' library). 2. Support for geometric Lie groups that are typically used in robotics (mainly SO(3) and SE(3)). 3. Explicit handling of various rotation representations (e.g., quaternions, rotation matrix, rotation vector, axis-angle representation, various types of Euler and Tait-Bryan angles, SO(3) representations), and conversions between them. What is the status of support for these use cases / features in the ecosystem? 1 and 2 would be hard requirements for my field, while 3 would address a major source of bugs and confusion. Since aurora is also in the computer vision / robotics space, I imagine that these same scenarios have come up at aurora. Also, an unrelated question: if your code base supports C++20, are there any significant reasons to prefer Au over mp-units, or would mp-units be preferred in that case?

@CharlesHogg

5 ай бұрын

For linear algebra: issue 70 in our repo has tons of detail on the current situation, and the plans. (I'm not linking directly because KZread has deleted comments with links in the past.) We did achieve an important proof of concept back in 2021, which showed both (a) the ability to have heterogeneous units (which is critical for Lie group support), and (b) full retention of Eigen's performance benefits, including proxy types, without having to write new containers explicitly for those proxy types. However, I didn't finish designing production quality interfaces, and now I don't have the bandwidth to start an effort like that. The silver lining is that the interfaces we ultimately get should be a lot nicer. The old proof of concept was done before Au; it was done using Aurora's previous units library. (Background: I designed Au as a zero-dependency drop-in replacement for our old units library, so we could explore open-sourcing it.) Au's interfaces are more composable and easier to use than the legacy ones, so when I (finally!!) get a chance to design interfaces for linear algebra, they should be easier to use and more aesthetic than what we'd otherwise have had. Given Aurora's very ambitious public goals in 2024, I don't expect to get a chance to start this during this year. However, this is an itch I've been wanting to scratch for a long time, so I hope it'll happen soon after!

@CharlesHogg

5 ай бұрын

As for Au vs. mp-units, here's my take. When Au was first made, I would have said that it was actually better than mp-units in many ways, even for C++20 users! However, mp-units has undergone a _huge_ upgrade with its new v2 interfaces, and it's leaps and bounds ahead of where it was. Specifically, the major features that Au was significantly ahead on were unit-safe interfaces, composability, and ease of migration. mp-units v2 has closed all of these gaps and now meets (or exceeds!) Au. So: what advantages remain for Au (for C++20 users)? I'd say these: - _Conversion safety._ Au is still best in class here thanks to the overflow safety surface and runtime conversion checkers, neither of which I've seen anywhere else. - _Constants._ mp-units' constants are awesome, and they had them before we did (they're new in Au 0.3.4). But Au's constants are better IMO because they convert to Quantity types --- and with a perfect (compile time) conversion policy, no less! - _Zero._ mp-units considered this, but went with an alternative solution. My considered opinion is that the `Zero` type approach is better on balance than `is_eq_zero` and friends. - _Learning curve._ Arguably, Au is a little easier to learn and use. Conversely, what are the concrete advantages for mp-units? Here are the ones I find most compelling: - _Composable type names._ This is something you can't get without C++20: you can write something like "quantity", and it will mean what you think it means! This is by far the biggest advantage IMO. - _Generic interfaces._ C++20's concepts let you write functions that take a "generic length" and "generic time", etc. - _Quantity point origins._ I really like the mp-units approach here. Au's quantity points are pretty good, but the origin is strongly coupled to the unit. (That said, I think this is a very active area of development for units libraries generally right now.) - _Better output customization._ The fmtlib support and unit name/symbol customizability is awesome! These lists aren't exhaustive, but they focus on the features that I find most compelling. (I thought I had posted a comment similar to this yesterday, but it looks like KZread ate it!)

@CharlesHogg

5 ай бұрын

Oops --- forgot to add that mp-units' support for "quantity kinds" is also really awesome and compelling.

Exemplary!

How do boost and Au compare in terms of program size, from what I understand from this speech, there is no in increase in program size with au, am I right?

@CharlesHogg

5 ай бұрын

Good question! I haven't explicitly measured the program size. The main thing we've paid attention to so far is the assembly code generated, so that we can make sure there isn't a runtime penalty.

Is Au for the latin for gold? Aurum? or is it for Astronomical unit?

@DFPercush

5 ай бұрын

He works for a company named Aurora.

@CharlesHogg

5 ай бұрын

Or for "Aurora Units"? That one is certainly convenient for our logo, which comes from the first two letters of the "Aurora" logo! The truth is "Au" is just "Au": it's the name of the library. It gives us a single, short namespace, and helps prevent us from being yet another C++ units library called "units". I think it originally came from "Aurora Units", but it quickly became simply "Au". And if that name suggests connotations of "golden" quality --- well, that's probably a total coincidence. 😄

@Sirus20x6

5 ай бұрын

@@CharlesHogg then a good logo would be AU on the periodic table of elements :)

@Sirus20x6

5 ай бұрын

although astronomical unit is the distance between the sun and the earth. also a cool name@@CharlesHogg

@davidhayward1426

4 ай бұрын

"Gold is best!" kzread.info/dash/bejne/a6STqNyLh8K8ppc.html

But where's the distance unit for Texan Buffalos end-to-end? And what's the equivalency from kilograms to macdonalds hamburgers?

CPU cycles to nanoseconds is not a rational conversion, CPU "clocks" have variable frequency. Even with scaling disabled (which is uncommon anywhere that has any consideration for power consumption) the frequency will still fluctuate enough to significantly limit the conversion accuracy. There are reasons for including the (small) expense of separate real-time clock hardware in most general-purpose systems.

@CharlesHogg

5 ай бұрын

The slide was explicitly not about "general purpose" systems; it was about an embedded system. And it was also about taking existing code and expressing it more cleanly, so these considerations --- while admittedly fascinating, thanks! --- are also beside the point. There exist valid use cases where all we need is a good quick approximation; I assume this was one of them.

@mytech6779

5 ай бұрын

​@@CharlesHogg Scaling frequency to save power is even a feature of many micro-controllers, though it is usually in very basic steps, like a standby level and an active level. Is the presentation about a general-purpose units library, or did I miss the part limiting it to embedded specific uses?

@CharlesHogg

5 ай бұрын

@@mytech6779 I think what you may have missed is that "*The slide* was... about an embedded system". The library is of course general purpose. And --- to reiterate --- the _point_ of the slide was to show how the library can express some example _pre-existing algorithm_ more cleanly and safely. If the algorithm itself would be better replaced with an alternative, that's fine, but also beside the point. I'm sorry if your expertise made this choice of example distracting for you.

You talk about your ability to use the library in many scenarios and configurations, but then you use Bazel? CMake is the single most used meta build tool in C++, you throw away your entire libraries usability when you use Bazel, and from stats, more than moving to C++20. You would have been better with Meson or heck, *auto tools* rather than Bazel. Don't use Bazel unless your google, no one else wants to deal with Bazel.

@CharlesHogg

5 ай бұрын

You'll find the answer to your question in the installation instructions in our documentation. (I'd include a link, but KZread has given me problems for adding links in the past.) The repo includes a script which can package the entire library as a single header file, which is then trivially compatible with every build system. We would love to support CMake as well as bazel, in the same way that projects such as absl do. But since we don't use CMake, we're going to need to lean on the community for that support. At least in the meantime folks can use the single-file delivery and obtain ~95% of the benefits.

@oriyadid

5 ай бұрын

I use, enjoy, and want to deal with bazel, and I'm not google. I appreciate this package having bazel support, because most packages don't which makes them hard to deal with.

@therealvbw

5 ай бұрын

If CMake intends to be a universal standard, it should be able to interoperate easily with other build systems. CMake-built libraries are equally as intimidating to use for those of us who aren't using it for our projects.

Why? There is boost::units. Instead of reinventing the wheel, you could have contributed to Boost if something was wrong with its units library. Also, Bazel is 🤮. It's a no-go from the start. Bazel is a Google tool developed to support Google workflow driven by Google business needs. If a company is adamant about using a tool developed for another company's business needs, there is something wrong with it. Also, don't read from the screen.

@CharlesHogg

5 ай бұрын

"Don't read from the screen" is great advice: watching the video, it's my biggest regret from this presentation. My top priority for my next talk is to work on a more natural delivery. Thanks!

@CharlesHogg

5 ай бұрын

I'm sorry that you do not like bazel. At my last company, we used CMake, and then switched to bazel --- it was such a breath of fresh air, and I never looked back. My experience is that bazel is a much better and cleaner experience once you set it up, but that setting it up in the first place is much harder. That's why in Au, we've done all the hard work for you. You can just run tools/bin/bazel (or just "bazel" if you set up direnv) and we'll fetch bazel and all toolchains automatically! And of course --- if you don't like bazel, you don't need to use it at all. Au supports a single file delivery, so you can package the library as a single header you can drop in your project. That works with all build systems.

@CharlesHogg

5 ай бұрын

Finally: why not boost::units? The main reason is that it's extremely challenging for developers to use. The learning curve is very steep, and the compiler errors are staggeringly long and hard to interpret --- I think you'll find this is a consensus view in the community. I have found that if you don't absolutely obsess about developer experience, people will simply _not use a units library_ rather than use one that's hard to use. The idea that we could have contributed to boost units sounds nice, in theory, but does not withstand scrutiny. One core selling point of Au is our unit safe interfaces: it's perhaps our most important units library innovation, which mp-units has now also adopted. "Completely change all user-facing interfaces" is a pretty tall order! Not to mention, it adds tons of delay for _us_ being able to use it _internally_, whereas by writing a new library I was able to get it up and running quickly.

@TheOnlyAndreySotnikov

5 ай бұрын

@@CharlesHogg CMake has a lot of footguns, then many tricks to compensate for footguns. However, it's a de facto standard. Bazel needs a separate team to set up and maintain. My personal choice is Meson. All of this is irrelevant. If you want this library to be used by a wider audience, you should provide CMake or Meson. This is irrelevant to what your company uses. Single file drop-in is not an option if you want a wide adoption. To be integrated into a system, it has to set up either pkg-config or CMake configuration files in the prefix. The most acceptable way to do this is either CMake or Meson.

@CharlesHogg

5 ай бұрын

@@TheOnlyAndreySotnikov In case this gets lost in conversation, I wanted to be clear: our plan has always been to support CMake natively; we just need to rely on the community to make that happen, because we ourselves don't use CMake. Indeed, that has now already started to happen; see issue 215 in our repo. That said, I'm struggling to understand how single file drop-in is somehow a barrier to wide adoption. We're presenting it as a stopgap solution while we wait for official CMake support. Users can get virtually all of the benefits of the library right now, and then smoothly upgrade to CMake delivery once it becomes available. Meanwhile, the single-file stopgap solution contains a complete manifest for full traceability. Can you honestly imagine somebody deciding that Au is best for their needs, but then deciding not to use it because they'll need to get it from a single file at the beginning?