Delma

How does this separation work with *Approx variants? Would we have something like: ``` rust pub trait MagmaAdditive : Add {} pub trait MagmaAdditiveLawApprox : MagmaAdditive + PartialEq {} pub...

Hmm.. Yeah that makes sense. I am not actually sure how much this library will be developed as https://github.com/sebcrozet/alga has been developed more. As you might have noticed development of...

Currently `ApproxEq` is implemented only for some of primitives in `approx`: https://github.com/brendanzab/approx/issues/6

Well one problem that approximate stuff is that there is different kinds of innaccuracies: - precision (floats) - under/overflow (in debug without Wrapping) - algebraic structure breaking values (Nan, Inf)...

This would close the door of using specialization to implement `Magma` for stuff that doesn't implement `Add`

One way to make usage easier would be to create macro that would automatically wrap stuff or associate ZSTs with symbols. Not sure how hard that would be though.

Here is POC of the operation association macro I was talking about: https://play.rust-lang.org/?gist=52e6f854ac55364809721f73452a6a30&version=nightly&backtrace=0

I made the numbers to go through `#[inline(never)]` function and looked ASM and didn't see any branching there. The macro should always generate if-else chain that has staticly only one...

I was able to improve the macro: https://play.rust-lang.org/?gist=3ba719a8390b05cf6d0e331ed86134a4&version=stable&backtrace=0 It now supports multiple tokens long operators and equality checking. I cannot unfortunately remove the unnessary paretheses because of `macro_rules` limitations (space...

Other choice is to have same kind of thing as the Approx\* variants, but that creates lots of bloat. However it has the benefit of being more flexible: If the...