You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we are changing objects in place. This might become an issue for clarity and jax just-in-time compilation. Should we switch to a functional paradigm throughout the package and avoid in-place object modification?
The text was updated successfully, but these errors were encountered:
I think if we write a lot of our internal functions of classes to follow the functional paradigm we will set ourselves up better for using JIT. This has mostly been my approach thus far. E.g., the NeighborList serves as a container that can be modified in place, but the underlying functions are all functional in nature with clear inputs and outputs. This has definitely made it a lot easier to Jax-ify/jit/vmap the various functions
Currently, we are changing objects in place. This might become an issue for clarity and
jax
just-in-time compilation. Should we switch to a functional paradigm throughout the package and avoid in-place object modification?The text was updated successfully, but these errors were encountered: