4 ms·

I wonder how performance sensitive this code has to be? Clojure is a pretty bad choice for numerical work in general since function parameters are usually just

I wonder how performance sensitive this code has to be? Clojure is a pretty bad choice for numerical work in general since function parameters are usually just Object and this leads to a lot of boxing. You can type hint them as primitives but it's pretty funky internally once you start doing that. If code can offload the numerically intensive bit to either Java or something native (as Neanderthal does) then it's more tractable, or of course if it doesn't actually require very high performance. Still, awesome effort - it looks like a ton of work.

db48x 8y ago
Presumably the Java library it uses for the numerical integrators works on unboxed data.
- lrc 8y ago
  You are correct.
hcarvalhoalves 8y ago
This library is for symbolic manipulation AFAIK.
- kkylin 8y ago
  Scmutils enables both symbolic and numerical computation, though as I recall much of the symbolic stuff (e.g., automatic differentiation) is done via generic functions rather than manipulating symbolic expressions.
kkylin 8y ago
All this is true. Similar issues arise in MIT Scheme as well. This can be partially alleviated by having specialized versions of VECTOR-SET! etc that avoid boxing floats. Presumably there are compiler optimizations focused on faster numerics as well. Anyway, for the purpose doing SICM-style problems (which are generally not computationally intensive), it's certainly fast enough.
fulafel 8y ago
> Clojure is a pretty bad choice for numerical work in general since function parameters are usually just Object and this leads to a lot of boxing This is quite easily solved by just declaring your parameters with type hints, and testing the code with the provided warnings about reflection and boxed math. This still leaves container data structures, the native arrays and vectors are boxed. To address this, you can to use Java arrays or 3rd party specialized containers like data.int-map instead.
- lrc 8y ago
  There is good news and bad news. The ODE integrators (etc.) in Apache Commons Math are great and work with unboxed types. In SICM, however, you'll be dealing with clojure functions generated by the system to map states to their time derivatives, and those states will be stored in "up tuples" and not native java []double. So copying must happen at state-derivative evaluation time. The system attempts to win back some speed by at least avoiding interpreting the state function. For the kind of explorations the book enables, it seems good enough. Also, you can "take your equations of motion out" of the system with ->JavaScript, and run that code in the browser with a suitable JavaScript integrator and that works too.

db48x 8y ago

Presumably the Java library it uses for the numerical integrators works on unboxed data.

lrc 8y ago
You are correct.

hcarvalhoalves 8y ago

This library is for symbolic manipulation AFAIK.

kkylin 8y ago
Scmutils enables both symbolic and numerical computation, though as I recall much of the symbolic stuff (e.g., automatic differentiation) is done via generic functions rather than manipulating symbolic expressions.

kkylin 8y ago

All this is true. Similar issues arise in MIT Scheme as well. This can be partially alleviated by having specialized versions of VECTOR-SET! etc that avoid boxing floats. Presumably there are compiler optimizations focused on faster numerics as well. Anyway, for the purpose doing SICM-style problems (which are generally not computationally intensive), it's certainly fast enough.

fulafel 8y ago

> Clojure is a pretty bad choice for numerical work in general since function parameters are usually just Object and this leads to a lot of boxing This is quite easily solved by just declaring your parameters with type hints, and testing the code with the provided warnings about reflection and boxed math. This still leaves container data structures, the native arrays and vectors are boxed. To address this, you can to use Java arrays or 3rd party specialized containers like data.int-map instead.

lrc 8y ago
There is good news and bad news. The ODE integrators (etc.) in Apache Commons Math are great and work with unboxed types. In SICM, however, you'll be dealing with clojure functions generated by the system to map states to their time derivatives, and those states will be stored in "up tuples" and not native java []double. So copying must happen at state-derivative evaluation time. The system attempts to win back some speed by at least avoiding interpreting the state function. For the kind of explorations the book enables, it seems good enough. Also, you can "take your equations of motion out" of the system with ->JavaScript, and run that code in the browser with a suitable JavaScript integrator and that works too.