{"id":"187acd77-7745-4bcd-ade1-5e89b339914e","arxiv_id":"2510.25693","paper_version":3,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"A unified PyTorch package implementing six differentiable particle filters, with benchmark comparisons on stochastic volatility, visual localization, and proposal learning.","lead":"PyDPF is a new Python package that bundles several differentiable particle filter algorithms into one PyTorch-based API. The paper demonstrates the package on toy and deep-learning benchmarks and compares the algorithms' speed, accuracy, and gradient variance.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Printed OT-resampling algorithm (Algs. 4–5) appears inconsistent with FilterFlow; if the code follows the paper, the OT benchmarks are invalid.","rationale":"The reader's weakest assumption was that the implementations faithfully reproduce the original DPFs. I agree that this is load-bearing, but the reader did not point to a specific algorithm where the fidelity is in question. The OT resampling section is the only place where the paper includes a full algorithmic description that can be checked against the cited original. The discrepancies I identified are specific, testable, and central: if the code follows the paper, the OT benchmark invalidates the 'faithful reproduction' claim; if the code follows FilterFlow, the paper's algorithms are wrong. Either way, the paper needs correction. This reinforces the reader's CONDITIONAL verdict rather than changing it, because the concern is about a single component and the package may still be useful; however, the OT results in Tables 8–12 should not be interpreted until resolved.","tokens_in":29282,"tokens_out":9956,"duration_ms":92508,"concrete_test":"Run PyDPF's OptimalTransportDPF and FilterFlow's OT resampler on identical inputs (same particles, weights, cost, epsilon schedule, max_iterations, and random seed). Compare the transport matrices and resampled particles; if the max-absolute difference exceeds, say, 1e-6, the implementation is not a faithful reimplementation. Additionally, inspect the PyDPF source to confirm whether the Sinkhorn loop iterates over K or d_x and whether the final reconstruction uses K P^T X or d_x P X. This will determine whether the bug is in the paper or the code.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim depends on the implemented DPFs faithfully reproducing the original algorithms. The strongest concrete threat is in Section 5.3: the printed Algorithm 4 loops 'for n=1,...,d_x' to update the Sinkhorn potentials f and g, but those potentials have length equal to the number of particles K, not the state dimension d_x; in the stochastic volatility examples d_x=1 while K=100, so 99 of the 100 potential entries would never be updated if the paper text were followed. Moreover, the updates use log(v) in the f-equation and log(w) in the g-equation, which is the reverse of the standard Sinkhorn marginals (f should be tied to w, g to v). And in Algorithm 5 line 11, the new particles are computed as \\tilde{X}=d_x P^{(ε)}X, whereas the correct transport-map reconstruction is K (P^{(ε)})^T X (or equivalently K P^T X). None of these appear in FilterFlow's published algorithm. If the shipped code follows the printed algorithm, then PyDPF's OptimalTransportDPF is not a reimplementation of Corenflos et al. (2021), so the 'faithful reproduction' premise fails and Tables 8–12 for optimal transport do not measure the intended method. If the code instead matches FilterFlow, then the algorithm boxes are grossly misleading and the paper is not self-contained.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents PyDPF, a Python/PyTorch package that unifies several differentiable particle filters (DPFs) under a common API, specifically implementations of the methods of Jonschkowski et al. (2018), Karkus et al. (2018), Corenflos et al. (2021), Šcibior and Wood (2021), and Younis and Sudderth (2023). The paper describes the package's design, the implemented algorithms, and a set of experiments: linear-Gaussian filtering versus the Kalman filter, stochastic volatility filtering and parameter learning, a DeepMind maze visual-localisation task, and learning proposal parameters. The central claim is that PyDPF is the first unified implementation of such a framework, enabling direct comparison and deployment of multiple DPF algorithms in PyTorch.","tokens_in":29642,"tokens_out":5346,"duration_ms":50306,"significance":"If the implementations are faithful to the original methods, PyDPF is a potentially useful community resource: it provides a single API, documentation, and reproducibility measures (deterministic mode, per-module random generators). The paper is also transparent about known limitations, e.g., it states that no consistency proof exists for kernel-mixture resampling (§5.5). However, the validation is currently weakened by (i) an incorrect printed optimal-transport algorithm that calls into question the fidelity of the OT experiments, and (ii) benchmark tables that mostly omit error bars, making the reported comparisons hard to assess. These issues are load-bearing for the paper's central 'faithful reproduction and benchmarking' claim.","major_comments":[{"comment":"The printed optimal-transport resampling algorithm is not a correct Sinkhorn iteration. In Algorithm 4, lines 6–9 loop over n=1,...,d_x, but the potentials f,g are length-K vectors (one entry per particle); in the stochastic volatility experiments d_x=1 and K=100, so 99 of 100 potential entries would never be updated. The updates also swap the marginals: the f-equation uses log(v) and the g-equation uses log(w), whereas the transport plan should couple weight vector w to uniform vector 1/K. Algorithm 5, line 8 sets P_{n,m}=w_n d_x exp(...), with an unexplained factor d_x, and line 11 computes \\tilde{X}=d_x P^{(\\epsilon)}X; the correct reconstruction implied by Eq. (11) is K (P^{(\\epsilon)})^T X. If the code follows the printed algorithm, the OT experiments in Tables 8–12 are not measuring the Corenflos et al. (2021) method; if the code is correct, the text does not describe the implement","section":"§5.3, Algorithms 4–5"},{"comment":"Several benchmark tables report point estimates without a measure of uncertainty. Table 8 gives a single value per metric; Table 9 gives a gradient s.d. but no variability for α error; Table 10 reports averages over 10 runs without error bars; Table 11 and Table 12 report averages over 5 runs/repeats without standard deviations. Comparative conclusions such as 'soft resampling outperforms stop-gradient' (§7.5) or 'optimal transport is much slower' (§7.2) are not supported without knowing the run-to-run variability. Standard errors or per-seed results should be reported.","section":"Section 7, Tables 8–12"}],"minor_comments":[{"comment":"The reference particle filter is described in the text as having 10,000 particles, while the table caption says 'N=1000 as the reference,' and also lists 'N=100' for the filters. Please reconcile.","section":"§7.2 / Table 8"},{"comment":"Typo 'Summaray' in the summary heading.","section":"§5.5"},{"comment":"The phrase 'the first implementation of such a framework' is strong given FilterFlow already implements the OT DPF (as acknowledged in §1.1). Recommend qualifying as 'the first unified implementation covering multiple DPF algorithms.'","section":"§1"},{"comment":"Please specify the Sinkhorn stopping criterion exactly (norm of potential updates? all batches?) and the decay schedule for \\epsilon.","section":"§5.3"}],"recommendation":"major_revision","confidential_remarks":"The OT algorithm inconsistency is the main concern: I would ask the authors to verify the code against Corenflos et al. (2021) and correct the text. If the code is wrong and the OT results are invalid, the paper may need to drop those results or reframe them as an implementation study of a variant. The lack of error bars in the benchmark tables should also be addressed, as the current reporting makes the comparative claims impossible to evaluate."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: PyDPF is a legitimate software contribution and worth taking seriously. It gives one PyTorch API to six published DPFs, and it ships. That is not a new inference method, but it fills a real gap; FilterFlow only covers one algorithm. The docs and code examples are substantial, and the package design—module abstraction, data schema, resampler API, deterministic mode—is sensible. The DeepMind maze result, with soft resampling beating OT, matches previous reports, which is a good sign.\n\nThe soft spots are real but mostly fixable. The big one is the printed optimal transport algorithm, Sec 5.3, Algs 4–5. The Sinkhorn potentials f and g have length K, but Alg 4 loops over state dimension dx and updates only f_n/g_n; for the stochastic volatility example dx=1 and K=100, so 99 of the 100 potentials never get updated. The log(v)/log(w) assignment is also reversed relative to standard Sinkhorn marginals, and Alg 5 line 11 uses d_x P X where the reconstruction should be K P^T X. None of that matches FilterFlow's published algorithm. If the shipped code follows the printed boxes, the OT results in Tables 8–12 are not measuring Corenflos et al. If the code matches FilterFlow instead, then the algorithm listings are misleading and the paper is not self-contained. I would not desk-reject over this, but I would insist the authors verify the code against the boxes and fix one side or the other before acceptance.\n\nSmaller issues: several benchmark tables (7, 8, 11, 12) report point estimates without error bars; Table 11 says average over 5 runs but reports no spread. For a software paper, pinning a commit hash and exact dependency environment would also be expected. The self-citations are fine—they are prior work and not circular.\n\nBottom line: the central claim, that a usable unified DPF package exists, is credible, and the code clearly exists. The main risk is the OT implementation, which is exactly where the comparative findings are least stable and the printed description is most confused. This deserves a serious referee, not a desk reject.","headline":"PyDPF is a real and broadly useful software package, but the printed Sinkhorn/OT algorithm looks inconsistent, so the OT benchmark tables need a code check before they can be trusted.","tokens_in":30120,"tokens_out":3668,"would_cite":true,"duration_ms":39331,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"PyDPF claims to be the first unified Python package for differentiable particle filters, implementing five gradient-based resampling strategies in one API and validating them by reproducing prior experiments.","keywords":["differentiable particle filtering","state-space models","sequential Monte Carlo","resampling","gradient estimation","parameter learning","software package","automatic differentiation"],"falsifier":"Run a built-in DPF and the original published implementation of the same algorithm on identical data, seed, and hyperparameters; if the losses and learned parameters diverge beyond random-seed variation, the package is not faithfully reproducing the algorithm and Section 7's comparisons would not support the paper's conclusions.","tokens_in":29167,"feed_emoji":"📦","tokens_out":5584,"duration_ms":56619,"temperature":0.7,"pith_summary":"Particle filters approximate hidden states in state-space models but do not admit gradients, so parameters cannot be learned by backpropagation. This paper presents PyDPF, a Python package that unifies several recently proposed differentiable particle filters (DPFs)—filters that replace the non-differentiable resampling step with strategies that let gradients flow. The package claims to be the first such implementation with a single API, and validates it on four tasks: a linear-Gaussian model checked against the Kalman filter, stochastic volatility filtering and learning, a visual localisation benchmark, and learning a proposal distribution. If the claim is right, a researcher can load data, define a model, and train or compare DPF variants in a few lines rather than reimplementing each algorithm. The paper's own experiments also indicate which resampling strategies favour low variance versus low bias in practice.","feed_headline":"Five differentiable particle filters, one Python package","feed_subtitle":"A new Python package unifies five DPF algorithms and reproduces prior experiments, making comparison straightforward.","key_machinery":"The load-bearing design is the resampler abstraction: every DPF is a standard particle filter with its resampling step swapped for a differentiable alternative. PyDPF implements five such mechanisms—gradient-truncated resampling, soft resampling, optimal transport resampling, stop-gradient resampling, and kernel mixture resampling—as interchangeable modules with a common interface. Around this, the package supplies cached and constrained parameters for model modules, a dataset/loader convention, an aggregation function to avoid storing all intermediates, and a low-level sequential importance sampling API so users can write custom filters that are not simple resampling swaps. This modularity","core_discovery":"The central claim is that five differentiable particle filters from the literature can be implemented in one extensible, automatic-differentiation-style package without changing the underlying sequential Monte Carlo structure. PyDPF treats a particle filter as a sequence of importance sampling steps and makes each DPF differ only in its resampler: non-differentiable (gradient-truncated) resampling, soft resampling, optimal transport resampling, stop-gradient resampling, and kernel mixture resampling. The package provides modules for state-space models, datasets, aggregation functions, and a low-level API for custom filters, and it reports experiments reproducing results from previous studies","pith_inferences":["A likely knock-on is that DPF research shifts from reimplementing baselines to designing new resamplers, since the package removes the hidden implementation variance that makes literature comparisons unreliable.","The empirical dominance of low-variance, biased estimators in the simple parameter-learning example suggests a frontier for future work: estimators that retain the forward pass of a standard filter while reducing the variance of REINFORCE-style gradients, perhaps by better control variates.","The package's benchmark harness could be reused to test combinations the paper does not explore, such as learned regularisation strength for optimal transport or learned kernel bandwidth for kernel mixture resampling, which the paper leaves as hyperparameters.","The claim of being 'first' is narrower than it sounds: earlier packages cover specific DPF algorithms. The durable contribution is the common API, which makes that claim testable and the field more cumulative."],"forward_implications":["Researchers can compare DPF variants on their own state-space models by changing one resampler argument, lowering the overhead of entering this area.","The reproduced benchmarks provide a practical map of trade-offs: non-differentiable and soft resampling are fast and low-variance; optimal transport is slow and, in the visual localisation task, hard to stabilise; stop-gradient and marginal variants offer low bias at higher variance.","Because the package is extensible, new resampling schemes can be tested against the built-in filters under identical data-loading and training loops, making benchmark results more directly comparable.","GPU batching across trajectories is supported, so large-scale parameter learning with DPFs becomes feasible without bespoke parallel code."],"fun_headline_variants":["PyDPF: five differentiable filters, one PyTorch package","One package, five differentiable particle filters","PyDPF: unify five differentiable particle filters","Five DPF variants in one Python package"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"All benchmark comparisons assume the package's implementations faithfully reproduce the original DPF algorithms, so the reported differences reflect the algorithms themselves rather than quirks or bugs in the code.","fun_headline_variants_meta":{"raw":{"variants":["PyDPF: five differentiable filters, one PyTorch package","One package, five differentiable particle filters","PyDPF: unify five differentiable particle filters","Five DPF variants in one Python package"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001098,"raw_usage":{"total_tokens":4387,"prompt_tokens":677,"completion_tokens":3710,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":421,"completion_tokens_details":{"reasoning_tokens":3649}},"tokens_in":421,"tokens_out":3710,"duration_ms":22154,"temperature":1.0,"reasoning_tokens":3649,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T07:24:38.129487+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a built-in DPF and the original published implementation of the same algorithm on identical data, seed, and hyperparameters; if the losses and learned parameters diverge beyond random-seed variation, the package is not faithfully reproducing the algorithm and Section 7's comparisons would not support the paper's conclusions.","supporting_citations":[],"review_version":1}