-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reopening *Residue
naming bikeshed
#351
Comments
Three independent proposals:
|
In favor for all three suggestions from @fjarri, especially 2 and 3 are more in line with what I have seen in other contexts. |
I would probably side on a shorter name, since e.g. I like the idea of dropping
I think "params" is fine, and can use whatever "monty" prefix we decide, e.g. |
|
"Ct" is a little confusing because it can also mean "constant time". Also in the other parts of the library we're using "const" prefixes for compile-time stuff, so if we use "ct" here, those should all be changed too. Edit: I suspect that OpenSSL uses "Ct" in the constant-time sense, since there's no such thing as const context in C, besides macros. "Precomputed" can be shortened to "Precomp", but I am not sure how it sounds for English speakers :) |
ah yes, I actually confused it myself 😅 |
I guess my vote would be:
|
The other things we have to name are the trait for abstracting over the various Montgomery form types the way Lacking a better name, I guess |
I suppose I'll make a PR then |
Yeah, as I keep expanding the |
Fixes #351 - `Residue` -> `ConstMontyForm` - `DynResidue` -> `MontyForm` - `BoxedResidue` -> `BoxedMontyForm` - `*ResidueParams` -> `*MontyParams` - `residue_params` -> `params` - `params.r` -> `params.one`
In #70 we discussed
FieldElement
andResidue
as names for these types.However @fjarri has pointed out, and I agree, that what these types really represent is Montgomery form. It's not just an implementation detail: we have
*_montgomery
methods which provide conversions and direct access to the Montgomery form.I think it would probably make sense to rename them to something with
*Mont*
in the name, although I could go a few different directions on specific names.cc @haslersn
The text was updated successfully, but these errors were encountered: