Standardize FactorState (name also)

[Affie]

WIP

FactorState Fields
eliminated::Bool
potentialused::Bool
multihypo::Vector{Float64}
certainhypo::Vector{Int}
nullhypo::Float64
inflation::Float64

Notes

• In Standardize solver data noun for variables and factors #1121 (comment) we went with state for variables and factors, later Recipe was also suggested as new name. xref Investigate splitting factor operational part from 'constant' part of factor #992.
• solveInProgress to be removed: Standardize [Packed]State #1181 (comment)
• certainhypo might have moved (@warn "CommonConvWrapper.certainhypo is now under ccw.hyporecipe.certainhypo" maxlog=5), TODO: there is also a chance that it is largely dead code?
• multihypo, nullhypo, and inflation looks like user parameters that are only set at factor creation and used to create the HypoRecipeCompute.
• We can maybe split the parameters/recipe part and the Bayes tree part (eliminated and potentialused).

[dehann]

Yes, from what I remember recipe is the right name. This ties in with "why use a bipartite factor graph" -- because a sensor producing an observation is effectively observing 'a state'. So DFG Variables* have .state but Factors have both the observation and the mechanics relating to the physics/process being observed. So the word .state is insufficient for factors, we need something that is (state + mechanics) and .recipe sounds right to me. It is also how the solver knows what to do -- work the recipe and end result is all the variable state estimates (new future HomotopyBelief estimates to be precise).

[Affie]

I brainstormed with copilot for some naming options:

• FactorState: Acceptable if you want a single struct for both config and runtime flags, but it’s ambiguous—users may expect only runtime/algorithm state, not configuration.
• FactorAttributes / FactorProperties: Both are generic and communicate a mix of config and runtime, but don’t clarify which fields are mutable or set at creation. Slightly better than FactorState for clarity, but still broad.
• FactorParameters: Implies only configuration/creation-time settings. Not suitable for runtime flags unless you split.
• FactorRecipe: Suggests a template or instructions, not actual state or flags. Not recommended for persisted state.
• Splitting (FactorState + FactorParameters): Best for clarity and future maintainability. FactorParameters for immutable config, FactorState (or FactorStatus) for runtime/persisted flags. This matches your intent and makes the API clearer for users and power users.

Recommendation:
If you want clarity and extensibility, split into FactorParameters (config) and FactorState (runtime/persisted flags).
If you prefer cohesion and minimal change, keep FactorState but document the mixed purpose clearly.

Summary:

• For clarity: Split (FactorParameters + FactorState)
• For minimal change: FactorState (with clear docs)
• Avoid: FactorRecipe (misleading), FactorProperties/Attributes (too generic)

[dehann]

I thought we already decided this and confused on why this is coming up again. And again, you are putting my existing comments second to chatgpt which will not be correct in this instance. I'll repeat in writing (again) -- please xref the existing discussion on FactorRecipe here.

• I'm in favor of FactorRecipe, bacuse no one else will have (non)Gaussian terminology, so don't use chatgpt. although the chatgpt definition above is exactly the right for what we need: Suggests a template or instructions, not actual state or flags. Not recommended for persisted state.
• I'm against all the following because:
  • FactorState, avoid confusion with fluid estimated (variable) states even though the measurement process has internal state estimation.
  • FactorParameters / FactorAttributes / FactorProperties, ambiguous with solver parameters, which has been the hacky solution for "robustness" -- this is contrary to why Caesar.jl solver base exists.
  • Splitting, I'm strongly against this. We have discussed this over and over, to put the various aspects for non-Gaussian solutions together with conventional parametric settings.

The field names are good enough for DFG v1.0, elimintated, potentialused, multihypo, certainhypo, nullhypo, inflation.

When the core algorithms change we'll update these names and likely to go to DFG v2.x if breaks are needed.

[Affie]

To close this issue we needs to:

• finalize the struct and field✓ names (looks like you are happy with the field names)
• Make sure fields are actually in use
• give a migration table like all the other structs in question.

And again, you are putting my existing comments second to chatgpt which will not be correct in this instance. ... so don't use chatgpt

Copilot is a good way of gauging what users might think and brainstorming ideas and that is where the noun State (replacing VariableNodeData) came from.
#1185 (comment) is just brainstorming options as the first line states. Of course, it will be biased by the way I asked the questions, but so far I haven't made up my mind on what will be the best way forward, I'm leaning towards rather splitting parameters and state as it is currently confusing with either name or just dropping the extra struct.

I'll repeat in writing (again) -- please xref the existing discussion on FactorRecipe here.

There are no such discussion to xref, you suggested a possible better name of Recipe (as in getRecipe not getFactorRecipe) in a meeting, the only thing that was decided on was to name the struct FactorState xrefed in first issue. Therefore, I looked at all the options with this suggestion in mind.

The story I saw after digging for a few hours was:

• User parameters are saved in a factor during creation.
• Some of these parameter are used to create the HypoRecipe for the non parametric solver, others are just used by the solver).
• The HypoRecipe is in factor.cache and not persisted.
• One of the variables in the recipe (certianhypo) is persisted (but this currently looks like dead code)
• eliminated and potentialused are variables used during tree construction and the persisted values are never used.

Splitting, I'm strongly against this. We have discussed this over and over, to put the various aspects for non-Gaussian solutions together with conventional parametric settings.

Where have we discussed splitting tree construction state variables from solver parameters/recipe. The comment clearly states splitting "for immutable config ... for runtime/persisted"

I like the Recipe noun where it is used in IIF (HypoRecipe), but eliminated and potentialused has nothing to do with a recipe. So that is why I think splitting makes more sense.

When the core algorithms change we'll update these names and likely to go to DFG v2.x if breaks are needed.

• This was previously called FactorData/SolverData/etc. and that is perhaps the most generic name that will not break, but it is not very descriptive.
• Splitting with generic names like FactorParameters (for static) and FactorState (for dynamic) will also help avoid breaking changes. If it is part of a Recipe that you want to persist, use the dynamic container or use the static container for the constants you use to build the recipe with.
• We can also make everything a lot easier and move the fields to the FactorDFG struct, I think this will be the most prone to break in the future, but avoids the nested data modelling issues.