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

NamedTuple constructor support for FieldArray subtypes #1246

Merged
merged 4 commits into from
Feb 26, 2024

Conversation

cadojo
Copy link
Contributor

@cadojo cadojo commented Feb 22, 2024

This PR was originally posted to StaticArraysCore.jl, but was moved to here because StaticArraysCore lacks the method definitions necessary to make this NamedTuple functionality work.

I have found NamedTuple to be a performant way to initialize FieldArray subtypes. See, for example, the following code in AstrodynamicalModels.jl. I think it may also be useful sometimes to go in reverse: convert a FieldArray subtype back into a NamedTuple. Do you agree this may be useful, and without undesirable side effects? I got this idea from SciML's Base.NamedTuple method for LabelledArrays.jl. Thanks for reading!

"""
A mutable vector, with labels, for 6DOF Cartesian states.
"""
Base.@kwdef mutable struct CartesianState{F} <: FieldVector{6,F}
    x::F = 0.0
    y::F = 0.0
    z::F = 0.0::F = 0.0::F = 0.0::F = 0.0

    CartesianState{F}(::UndefInitializer) where {F} = new{F}()
    CartesianState(::UndefInitializer) = CartesianState{Float64}(undef)

    CartesianState{F}(x, y, z, ẋ, ẏ, ż) where {F} = new{F}(x, y, z, ẋ, ẏ, ż)
    CartesianState(x, y, z, ẋ, ẏ, ż) = new{promote_type(typeof(x), typeof(y), typeof(z), typeof(ẋ), typeof(ẏ), typeof(ż))}(x, y, z, ẋ, ẏ, ż)
    CartesianState{F}(state::NamedTuple) where {F} =
        let
            (; x, y, z, ẋ, ẏ, ż) = merge((; x=zero(F), y=zero(F), z=zero(F), ẋ=zero(F), ẏ=zero(F), ż=zero(F)), state)
            CartesianState{F}(x, y, z, ẋ, ẏ, ż)
        end
    CartesianState(state::NamedTuple) = CartesianState{Float64}(state)
end

test/FieldVector.jl Outdated Show resolved Hide resolved
@mateuszbaran
Copy link
Collaborator

I think this is useful.

@mateuszbaran
Copy link
Collaborator

Could you just add a test for convert and bump patch version?

src/FieldArray.jl Outdated Show resolved Hide resolved
@cadojo
Copy link
Contributor Author

cadojo commented Feb 26, 2024

Is this okay as-is, despite the julia-nightly failure? I am assuming that is a Julia development branch quirk and not a problem with this branch.

@mateuszbaran
Copy link
Collaborator

There is no julia-nighty failure on the latest commit but even if there was, it would be fine as long as the failure is not related to changes in the PR.

@mateuszbaran mateuszbaran merged commit 07c1245 into JuliaArrays:master Feb 26, 2024
26 checks passed
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.

3 participants