Recently, I have been playing around with a little units of measurement system in D. As this topic has already been brought up quite a number of times here, I thought I would put my implementation up for discussion here.

When this topic came up previously, it has been proposed to include units support with Phobos, and thus I have merged my work into my Phobos fork. Please note, however, that even if we should come to the conclusion that we really want something like this in Phobos, this is not a formal review request yet. There are still a couple of items left on my to-do list, but I'd like to get some feedback first.

Anyway, here is a link to the code: https://github.com/klickverbot/phobos/tree/units (std/units.d and std/si.d). Also, I put up a build of the DDoc output at http://klickverbot.at/code/units/std_units.html resp. http://klickverbot.at/code/units/std_si.html.


A couple of notes:

 - DDoc emits the documentation for some template functions twice,
once for the template, and once for the eponymous function itself (bug 4107). Is there a workaround for this issue? This also affects, amongst others, the docs for std.container.

 - The documentation could use quite a bit of work in general, I'd be happy about any suggestions.

 - In a previous discussion, Andrei brought up the topic of categorical types implemented as quantities without any operators defined. An extra template parameter to disable arithmetic could easily be added to Quantity, if deemed useful. However, I think that using an units system to define them is pretty much overkill, as neither conversions nor arithmetic operations would be used.

 - Currently, »auto« returns are used quite liberally for things that should »just work«, e.g. just mirror underlying value type operations. This has the advantage of keeping code and function signatures readable, but obviously also hides the real type from the user. Any other thoughts on this?

 - I have followed the general Phobos guidelines to use template constraints where they would logically belong (and where they are actually implementable without hacks due to DMD bugs), instead of, say, static asserts or just letting instantiation fail. However, this way, you lose the ability to specify helpful error messages (which is somewhat important as the underlying types can be quite complex), and the DDoc documentation is cluttered up somewhat.

 - The helper functions for creating instances of new unit types (scale, affine, ...) are currently template functions taking an instance of the unit they manipulate as actual argument. This is only for »historical« reasons really, would it be cleaner to use just templates?

 - If this library should really be included into Phobos eventually, I am not quite sure about the right organization of the code. While I think that std.units would be a good fit for the core module, I am not sure how modules containing definitions of actual physical units and other related code (e.g. CODATA values for the natural constants) should be organized. Putting them directly into std.* is certainly a bad idea, as it would add even more clutter to the already crowded (overcrowded, in my opinion) package. What about a new std.physical (or similar) package?


David

I see no one's responded yet. FWIW, I love the idea of having a static units system in D. But I just haven't really had a chance to look through your post here, or your code. So busy...  :(

This looks very good. I'd suggest calling them std.units and std.units.si, if possible.
It seems to support all the features I wanted when I started writing such a module, though I never finished mine.
The documentation is very nice if, as you said, somewhat duplicated. Could perhaps use a better first example, maybe also suggestions for its use (I'd like to see OpenGL headers using this for vectors, angles, etc).

All in all, it seems a high-quality submission, and I'm prepared to vote for its inclusion in Phobos.

--
  Simen

Oh, and it would appear I have found a bug:

enum foo = metre / 2;
std\units.d(165): Error: cannot raise int to a negative integer power. Did you m
ean (cast(real)rhs)^^-1 ?

On 4/15/11 3:06 PM, Simen Kjaeraas wrote:
> Oh, and it would appear I have found a bug:
>
> enum foo = metre / 2;
> std\units.d(165): Error: cannot raise int to a negative integer power. Did you m
> ean (cast(real)rhs)^^-1 ?

Oh, thanks, I just pushed a fix (which uses (rhs ^^ 0) / rhs to work around the issue for integer types).

Be aware, however, that your code might not be what you want – the value type is inferred to int, and thus the result is 0 * metre…

David

On 4/15/11 2:24 PM, Simen Kjaeraas wrote:
> This looks very good. I'd suggest calling them std.units and std.units.si, if possible.

Thanks for your comments. Unfortunately, having a package of the same name as a module is not possible in D – any other ideas? What about std.measure(ment).*?

David

On 4/12/11 6:40 PM, David Nadlinger wrote:
> - The helper functions for creating instances of new unit types (scale,
> affine, ...) are currently template functions taking an instance of the
> unit they manipulate as actual argument. This is only for »historical«
> reasons really, would it be cleaner to use just templates?

I just went ahead and changed them to pure templates, having the unit helpers as functions only to infer the type of the passed unit instance really made no sense in the current design (which uses template alias parameters to pass unit instances heavily anyway).

Another missing thing I didn't mention in the original post is support for named derived units – currently, there is no way you could enable (kilogram * metre / pow!2(second) to be printed as »Newton«. It wouldn't be hard to implement, but I didn't really feel the need for it so far…

David

Is somebody waiting for this to be reviewed?

/Per

Tangentially related: https://github.com/biozic/quantities

On Wednesday, 26 February 2014 at 21:41:57 UTC, Kelet wrote:
> Tangentially related: https://github.com/biozic/quantities

Impressive!

This seems similar to David Nadlingers std.units and std.si.

When will all these efforts on implementing Units/SI be synchronized and reviewed?

One question:

I know what angles are but I have never seen them defined like this before!

enum radian = meter / meter; // ditto
enum steradian = square(meter) / square(meter); /// ditto

What on earth does this mean?

/Per