<div dir="auto"><br><br><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><br><br>1. Should there be a prefix on the C functions?<br>2. If so, what should the prefix be?</div></blockquote></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>if the only goal is to let people write new generators rather than use the existing ones from Cython without the Python overhead).</div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">Is it the only goal?</div><div dir="auto"><br></div><div dir="auto">If possible, it'd be worth IMO supporting something more like cython_lapack, so that one can use existing machinery from a cython application.</div><div dir="auto"><br></div><div dir="auto">Use case: an MC application where drawing random variates is in a hot loop.</div><div dir="auto">Then I can start from a python prototype and cythonize it gradually.</div><div dir="auto">Sure I can reach into non-public parts </div><div dir="auto"><br></div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>In the end we want to get to a doc section similar to <a href="http://scipy.github.io/devdocs/special.cython_special.html" rel="noreferrer noreferrer" target="_blank">http://scipy.github.io/devdocs/special.cython_special.html</a> I'd think.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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. <br></div></div></blockquote><div><br></div><div>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".<br></div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">Unless it's a big maintenance burden, is there an issue with exposing both ziggurat_normal and bm_normal?</div><div dir="auto">Sure, I can cook up a BM transform myself (yet again) however. </div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.<br></div></div></blockquote><div><br></div><div>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?</div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">While I gave only anecdotal evidence, not hard data, I suspect that both cython and C API would be useful.</div><div dir="auto">E.g. there are c++ applications which use boost::random, would be nice to be able to swap it for numpy.random.</div><div dir="auto">Also reproducibility: it's *much* easier to debug the compiled app vs its python prototype if random streams are identical.</div><div dir="auto"><br></div><div dir="auto">Like I said, take all I'm saying with enough salt, as I'm wearing my user hat here.</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Evgeni</div></div>