4 ms·

The context here is that the author is the principal developer of one of the biggest (if not the biggest) and most performant differential equation solver suite

The context here is that the author is the principal developer of one of the biggest (if not the biggest) and most performant differential equation solver suites in the world[1]. It's written in julia, and it is very widely used, and known to be state of the art. [1] https://github.com/SciML/DifferentialEquations.jl https://github.com/SciML/DifferentialEquations.jl

drnick1 1y ago
Would it not make more sense to write such a tool in C? The idea here is that C is universal, and higher level languages like Python, R, Julia and others all have a foreign function interface for C.
- eigenspace 1y ago
  Good luck being that productive in C, distributing the software adequately, and attracting collaborators.
- adgjlsfhk1 1y ago
  No. C isn't an expressive enough language to write many solvers in. Many of the best solvers are basically impossible to write without meta-programming (where you write a generator for the n-stage version that is then able to generate the code for all the possible permuations), and there are also massive performance gains through symbolic-numeric approaches where the solver does introspection of the user function to rearrangements that aren't possible in a black-box framework.
- ChrisRackauckas 1y ago
  This tool already exists in Python and R. See https://cran.r-project.org/web/packages/diffeqr/index.html https://cran.r-project.org/web/packages/diffeqr/index.html and https://anaconda.org/conda-forge/diffeqpy https://anaconda.org/conda-forge/diffeqpy. Julia has language bindings that make it simple enough to bind to other high level languages that these projects are maintained by the core team and supports lots of the library, including forms of automatic differentiation and GPU kernel generation. See for example the bindings that allow for usage within PyTorch https://github.com/SciML/juliatorch https://github.com/SciML/juliatorch and the Python-based Collab notebooks showing the GPU usage https://colab.research.google.com/drive/1bnQMdNvg0AL-LyPcXBiH10jBij5QUmtY?usp=sharing https://colab.research.google.com/drive/1bnQMdNvg0AL-LyPcXBi.... With Julia v1.12's small binary generation, we plan to release forms via binaries with C ABIs over the next year as well. Are those sufficient or should we consider supporting other deployments?

drnick1 1y ago

Would it not make more sense to write such a tool in C? The idea here is that C is universal, and higher level languages like Python, R, Julia and others all have a foreign function interface for C.

eigenspace 1y ago
Good luck being that productive in C, distributing the software adequately, and attracting collaborators.
adgjlsfhk1 1y ago
No. C isn't an expressive enough language to write many solvers in. Many of the best solvers are basically impossible to write without meta-programming (where you write a generator for the n-stage version that is then able to generate the code for all the possible permuations), and there are also massive performance gains through symbolic-numeric approaches where the solver does introspection of the user function to rearrangements that aren't possible in a black-box framework.
ChrisRackauckas 1y ago
This tool already exists in Python and R. See https://cran.r-project.org/web/packages/diffeqr/index.html https://cran.r-project.org/web/packages/diffeqr/index.html and https://anaconda.org/conda-forge/diffeqpy https://anaconda.org/conda-forge/diffeqpy. Julia has language bindings that make it simple enough to bind to other high level languages that these projects are maintained by the core team and supports lots of the library, including forms of automatic differentiation and GPU kernel generation. See for example the bindings that allow for usage within PyTorch https://github.com/SciML/juliatorch https://github.com/SciML/juliatorch and the Python-based Collab notebooks showing the GPU usage https://colab.research.google.com/drive/1bnQMdNvg0AL-LyPcXBiH10jBij5QUmtY?usp=sharing https://colab.research.google.com/drive/1bnQMdNvg0AL-LyPcXBi.... With Julia v1.12's small binary generation, we plan to release forms via binaries with C ABIs over the next year as well. Are those sufficient or should we consider supporting other deployments?