Issue Summary

History:

variableTypesofttype was added to DFGVariable DataLevel2 to solve two problems, then DFGVariableSummary (DataLevel1) came along and is exposing two competing needs which are being wrestled out as softtypename.

Requirements

• ("Manifest" aspect) information like which Manifolds, variable dimension, or Visualization projection functions to use.
• (Stateful aspect) When a user suddenly has some funky situation that requires additional variable information that must be available during deep-inner-computation-loop computations.
  • Related, see FactorMetadata that exposes the softtype and other information to the solver.
  • Possible alternative, Smalldata is an ongoing discussion for which the design is still in flux, and might induce serious performance problems owing to risk of user adding Unstable Types into the deep-inner-computation-loops.
  • Prior example is DynPose2 need to store microsecond time to allow velocity calculation, which was only added as full timestamp much later -- however, the situation can repeat with some other user data that cannot be designed in advance.

Related Issues

• Manifolds.jl Standardization:
  • Integrate with Manifolds.jl RoME.jl#244
  • Integrate with Manifolds.jl ApproxManifoldProducts.jl#32
• DataLevel1 softtypename: was softypename::Symbol a bad idea? DistributedFactorGraphs.jl#237
• smalldata:
  • Serialize smalldata to a blob-less entry in CGDFG DistributedFactorGraphs.jl#509
  • Discussion: Pass variables to factor evaluation so that we can use variable data? #784
• Towards immutable FactorMetadata(...) #825

Plan of Action

Can split these into more issues once a design decision is made.

• quickly do change Singleton / Pairwise to AbstractPrior / AbstractRelativeFactor DistributedFactorGraphs.jl#533 as easy picking to solve naming problem,
• Decide whether softtype::T should have stateful information or where to offload that requirement?
  • DF vote +1 to split stateful aspect out, see mechanism vote hereafter.
  • SC +1 to split it out. If we're going to store info, I'd like it in the variables, even if there is a performance hit (factor evaluation may retrieve smallData, or even bigData - that's up to the user). The alternative (duplicating data) I think is arguably worse.
  • JT vote +1 to split out. split inference variables (currently described by the softtype) from "constants" (the utime field for example) - I want to keep the possibility open that softtype becomes a hard type of a manifold (it feels right, but its a whole new issue) and think this is a step in that direction.
• Decide how to solve future user stateful variable data for computations problem
  • See proposals here: Manifest VariableTypes (Singleton model) and new FMD #783 (comment)
    • DF vote +1: use "inheritance"/"interface"/"traits" from a singleton type like Pose2 that you "inherit" and add own data to
    • SC +1 to just exposing the data to the user and letting them decide (i.e. you can make your own factor types, but you can also retrieve variable data).
    • JT I'll need a bit more insight into the uses and core inference before I can say. Currently, I'm leaning towards: It should be in solver data (lv2). Singleton types for now.
  • requires solution for ensuring type stability and can implement that process in Discussion: Pass variables to factor evaluation so that we can use variable data? #784 once decision on mechanism is made in this issue 783.
• Decide how getSofttype should work.
  • DF vote+1 for anything that follows from above votes.
  • SC +1 to it's stateless Singleton
  • JT +1 stateless - for now Singleton.
• Integrate new stateful mechanism with FactorMetadata
  • Likely will also be part of Discussion: Pass variables to factor evaluation so that we can use variable data? #784
• Documentation on how a user should add computational data and use in computations
  • e.g. first use see Changing radar factor to use a correct serialization strategy Caesar.jl#611
• Deprecate name softtype to only VariableType see Deprecation, rename softtype -> VariableType DistributedFactorGraphs.jl#603

Original Question

We need to fix all softtypes to have a default constructors, and take out all state information.

Types with issues:

struct ContinuousMultivariate{T1 <: Tuple} <: InferenceVariable
  dims::Int
  manifolds::T1
  ContinuousMultivariate{T}() where {T} = new()
  ContinuousMultivariate{T}(x::Int; manifolds::T=(:Euclid,)) where {T <: Tuple} = new(x, manifolds)
end

mutable struct DynPose2 <: IncrementalInference.InferenceVariable
  ut::Int64 # microsecond time
  dims::Int
  manifolds::Tuple{Symbol,Symbol,Symbol,Symbol,Symbol}
  DynPose2(;ut::Int64=-9999999999) = new(ut, 5, (:Euclid,:Euclid,:Circular,:Euclid,:Euclid))
end

struct ContinuousScalar <: InferenceVariable
  dims::Int
  manifolds::Tuple{Symbol}
  ContinuousScalar(;manifolds::Tuple{Symbol}=(:Euclid,)) = new(1, manifolds)
end

DF EDIT, a related issue is how to make it easy for the user to add their own data types to the default factors. Softtype with state solved that problem, but making it a manifest or hardtype removes that option.
SC: I suggest we add smallData to factors.