Closed Siel closed 1 year ago
I think forcing the state to be 'mut' by default may cause problems for systems where the state doesn't have to be mut. I think, we could create a new trait "SystemMut" where the function
fn system(&self, x: f64, y: &V, dy: &mut V);
could be
fn system(&self, x:f64, y: &mut V, dy: &mut V);
In this way, the two approaches could be separated without causing confusion.
That is an option, the problem is that there are a lot of different options regarding mut/non-mut, for example issue #15 is asking for a mut reference to self (and there are some scenarios in which that's ok).
In my opinion, there are some alternatives. One is allowing everything to be mut and hoping the users behave Another one is to find a way to define a trait that allows its parameters to be defined as mut/non-mut (don't know if that is possible). And the last one is to define a trait for every different combination.
In some scenarios (Like Pharmacometrics) bolus doses are represented as impulses into the 'compartment' of interest. To make it work it is necessary to modify the state based on the time of the dose.
i.e:
represents a dose of 500mg at time 5.0.
My changes allow the state to be mut, all examples and tests still work.