-
Notifications
You must be signed in to change notification settings - Fork 33
Description
Hello,
First of all, I wanted to thank you again for your previous guidance regarding multivariate power series at (#131). Thanks to python-flint
, our migration of CryptographicEstimators
from Sage to a pure Python library was successful, and we truly appreciate the work you've put into this project.
During the migration I collected a few questions regarding the use of power series and the future roadmap for python-flint
, so I would like to ask for your orientation:
Currently, the ctx
global variable seems to control the maximum number of computable coefficients for a power series, rather than the precision declared during series construction. This behavior raises a few questions for me:
- Is there a low-level implementation reason for this? I've found it a bit tricky that if
ctx.cap
is set to 10 and a series is created with precision 15, the series effectively has precision 10. However, ifctx.cap
is 10 and the series precision is 5, the series retains precision 5. - Beyond my curiosity, we've decided to set a large
ctx.cap
(20000) in our library's root__init__
to prevent new developers from needing to worry about this. Is this considered a bad practice? Should we anticipate any impact on overall library performance, such as overhead or slower utilization?
Additionally, I recall having to create a prec
attribute in our classes that use power series because the only way I found to retrieve the precision directly from the series was by parsing its repr
. Could you please clarify if there's another way to extract the precision for future use?
Finally, during our migration we needed to handle matrices of polynomials to calculate their determinants. I noticed that C-flint supports these types, but I didn't find them in the python-flint
documentation the last time I checked. Is it in the feasible future roadmap to include these types in python-flint
? We are currently using SymPy polynomials for these determinant calculations, but the final implementation is approximately 8x slower than the Sage version.
Thanks for your time and assistance.