FFroehlich
commented
4 years ago IMHO probably not worth the trouble.
Open paulstapor opened 4 years ago
FFroehlich
commented
4 years ago IMHO probably not worth the trouble.
dweindl
commented
4 years ago I think this will need some deeper discussion on how we want to implement matlab support in the future.
I think it's relatively clear, that we will drop the redundant (and with recent matlab versions unsupported) model import / code generation.
Beyond that, we need to decide whether we want to keep the mex files and the current matlab wrapper which I think you are mostly referring to, or whether this should also go via Matlab/Python integration.
Would only go deeper there once somebody intends to allocate some time on doing that properly.
paulstapor
commented
4 years ago Hm... Maybe... My intention was the following: We agreed on exposing the functionality, which the C++/Python interface has, also to the Matlab interface (as currently, there are some features, which simply can't be used from Matlab, such as parameter scales for individual parameters (as far as I know, Matlab only knows a global parameter scale, or fine-grained solver tolerance accessors beyond general atol and rtol). While doing this, it would make sense to give the api a more general refactoring, I thought, but might well be that this is the overkill...
In the longer run, Amici will always be called through the Python interface, also when using it from Matlab (see Milestone v1.0.0 and #887).
Moreover, the Matlab interface does not allow to access all options which are available in C++/Python. I would suggest adapting the Matlab api to be already now (mostly) identical to the one from Python. In order to not break backwards compatibility for the moment, we should trigger deprecation warnings, if the old API is used. One could, e.g., rename amioption to solver and amidata to ExpData.
Opinions/Objections?