The methods field::one(), field::zero(), field::neg_one() are very old holders from when our field class was written in more of a C-style.
The original goal was to compute (at compile time) the Montgomery representation of 0, 1, -1 and access them via the above methods. This was, in the past, faster than constructing out of an integer.
The field class can implicitly construct from an int type. This constructor is also constexpr which means that the Montgomery reduction should be performed at compile-time when the input parameter is a literal.
(e.g. field foo = 1; should compile to the same code as field foo = field::one())
summary: these 3 methods serve no purpose vs constructing from int literals and add complexity + clutter. We should remove.
The methods
field::one(), field::zero(), field::neg_one()are very old holders from when our field class was written in more of a C-style.The original goal was to compute (at compile time) the Montgomery representation of
0,1,-1and access them via the above methods. This was, in the past, faster than constructing out of an integer.The
fieldclass can implicitly construct from aninttype. This constructor is alsoconstexprwhich means that the Montgomery reduction should be performed at compile-time when the input parameter is a literal.(e.g.
field foo = 1;should compile to the same code asfield foo = field::one())summary: these 3 methods serve no purpose vs constructing from int literals and add complexity + clutter. We should remove.