Redefining angle for different contexts about units

[nholthaus]

the real plan is to incorporate some code developed during C++Now 2017 which will allow arbitrary dimension definitions (as opposed to the current SI exponent/ratio based strategy), which should solve the problem of incompatible dimensionless units. It's next on my to-do list, but I don't have an ETA on it yet.

[nholthaus]

you can't really do what you want with UNIT_ADD because the radians have the same base unit, and there's no way (yet) to implement custom category/dimension.

I haven't tried it myself, but what about just inheriting the radian types?
e.g.

class radian_a : public units::angle::radian_t { /* ... */ };
class radian_b : public units::angle::radian_t { /* ... */ };

[pylipp]

Thank you for your input! I tried your suggestion.

#include "units.h"

using namespace units;

class radian_a : public angle::radian_t {};

double ComputeSine(radian_a alpha) {
  return math::sin(alpha);
}

int main() {
  radian_a angle_a(0.1);
  return 0;
}

Unfortunately I get the error

> g++ -std=c++14 -o units_angle units_angle.cpp
units_angle.cpp: In function ‘int main()’:
units_angle.cpp:46:23: error: no matching function for call to ‘radian_a::radian_a(double)’
   radian_a angle_a(0.1);
                       ^
units_angle.cpp:30:7: note: candidate: radian_a::radian_a()
 class radian_a : public angle::radian_t {};
       ^
units_angle.cpp:30:7: note:   candidate expects 0 arguments, 1 provided
units_angle.cpp:30:7: note: candidate: constexpr radian_a::radian_a(const radian_a&)
units_angle.cpp:30:7: note:   no known conversion for argument 1 from ‘double’ to ‘const radian_a&’
units_angle.cpp:30:7: note: candidate: constexpr radian_a::radian_a(radian_a&&)
units_angle.cpp:30:7: note:   no known conversion for argument 1 from ‘double’ to ‘radian_a&&’
In file included from units_angle.cpp:3:0:
units.h: In instantiation of ‘units::dimensionless::scalar_t units::math::sin(AngleUnit) [with AngleUnit = radian_a; units::dimensionless::scalar_t = units::unit_t<units::unit<std::ratio<1l>, units::base_unit<> > >]’:
units_angle.cpp:35:25:   required from here
units.h:3785:4: error: static assertion failed: Type `AngleUnit` must be a unit of angle derived from `unit_t`.
    static_assert(traits::is_angle_unit<AngleUnit>::value, "Type `AngleUnit` must be a unit of angle derived from `unit_t`.");
    ^

Do I have to declare more methods when inheriting? I looked into units.h but became lost between the macros...

[nholthaus]

yeah it probably needs some using operators for constructors and things. I'll prototype it and give you a better answer.

[djleach-belcan]

Was a working prototype ever created for this use case? I'd like to do something similar with dimensionless units that aren't compatible with each other and it seems with the current version of the library I can't define a new base unit. Is that correct?

[MikeGitb]

The problem I see with the inheriting strategy is that functions like e.g. operator+ will probably (I haven't looked into the implementation) return the base type unless they are also overloaded.

[EvanBalster]

Hey all —

I just finished writing a rough fork of the units library that lets you define new base dimensions. How's that for quick turnaround? (JK, I started tinkering with this months ago.)

>> https://github.com/EvanBalster/units/tree/eb-variadic-dimensions

This needs some testing, so I'd love to get your input. In your case, a new angle dimension could be defined like so:

#include <units.h>

namespace units
{
    UNIT_ADD_BASE_DIMENSION(d, 10101, angle_b, "Rad_b", "rad_b")

    namespace category
    {
        typedef base_unit<d::angle_b, std::ratio<1>> angle_b_unit;
    }

    UNIT_ADD_WITH_METRIC_PREFIXES(angle_b, radian_b, radians_b, rad_b, unit<std::ratio<1>, units::category::angle_b_unit>)
}

[EvanBalster]

Re-reading this thread, it sounds as if this use-case might be better served by defining multiple vector bases rather than multiple base dimensions (which no library can do right now).

https://en.wikipedia.org/wiki/Basis_(linear_algebra)

(For example, in a space with basis xyz (all in meters), components x and y are technically incommensurable even though the units are the same. To add one vector's x to another's y, I must first multiply it by some "dimensionless" quantity whose basis is (y / x). Such a quantity might show up as an entry in a matrix. However, x and y aren't different dimensions at all; I can combine them to produce a scalar magnitude in meters. We can also have a different xyz in a different basis, so that local x and global x require some transformation to be exchanged.)

This is a feature I've considered implementing in a programming language alongside the sort of dimensional analysis seen in units, in order to facilitate "strongly-typed" vector space modeling. I'm still trying to get my head around the nuances of it, though.

[nholthaus]

@EvanBalster check out this repo, which is what I'd been planning to incorporate: https://github.com/swatanabe/cppnow17-units.

You're probably onto something with the macros. I want to compare yours and this one and take the best of both worlds. Just skimming both, there seems to be some passing similarity, which is a good sign.

I also think we need a new vector math library with first-class unit support.

[nholthaus]

one difference is I don't think Steven's need a canonical order, which is pretty sweet, and something I've disliked about my own implementation.

[EvanBalster]

Hey, Nic —

To avoid derailing this thread, I replied to your comments about Steven's implementation over in the "Feature Implementation" thread. I may start another issue related to vector/matrix semantics, also to avoid any derailment.

Forgive me, pylipp, for the terrible damage I have wrought upon these rails...

[pylipp]

I'm happy to have sparked such a lively discussion, though I'm slightly confused now. Bottomline is that units currently does not provide a way to tackle the problem I have, however it is planned to implement such functionality?

Also thanks for the idea of using vector bases for defining multiple incompatible base dimensions of the same type.

[EvanBalster]

Hey, pylipp —

Pedantic note, but vector dimensions and dimensions of measure are different things! Unfortunately people tend to use the same words for them because there's a lot of conceptual overlap. Basically the key difference is that if I have vector "dimensions" meter_x, meter_y and meter_z, the following should be legal:

struct meter_vec
{
    meter_x_t x;
    meter_y_t y;
    meter_z_t z;
};

meter_vec v = {1_m_x, 2_m_y, 10_m_z};

sq_meter_t = (v.x*v.x) + (v.y*v.y) + (v.z*v.z);  // Legal vector math, fails with units

...But units doesn't distinguish between dimensions of measure and vector dimensions, so the square of meter_x_t will just be in dimension meter_x^2 instead of meter^2.

Nevertheless you can get pretty far with units as it exists now in spite of this incompleteness.

[nholthaus]

This will be possible in v3.0

[kunaltyagi]

@EvanBalster is there anything you've been tinkering with that allows basis vectors? I'm working on a project on which my headache will go away if I didn't have to call casting functions (or create templated auto casts) before every single call.