Standardize graph CRUD API for update/merge/union

[dehann]

To capture discussion and decision: want to make sure we have consistent update/merge/union behavior. I think there was a renaming from update to merge at some point perhaps. Something to the effect of (and free to disagree):

• update will update an existing key,
• merge will update or add depending on the key,
• union cannot update existing key but can add differing keys.

Strictly speaking union should return differing and both on collision, but we not ready to support all that functionality yet I think.

[Affie]

What is the scope for this? Does it include addVariable/factor. It would be nice to have consistency everywhere.

[dehann]

also entails question of:
https://github.com/JuliaRobotics/IncrementalInference.jl/blob/master/src/SubGraphFunctions.jl#L223
vs
https://github.com/JuliaRobotics/IncrementalInference.jl/blob/77e21ff4f145c83a3c7609eb3efcffbbb53e8717/src/CliqStateMachineUtils.jl#L642-L658

[dehann]

Personally, we should just make it work (i.e. use what we have) for DFG v0.5.0, but then we should think about

nice to have consistency everywhere

for DFG v0.6.0?

[Affie]

ref: https://github.com/JuliaRobotics/IncrementalInference.jl/pull/395/files

[Affie]

@dehann , please explain a bit more on the different solves solveKey (i think you called it super, sub solves). It Impacts this for me.

[GearsAD]

EDIT DF, JT

Sideline: So there's a larger discussion about how to stop users from using DFG.addVariable and start using IIF.addVariable for graphs that pack etc. It's led to a bit of confusion, trying to think of a good way to encourage users to use the IIF functions, and actually hide the DFG functions. Just planting the seed that it will affect this discussion.

• DF, below
• JT,
  • addFactor!(dfg, factor) and addVariable!(dfg, variable) are hard to use.
  • So not reexporting it should be enough.
  • We should still make it easy for contributors.

Overall: These will be breaking changes as we would be changing signatures/behavior for addVariable/etc.. Let's do them for DFG 0.6.

• DF, agree 👍
• JT 👍

As a philosophy, I'd like us to represent the underlying datastructure with no magic - e.g. most of our graph represents a dictionary - so implement standard behavior like a dictionary so that it feels familiar to users. Think of it as making sure users feel at home.

• DF, agree with that 👍
• JT 👍

[dehann]

trying to think of a good way to encourage users to use the IIF functions,

• easiest is to not use reexport in IIF.
  • JT 👍
• would it work if there only abstract dispatch implementations in DFG, so when the user defines the graph type it forces specific functions.
  • Remember on the serialization design -- neither DFG or IIF will ever have access to all the packing and unpacking converters. For the sake of design assume there will always be converters in some user package, as well as Main and that is driven by a design requirement. This means we can't abstract away the problem, and hence we have things like DFG.loadDFG(file, Main, fg1).
• another option might be to not export addVariable!/addFactor! from DFG at all, and only IIF, but that feels weird.

[dehann]

please explain a bit more on the different solves solveKey (i think you called it super, sub solves). It Impacts this for me.

solveKey is another open ended concept that allows the user to request all kinds of ad-hoc changes to a particular factor graph. Things like,

• tweak this factor solve it all again,
• collapse those two variables and solve again.
• Change the measurement on this factor and solve again,
• summarize that long empty odometry chain with a single factor and use as primary response to user.
• please reconstruct at higher resolution using BigData elements and keep as secondary piggy back, and only re-solve this little fraction of the graph with secondary setup (image interpolating from IMU inertial odometry the accurate position of each camera frame location at 30Hz between two poses)
• Human requests test solve on something somewhere,
• request 3 parallel solves to validate they all get the same answer,
• compare different solver versions over time on the same factor graph,
• etc, etc, the list goes on

EDIT: xref https://www.juliarobotics.org/Caesar.jl/latest/faq/#What-is-supersolve?-1

[Affie]

Ok, Thanks, That cleared it up somewhat.
So I'd also like to treat it as a dictionary concept.