30
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill lyndonkl/claude --skill symmetry-group-identifier- SKILL.md9.2 KB
Overview
This skill maps identified symmetry transformations into precise mathematical groups to guide equivariant or invariant architecture design. It turns domain-level symmetry observations (rotations, reflections, permutations, translations) into formal group names, notations, and properties that directly inform model choice. Use it to produce a compact, implementable group specification for neural architecture design.
How this skill works
You provide candidate symmetries or I help elicit them from the domain. The skill classifies each symmetry as discrete or continuous, matches it to standard groups (C_n, D_n, S_n, SO(n), SE(n), E(n), etc.), determines combination structure (direct vs semidirect product), and verifies key group properties relevant for representation and implementation. The final output is a concise group specification with recommended architecture family and verification checklist.
When to use it
- You’ve discovered transformations that should leave outputs invariant or equivariant and need formal group names
- Designing equivariant neural networks for images, point clouds, molecules, or robots
- You need to decide whether symmetries combine independently or via twisting (direct vs semidirect product)
- Translating domain symmetries into constraints that affect layer design or representation choices
- Validating whether candidate symmetry hypotheses satisfy group axioms before engineering models
Best practices
- Start by listing concrete transformations and whether you require invariance or equivariance
- Classify each symmetry as discrete (finite) or continuous (Lie group) early — it drives implementation choices
- Prefer the simplest group that captures observed invariances to avoid over-constraining models
- When multiple symmetries exist, explicitly test if they commute to choose direct vs semidirect product
- Document group properties (compact, connected, abelian, finite) since they determine representation methods
- Empirically validate symmetry assumptions with controlled augmentations or ablation tests
Example use cases
- Image classifier with rotation-only symmetry → map to cyclic group C_n (or SO(2) if continuous)
- Square object recognition with flips → identify dihedral group D_4 and use equivariant convolutions
- 3D point-cloud pose-invariant model → select SO(3) × S_n (rotations × permutations)
- Molecular energy prediction where reflections are allowed → choose E(3) × S_n
- Robotics pose estimation with rigid motions → formalize as SE(3) and design SE(3)-equivariant layers
FAQ
Use SE(3) when handedness matters (no reflections). Use E(3) when reflections are symmetry-allowable; E(3) = O(3) ⋊ ℝ³ includes reflections.
When should I model a symmetry as discrete C_n instead of continuous SO(2)?
Choose C_n if rotations are limited to specific angles (e.g., 90°). Use SO(2) for invariance to arbitrary rotation angles.