[RFC] Allowing storage of an value in VariableAssignments with specific Key

[ProfFan]

Historically in GTSAM (and in old SwFusion) we have a system where we use a single number to represent a variable. This has its disadvantages, but it makes association of data from different stages of optimization easy.

We should be able to do similar thing in the new implementation, or should we?

[marcrasi]

Yes this sounds important and doable.

For performance, it is important to keep the consecutive TypedIDs under the hood but there can be a Dictionary somewhere that maps custom Keys to TypedIDs. The APIs could be arranged so that the TypedIDs are usually hidden and users only need to deal with them if they want fastest random access. Like:

var x = VariableAssignments<String>() // "String" is the key type

// under the hood, generates a TypedID<Int>(0) for `1` and also adds the mapping "a" -> TypedID<Int>(0) to the dict
x.store("a", 1)

x["a", type: Int.self]

// under the hood, generates a TypedID<Pose2>(0) for `Pose2(0, 0, 0)` and also adds the mapping "b" -> TypedID<Pose2>(0) to the dict
x.store("b", Pose2(0, 0, 0))

var graph = FactorGraph()

// under the hood, looks up that "b" means `TypedID<Pose2>(0)`, and stores the `TypedID` inside the `PriorFactor` instead of the string
graph.add(PriorFactor("b", Pose2(1, 0, 0))

There are a few ways this can be implemented. It could be built into VariableAssignments. It could be a wrapper type over VariableAssignments, so that methods that don't care about the custom keys can pass the VariableAssignments around without the dictionary overhead.

We could discuss this a bit during the meeting tomorrow. Dave may have useful opinions!

[dellaert]

Newbie question: If it’s important to keep consecutive, then why is Int part of the type? FWIW I love the typed ids. I always wanted to do this in GTSAM, and in fact we have a symbol class that approximates it. Fan, is it not easy to just create a local function x:Int-> TypedId<Pose,Int> to create pose keys, etc? One use case that I do think is important is time stamps : some users use system time stamps to index poses, and sometimes these can come in *out of order*, because of different latencies associated with different sensors.  GitHub <[email protected]> wrote: “Yes this sounds important and doable. For performance, it is important to keep the consecutive TypedIDs under the hood but there can be a Dictionary somewhere that maps custom Keys to TypedIDs. The APIs could be arranged so that the TypedIDs are usually hidden and users only need to deal with them if they want fastest random access. Like: var x = VariableAssignments<String>() // "String" is the key type x.store("a", 1) // under the hood, generates a TypedID<Int>(0) for `1` and also adds the mapping "a" -> TypedID<Int>(0) to the dict x.store("b", Pose2(0, 0, 0)) // under the hood generates a TypedID<Pose2>(0) for `Pose2(0, 0, 0)` and also adds the mapping "b" -> TypedID<Pose2>(0) to the dictThere are a few ways this can be implemented. It could be built into VariableAssignments. It could be a wrapper type over VariableAssignments, so that methods that don't care about the custom keys can pass the VariableAssignments around without the dictionary overhead. We could discuss this a bit during the meeting tomorrow. Dave may have useful opinions!” — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[ProfFan]

Fan, is it not easy to just create a local function x:Int-> TypedId<Pose,Int> to create pose keys, etc?

Yes, but then we will need to have boilerplate :)

[marcrasi]

Newbie question: If it’s important to keep consecutive, then why is Int part of the type?

No good reason. I want to remove it soon.