You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/copilot-instructions.md
+8Lines changed: 8 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,8 +4,16 @@ For reviewing PRs:
4
4
* Use meaningful variable names, e.g. `measurement` not `msm`, avoid abbreviations.
5
5
* Flag overly complex or long/functions: break up in smaller functions
6
6
* On Windows it is necessary to explicitly export all functions from the library which should be externally accessible. To do this, include the macro `GTSAM_EXPORT` in your class or function definition.
7
+
* When adding or modifying public classes/methods, always review and follow `Using-GTSAM-EXPORT.md` before finalizing changes, including template specialization/export rules.
7
8
* If we add a C++ function to a `.i` file to expose it to the wrapper, we must ensure that the parameter names match exactly between the declaration in the header file and the declaration in the `.i`. Similarly, if we change any parameter names in a wrapped function in a header file, or change any parameter names in a `.i` file, we must change the corresponding function in the other file to reflect those changes.
8
9
* Classes are Uppercase, methods and functions lowerMixedCase.
9
10
* Public fields in structs keep plain names (no trailing underscore).
10
11
* Apart from those naming conventions, we adopt Google C++ style.
12
+
* Notebooks in `*/doc/*.ipynb` and `*/examples/*.ipynb` should follow the standard preamble:
13
+
1) title/introduction markdown cell,
14
+
2) copyright markdown cell tagged `remove-cell`,
15
+
3) Colab badge markdown cell,
16
+
4) Colab install code cell tagged `remove-cell`,
17
+
5) imports/setup code cell.
18
+
Use the same `remove-cell` tagging convention as existing notebooks so docs build and Colab behavior stay consistent.
11
19
* After any code change, always run relevant tests via `make -j6 testXXX.run` in the build folder $WORKSPACE/build. If in VS code, ask for escalated permissions if needed.
Copy file name to clipboardExpand all lines: gtsam/base/doc/MatrixLieGroup.md
+4-1Lines changed: 4 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,9 +29,12 @@ You must implement everything from the `LieGroup.md` guide, plus the following:
29
29
30
30
By inheriting from `gtsam::MatrixLieGroup`, you get:
31
31
32
-
***A default `AdjointMap()` implementation**: This generic version works by repeatedly calling your `Hat` and `Vee` methods. While it is correct, it is often slow. For performance-critical applications, you should still provide a faster, closed-form `AdjointMap()` implementation in your class, which will override the default.
32
+
***Default group adjoint methods**: `AdjointMap()`, `Adjoint(xi)`, and `AdjointTranspose(x)` are provided generically, including Jacobians for the latter two.
33
+
***Default Lie algebra methods**: `adjointMap(xi)`, `adjoint(xi, y)`, and `adjointTranspose(xi, y)` are provided generically, including Jacobians for the latter two.
33
34
***A `vec()` method**: This vectorizes the `N x N` matrix representation of your group element into an `(N*N) x 1` vector.
34
35
36
+
**Performance Note:** The generic implementation of `AdjointMap()` is correct but may be slower because it is derived via the `Hat`/`Vee` mappings. If a closed-form expression for `AdjointMap()` is available for your group, consider overriding the default implementation for better performance.
37
+
35
38
### 4. Traits and Concept Checking
36
39
37
40
Finally, the traits specialization in your header file must be updated to reflect that your class is now a `MatrixLieGroup`.
0 commit comments