JuliaPhysics / JuliaPhysics/DynamicQuantities.jl

Make AbstractDimensions <: Number

Open
#176 4 comments 0 reactions 0 assignees View on GitHub
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.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.