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

Better interface for re-using routines #30

Open
mstechly opened this issue May 3, 2024 · 0 comments
Open

Better interface for re-using routines #30

mstechly opened this issue May 3, 2024 · 0 comments

Comments

@mstechly
Copy link
Contributor

mstechly commented May 3, 2024

Currently, the supposed workflow for using Routines is as follows:

  1. Define a routine – both in terms of structure and resources.
  2. Compile this routine.
  3. Validate compiled routine. (Not necessary, but probably a good thing to do.)

At this point, we can say we have "validated" a given estimate. Let's say we did it for a QROM.

Since we might not wish to specify routine's substructure in future, higher-level routines (such as using a QROM as a black-box subroutine in Double Factorization), we would now want a new workflow for using product of the above one, i.e.:

  1. Define routine for a higher-level algorithm
  2. Import pre-defined, compiled and validated routines for any black-boxed subroutines.
  3. Compile as before.
  4. Validate as before.

Hence, we would therefore like a way to straightforwardly "access" a subroutine's precompiled, prevalidated resources and ports.

There are two things that should be done to enable this:

  1. Pre-validated estimators should be accessed via a different mechanism than uncompiled ones. However, the user shouldn't have to care about whether the estimator they're using is really atomic, prevalidated, or anything else.
  2. Compilation and validation of the routines that has been already compiled and validated

Originally by @sammorley-short

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

No branches or pull requests

1 participant