From neopdf's strategy implementations, it seems ninterp's custom strategy example might have a couple gaps:
- Pervasive use of data.grid[i].as_slice().unwrap() in every
neopdf custom strategy.
- Every strategy in neopdf's strategy.rs accesses grid coordinates via .as_slice().unwrap() rather than direct ArrayView indexing (which is what ninterp's own built-ins use — see find_nearest_index taking ArrayView1 and indexing directly). .as_slice() panics on non-contiguous storage, which is exactly what Interp*Viewed (ninterp's explicit zero-copy/borrowed-data variant) can produce from a strided slice. Nothing in examples/custom_strategy.rs or the custom-strategy guide warns against this. It hasn't bitten neopdf because they always pass owned, freshly-.to_owned()'d arrays — but it's a panic waiting for whoever's first to combine a custom strategy with Viewed data. Feels like a docs/guidance fix (maybe a data.grid[i] accessor note, or a CowArray-safe helper)
- We should call out use of ndarray's API for indexing
- make note of
find_nearest_index (left of point) binary search helper for use in custom strategies
Additionally, examples/dynamic_interpolator.rs and examples/dynamic_strategy.rs should probably be renamed examples/swap_interpolator.rs and examples/swap_strategy.rs, since dynamic implies dyn, which is one of multiple ways to swap these at runtime.
From neopdf's strategy implementations, it seems ninterp's custom strategy example might have a couple gaps:
neopdfcustom strategy.find_nearest_index(left of point) binary search helper for use in custom strategiesAdditionally,
examples/dynamic_interpolator.rsandexamples/dynamic_strategy.rsshould probably be renamedexamples/swap_interpolator.rsandexamples/swap_strategy.rs, since dynamic impliesdyn, which is one of multiple ways to swap these at runtime.