Potential missing identity_element in v0.6.0, SpecialEuclidean(2)?

[dehann]

I'm having a little unexpected difficulty around using identity as we had been doing before. Trying to debug something else, but now wondering if this is the correct way for SpecialEuclidean(2) --- i.e. should this work or is the error valid?

M = SpecialEuclidean(2)
G = Identity(M)

Manifolds.identity_element(G)

ERROR: MethodError: no method matching identity_element(::Identity{Manifolds.SemidirectProductOperation{RotationAction{TranslationGroup{Tuple{2}, ℝ}, SpecialOrthogonal{2}, LeftAction}}})
Closest candidates are:
  identity_element(::ProductGroup{𝔽, T} where {𝔽, T}) at /home/dehann/.julia/packages/Manifolds/EY0G1/src/groups/product_group.jl:37
  identity_element(::CircleGroup) at /home/dehann/.julia/packages/Manifolds/EY0G1/src/groups/circle_group.jl:27
  identity_element(::CircleGroup, ::Number) at /home/dehann/.julia/packages/Manifolds/EY0G1/src/groups/circle_group.jl:28
  ..

Originally posted by @dehann in #401 (comment)

[mateuszbaran]

I think the recommended thing to do is to call identity_element(M) instead of identity_element(G). Would that work for you?

julia> M = SpecialEuclidean(2)
SpecialEuclidean(2)

julia> identity_element(M)
ProductRepr with 2 submanifold components:
 Component 1 =
  2-element Vector{Float64}:
   0.0
   0.0
 Component 2 =
  2×2 Matrix{Float64}:
   1.0  0.0
   0.0  1.0

[dehann]

Yes, that will work thanks!

[mateuszbaran]

Great! Let me know if you'd prefer identity_element to return something different for the SpecialEuclidean group (for example the affine matrix or a ProductRepr of SArrays).

[dehann]

thanks, I prefer ProductRepr, and perhaps in future pass the datatype similar to Base, e.g. zeros(Int,3). We're currently using Array{Float64}, and likely to move to MArray or SArray as able. Also a good chance we will use things like Float16 in the future too.

[mateuszbaran]

OK, Manifolds.jl will probably migrate from ProductRepr to ArrayPartition in the future (see #402 ). It's very similar to ProductRepr and I think it makes sense to use a more "standard" solution that also has better interoperability with the DiffEq ecosystem.

Moving to MArray and SArray can give a big performance boost so I definitely recommend it if you need to get things faster. Manifolds.jl should handle them, as well as Float16 or for example GPU arrays, quite well (I made a small test some time ago).

[dehann]

Thanks, all sounds good, and thanks for the heads up on ArrayPartition since we are starting to hard-code a few ProductRepr definitions into the (IncrementalInference / RoME.jl) codebases.

[dehann]

Note, not sure yet if something changed or a bug somewhere but looks like there is a behaviour change when calling from inside a function (doesn't return a ProductRepr like yesterday but rather just a vector):

SE2 = SpecialEuclidean(2)
Manifolds.identity_element(SE2)

[0.0, 0.0, 1.0, 0.0, 0.0, 1.0]

Yet, when I call it from REPL I get a ProductArray (again not ProductRepr):

SE2 = SpecialEuclidean(2)
Manifolds.identity_element(SE2)

ProductArray with 2 submanifold components:
 Component 1 =
  2-element StaticArrays.SizedVector{2, Float64, SubArray{Float64, 1, Vector{Float64}, Tuple{UnitRange{Int64}}, true}} with indices SOneTo(2):
   0.0
   0.0
 Component 2 =
  2×2 StaticArrays.SizedMatrix{2, 2, Float64, 1, SubArray{Float64, 1, Vector{Float64}, Tuple{UnitRange{Int64}}, true}} with indices SOneTo(2)×SOneTo(2):
   1.0  0.0
   0.0  1.0

Did ProductArray get resurrected somehow perhaps?

---

EDIT:

(@v1.6) pkg> st Manifolds
      Status `~/.julia/environments/v1.6/Project.toml`
  [1cead3c2] Manifolds v0.6.0

[mateuszbaran]

Sorry, that's one last place where ProductArray was the default. I'll fix this. By the way, [0.0, 0.0, 1.0, 0.0, 0.0, 1.0] is how ProductArray is printed when it's not at the top level (a bit misleading but it's deprecated anyway).

[dehann]

No problem, thanks for fixing!