As part of the JOSS review guidelines, the paper's "Sampling API" section (Section 4) currently reads more as API documentation than a discussion of design trade-offs. The JOSS review criteria require a section explaining the architectural choices, trade-offs considered, and why they matter.
I'd suggest adding or expanding a section that addresses:
- The choice to support both mutable and immutable sampler variants (via HybridStructs.jl) and the performance trade-off this enables
- The decision to integrate with the OnlineStats.jl API (
fit!/value/merge!) rather than designing a standalone interface, and why this matters for ecosystem composability
- The use of a binary heap for weighted sampling without replacement (AlgARes/AlgAExpJ) vs. the array-based approach for with-replacement algorithms, and the trade-off involved
- The design of
itsample to automatically dispatch between reservoir and sequential methods based on iterator traits (Base.SizeUnknown vs Base.HasLength)
These are all interesting design decisions already present in the code, surfacing them in the paper would strengthen it.
As part of the JOSS review guidelines, the paper's "Sampling API" section (Section 4) currently reads more as API documentation than a discussion of design trade-offs. The JOSS review criteria require a section explaining the architectural choices, trade-offs considered, and why they matter.
I'd suggest adding or expanding a section that addresses:
fit!/value/merge!) rather than designing a standalone interface, and why this matters for ecosystem composabilityitsampleto automatically dispatch between reservoir and sequential methods based on iterator traits (Base.SizeUnknownvsBase.HasLength)These are all interesting design decisions already present in the code, surfacing them in the paper would strengthen it.