Skip to content
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

Closed
tarcieri opened this issue Nov 29, 2023 · 10 comments · Fixed by #485
Closed

Reopening *Residue naming bikeshed #351

tarcieri opened this issue Nov 29, 2023 · 10 comments · Fixed by #485

Comments

@tarcieri
Copy link
Member

tarcieri commented Nov 29, 2023

In #70 we discussed FieldElement and Residue 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

@fjarri
Copy link
Contributor

fjarri commented Dec 15, 2023

Three independent proposals:

  1. Drop the Dyn prefix for runtime residues and instead use the Const prefix for constant-time ones. This goes in line with the rest of the naming.
  2. Rename "Residue" to "MontgomeryForm" (or "MgForm" for short). Montgomery form is not a mere implementation detail, so it seems logical that it's reflected in the name.
  3. Rename "Params" to "Precomputed" or something of the kind.

@dignifiedquire
Copy link
Member

In favor for all three suggestions from @fjarri, especially 2 and 3 are more in line with what I have seen in other contexts.

@tarcieri
Copy link
Member Author

MontgomeryForm/MontForm/MontyForm/MgForm or the same thing with Montgomery/Mont/etc/MgRepr (i.e. representative) all seem like reasonable names to me (though elsewhere we and ff/group use Repr for "bytestring representation")

I would probably side on a shorter name, since e.g. ConstMontgomeryForm/BoxedMontgomeryForm are quite verbose.

I like the idea of dropping Dyn and adding Const.

Rename "Params" to "Precomputed" or something of the kind.

I think "params" is fine, and can use whatever "monty" prefix we decide, e.g. MontParams. BoxedMontPrecomputed would get a little verbose.

@dignifiedquire
Copy link
Member

  • slight favor of MontyForm over the other variants
  • openssl uses Ct instead of Const, so could also use that for naming if we want shorter names

@fjarri
Copy link
Contributor

fjarri commented Dec 15, 2023

"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 :)

@dignifiedquire
Copy link
Member

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.

ah yes, I actually confused it myself 😅

@tarcieri
Copy link
Member Author

I guess my vote would be:

  • BoxedMontForm/BoxedMontParams
  • ConstMontForm/ConstMontParams
  • MontForm/MontParams

@tarcieri
Copy link
Member Author

The other things we have to name are the trait for abstracting over the various Montgomery form types the way Integer abstracts over the integer types (#448), and a trait for associating a Montgomery form type with a particular integer type. See also #431.

Lacking a better name, I guess Mont/Monty would work for the former. We could probably just add an associated type to Integer for the latter.

@fjarri
Copy link
Contributor

fjarri commented Dec 19, 2023

I suppose I'll make a PR then

@tarcieri
Copy link
Member Author

Yeah, as I keep expanding the *Residue tests/benchmarks I keep thinking "more stuff to rename"

@fjarri fjarri mentioned this issue Dec 20, 2023
tarcieri pushed a commit that referenced this issue Dec 20, 2023
Fixes #351

- `Residue` -> `ConstMontyForm`
- `DynResidue` -> `MontyForm`
- `BoxedResidue` -> `BoxedMontyForm`
- `*ResidueParams` -> `*MontyParams`
- `residue_params` -> `params`
- `params.r` -> `params.one`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants