You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When there are multiple bundled Estimates, like an Estimate for temperature and salinity in one problem, their uncertainty can be correlated through off-diagonal elements in the joint Estimate uncertainty matrix. Therefore some information is missing if two independent Estimates are used for temperature and salinity separately.
One could expand the Estimate struct to include a covariance matrix. Depending on the number of variables/sub-types in the Estimate, it would get messy fast. BlockFactorizations could probably handle these blocks in the Estimate uncertainty matrix.
Alternatively one could use a Matrix that has indexing to locate various subtypes. This approach would just store one vector and one matrix in Estimate, as it was originally constructed. We expect the uncertainty matrix to generally be dense and full, and thus this approach would not be missing out on memory savings by storing one big matrix.
For approach #2, there are a number of community packages. AxisArrays.jl is less maintained.
Approach #2 with one vector and one matrix under the hood had been implemented by PR #26 or earlier. Estimate contains logic to display a tidy dimensionalData style array or matrix.
Estimate
tracks best estimate and uncertaintyWhen there are multiple bundled
Estimate
s, like an Estimate for temperature and salinity in one problem, their uncertainty can be correlated through off-diagonal elements in the joint Estimate uncertainty matrix. Therefore some information is missing if two independentEstimate
s are used for temperature and salinity separately.One could expand the
Estimate
struct to include a covariance matrix. Depending on the number of variables/sub-types in the Estimate, it would get messy fast.BlockFactorizations
could probably handle these blocks in the Estimate uncertainty matrix.Alternatively one could use a Matrix that has indexing to locate various subtypes. This approach would just store one vector and one matrix in Estimate, as it was originally constructed. We expect the uncertainty matrix to generally be dense and full, and thus this approach would not be missing out on memory savings by storing one big matrix.
For approach #2, there are a number of community packages. AxisArrays.jl is less maintained.
AxisArrays 35, AxisArraysFuture 30, NamedDims.jl 40, DimensionalData.jl 37
https://github.com/Tokazama/AxisIndices.jl
discussion here:
JuliaCollections/AxisArraysFuture#1
https://discourse.julialang.org/t/the-fate-of-dimensionalarrays-axisarrays-in-julia-and-which-to-actually-use/33253
The text was updated successfully, but these errors were encountered: