1. Should there be a prefix on the C functions? 2. If so, what should the prefix be?
Preferably, yes. Don't have an opinion on an exact prefix, as long as it allows me to e.g. swap a normal distribution generator in my cython/c++ user code without too much mess. if the only goal is to let people write new generators rather than use the
existing ones from Cython without the Python overhead).
Is it the only goal? If possible, it'd be worth IMO supporting something more like cython_lapack, so that one can use existing machinery from a cython application. Use case: an MC application where drawing random variates is in a hot loop. Then I can start from a python prototype and cythonize it gradually. Sure I can reach into non-public parts In the end we want to get to a doc section similar to
http://scipy.github.io/devdocs/special.cython_special.html I'd think.
3. Should the legacy C functions be part of the API -- these are mostly
the ones that produce or depend on polar transform normals (Box-Muller). I have a feeling no, but there may be reasons to prefer BM since they do not depend on rejection sampling.
Even if there would be a couple of users interested, it would be odd starting to do this after deeming the code "legacy". So I agree with your "no".
Unless it's a big maintenance burden, is there an issue with exposing both ziggurat_normal and bm_normal? Sure, I can cook up a BM transform myself (yet again) however.
4. Should low-level API be consumable like any other numpy C API by including the usual header locations and library locations? Right now, the pxd simplifies writing Cython but users have sp specify the location of the headers and source manually An alternative would be to provide a function like np.get_include() -> np.random.get_include() that would specialize in random.
Good question. I'm not sure this is "like any other NumPy C API". We don't provide a C API for fft, linalg or other functionality further from core either. It's possible of course, but does it really help library authors or end users?
While I gave only anecdotal evidence, not hard data, I suspect that both cython and C API would be useful. E.g. there are c++ applications which use boost::random, would be nice to be able to swap it for numpy.random. Also reproducibility: it's *much* easier to debug the compiled app vs its python prototype if random streams are identical. Like I said, take all I'm saying with enough salt, as I'm wearing my user hat here. Cheers, Evgeni