Implement strategies for ReadGate/SolutionReadout

[AlessandroPierro]

Objective of issue: propose implementation of different reading strategies for ReadGate/SolutionReadout

lava-optimization version:

• [x] 0.2.2 (current version)

I'm submitting a ...

• [x] feature request

Current behavior:

• ReadGate/SolutionReadout of OptimizationSolver store and communicate only the best found solution, along with the associated cost and time step, for performance reasons.

Expected behavior:

• For profiling and research purposes, it would be useful to have the possibility to specify an alternative reading strategy, e.g. communicating the new solution each time the cost improves.

[GaboFGuerra]

We had the expected behavior in a previous release and it was removed in the last one in favor of the current behavior. We should bring back the previous version which I would have left as default and offered the most performant version as optional. The reason being that the cost in performance is relatively low and the user experience is much better if the user can track the evolution of the search.

Also, are we sure we are providing the best solution if target cost was not found? In a debug session one user was getting an all -1 vector when target_cost was not found. Maybe we need a test for this.

But @AlessandroPierro, how are you envisioning the strategy implementation? We can probably not support a fully generic strategy easily, because it requires changing the CostIntegrator (microcode) and ReadGate (C) processes. Thus, we would only allow the user to switch between streaming every better cost or only the best. Right?

[AlessandroPierro]

We had the expected behavior in a previous release and it was removed in the last one in favor of the current behavior. We should bring back the previous version which I would have left as default and offered the most performant version as optional. The reason being that the cost in performance is relatively low and the user experience is much better if the user can track the evolution of the search.

I agree for CPU backend, but on Loihi we observed 100x speedup. We can redesign this now using StateProbes. I would leave the most performant version for the ReadGate/SolutionReadout and delegate the finer tracking to a probe_cost flag as we discussed. What do you think? @GaboFGuerra