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

Create LazyFloat64 type for units #30

Closed
wants to merge 4 commits into from
Closed

Create LazyFloat64 type for units #30

wants to merge 4 commits into from

Conversation

MilesCranmer
Copy link
Member

This PR creates the LazyFloat64 type for storing units. It makes units try to demote their numeric type, rather than promote everything to Float64:

julia> typeof(1u"m/s")
Quantity{Int64, Dimensions{DynamicQuantities.FixedRational{Int32, 25200}}}

julia> typeof(1.0u"m/s")
Quantity{Float64, Dimensions{DynamicQuantities.FixedRational{Int32, 25200}}}

julia> typeof(1f0u"m^2.5")
Quantity{Float32, Dimensions{DynamicQuantities.FixedRational{Int32, 25200}}}

julia> typeof(1u"fm")
ERROR: InexactError: Int64(1.0e-15)

@mcabbott could you review this?

src/units.jl Outdated
@@ -126,12 +127,12 @@ Parse a string containing an expression of units and return the
corresponding `Quantity` object with `Float64` value. For example,
`uparse("m/s")` would be parsed to `Quantity(1.0, length=1, time=-1)`.
"""
function uparse(s::AbstractString)
return as_quantity(eval(Meta.parse(s)))::Quantity{DEFAULT_VALUE_TYPE,DEFAULT_DIM_TYPE}
function uparse(s::AbstractString)::Quantity{LazyFloat64,DEFAULT_DIM_TYPE}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This ensures that any unit is converted to a LazyFloat64 at the end. So even u"1.0" would become a LazyFloat64.

@github-actions
Copy link
Contributor

github-actions bot commented Jun 29, 2023

Benchmark Results

main a1cfbbb... t[main]/t[a1cfbbb...]
creation/Quantity(x) 3.2 ± 0.1 ns 2.8 ± 0.1 ns 1.14
creation/Quantity(x, length=y) 3.3 ± 0.1 ns 3.3 ± 0.1 ns 1
time_to_load 0.139 ± 0.0029 s 0.145 ± 0.003 s 0.961
with_numbers/*real 2.9 ± 0.1 ns 3.2 ± 0.1 ns 0.906
with_numbers/^int 21 ± 1.6 ns 20.7 ± 1.7 ns 1.01
with_numbers/^int * real 21.1 ± 1.7 ns 21.1 ± 1.3 ns 1
with_quantity/+y 5.9 ± 0.1 ns 5.7 ± 0.2 ns 1.04
with_quantity//y 3.3 ± 0.1 ns 3.7 ± 0 ns 0.892
with_self/dimension 1.6 ± 0.1 ns 1.6 ± 0.1 ns 1
with_self/inv 3.3 ± 0.1 ns 3.3 ± 0.1 ns 1
with_self/ustrip 1.6 ± 0.1 ns 1.6 ± 0.1 ns 1

Benchmark Plots

A plot of the benchmark results have been uploaded as an artifact to the workflow run for this PR.
Go to "Actions"->"Benchmark a pull request"->[the most recent run]->"Artifacts" (at the bottom).

[Diff since v0.5.0](v0.5.0...v0.6.0)

**Closed issues:**
- Physical constants (#26)

**Merged pull requests:**
- Create (1) physical constants, and (2) symbolic dimensions object (#32) (@MilesCranmer)
@MilesCranmer
Copy link
Member Author

Actually I think it's better if we only demote to abstract floats, but try to promote for everything else. Then we don't have to worry about integers.

@MilesCranmer
Copy link
Member Author

Moved to #66

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

Successfully merging this pull request may close these issues.

1 participant