[Numpy-discussion] Low-level API for Random

[Evgeni Burovski]

>>
>>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190919/c6fa99f4/attachment.html>