Add a filter_limit option on NumPy(Minimum)Eigensolver

[mrossinek]

What should we add?

The Problem

When prototyping or debugging non-quantum parts of the stack I often find myself getting back to the NumPy(Minimum)Eigensolver classes. However, in less trivial chemistry applications, the naive lowest eigenvalue is oftentimes not a physical one, so I need to rely on adding a filter_criterion to find a physically meaningful eigenvalue.

Unfortunately, the code currently hard-codes k when a filter_criterion is supplied:
https://github.com/Qiskit/qiskit-terra/blob/332bd9fe0bea82c0fdf7329cea3da115d86e3fc2/qiskit/algorithms/eigensolvers/numpy_eigensolver.py#L257-L259

This means that ALL eigenvalues will be computed, which can take a VERY long time.
The reason for doing this is well motivated though, because one cannot know a priori what value to pick for k.

My proposed solution

I would like to propose that we support setting k and filter_criterion simultaneously.
Since as an end-user I have written the filter_criterion myself, I do have more knowledge about the problem that I am trying to solve. Thus, I may also be able to make an educated guess for k.
And even if that fails, I may be willing to try setting k to 100, then 200, then 300 and so on , rather than having to wait for say 2**10=1024 eigenvalues to be computed regardless of whether my value of interest might have been in the first 10% or so.

I think the prototyping and debugging speed that could be gained here is quite significant.

So in summary:

• the defaults should remain as they are right now
• but it should be possible for an end-user to manually set k while also setting a filter_criterion

---

I would work on this myself, but in the recent months where I thought of doing this I have not found the time to come up with a clean code solution. Thus, I am opening this issue to see if someone else might find this interesting and has the time to do this.
I will gladly review a PR once time has come. Otherwise I might get back to this once I have a bit more time on my hands in the (potentially far) future.

[woodsp-ibm]

k was supposed to mean the number you were interested in being given back. I wonder if it would be better to have a new parameter say filter_limit (or whatever it was called) that defaults to None and internally controls how many eigenvalues it will get to filter, defaulting to all (as it is at present). Then if you have a better idea that your k desired values are within some range (limit) of eigenvalues you could set this. It already states you may get less than the k you ask for due to filtering - this limit would just bound the set of eigenvalues it was looking at to start with.

[mrossinek]

Interesting.. 🤔 I guess k is then being misused in the context when a filter is applied because you do not get back that number of eigenvalues... But you're suggestion for splitting the responsibility here sounds like a good approach! 👍

[woodsp-ibm]

When a filter is applied it states you might get back less than k - if there are at least k eigenvalues in the entire set that match the filter you should get k or them. At least that was the intent - it saves k internally as k_orig before it gets all of them and then returns what matches limited by k_orig - maybe there is some issue there.

[mrossinek]

It could be that this works as intended. My main grind is with the slowness associated with computing all eigenvalues whenever the filter_criterion is set. I like your proposal of the filter_limit 👍

[ElePT]

Transferred to new repo: qiskit-community/qiskit-algorithms#61