Steven Watanabe wrote:
AMDG
Noah Roberts <roberts.noah <at> gmail.com> writes:
Frankly put, I don't have a use for a library that does static unit conversions. We work in one system of units and convert into/out of those units when required to arbitrary units the user specifies and there are of course only a few dimensions we do this in. I have a hard time seeing a situation in which this isn't the way you would want to go about it.
As has been stated before, this library is primarily about type safety. The conversions are a secondary concern.
From what you are saying I think that you have not seriously considered what the implementation should look like. There are two basic possibilities
1) Store everything in some standard unit system and also store the conversion factor to the requested system.
2) Store the value in the requested unit system and remember the conversion factor to the standard system.
How should addition and subtraction be defined? You cannot require that the operands have the same unit. Otherwise harmless looking code such as 1.0 * joules + (2.0 * kilograms * pow<2>(2.5 * meters / second)) / 2; might not work. Converting the second to match the first will work but loses precision. If you use 2. to avoid the precision loss brought about by the conversions involved in 1., by the time you are finished you will end up losing more precision than if you had simply converted to SI to begin with.
"Converting the second to match the first" doesn't make sense to me. I guess you might be talking about operands of '+'? Yeah, not necessary. The answer is pretty simple. All arithmetic operators work in the base system. The result is converted on assignment if necessary.
Both of these require storing twice as much information as the current implementation.
There is one condition in which that is necessary. That is if you are using a value that is entered by the user and the calculation loop keeps requesting it from whatever object it is provided by. Then, in order that the conversion isn't repeatedly done you would want to store two values...the user entered value and the converted value. The reason you wouldn't just store the converted value is double creep...the number might change on the user. I imagine that a developer who needs to can work with this so that it does not happen...so that the calculation loop is not asking for the same conversion on the same value repeatedly. Any other time it is sufficient that you keep only the user entered value and the unit (ie the conversion factor) to translate it into the base system...OR...the converted value in the base system without a conversion factor. The inefficiency is
probably more than a simple factor of two because the size increase will most likely force the compiler to continually load and store instead of keeping the values in a register.
Any more complex approach will add even more overhead. For example, storing a sorted dimension list necessiates a call to merge for every single multiplication or division.
Don't know why any of that would be necessary.