>> >> >> 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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion