feat: algebra

[lonerapier]

It changes the following:

• FiniteGroup trait
• MultiplicativePrimeGroup struct
• CurveGroup trait
• refactor ECDSA to generic group

[Autoparallel]

I left a few comments, nothing major.

Given those comments and the general structure, may I suggest the following refactor and generalization?

Consider creating an algebra module with:

• group
• ring
• field
  As submodules. (You can leave ring as TODO).

Now, it is probably reasonable to then define the abstract notion of group and field and then use these as super traits for the more refined items such as FiniteGroup, FiniteCyclicGroup, FiniteField, etc.

[lonerapier]

@Autoparallel Thanks for the review.

• refactored as algebra module with separate submodules for group, field, ring (in future).
• Tried adding Group, Field trait separately, but we need function overriding in derived traits because operation in Group and FiniteGroup can be done in different ways.
  • Is there any other way that we can define Group trait's operation and FiniteGroup trait's operation separately?

[Autoparallel]

@lonerapier let me take a look.

One thing we could also consider is making the ring/field + op be a AbelianGroup. Food for thought.

Give me a sec to go look through this.

[Autoparallel]

This is a nitpick, so don't feel compelled to change this (i love your documentation always) but I have a disdain for the $\oplus$ as a group op. Why?

$\oplus$ is used, usually, as a direct sum or coproduct so it is a bit weird. It also carries connotation of commutivity which is usually not guaranteed in groups! (most groups are not commutative)

Instead consider just using concatenation: $ab = c$, $(ab)c=a(bc)$, etc.

[lonerapier]

I need to learn more abstract algebra :)

I think concatenation is mostly substituted as multiplication, at least in my head, so might create confusion. does using \cdot make more sense?

Found it used in Ben Lynn's notes as well: https://crypto.stanford.edu/pbc/notes/group/group.html

[lonerapier]

modified it to $\cdot$, does this work?

if not can just simplify it to concatenation

[Autoparallel]

$\cdot$ is fine. For a group, we just don't want to convey the operation is + as that implies commutativity in math people's heads. Concatenation is actually really general as you are thinking of group elements as strings of chars with rules in how to reduce the strings into other strings. Strings of minimal length given the reduction rules are considered canonical representatives (this, at least, is the way group presentations define a group). All groups can be given via a presentation, albeit that they may not be finite presentations (that is really not a problem for us lol)

[Autoparallel]

Again here $\oplus$ if you care to change :)

[Autoparallel]

Adding a touch here about how fields exist as special instances of rings (where there is division and no zero-divisors).

Adding a commented TODO is also okay.

[lonerapier]

makes sense, will change it

[lonerapier]

done

[lonerapier]

One thing we could also consider is making the ring/field + op be a AbelianGroup. Food for thought.

Regarding this suggestion, I can't find a way to add this without complicating the traits and structs more

Like it wouldn't be easy for a beginner to implement 5 traits just to have a PrimeField implementation

[Autoparallel]

Like it wouldn't be easy for a beginner to implement 5 traits just to have a PrimeField implementation

That's true... it would introduce having some wrapper types and what not. The only benefit it would give is that if you did something like:

let element: impl FiniteField = ...;
let (element as impl AbelianGroup) + ... 

but that's probably not worth it.

Another option is something like

trait FiniteField {
    type Monoid: ...
    type AbelianGroup: ...
    ...
}

but then I think we are hitting abstraction for the sake of abstraction.

You're right, let's not make the implementation needs abusive to beginners.

[Autoparallel]

Looks fantastic!

[Autoparallel]

filename here is misleading, but if you are wanting to learn more abstract algebra, every finite group is a subgroup of a permutation (symmetric) group and the dihedral group is an especially nice subgroup of it which is implied by Lagrange's theorem

Inside of the dihedral group is then two cyclic groups. One of order n, and one of order 2. Also implied by lagrange's theorem.

If you don't implement those (don't have to at all), i'd suggest changing the filename :)

[Autoparallel]

Though i guess in this case D6 is S3

[lonerapier]

Have changed to symmetric_group

[Autoparallel]

A little misleading. This returns true if a pair of elements commutes.

Sadly an (almost) impossible task for Rust to handle is that there exists a proof that your impl of this trait is actually abelian (rip)

[lonerapier]

Yeah, IDK why I put it this way. Have changed this to an assertion

[lonerapier]

That's true... it would introduce having some wrapper types and what not.

Maybe we can implement this as an example demonstration with Ring implementation. Like showing a ring with inverse and commutativity forms a field, and then comparing it with the actual Field implementation.