Terser syntax for temporaries about mp-units HOT 12 CLOSED

Thanks for a helpful suggestion. As you know, I am trying to make error messages as short as possible. In the new design that I will soon merge to master, there is no base_ prefix anymore. Overall, I am pleased with the latest design, and I am curious about your feedback. It should be merged soon.

Regarding having another type for den, I do not think it is a good idea. We save only one template parameter, but we have to introduce (and standardize) a new type for every dimension. Also, having a template parameter in the dimension for its exponent does not look right. The dimension by itself should not know about its exponent in a derived quantity. Also, it does not apply only to base dimensions as I allow to provide a recipe for a derived dimension containing other derived dimensions (to create a deduced unit or to use it while printing unit symbols).

from mp-units.

I am guessing the following is something like the type of syntax you want (I am using make_quantity() function, bearing in mind I am targeting c++11 and in c++23 this could be done in template parameters as I understand it). Here is constructed some quantity representing a force.

   auto constexpr q2 = make_quantity<-3>(
      mass_dim * length_dim / (time_dim * time_dim), 20.0
   );

https://github.com/kwikius/pqs/blob/master/test/syntax_test2.cpp#L227

The definition of operations is also shown there above, all either acting on the various combainations of dimension and base_dimension_ratio
I concocted an error message to show the output shown at the bottom in the source file above.

EDIT: I stripped out the dimension from the unit which makes it shorter yet.

Anyway I am looking forward to your next version of your code.

from mp-units.

Please remember that the most important requirement here is ease of use. I think that:

auto constexpr q2 = si::force<si::newton>(20);

is way easier to work with than:

auto constexpr q2 = make_quantity<-3>(mass_dim * length_dim / (time_dim * time_dim), 20.0);

;-)

Of course, you can predefine some stuff but from my experience:

• dim_length and metre should be defined once in the library as a base dimension and a base unit (there should be no derived dimension of length)
• dim_length is the one that the user would use in a quantity than having num and den template parameters there is an issue for the user
• unit depending on a dimension has issues with multi-system system support; this is one of the biggest reasons why I provided a new design
• dimensions as values look nice in the code but will not work with downcasting. We need types for that.

from mp-units.

Regarding the latest design and documentation, it is already on top and starting from tomorrow should also work fine with the Compiler Explorer.

from mp-units.

Please remember that the most important requirement here is ease of use. I think that:

auto constexpr q2 = si::force<si::newton>(20);

is way easier to work with than:

auto constexpr q2 = make_quantity<-3>(mass_dim * length_dim / (time_dim * time_dim), 20.0);

;-)

I know that

auto constexpr q1 = si::force::mN{20};

which is my preferred syntax for many years, is way easier to work with than

auto constexpr q2 = si::force<si::newton>(20);

;-)

The operations on abstract quantities is just for fun but is useful for learning about quantities and dimensional analysis , testing out quantities and scripting , so I found it rewarding and potentially useful...

#include <iostream>
#include <pqs/bits/quantity.hpp>
#include "make_quantity.hpp"

using namespace pqs;

namespace {

  // the base_quantities (or base_dimensions )

   constexpr dim_mass<1> mass;
   constexpr dim_length<1> length;
   constexpr dim_time<1> time;

  // can be used to construct more complicated abstract quantities 
 
   constexpr auto velocity = length / time; 
   constexpr auto acceleration = velocity / time; 
   constexpr auto force = mass * acceleration;
}

// which can be used to create arbitrary quantity types for use at runtime...

int main()
{
   auto q1 = make_quantity<-3>(force, 20.0);
}

from mp-units.

Yes, values usage is really tempting here. I experimented with them a lot too (you can find some of it here: https://mpusz.github.io/wg21-papers/papers/1935_a_cpp_approach_to_physical_units.html#prefixes-and-units). However, I still do not know how to make them work with a downcasting facility so the user will actually see force as defined by the user rather than a long exponents list in a derived dimension.

People will more often work with quantities and see error messages and types in a debugger than add new derived dimensions to the library. We have to optimize for the first case.

from mp-units.

... However, I still do not know how to make them work with a downcasting facility so the user will actually see force as defined by the user rather than a long exponents list in a derived dimension.

maybe via derivation:

namespace {

   constexpr dim_mass<1> mass;
   constexpr dim_length<1> length;
   constexpr dim_time<1> time;
   constexpr auto velocity = length / time; 
   constexpr auto acceleration = velocity / time; 
   constexpr auto force = mass * acceleration;
//#################################################
   struct dim_torque : decltype(force * length){};
   struct dim_energy : decltype(force * length){};
//################################################
    
   // separate types...
   dim_torque torque;
   dim_energy energy;
}

int main()
{
   auto q1 = make_quantity<3>(torque,20.0);
   auto q2 = make_quantity<3>(energy,20.0);
}

People will more often work with quantities and see error messages and types in a debugger than add new derived dimensions to the library. We have to optimize for the first case.

1. The type of code above is useful to lower barrier to entry, an important issue in making c++ more accessible
2. I found I needed to create new 'named' quantities quite frequently and so the process needs to be simple as possible.
   Here are some types I used. https://github.com/kwikius/quan-trunk/tree/master/quan/components

As I stated before I did experiment with converting anonymous quantities to named quantities(which I called 'hoisting'), but the results will always be arbitrary dependent on which named quantities are visible, therefore I opted eventually to just leave anonymous quantity r-values to be be converted to named l-values as required by the programmer. That at least provides consistency in a large codebase.

from mp-units.

In such a case we will need to write something like this:

namespace {

   constexpr dim_mass<1> mass;
   constexpr dim_length<1> length;
   constexpr dim_time<1> time;
   constexpr auto velocity = length / time; 
   struct dim_velocity = derived_dimension<dim_velocity,  metre_per_second, decltype(velocity)>
   constexpr auto acceleration = velocity / time; 
   struct dim_acceleration = derived_dimension<dim_acceleration, metre_per_second_sq, decltype(acceleration)>
   constexpr auto force = mass * acceleration;
   struct dim_force = derived_dimension<dim_force, newton, decltype(force)>
//#################################################
//   struct dim_torque : decltype(force * length){};
//   struct dim_energy : decltype(force * length){};
// above will not work because the downcasting framework is 1-to-1 binding
// The framework will never be able to know which  of the child classes to instantiate when force * length is found
//################################################

I do not think that repeating a value and a type simplifies stuff. Also as I pointed out the downcasting will not work for energy and torque. If you will not downcast you will not know how to i.e. print its units. :-(

from mp-units.

Sorry, I closed it accidentally by clicking the wrong button. But it seems that even though I like values and their potential usage as NTTPs, without the support for downcasting we will have to just close this issue without doing any changes to the design :-(

from mp-units.

 constexpr dim_mass<1> mass;
   constexpr dim_length<1> length;
   constexpr dim_time<1> time;
   constexpr auto velocity = length / time; 
   struct dim_velocity = derived_dimension<dim_velocity,  metre_per_second, decltype(velocity)>
   constexpr auto acceleration = velocity / time; 
   struct dim_acceleration = derived_dimension<dim_acceleration, metre_per_second_sq, decltype(acceleration)>
   constexpr auto force = mass * acceleration;

There is a misunderstanding there
Bear with me, I will see if I can explain this better.

from mp-units.

Just to make it more clear. If you divide length<1> by time<1> the framework will end up with something like a quantity<dimension<length<1>, time<-1>>, ...>. The question now is how to know in a framework that the user created a dedicated type (or value) called velocity for such a dimension so the actual downcasted type will look like quantity<velocity, ...>.

Also, as you are aware torque and energy have exactly the same dimension but they are 2 different stuff (among others their symbols should be printed differently). You can provide information about such differences only in concrete types dedicated to torque and energy but the framework will never know which of those to choose. I hope that I will be able to find a trick that will disable downcasting for such cases (instead of having a compile-time error) and user will have to make a quantity_cast to those. But I would prefer to continue this discussion in #32.

from mp-units.

OK

from mp-units.