3 ms·

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 ha

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?

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?