⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.32%. Comparing base (2389d44) to head (c37dbba).

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

@@           Coverage Diff           @@
##             main      #96   +/-   ##
=======================================
  Coverage   98.32%   98.32%           
=======================================
  Files           6        6           
  Lines        1250     1250           
=======================================
  Hits         1229     1229           
  Misses         21       21           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I have some issues regarding PDSProblem. See https://github.com/SKopecz/PositiveIntegrators.jl/blob/2389d44d8037e2d3a2c1ba0d3be67a179dfd3569/src/proddest.jl#L7C24-L7C45.

1. I don't see why we need d_prototype in PDSProblems. D will always be a vector with the same floating point type as P. Or are there other reasonable choices?
2. The docu says "If P is given in in-place form, p_prototype is used to store evaluations of P". This is true for PDSFunctions, but these are only used internally and not documented. Users might think that p_prototype is used to store evaluations of P inside an algorithm like MPE() while solving a PDS. But this is not the case. All algorithms allocate new memory using something like P=zero(f.p_prototype).
3. Would it be a good idea to actually use f.p_prototype to store evaluations of P inside the algorithms?

1. I don't see why we need d_prototype in PDSProblems. D will always be a vector with the same floating point type as P. Or are there other reasonable choices?

Maybe someone wants to use a SparseVector (from SparseArrays) or some custom struct encoding sparsity? Or we may want to have the flexibility to run on GPUs in the future?

2. The docu says "If P is given in in-place form, p_prototype is used to store evaluations of P". This is true for PDSFunctions, but these are only used internally and not documented. Users might think that p_prototype is used to store evaluations of P inside an algorithm like MPE() while solving a PDS. But this is not the case. All algorithms allocate new memory using something like P=zero(f.p_prototype).

Maybe we should write "p_prototype or copies thereof are used to store evaluations of P" to clarify this aspect?

3. Would it be a good idea to actually use f.p_prototype to store evaluations of P inside the algorithms?

I don't think so. Right now, it is possible to solve the same problem concurrently using different time integration methods. If we overwrite some memory of the problem, this is not possible anymore.

I created #97 for the implementation of d_prototype in PDSProblems.

I created #98 to improve the efficiency of sparse matrices.