Standardize `Recipehyper` and `Recipestate` (was `FactorState`)

[Affie]

FactorState is split into Recipestate and Recipehyper as follows:

	FactorState Fields	Recipestate Fields	Recipehyper Fields
✓	✎eliminated::Bool	eliminated::Bool
✓	✎potentialused::Bool	potentialused::Bool
✓	✎multihypo::Vector{Float64}		multihypo::Vector{Float64}
✓	×certainhypo::Vector{Int}
✓	✎nullhypo::Float64		nullhypo::Float64
✓	✎inflation::Float64		inflation::Float64
✓	×solveInProgress::Int

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 (and comments like this), 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 noun of Recipe (as in getRecipe not getFactorRecipe - as the factor equivalent of getState) in a meeting, the only thing that was decided on was to name the struct FactorState xrefed in first issue and #1138 specifically mentions that recipe is part of factor cache. 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? (please give a xref if I missed it, the closest I know if is this). The splitting comment states splitting "for immutable config ... for runtime/persisted"

I included Parameters as one of the options because it is already in use in IIF as SolverParams. inflation gets it's default from SolverParams

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. I think the equivalent parametric recipe (maybe buildRecipeParametric) is basically the badly named specialAlg:

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

• Use a generic name: 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. FactorState still fits here and can remain as the name because for example, parameters can originate from a parameter sweep and state captures the state of these parameters or the state of the recipe variables.
• Split static/dynamic: 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.
• Flatten: 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. This is my least favourite for the long term (although easiest for short term) as the fields in FactorDFG will be a lot more stable than the fields in FactorState(TBD)
• Split tree variables to FactorDFG Splitting out only the tree construction variables to FactorDFG.

I made this table to try and match the fields to the types.

Fields	Class
eliminated	Tree elimination variable
potentialused	Tree elimination variable
solveInProgress	Solver variable (unused/dead code)
certainhypo	Factor solver variable (from ccw.hyporecipe)
multihypo	Factor solver parameter (from construction parameter)
nullhypo	Factor solver parameter (from construction parameter)
solvable	Factor solver parameter (from construction parameter and setSolvable!)
inflation	Solver parameter (from construction parameter with default from SolverParams.inflation)

Summary on Recipe

• I like Recipe for buildRecipe,something like:
  • buildRecipe[Default](recipe_parameters) -> HypoRecipe <: [Abstract]Recipe
  • buildRecipeParametric(recipe_parameters) -> MaxMixtureRecipe <: [Abstract]Recipe
• Recipe also ties in nicely with my epoch idea.
  • "Solve epoch: 13 used solver MM-iSAMv1 with Recipe d14a02" (tree ordering included in recipe)

[Affie]

From call:
Splitting has engineering motivation for larger than memory operations.
Naming decided as

• Recipehyper

  • Hyperparameters (The "Knowns" / Configuration)
  • .hyper

• Recipestate

  • for states such as eliminated and potentialused )
  • .state