Seeking collaboration with QuasiMonteCarlo.jl

[sou-cheng-choi]

SciML’s QuasiMonteCarlo.jl focuses on point generation (low-discrepancy sequences).

Our repository at https://github.com/QMCSoftware/QuasiMC.jl is broader: it adds true-measure transforms, integrands, and adaptive stopping criteria, mirroring the full pipeline of the Python package QMCPy (https://github.com/QMCSoftware/QMCSoftware).

We are interested in contributing our framework to SciML’s QuasiMonteCarlo.jl package.

Hi @ChrisRackauckas, since you maintain QuasiMonteCarlo.jl, would you be willing to comment on whether some or all of this framework would make sense to merge, upstream, or otherwise integrate into QuasiMonteCarlo.jl? Our package is currently a Julia port of QMCPy v2.3, with a broader structure around discrete distributions, true measures, integrands, stopping criteria, and adaptive QMC/MLMC cubature workflows. We do not want to create unnecessary fragmentation in the Julia QMC ecosystem. If you think the scope fits naturally into QuasiMonteCarlo.jl, we would be open to discussing a migration or staged integration. If you think it is better as a separate package, that would also help clarify the registration path.

Thank you very much for your consideration and advice in advance.

Remarks: Our idea of contributing to QuasiMonteCarlo.jl stems from the Julia registration discussion at JuliaRegistries/General#159512 (comment)

[dmetivie]

Dear @sou-cheng-choi, thanks for the issue!
I have been very much interested in QMC at some point for my research (much less now), and end up coding a few randomized QMC method in QuasiMonteCarlo.jl.

Note that kind of intimidated by writing code in another package, or because I was not sure how to do so #17 I started writing my own package RandomizedQuasiMonteCarlo.jl. Eventually I end up porting my package to QuasiMonteCarlo.jl and I am very happy by this decision!
All that to say I kind of feel where you're coming from! Plus I met/discuss with some of the people behind QMCpy at a conference.
Note that, there is also QMCGenerator.jl (with fewer functionalities than your QuasiMC) by @alegresor (also someone who worked on QMCpy?).

IMO, the path for contribution would be:

1. Integrate as much QMC and RQMC methods into QuasiMonteCarlo.jl that are not already there and already in QMCpy/QuasiMC.jl.
   For that, you would need to rewrite using Julia style and the conventions of this package DeterministicSamplingAlgorithm, RandomSamplingAlgorithm QuasiMonteCarlo.sample, randomize, etc (have a look at the code in the scr files, doc, readme). Don't hesitate if you have issues/questions, I'll be happy to help on that part.

2. IMO, QuasiMonteCarlo.jl should only be about sampling, not estimation with stopping criteria etc. All these functionalities could be in a separate package like QuasiMonteCarloExtras.jl or QuasiMonteCarloIntegrals.jl (like discussed in Estimators and Statistics for RQMC Integraiton #89). This is more like Julia spirit of having multiple lightweight packages (that can talk easily to each other) doing one thing instead of having a larger package doing it all.

3. Reuse as much as possible Julia existing ecosystem. For example, I see that you define your own distributions here, could you use directly Distributions.jl ? That's really one of the power of Julia to be able to reuse the ecosystem, it can make your functionalities even more generic.

The pros of doing all that:

• As you said one reference package rather than multiple ones doing similar things should be better
• this package has already a lot of visibility already, so your features could be used by a lot of people.
• it would be maintained/reviewed/documented by a diverse and large scientific community
• QMC can easily be used into downstream packages e.g. to train PINNs or applications we did not think it was possible! All that with the speed/features of Julia.

The cons/difficulties I see

• I feel in academia that contributions to another one package are harder to value. However, if a few are motivated we could write a paper on this package.
• Porting your functionalities to this package will require some work (and concessions in the syntax), I guess? For example, I see you have advance Lattice methods. The lattice method in this package is in fact coming from LatticeRules.jl. Sobol method is in Sobol.jl (which still has the 0 issue, but it should soon be resolved?). Hence, should you contribute to all this smaller packages to add all you advanced sampling functionalities? I am not sure. Should QuasiMonteCarlo restructure to make it easier to contribute?