> enum radian = meter / meter; // ditto
> enum steradian = square(meter) / square(meter); /// ditto
>
> What on earth does this mean?

It has to do with the definition of radian itself. If you draw a circle (of any radius) around an angle. The measure of the angle is radian is the ratio between the arc length of the circle and the radius. This is the reason why one full rotation is 2*pi radians: A circle's circumference is always 2*pi times its radius.

Steradian is similar, but in three dimensions.

On Wednesday, 26 February 2014 at 22:49:57 UTC, Nordlöw wrote:
> 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

Thanks! I think David Nadlingers' is more elaborate (scaled and
affine units) and less prone to rounding errors. I haven't used
it yet. Mine is more basic but has a parsing system that I use to
define units quickly at compile-time and parse data files at
runtime.

--
Nicolas

> Thanks! I think David Nadlingers' is more elaborate (scaled and
> affine units) and less prone to rounding errors. I haven't used
> it yet. Mine is more basic but has a parsing system that I use to

So you cannot defined things lika kPa from Pa in compile-time?

> define units quickly at compile-time

Can't David's package also quickly define in compile-time?


Have you thought about merging your effort vid Davids and propose it to Phobos? This issue has stale for quite some time know.

I would like to have support add support for geometric units like angles, coordinate systems, etc. Have you thought about integrating these with your module?

On Tuesday, 4 March 2014 at 13:20:02 UTC, Nordlöw wrote:
>> Thanks! I think David Nadlingers' is more elaborate (scaled and
>> affine units) and less prone to rounding errors. I haven't used
>> it yet. Mine is more basic but has a parsing system that I use to
>
> So you cannot defined things lika kPa from Pa in compile-time?

enum kPa = kilo(pascal);

which is equivalent to

enum kPa = 1000 * pascal;

Note that my module defines no real unit type, just quantities: a unit is only a special quantity with a value of 1 and a set of dimensions (a "base unit" in the sense of the SI). I think it better fits what physical units really are.  kPa would then be a quantity that stores 1000 and a set of dimensions corresponding to a pressure.

If you declare:

auto p  = 101.3 * kPa;

p stores a value that is 101.3 * 1000 internally, not 101.3. With David's library, I think you can declare kilopascal as a scaled unit derived from pascal, and then a quantity in kilopascal would actually store 101.3. The result is globally the same, but in fact the representations of the numeric values would be a bit different, and so would the rounding errors, when using floating point types.

>> define units quickly at compile-time
>
> Can't David's package also quickly define in compile-time?

I think it can.

>
> Have you thought about merging your effort vid Davids and propose it to Phobos? This issue has stale for quite some time know.

I just think that David's package could have been proposed for Phobos a long time ago. I don't know what has stopped it then. I developed mine afterwards, not being aware of David's one.

> I would like to have support add support for geometric units like angles, coordinate systems, etc. Have you thought about integrating these with your module?

My package is extendable. The SI module is just a predefined set of common quantities and prefixes. You can use your own. Some angle units are defined in quantites.si. I am not sure of what you call a coordinate systems in this respect.

--
Nicolas

On Tuesday, 12 April 2011 at 16:44:10 UTC, David Nadlinger wrote:
> 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.

I would like to move forward with std.experimental.unit(s).

A question that needs to be decided on Before starting this is:

- David's library and quantities use different interal representation. Davids 7-dimensional vector of rational integers (a la Boost) is hardcoded to represent SI units. biozic's is not and uses a tuple of strings and is therefore more flexible. Which direction should we choose?

On Wednesday, 9 September 2015 at 07:04:05 UTC, Per Nordlöw wrote:
> Which direction should we choose?

quantities

On Tuesday, 12 April 2011 at 16:44:10 UTC, David Nadlinger wrote:
> 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.
>
> ...
>
> 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.
>
> ...
>
> David

One big problem is, that in SI base unit for mass is kilogram not gram.

On Wednesday, 9 September 2015 at 07:04:05 UTC, Per Nordlöw wrote:
> - David's library and quantities use different interal representation. Davids 7-dimensional vector of rational integers (a la Boost) is hardcoded to represent SI units.

You must be confusing the library with something else (or me with another David). I'm pretty sure that my original proof-of-concept is the most flexible of all of them, coming with support for composing arbitrary runtime conversion functions, affine quantities and so on. SI unit definitions are merely predefined in a second module because they are commonly used.

That being said, my implementation is ages old and could probably be done much better today.

 - David

On Wednesday, 9 September 2015 at 15:21:22 UTC, HaraldZealot wrote:
> One big problem is, that in SI base unit for mass is kilogram not gram.

This is definitely not a "big problem". There is nothing that sets apart the "base" units in my old library from any other units, except for the fact that they happen to be defined using baseUnit!(), not by adding a prefix. Kilogram just happens to be defined as kilo!gram so that you don't get things like millikilogram.

 — David

On Thursday, 10 September 2015 at 07:01:19 UTC, David Nadlinger wrote:
> You must be confusing the library with something else (or me with another David). I'm pretty sure that my original proof-of-concept is the most flexible of all of them, coming with support for composing arbitrary runtime conversion functions, affine quantities and so on. SI unit definitions are merely predefined in a second module because they are commonly used.
>
> That being said, my implementation is ages old and could probably be done much better today.
>
>  - David

I've gained time and energy to take up this task again. It seems like David Nadlinger's solution is very complete:

https://github.com/klickverbot/phobos/tree/undefined

http://klickverbot.at/code/units/std_units.html
http://klickverbot.at/code/units/std_units.html#PrefixSystem

but not a complete superset of

https://github.com/nordlow/quantities/tree/master/source/undefined

One key issue here is whether we should provide an instantiator based API

    auto q = 1.0.meter;

or operator plus constants/CT-constants (via David's std.si)
    import std.si : meter;
    const q = 1.0*meter;

or a combined (my proposal)

    auto q = 1.0.meters; // plural naming
    auto q = 1.0*meter; // singular naming

for expressing quantities.

David's SI-unit solution is, IMO, better than biozic's as it doesn't force the unit to be associated with a specific numerical scalar type upon construction.

Another key-question is whether we should support biozic's compile-time parsing of unit expressions such as

- 1.0.si!"km/h"
- 1.0.si!"m/s"
etc.

Could somebody point out if something is missing in David's solution. And, if so, which parts of biozic's which could be reused.

that could/should be reused for filling in these gaps.

Another key-issue is if the template `Rational` in std.units should be extracted and put into a separate module.

I vote for moving forward with David's solution.