You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a significant amount of code re-use in data_structures.rs, which makes maintaining the code unreasonably difficult to work with; in particular, Com1 and Com2 are implemented incredibly similarly.
Figure out if it's possible for a macro to include a "match" statement on the identifier passed as input such that, if it equals a certain value (e.g. Com1), one can define a new identifier macro variable based on it (e.g. G1Affine)
Coalesce Com1 / Com2 implementations to a greater extent (and also ComT, if it shares any similarities that can be macro'ed out)
Similarly, coalesce Mat implementations for Com1, Com2, and/or field matrices, if possible (may require implementing Com1 and Com2 as a Field, or specifying the current Field generics at a finer-grained level)
Optionally, consider defining a mat![ a, b, c; ... ; ...] macro (or similar) which expands out to vec![vec![a, b, c], vec![...]. vec![...]
This should be transparent to the API and test cases.
The text was updated successfully, but these errors were encountered:
There is a significant amount of code re-use in data_structures.rs, which makes maintaining the code unreasonably difficult to work with; in particular,
Com1
andCom2
are implemented incredibly similarly.match
" statement on the identifier passed as input such that, if it equals a certain value (e.g.Com1
), one can define a new identifier macro variable based on it (e.g.G1Affine
)Com1
/Com2
implementations to a greater extent (and alsoComT
, if it shares any similarities that can be macro'ed out)Mat
implementations forCom1
,Com2
, and/or field matrices, if possible (may require implementingCom1
andCom2
as aField
, or specifying the currentField
generics at a finer-grained level)mat![ a, b, c; ... ; ...]
macro (or similar) which expands out tovec![vec![a, b, c], vec![...]. vec![...]
This should be transparent to the API and test cases.
The text was updated successfully, but these errors were encountered: