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

A lower-level interface to Flint #54

Open
oscarbenjamin opened this issue Aug 13, 2023 · 5 comments
Open

A lower-level interface to Flint #54

oscarbenjamin opened this issue Aug 13, 2023 · 5 comments

Comments

@oscarbenjamin
Copy link
Collaborator

Currently the python-flint interface to Flint is sort of somewhere between a high-level interface and a lower-level interface. In #53 I mention some ideas related to fleshing out what a more complete higher-level interface might look like. It will take a long time though to design high-level interfaces to all parts of Flint though and those interfaces will always lag behind the features that exist in Flint itself.

Another idea would be to try to add a lower-level interface within python-flint that just directly wraps each individual C type and public C function. There could be Cython types for e.g. ulong, slong, fmpz_t etc and then Cython functions like fmpz_add that take these types. The code to use this sort of low-level interface would look exactly like the corresponding C code using Flint's C API with the possible exception that Python's reference counting could be used instead of needing explicit *_free calls.

The advantages of having a low-level interface like this are that:

  • The Cython code could be generated in a semi-automatic way e.g. by scraping the function names from the Flint headers so that it always keeps up with the latest new functions in Flint.
  • While the low-level interface might not be very convenient it would always be possible to call any Flint function from Python.
  • It might be easier for python-flint contributors to prototype some new additions to python-flint in Python before subsequently transferring them to Cython.
@fredrik-johansson
Copy link
Collaborator

The Cython code could be generated in a semi-automatic way e.g. by scraping the function names from the Flint headers so that it always keeps up with the latest new functions in Flint.

Some others (eg Arblib.jl) have done this by scraping the documentation rather than the header files.

@Mollywall
Copy link

Mollywall commented Sep 8, 2023

Thanks for the info. Tell Tims Survey

@edgarcosta
Copy link
Member

If we build a dictionary name -> cfunction something like

def call(fname, *args):
    return name_to_cfunction[fname](*args)

might work

@oscarbenjamin
Copy link
Collaborator Author

I was imagining a script that would parse all of the docs and generate thousands of functions that are just wrappers around a call to each individual documented Flint function.

@oscarbenjamin
Copy link
Collaborator Author

oscarbenjamin commented Sep 3, 2024

A first step for this is just to have all of the .pxd files generated fully automatically, proving that we are able to automatically parse all of the functions from the docs.

In gh-215 I have set this up for all of the fmpz_* types but so far that's only 6 modules out of about 70.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants