>
> I'd like to clarify what exactly we mean by exposing a C API. Do we have
> in mind that our random number generators can be used from standalone C
> code, or via Cython `cimport` like with the current numpy.pxd?
>
> It sounds like we want to expose the highest level generators; do we also
> wa
On Wed, Sep 25, 2019, 12:56 PM Stefan van der Walt
wrote:
> On Fri, Sep 20, 2019, at 21:30, Robert Kern wrote:
>
> Given the prevalence of Cython, it's actually really easy to use the
> Python API pretty easily in "C", so it's actually a huge waste if the C API
> matches the Python API too closel
On Fri, Sep 20, 2019, at 21:30, Robert Kern wrote:
> Given the prevalence of Cython, it's actually really easy to use the Python
> API pretty easily in "C", so it's actually a huge waste if the C API matches
> the Python API too closely. The power and utility of the C API will be in how
> it *di
On Fri, Sep 20, 2019 at 9:31 PM Robert Kern wrote:
> On Fri, Sep 20, 2019 at 11:33 PM Ralf Gommers
> wrote:
>
>>
>>
>> On Fri, Sep 20, 2019 at 7:09 AM Robert Kern
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 20, 2019 at 6:09 AM Ralf Gommers
>>> wrote:
>>>
On Fri, Sep 20, 2019 at 5:29 AM
On Fri, Sep 20, 2019 at 11:33 PM Ralf Gommers
wrote:
>
>
> On Fri, Sep 20, 2019 at 7:09 AM Robert Kern wrote:
>
>>
>>
>> On Fri, Sep 20, 2019 at 6:09 AM Ralf Gommers
>> wrote:
>>
>>>
>>>
>>> On Fri, Sep 20, 2019 at 5:29 AM Robert Kern
>>> wrote:
>>>
We might end up with more than 2 i
On Fri, Sep 20, 2019 at 7:09 AM Robert Kern wrote:
>
>
> On Fri, Sep 20, 2019 at 6:09 AM Ralf Gommers
> wrote:
>
>>
>>
>> On Fri, Sep 20, 2019 at 5:29 AM Robert Kern
>> wrote:
>>
>>>
>>> We might end up with more than 2 implementations if we need to change
>>> something about the function signa
On Fri, Sep 20, 2019 at 6:09 AM Ralf Gommers wrote:
>
>
> On Fri, Sep 20, 2019 at 5:29 AM Robert Kern wrote:
>
>>
>> We might end up with more than 2 implementations if we need to change
>> something about the function signature, for whatever reason, and we want to
>> retain C/Cython API compati
I'm using the low-level generator. In this example I need to generate
small random integers of defined bit widths (e.g., 2 bit). So
I get 64-bit uniform random uintegers, and cache the values, returning
them n-bits (e.g. 2 bits) at a time to the caller.
On Fri, Sep 20, 2019 at 9:03 AM Matti Picu
On 20/9/19 2:18 pm, Neal Becker wrote:
I have used C-api in the past, and would like to see a convenient and
stable way to do this. Currently I'm using randomgen, but calling
(from c++)
to the python api. The inefficiency is amortized by generating and
caching batches of results.
I thought ran
I have used C-api in the past, and would like to see a convenient and
stable way to do this. Currently I'm using randomgen, but calling
(from c++)
to the python api. The inefficiency is amortized by generating and
caching batches of results.
I thought randomgen was supposed to be the future of n
On Fri, Sep 20, 2019 at 5:29 AM Robert Kern wrote:
> On Thu, Sep 19, 2019 at 11:04 PM Ralf Gommers
> wrote:
>
>>
>>
>> On Thu, Sep 19, 2019 at 4:53 PM Robert Kern
>> wrote:
>>
>>> On Thu, Sep 19, 2019 at 5:24 AM Ralf Gommers
>>> wrote:
>>>
On Thu, Sep 19, 2019 at 10:28 AM Kevin Shepp
On 20/9/19 6:25 am, Robert Kern wrote:
Well, we must because one's used by the legacy RandomState and one's
used by Generator. :-)
I would prefer not to create a legacy C-API at all. Are we required to
from the NEP?
Matti
___
NumPy-Discussio
On Thu, Sep 19, 2019 at 11:04 PM Ralf Gommers
wrote:
>
>
> On Thu, Sep 19, 2019 at 4:53 PM Robert Kern wrote:
>
>> On Thu, Sep 19, 2019 at 5:24 AM Ralf Gommers
>> wrote:
>>
>>>
>>> On Thu, Sep 19, 2019 at 10:28 AM Kevin Sheppard <
>>> kevin.k.shepp...@gmail.com> wrote:
>>>
There are some u
On Thu, Sep 19, 2019 at 4:53 PM Robert Kern wrote:
> On Thu, Sep 19, 2019 at 5:24 AM Ralf Gommers
> wrote:
>
>>
>> On Thu, Sep 19, 2019 at 10:28 AM Kevin Sheppard <
>> kevin.k.shepp...@gmail.com> wrote:
>>
>>> There are some users of the NumPy C code in randomkit. This was never
>>> officially
Just to chime in: Numba would definitely appreciate C functions to access
the random distribution implementations, and have a side-project
(numba-scipy) that is making the Cython wrapped functions in SciPy visible
to Numba.
On Thu, Sep 19, 2019 at 5:41 AM Kevin Sheppard
wrote:
>
>
> On Thu, Sep
On Thu, Sep 19, 2019 at 5:24 AM Ralf Gommers wrote:
>
> On Thu, Sep 19, 2019 at 10:28 AM Kevin Sheppard <
> kevin.k.shepp...@gmail.com> wrote:
>
>> There are some users of the NumPy C code in randomkit. This was never
>> officially supported. There has been a long open issue to provide this
>>
>>
>>
>> 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
On Thu, Sep 19, 2019 at 10:23 AM Ralf Gommers
wrote:
>
>
> On Thu, Sep 19, 2019 at 10:28 AM Kevin Sheppard <
> kevin.k.shepp...@gmail.com> wrote:
>
>> There are some users of the NumPy C code in randomkit. This was never
>> officially supported. There has been a long open issue to provide this
On Thu, Sep 19, 2019 at 10:28 AM Kevin Sheppard
wrote:
> There are some users of the NumPy C code in randomkit. This was never
> officially supported. There has been a long open issue to provide this
> officially.
>
> When I wrote randomgen I supplied .pdx files that make it simpler to write
>
There are some users of the NumPy C code in randomkit. This was never
officially supported. There has been a long open issue to provide this
officially.
When I wrote randomgen I supplied .pdx files that make it simpler to write
Cython code that uses the components. The lower-level API has not h
20 matches
Mail list logo
