Feature Request: Allow defining incompatible units using existing unit_type/dimensions

[stellarpower]

Afraid I'm new to this library, so apologies if this has already been fixed/covered in another issue or I'm not getting things techinically correct.

I see an example here with something similar to what I am lookingto use the library for. I will have co-ordinates in the real world, and co-ordinates expressed in terms of a screen - in pixels, naturally - and I have code that maps between the two. I want to ensure that erroneous conversions can't happen.

I see that v3.0 will introduce the ability to add new base units, which is great. However, I'd like to add that I'd argue pixels are still in the dimensions of length. We can do all sorts of things the same - area, volume, accelerations - but, crucially, we shouldn't be able to convert (at leats not off the bat) betwee pixels and metres, because they represent units in totally different abstract co-ordinate spaces. It may be overkill to add a lot of user-defined unit types when we're really representing the same physical concepts but in a different world.

To add another couple of example use cases:

• I'm writing a simulation - say the traditional forest fire/disease/preadtor-prey simulation that is represented as a grid, where each space in the grid contains an agent (tree, infected animal, fox/rabbit) that has a probability of passing this onto the agent next grid. We have concepts like length, area, and time in simulation cycles, yet these aren't in any way meaningfully converted to SI units, without some kind of separate logic.
• We're designing and modelling an abstract processor. We have units of clock cycles that could theoretically be represented in seconds, if we were using real hardware. However, as a theoretical machine, we will never have a real frequency to operate on.
• I see some mention of currency exchange. Adding a concept like a quantity of money to the dimensions/base units makes sense to me, we can't possibly represent it using any other system, and we can now add concepts like cost per square metre, or our profit each year, using existing SI units. But perhaps we write a Sims-style game. If we had money as a base dimension, we'd now need to add another, to represent their abstract in-game currency, which we can't evcer express meaningfully in real-world units. I understand a units library for this case would be a bit unusual, but think it illustrates the idea that a same set of base units could exist in a modelled system, but without ever being able to convert using existing logic.

So whilst I can define some new units to suit my use-case of pixels, I think that it might also be helpful if it were possible to define new base_unit sets that are using the same existing dimensions, but are not convertible between each other - we can't simply represent one as a std::ratio of the other. I'd be concerned that adding new dimensions repeatedly could rapidly lead to code bloat if the library is well-utilised in a body of code, where I'd prefer to see new dimensions added when the quantity being expressed is totally different from anything already in the standard set - money, as an example. I could probably achieve this by adding some new base units and strong-type wrapping these, but I think having some of this built-in, as a halfway between a new dimension and using existing units would be a bonus. Even just tag dispatch added in might be enough.

Thanks :)

[JohelEGP]

I could probably achieve this by adding some new base units and strong-type wrapping these

I think a separate base dimension does the job.