3 ms·
> you might be doing addition over GF2 Then the function name, class, and/or comments should be making that clear! In this case, the BatchGF2 class does so. Ma
by zild3d 5y ago
> you might be doing addition over GF2
Then the function name, class, and/or comments should be making that clear! In this case, the BatchGF2 class does so. Maybe somewhere else a Fourier class has `fn add() { a * b } // a and b are in time domain`
but a standalone add() function with no comments or class should probably not be doing a ^ b, a - b, or a * b.
some github copilot like linter can then draw from other GF2, Fourier, etc code references vs vanilla add functions
- catlifeonmars 5y agoThat’s abstraction breaking. The code calling add should generally not need to be aware of the implementation details of add. The users of the add API should generally not need to be aware of the implementation details of add.
- couchand 5y agoIn the case of a Galois field I think you're always intentionally reaching for the tool, you use it because of those implementation details. Making sure the struct's name clarifies that that's how the arithmetic works is appropriate. In that case you definitely want to implement the standard Add trait, so the user can naturally write their maths. They've already opted in to the behavior with a call to Gf2::from.