Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Registering custom unit propagation rules #64

Open
gaurav-arya opened this issue Oct 15, 2023 · 0 comments
Open

Registering custom unit propagation rules #64

gaurav-arya opened this issue Oct 15, 2023 · 0 comments

Comments

@gaurav-arya
Copy link
Collaborator

gaurav-arya commented Oct 15, 2023

It could be useful for users (especially package authors) to write custom unit propagation rules for their functions, that instruct DynamicQuantities on how units propagate from the input to the output without having to analyze the whole function. Writing a generic rule for abstract quantities seems nearly already possible with a simple dispatch, for example:

julia> using DynamicQuantities

julia> function mycube(x)
           # this function does not like DynamicQuantities
           x isa AbstractQuantity && sleep(1)
           return x^3
       end
mycube (generic function with 1 method)

julia> function mycube(x::AbstractQuantity)
           return DynamicQuantities.new_quantity(typeof(x), mycube(ustrip(x)), dimension(x)^3)
       end
mycube (generic function with 2 methods)

julia> @time mycube(1u"m")
  0.000001 seconds
1.0

The "nearly" is because DynamicQuantities.new_quantity is not currently public API: should it be?

One could imagine using this pattern for performance on a complicated function (e.g. with many inner loops, scalar calculations, etc.), in cases where exists a performance overhead of DynamicQuantities and a package author wants to ensure zero-overhead performance while avoiding the everything-is-a-new-type approach of unitful, e.g. #55.

We could make the process even easier than the above, too. For example, we could automate the process of ustrip'ing and feeding into the original functions, handling general inputs via Functors.fmap(ustrip, args), so that the user only has to specify how the dimension is propagated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant