Mateusz Pusz
Mateusz Pusz
The above naming is also more consistent with the `value_cast(q)` that does the same thing.
Yes, I agree that naming is hard ;-) The first question is, do we agree that `cast_to` is a better choice than `force_in`? The second one is if we have...
Please note that at some point, we may also have `.cast_to()`. `cast_in()` does not look that nice anymore.
I thought about `.cast_in()` as well but then the problem comes with `cast_numerical_value_in()` or `numerical_value_cast_in()` where both seem to not read right. `cast_numerical_value_to()` looks better for me.
"Stored", "kept", or "hold" are not a valid solution here. We need two options for conversion. One that means 'convert safely' (e.g., no data truncation), and for that, we have...
I didn't mean it to be treated as a derived thing. Inheritance here is just an implementation detail to create a strongly typed name. We do it for other entities...
> Is Kelvin a Temperature-Distance? Kelvin is a unit. `quantity` is a differential/distance/vector type. `quantity_point` is a point type with the internal `quantity` value being stored relative to the `absolute_zero`...
Done some time ago
It seems that the IAU is not the only library customer for such a utility. #510 mentioned plenty of constants that are also specified with some uncertainty that might change...
We should also study what Python did for a similar feature: https://pythonhosted.org/uncertainties.