-
Notifications
You must be signed in to change notification settings - Fork 25
Description
Background
Hello,
I am the developer of UnitfulTensors.jl, a linear algebra library with support for physical units. At the start of the development, I defined some types for working with scalar quantities, which are basically equivalent to your Dimensions, AbstractDimensions, Quantity, and AbstractQuantity. Now I am considering outsourcing all scalar functionality to DynamicQuantities.jl.
I noticed that things get simpler if AbstractDimensions was a subtype of Number.
Motivation
Physical dimensions are scalar (i. e., non-container) objects supporting arithmetic operations:
- length + length = length, length + time = error
- length - length = length, length - time = error
- length * length = area
- length / length = dimensionless
Other mathematical functions can be defined too:
- abs(length) = length
- exp(dimensionless) = dimensionless, exp(length) = error
With such definitions, most operations on physical quantities can be expressed in a uniform manner:
function f(args::Vararg{Quantity})
vals = map(ustrip, args)
dims = map(dimension, args)
return Quantity(f(vals...), f(dims...))
endWhich is rather neat.
Also, AbstractDimensions <: Number would ensure the correct (scalar-like) broadcasting behavior.
Possible objections
- Addition and subtraction are defined only for identical dimensions.
However, even with more usual Numbers there are cases when some arithmetic operations are undefined. E.g., you cannot divide by zero. You generally cannot divide integers and expect the result to be an integer. For positive integers, even subtraction is generally undefined (if one requires the result to be a positive integer), as well as zero(x). Addition may result in overflow.
- Dimensions cannot be
converted to something likeFloat64orComplex{Float64}.
But the same can be said about quaternions, transfinite numbers, Grassmann numbers.
And, of course, the same objections would apply to quantities as well.
An unrelated question
Why did you write your own parsing/printing functions instead of using those from Unitful.jl? Defining megameters but not megagrams looks arbitrary. Dimensions are not units, so printing dimension(1u"cm") as "m" is arguably incorrect.