Future plans for Keops / Geomloss

[gabrielfougeron]

Dear Keops dev team,

I've discovered your project circa six month ago. I'm very impressed with both Keops and Geomloss. I've read Jean Feydy's thesis cover to cover (which is extremely well written btw) and I can tell there is a lot of potential for these libraries.

I've started using Keops and Geomloss at work, and (especially since version 2.0 of Keops) I'm wondering what are your plans / ambitions for the futures (6 months ? 2 years ? 5 years ?) ? Should I expect these libraries to be maintained / enhanced ?

Thanks for your amazing work

[gabrielfougeron]

Hi,

I can only assume how complex it is to properly communicate when part of an open source project like Keops, and I wouldn't want any member of the dev team to feel pressure to commit to anything.
This being said, from an outside perspective, it is difficult to get insight about the project's directions. Could it please be possible to have a bit more info?

@joanglaunes : I see you have been involved quite intensely in the projects for a few weeks. Could you maybe share your perspective?

[joanglaunes]

Hello @gabrielfougeron ,

Thank you for your interest and sorry for leaving this discussion unanswered for such a long time! We are all professors / researchers in applied maths, which forbids us unfortunately to spend all the time it would require for developing and maintaining KeOps.
But the good news is that we will most certainly be able to hire a research engineer for the KeOps project in the coming months ; we will communicate about this very soon.

About future plans, there are a whole lot of improvements that we have been discussing together over the last months. It is not easy to list them all. Several of them correspond to improvements suggested by users in the issues, like improving the support for operations on complex, supporting JAX, maybe develop bindings for Julia, a better support of advanced features of recent Gpus or Cpus, etc. Definitely we will not be able to address all of these, but we will try to do some!

About such improvements suggested by users, I merged yesterday a branch that adds support for forward autodiff, both in the internal engine and in the PyTorch interface (support of torch.func tools such as jacfwd or hessian for example), as were suggested in issues #303 and #319, and also adds symbolic computations of the laplacian of a formula, which allows to compute it without having to evaluate the whole jacobian of the formula (cf issue #283).

One of our goals in the coming months is to propose a new SymbolicTensor class that will be a sort of rewriting of the LazyTensor class, in order to get a fully seamless interface for the user. Basically this means that these symbolic tensors and the operations made on them should exactly mirror the corresponding operations on actual tensors, whereas with the LazyTensor class there are some tiny differences regarding output shapes for example that can be annoying for the user. Also with this class we plan to introduce a clear "point of exit" in the form of a .dense() operation, that will convert the symbolic tensor to the actual tensor, by calling the KeOps reduction engine. Finally we also plan to allow the user to operate the reduction over arbitrary axis, whereas in the current state the axis of reduction must be the -1or -2 axis. Equivalently this mans that the internal expression (the F_ij function) will have itself several dimensions, and not just one as it is the case currently. With this new class we will ba able to introduce function decorators as is done in JAX for example.

Probably I must be forgetting about several points, and we should make a clear list of what are our plans. This is actually the purpose of the Projects section, but it needs to be updated!

About Geomloss, I will let @jeanfeydy answer!

[gabrielfougeron]

Thank you so much @joanglaunes for your answer!
The announcement of your new hire sounds to me like a huge step forward. I'm very excited about it and about the new SymbolicTensor interface!