JuliaPhysics / JuliaPhysics/DynamicQuantities.jl
Make AbstractDimensions <: Number
- Dominant language
- Julia
- Stars
- 155
- Forks
- 32
- PR merge metrics
- No merged PRs in 30d
Description
## Background
Hello,
I am the developer of [UnitfulTensors.jl](https://github.com/anonymous-shrew/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:
```julia
function f(args::Vararg{Quantity})
vals = map(ustrip, args)
dims = map(dimension, args)
return Quantity(f(vals...), f(dims...))
end
```
Which 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 `Number`s 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 `convert`ed to something like `Float64` or `Complex{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.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.