ENH: Add other array frameworks as backends

[timmens]

PyLCM heavily depends on the JAX array framework and many of its amazing operators (e.g., vmap, jit). Additionally it allows for straightforward computation on the GPU.

Other notable array frameworks are pytorch and mlx. Both frameworks provide very similar operators to vmap and jit, and could thus be potentially relatively easy to support or test.

In particular, the mlx framework could benefit rapid development for users on modern MacBooks as it is optimized for Apple Silicon.

[hmgaudecker]

We have 1064 occurrences of jnp|jax in the codebase. I am a bit afraid this would complicate the codebase quite a lot. Plus, personally I do not have any inclination of spending time on this. Since open issues are always a distraction, my vote is for closing it.

[timmens]

I do agree that this does not need to be an issue (so please go ahead with closing the issue after reading the following comments). However, I would argue that we need something like a PyLCM product backlog, which captures potential features and ideas for the project for which we haven't decided yet whether we want to do it.

For example, I can still see that the above could be very beneficial for a specific user group. I can also see that it is not of high priority right now.

Regarding such a product backlog I am not sure what the best approach is. One could use a single living issue (probably the easiest solution), exploit GitHub Discussions, or even setup a GitHub project (most suited for project work, but most likely overkill for the current state of the project).

[hmgaudecker]

Fair enough. I still find it difficult to come up with a scenario where the maintenance vs. usability-for-some balance shifts in favor of the latter, but I guess we could also do with clearer labels. So far, we did not do well with priority status, for example, the signaling value of that re importance when going through issues was zero.

Here, we would need to signal "Somebody thought about this before but nobody needs to worry about it when looking for things that could be improved".

For something like #80, we'd want something like "Somebody thought about this before, but it is impossible for now".