Closed alxiong closed 7 months ago
Hi, we're more or less trying to mirror FPLLL in our API since the idea is to make that, including its low-level routines, accessible for easy experimentation. This also means it is easy to shoot yourself in the foot with the library, by design. So, while I get the dissatisfaction with the API from an application perspective, I'm not too keen to change it drastically.
But perhaps an additional high-level API could be defined and added as a submodule?
I see, that's fair. Thanks for the clarification.
I'm a little surprised by the API design for many methods/functions under
class LLL
, particularly on decision between in-place mutation and immutable-functional-style,fpylll
seems to choose neither.Specifically,
reduced_A = LLL.reduction(A)
currently also mutate the originalA
which is counterintuitive. I think we should choose one of the two:LLL.reduction_in_place(A)
that doesn't return anything +LLL.reduction(A)
that doesn't mutate A and returns the reduced matrix. (this pattern can also be found in other library, such as thefft()
andfft_in_place()
)I find the first option more ergonomic.