Torkel Loman

Documentation is always the never ending task, isn't it? I guess one thing which makes MTK documentation tricky is that, as a package, it essentially serves two roles. It is...

I think one problem is that MTK's doc (which has actually gotten quite good) have been written quite incohesively, and especially from different times of a package that have evolved...

I don't think we need (or should) rush into things, especially while MTK is seeing some amount of flux. But considering some stuff that Chris was mentioning about future workflows...

I usually use the progrmmatic approach, but mostly because I haven't bothered learning the macro properly (and last time I read through the MTK docs from start to finish it...

Sounds good. If I understand it correctly, the big difference is that any non-default types cannot be tunable (and we should put a note about that wherever relevant)?

Basically it seems as long as one doesn't mix no-default parameter types and anything which requires AD/tuning, one should be fine. And if one do, one should know what one...

this is the case now for the OrdinaryDiffEq stuff. Unless we want to keep this open to try and reduce other dependencies we could close this one?

There is an issue for this over at DiffEq, however, it hasn't really gotten any traction: https://github.com/SciML/DifferentialEquations.jl/issues/1034

I think I am relatively agnostic to the actual implementation (as I don't know anything about it), but like @kaandocal I think there is a feature here that should be...

It came up when I discussed with my collaborator. I am not sure if there are any standardise approaches for this (will ask around) or just a frequent phenomena that...