declearn v2.3.0

Release date: 30/08/2023

Release Highlights

New Dataset subclasses to interface TensorFlow and Torch dataset APIs

The most visible addition of v2.3 are the new TensorflowDataset and TorchDataset classes, that respectively enable wrapping up torch.utils.data.Dataset and tensorflow.data.Dataset objects into declearn Dataset instances that can be used for training and evaluating models in a federative way.

Both of these classes are implemented under manual-import submodules of declearn.dataset: declearn.dataset.tensorflow and declearn.dataset.torch. While applications that rely on memory-fitting tabular data can still use the good old InMemoryDataset, these new interfaces are designed to enable users to re-use existing code for interfacing any kind of data, including images or text (thay may require framework-provided pre-processing), that may be loaded on-demand from a database or distributed files, or even generated procedurally.

Our effort has been put on keeping the declearn-side code minimal and to try to leave the door open for as much framework-provided features as possible, but it is possible that we have missed some things; if you run into issues or limits when using these new classes, feel free to drop us a message, using either the historical Inria-Gitlab repository or the newly-created mirroring GitHub one!

Support for Torch 2.0

Another less-visible but possibly high-impact update is the addition of support for Torch 2.0. It took us a bit of time to adjust the backend code for this new release of Torch as all of the DP-oriented functorch-based code has been made incompatible, but we are now able to provide end-users with compatibility for both the newest 2.0 version and the previously-supported 1.10-1.13 versions. Cherry on top, it should even be possible to have the server and clients use different Torch major versions!

The main interest of this new support (apart from not losing pace with the framework and its backend improvements) is to enable end-users to use the new torch.compile feature to optimize their model's runtime. There is however a major caveat to this: at the moment, options to torch.compile are lost, which means that they cannot yet be properly-propagated to clients, making this new feature usable only with default arguments. However, the Torch team is working on improving that (see for example this issue), and we will hopefully be able to forward model-compilation instructions as part of declearn in the near future!

In the meanwhile, if you encounter any issues with Torch support, notably as to 2.0-introduced features, please let us know, as we are eager to build on user feedback to improve the package's backend as well as its APIs.

Numerous test-driven backend fixes

Finally, a lot of effort has been put in making declearn more robust, by adding more unit and integration tests, improving our CI/CD setup to cover our code more extensively (notably systematically testing it on both CPU and GPU) and efficiently, and adding a custom script to launch groups of tests in a verbose and compact way. We thereof conducted a number of test-driven backend patches.

Some bugs were pretty awful and well-hidden (we recently backported a couple of hopefully-unused operations' formula fix to all previous versions via sub-minor version releases); some were visible but harmful (some metrics' computations were just plain wrong under certain input shapes conditions, which showed as values were uncanny, but made results' analysis and use a burden); some were minor and/or edge-case but still worth fixing.

We hope that this effort enabled catching most if not all current potential bugs, but will keep on improving unit tests coverage in the near future, and are adopting a stricter policy as to testing new features as they are being implemented.

Full Release Notes

Release notes are available on our website and on the source GitLab repo.