FusionBlossomDecoder's max_tree_size is stored but never used, so it is currently inert configuration.
What exists
FusionBlossomConfig declares it, and the doc comment already admits the gap (crates/pecos-fusion-blossom/src/decoder.rs:43):
/// Maximum tree size for union-find decoder (currently not supported in Rust API)
pub max_tree_size: Option<usize>,
The builder accepts it (crates/pecos-fusion-blossom/src/builder.rs:91) and stores it, but nothing in the crate reads it back — the solver never consumes it.
Why it matters now
It is not reachable from Python today, so nobody can be misled by it yet. It came up while surveying which decoder knobs should be exposed on the DEM constructors (PR #420 discussion): max_tree_size looked like a legitimate tuning parameter from the struct definition, and exposing it would have shipped a parameter that is accepted and silently ignored. It has been deliberately left out of that work for exactly that reason.
So there are two coherent end states, and the field should not stay as-is:
- Support it — bound cluster growth in the union-find path, which is a real accuracy/runtime tradeoff worth having, and then expose it alongside the other decoder tuning parameters.
- Remove it — drop the field and the builder method, so nothing suggests a knob that does nothing.
Option 1 is preferable if the underlying solver can honour it; option 2 is strictly better than the status quo either way.
Acceptance if supported
- Setting
max_tree_size changes decoding behaviour on a case where cluster growth would otherwise exceed it — assert on a decode result, not merely that the value round-trips through the config.
- The default (
None) leaves current behaviour byte-identical.
- It becomes reachable from
FusionBlossomDecoder.from_dem(...) with the rest of that decoder's tuning surface.
Related: SolverType::Parallel in the same config requires a partition configuration and panics without one (crates/pecos-fusion-blossom/src/decoder.rs:908), so it is likewise not safe to expose as a free choice. Worth handling in the same pass.
FusionBlossomDecoder'smax_tree_sizeis stored but never used, so it is currently inert configuration.What exists
FusionBlossomConfigdeclares it, and the doc comment already admits the gap (crates/pecos-fusion-blossom/src/decoder.rs:43):The builder accepts it (
crates/pecos-fusion-blossom/src/builder.rs:91) and stores it, but nothing in the crate reads it back — the solver never consumes it.Why it matters now
It is not reachable from Python today, so nobody can be misled by it yet. It came up while surveying which decoder knobs should be exposed on the DEM constructors (PR #420 discussion):
max_tree_sizelooked like a legitimate tuning parameter from the struct definition, and exposing it would have shipped a parameter that is accepted and silently ignored. It has been deliberately left out of that work for exactly that reason.So there are two coherent end states, and the field should not stay as-is:
Option 1 is preferable if the underlying solver can honour it; option 2 is strictly better than the status quo either way.
Acceptance if supported
max_tree_sizechanges decoding behaviour on a case where cluster growth would otherwise exceed it — assert on a decode result, not merely that the value round-trips through the config.None) leaves current behaviour byte-identical.FusionBlossomDecoder.from_dem(...)with the rest of that decoder's tuning surface.Related:
SolverType::Parallelin the same config requires a partition configuration and panics without one (crates/pecos-fusion-blossom/src/decoder.rs:908), so it is likewise not safe to expose as a free choice. Worth handling in the same pass.