Bind ReducedComplexityModeling to 0.5

CHANGELOG.md

@@ -53,7 +53,7 @@ breaking release).
 
 ### Changed (breaking)
 
-- **The data loader is `ReducedComplexityModeling`'s, and `DataLoader`, `Batch` and `train!` are re-exported from it.** `parentmodule` of all three is that package, this package's method of `train!` extends its generic, and `using GeometricMachineLearning` alone still gives the three names. The loader's routines and their reference documentation move with the code: `GeometricMachineLearning.number_of_batches`, `.convert_input_and_batch_indices_to_array`, `.accuracy`, `.assign_output_estimate`, `.data_tensors_from_geometric_solution`, `.map_to_type` and `.map_to_new_backend` are `ReducedComplexityModeling`'s, and the docstrings of `DataLoader`, `Batch`, `number_of_batches`, `convert_input_and_batch_indices_to_array`, `accuracy` and `assign_output_estimate` are in that package's manual, and so are those of `data_tensors_from_geometric_solution`, `map_to_type` and `map_to_new_backend`, which ReducedComplexityModeling 0.4.1 adds. That release also declares these seven routines `public`, so this package's `[compat]` entry for it is `"0.4.1"`. `accuracy`, `number_of_batches`, `map_to_type` and `map_to_new_backend` leave this package's namespace with them; `assign_output_estimate`, `convert_input_and_batch_indices_to_array` and `data_tensors_from_geometric_solution` keep a binding here, because this package's own code calls them. `ParametricDataLoader` is public there and not here, so `using GeometricMachineLearning: ParametricDataLoader` becomes `using ReducedComplexityModeling: ParametricDataLoader`. A package that names one of these routines declares `ReducedComplexityModeling` in its own `[deps]`, as this one now does; `GeometricSolutions` leaves `[deps]` and `[compat]` with the code that read its types.
+- **The data loader is `ReducedComplexityModeling`'s, and `DataLoader`, `Batch` and `train!` are re-exported from it.** `parentmodule` of all three is that package, this package's method of `train!` extends its generic, and `using GeometricMachineLearning` alone still gives the three names. The loader's routines and their reference documentation move with the code: `GeometricMachineLearning.number_of_batches`, `.convert_input_and_batch_indices_to_array`, `.accuracy`, `.assign_output_estimate`, `.data_tensors_from_geometric_solution`, `.map_to_type` and `.map_to_new_backend` are `ReducedComplexityModeling`'s, and the docstrings of `DataLoader`, `Batch`, `number_of_batches`, `convert_input_and_batch_indices_to_array`, `accuracy` and `assign_output_estimate` are in that package's manual, and so are those of `data_tensors_from_geometric_solution`, `map_to_type` and `map_to_new_backend`, which ReducedComplexityModeling 0.4.1 adds. That release also declares these seven routines `public`. This package's `[compat]` entry for it is `"0.5"`: ReducedBasisMethods 0.4 and VlasovMethods from its next release bind ReducedComplexityModeling 0.5, so an environment that holds them resolves this package only on 0.5, and 0.5 changes none of the data-loader code that this package imports. `accuracy`, `number_of_batches`, `map_to_type` and `map_to_new_backend` leave this package's namespace with them; `assign_output_estimate`, `convert_input_and_batch_indices_to_array` and `data_tensors_from_geometric_solution` keep a binding here, because this package's own code calls them. `ParametricDataLoader` is public there and not here, so `using GeometricMachineLearning: ParametricDataLoader` becomes `using ReducedComplexityModeling: ParametricDataLoader`. A package that names one of these routines declares `ReducedComplexityModeling` in its own `[deps]`, as this one now does; `GeometricSolutions` leaves `[deps]` and `[compat]` with the code that read its types.
 
 - **`DataLoader`'s `autoencoder` defaults to `false` in every constructor that takes it, except the copying constructor, where `autoencoder = nothing` inherits the loader's kind, and a loader given an input and an output is a set of samples.** A matrix or a vector is a time series unless `autoencoder = true` is passed: that keyword is what reads a matrix's second axis as the parameter index, and the matrix and the vector method defaulted to `true`, so migrate `DataLoader(matrix)` to `DataLoader(matrix; autoencoder = true)` where the columns are samples — `scripts/reproduction/symplectic_autoencoders/training.jl` and the tutorials do. `DataLoader(input, output)` builds a `:RegularData` loader whatever its kind, so its target is its output and never the input shifted by the sequence length: in 0.8.0 a `DataLoader(x, y)` of ten pairs drew the samples 1 to 9 and, where the input and the output differed in array type, returned one minibatch holding the whole data set. The count is `cld(n · n_params, batch_size)` with `n` the start positions of one parameter index, and a loader and a `Batch` that leave no start position raise an `ArgumentError` naming the time steps, the sequence length and the prediction window, where 0.8.0 asserted and an epoch could be empty. `Batch(batch_size, dl)` takes its two lengths from the loader, so a classifier's minibatch holds the whole patch sequence and the whole one-hot output of each of its samples. On a loader whose output's time axis differs from its input's, such as a classifier's with one output column, `Batch(batch_size)` raises an `ArgumentError` that names `Batch(batch_size, dl)`, where 0.8.0's minibatch held the whole input sequence; migrate it to `Batch(batch_size, dl)`. That batch is a `Batch{:Transformer}`, so `train!` on a `NeuralNetworkIntegrator` with it needs an explicit `loss`. `suppress_info` is a keyword of every constructor that takes a data set, which makes `DataLoader(solution, true)` a `MethodError`.
 

Project.toml

@@ -34,6 +34,6 @@ NNlib = "0.8, 0.9"
 NeuralNetworkParameters = "0.5"
 ProgressMeter = "1"
 Random = "1"
-ReducedComplexityModeling = "0.4.1"
+ReducedComplexityModeling = "0.5"
 Zygote = "0.7"
 julia = "1.12"