Plonk: do not store the Lagrange basis L_basis explicitly and keep domain once

[dtebbs]

(bullet 2) Do not store the Lagrange basis L_basis explicitly (e.g. as part of the srs class and circuit_t struct). Instead compute it on-the-fly as needed. For the purpose store the domain instead (obtained through libfqfft::get_evaluation_domain<Field>()) in the srs and circuit_t and pass this as input to functions that use the L_basis parameter.

(bullet 3) (related to 2): create the domain once (using libfqfft::get_evaluation_domain<Field>()) and carry it around as necessary. See #49 (comment)

[vesselinux]

libfqfft returns domain as a shared pointer std::shared_ptr<libfqfft::evaluation_domain<FieldT>> via libfqfft::get_evaluation_domain<Field>() and I experience issues when trying to pass this as an argument to a function.

Just wondering do we actually need to have the domain pre-stored and pass it as input in order to compute the Lagrange basis? Can't we just get the domain on-the-fly as we need it from the number of gates stored in the srs e.g. execute the following

std::shared_ptr<libfqfft::evaluation_domain<FieldT>> domain = libfqfft::get_evaluation_domain<FieldT>(srs.num_gates);

and then proceed to computing the Lagrange basis via domain->iFFT?

That is the solution I am implementing at the moment, but happy to discuss.

[dtebbs]

libfqfft returns domain as a shared pointer std::shared_ptr<libfqfft::evaluation_domain<FieldT>> via libfqfft::get_evaluation_domain<Field>() and I experience issues when trying to pass this as an argument to a function.

Just wondering do we actually need to have the domain pre-stored and pass it as input in order to compute the Lagrange basis? Can't we just get the domain on-the-fly as we need it from the number of gates stored in the srs e.g. execute the following

std::shared_ptr<libfqfft::evaluation_domain<FieldT>> domain = libfqfft::get_evaluation_domain<FieldT>(srs.num_gates);

and then proceed to computing the Lagrange basis via domain->iFFT?

The rationale for getting not generating it again and again is that IIRC get_evaluation_domain simply tries a sequence of domain implementations one-by-one, so it is not very efficient.

If we know in advance that num_gates is 2^n, we can potentially manually select the correct domain to use (although we'd want to check whether it's doing some expensive setup).

But, even if it's perfectly efficient and we decide to always create on demand, we should solve the issue with the shared_ptr. Shared pointers should be passed by value, since internally they contain the logic to track the number of live instances, and then delete the object pointed to when there are no longer any references.

Can you let me know the issues you are facing?

[vesselinux]

The rationale for getting not generating it again and again is that IIRC get_evaluation_domain simply tries a sequence of domain implementations one-by-one, so it is not very efficient.

That is the case indeed.

Shared pointers should be passed by value, since internally they contain the logic to track the number of live instances, and then delete the object pointed to when there are no longer any references.

That was the issue -- I was passing it by reference. This is fixed now and committed in branch plonk-lagrange-basis-on-demand-issue-55 . The domain parameter is now part of the srs .

[vesselinux]

For this open Issue, in our last meeting I have recorded that I need to fix the conflicts in the branch plonk-lagrange-basis-on-demand-issue-55 . AFAICT from #62 the branch has been successfully merged though. Have the conflicts been resolved then or am I looking at the wrong place?