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
JAX already has jax.numpy which is close enough to existing numpy for most python users' needs
JAX works on CPU as well as GPU and TPU, so once you have your JAX arrays for A, B, C etc. I don't believe anything would need to change anyway
JAX at this point is pretty intermeshed in our codebase, it would probably be less effort to just create a new package using a different technology if we wanted to. (also how would we handle return types? converting them all to custom types would likely have a performance impact)
This is the most exciting reason for this idea to me - but in practice I think it would be difficult to establish the correct abstraction without knowing more about how users would want this feature. also validation that a bring your own function is JAX compatible could be trickier if it isn't using JAX types and primitives
I am leaning 70/30 away from this idea, but I wanted to document it here and get opinions. If someone can address the concerns and thinks the reward is worthwhile to do the work before we do a v1 release then we can prioritise it accordingly.
There is a case to be made for abstracting out JAX from the pymdp API (I got this feedback from a user at IWAI).
This would have the following benefits:
However I do have concerns:
jax.numpywhich is close enough to existingnumpyfor most python users' needsI am leaning 70/30 away from this idea, but I wanted to document it here and get opinions. If someone can address the concerns and thinks the reward is worthwhile to do the work before we do a v1 release then we can prioritise it accordingly.