[Numpy-discussion] Handle type convertion in C API

2020-03-10 Thread Benoit Gschwind
Hello,

I writing a python binding of one of our library. The binding intend to
vectorize the function call. for exemple:

double foo(double, double) will be bound to a python:

 module.foo(, )

and the function foo will be called like :

for (int i = 0; i < size; ++i)
outarr[i] = foo(inarr0[i], inarr[1]);

My question is about how can I handle type conversion of input array,
preferably in efficient manner, given that each input array may require
different input type.

Currently I basically enforce the type and no type conversion is
performed. But I would like relax it. I thought of several possibility
starting from the obvious solution consisting on recasting in the inner
loop that would give:

for (int i = 0; i < size; ++i)
if (inarr[i] need recast)
in0 =
recast(inarr[i])
else
in0 = inarr[i]
[... same for all
inputs parameter ...]
outarr[i] = foo(in0, in1, ...);

This solution is memory efficient, but not actually computationally
efficient.

The second solution is to copy&recast the entire inputs arrays, but in
that case it's not memory efficient. And my final thought is to mix the
first and the second by chunking the second method, i.e. converting N
input in a raw, then applying the function to them en so on until all
the array is processed.

Thus my questions are:
 - there is another way to do what I want?
 - there is an existing or recommended way to do it?

And a side question, I use the PyArray_FROM_OTF, but I do not
understand well it's semantic. If I pass a python list, it is converted
to the desired type and requirement; when I pass a non-continuous array
it is converted to the continuous one; but when I pass a numpy array of
another type than the one specified I do not get the conversion. There
is a function that do the conversion unconditionally? Did I missed
something ?

Thank you by advance for your help

Best regards



___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] Handle type convertion in C API

2020-03-11 Thread Benoit Gschwind
Hello Eric,

Thank you for pointing out ufunc, I implemented my binding using it,
it's working and it's simpler than my previous implementation, but I
still not have the flexibility to dynamically recast input array, i.e.
using a int64 array as input for a int32. For instance for testing my
code I use numpy.random that provide int64 array, I have to convert the
array manually before calling my ufunc, which is somehow annoying.

For function that have 1 or 2 parameters it's practical to have 4
variant of the function, but in case of 6-8 parameters it's becoming
more difficult.

Best regards

Le mardi 10 mars 2020 à 13:13 -0400, Eric Moore a écrit :
> Hi Benoit, 
> 
> Since you have a function that takes two scalars to one scalar, it
> sounds to me as though you would be best off creating a ufunc.  This
> will then handle the conversion to and looping over the arrays, etc
> for you.  The documentation is available here: 
> https://numpy.org/doc/1.18/user/c-info.ufunc-tutorial.html.
> 
> Regards,
> 
> Eric
> 
> On Tue, Mar 10, 2020 at 12:28 PM Benoit Gschwind <
> gschw...@gnu-log.net> wrote:
> > Hello,
> > 
> > I writing a python binding of one of our library. The binding
> > intend to
> > vectorize the function call. for exemple:
> > 
> > double foo(double, double) will be bound to a python:
> > 
> >  module.foo(, )
> > 
> > and the function foo will be called like :
> > 
> > for (int i = 0; i < size; ++i)
> > outarr[i] = foo(inarr0[i], inarr[1]);
> > 
> > My question is about how can I handle type conversion of input
> > array,
> > preferably in efficient manner, given that each input array may
> > require
> > different input type.
> > 
> > Currently I basically enforce the type and no type conversion is
> > performed. But I would like relax it. I thought of several
> > possibility
> > starting from the obvious solution consisting on recasting in the
> > inner
> > loop that would give:
> > 
> > for (int i = 0; i < size; ++i)
> > if (inarr[i] need recast)
> > in0 =
> > recast(inarr[i])
> > else
> > in0 = inarr[i]
> > [... same for all
> > inputs parameter ...]
> > outarr[i] = foo(in0, in1, ...);
> > 
> > This solution is memory efficient, but not actually computationally
> > efficient.
> > 
> > The second solution is to copy&recast the entire inputs arrays, but
> > in
> > that case it's not memory efficient. And my final thought is to mix
> > the
> > first and the second by chunking the second method, i.e. converting
> > N
> > input in a raw, then applying the function to them en so on until
> > all
> > the array is processed.
> > 
> > Thus my questions are:
> >  - there is another way to do what I want?
> >  - there is an existing or recommended way to do it?
> > 
> > And a side question, I use the PyArray_FROM_OTF, but I do not
> > understand well it's semantic. If I pass a python list, it is
> > converted
> > to the desired type and requirement; when I pass a non-continuous
> > array
> > it is converted to the continuous one; but when I pass a numpy
> > array of
> > another type than the one specified I do not get the conversion.
> > There
> > is a function that do the conversion unconditionally? Did I missed
> > something ?
> > 
> > Thank you by advance for your help
> > 
> > Best regards
> > 
> > 
> > 
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] advice for using datetime64 in C binding

2022-01-18 Thread Benoit Gschwind
Hello,

I using the following code:

if (PyArray_TYPE(arr1) == NPY_DATETIME) {
// Ensure datetime64[ms]
auto tmp = 
reinterpret_cast(PyObject_CallMethod(reinterpret_cast(arr1),
 "astype", "(s)", "datetime64[ms]"));
std::swap(arr1, tmp);
Py_XDECREF(tmp);
// Ensure integer
tmp = 
reinterpret_cast(PyObject_CallMethod(reinterpret_cast(arr1),
 "astype", "(s)", "i8"));
std::swap(arr1, tmp);
Py_XDECREF(tmp);
tmp = reinterpret_cast(PyArray_FromArray(arr1, 
PyArray_DescrFromType(NPY_INT64), NPY_ARRAY_IN_ARRAY));
std::swap(arr1, tmp);
Py_XDECREF(tmp);
}

First, if something is wrong with my code let me known. Then I wonder
if I can have a safe shortcut to avoid converting datetime64 to i8. I
guess the internal data of datetime64[ms] is i8 thus copying and
casting the array may be avoided.

Thanks by advance
Best regards.


___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com


[Numpy-discussion] Re: advice for using datetime64 in C binding

2022-01-18 Thread Benoit Gschwind
Hello Sebastian,

Thanks for detail.

The last call has the NPY_ARRAY_C_CONTIGUOUS and NPY_ARRAY_ALIGNED,
thus I guess it can be no-op most of the time but for some unknown case
it's may be safer ?

Best regards

On Tue, 2022-01-18 at 09:22 -0600, Sebastian Berg wrote:
> On Tue, 2022-01-18 at 14:56 +0100, Benoit Gschwind wrote:
> > Hello,
> > 
> > I using the following code:
> > 
> > if (PyArray_TYPE(arr1) == NPY_DATETIME) {
> > // Ensure datetime64[ms]
> > auto tmp =
> > reinterpret_cast(PyObject_CallMethod(reinterpret_ca
> > st
> > (arr1), "astype", "(s)", "datetime64[ms]"));
> > std::swap(arr1, tmp);
> > Py_XDECREF(tmp);
> > // Ensure integer
> > tmp =
> > reinterpret_cast(PyObject_CallMethod(reinterpret_ca
> > st
> > (arr1), "astype", "(s)", "i8"));
> > std::swap(arr1, tmp);
> > Py_XDECREF(tmp);
> > tmp =
> > reinterpret_cast(PyArray_FromArray(arr1,
> > PyArray_DescrFromType(NPY_INT64), NPY_ARRAY_IN_ARRAY));
> > std::swap(arr1, tmp);
> > Py_XDECREF(tmp);
> > }
> > 
> > First, if something is wrong with my code let me known. Then I
> > wonder
> > if I can have a safe shortcut to avoid converting datetime64 to i8.
> > I
> > guess the internal data of datetime64[ms] is i8 thus copying and
> > casting the array may be avoided.
> 
> Yes, you can assume datetime64 is stored as an i8 with the unit and
> possible byteswapping.  Both of which, your initial cast will ensure.
> 
> The internal data is i8, except for the special NaT value.
> 
> Code-wise, you can avoid calling `astype`, but if you do (also in
> python), I suggest to pass `copy=False`, so that it does not copy if
> it
> clearly is not necessary (I am hoping to improve on the "clearly"
> here
> at some point).
> 
> The last call again seems to be a no-op?  Just the last call with the
> correct `datetime64[ms]` descriptor could be enough.
> 
> Cheers,
> 
> Sebastian
>  
> 
> > 
> > Thanks by advance
> > Best regards.
> > 
> > 
> > ___
> > NumPy-Discussion mailing list -- numpy-discussion@python.org
> > To unsubscribe send an email to numpy-discussion-le...@python.org
> > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > Member address: sebast...@sipsolutions.net
> > 
> 
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: gschw...@gnu-log.net


___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com


[Numpy-discussion] Re: advice for using datetime64 in C binding

2022-01-19 Thread Benoit Gschwind
Hello Sebastian,

Thanks for the precision 

Best regards

On Tue, 2022-01-18 at 11:52 -0600, Sebastian Berg wrote:
> On Tue, 2022-01-18 at 18:29 +0100, Benoit Gschwind wrote:
> > Hello Sebastian,
> > 
> > Thanks for detail.
> > 
> > The last call has the NPY_ARRAY_C_CONTIGUOUS and NPY_ARRAY_ALIGNED,
> > thus I guess it can be no-op most of the time but for some unknown
> > case
> > it's may be safer ?
> 
> Ah, yes, you are right, and it should indeed by very quick, anyway. 
> My
> guess is, that you can do _only_ the last call with the appropriate
> `datetime64[ms]` descriptor passed in.
> (Since whatever C-code that follows is allowed to work with
> datetime64
> as if it were int64.)
> 
> Cheers,
> 
> Sebastian
> 
> 
> > 
> > Best regards
> > 
> > On Tue, 2022-01-18 at 09:22 -0600, Sebastian Berg wrote:
> > > On Tue, 2022-01-18 at 14:56 +0100, Benoit Gschwind wrote:
> > > > Hello,
> > > > 
> > > > I using the following code:
> > > > 
> > > > if (PyArray_TYPE(arr1) == NPY_DATETIME) {
> > > > // Ensure datetime64[ms]
> > > > auto tmp =
> > > > reinterpret_cast(PyObject_CallMethod(reinterpre
> > > > t_
> > > > ca
> > > > st
> > > > (arr1), "astype", "(s)", "datetime64[ms]"));
> > > > std::swap(arr1, tmp);
> > > > Py_XDECREF(tmp);
> > > > // Ensure integer
> > > > tmp =
> > > > reinterpret_cast(PyObject_CallMethod(reinterpre
> > > > t_
> > > > ca
> > > > st
> > > > (arr1), "astype", "(s)", "i8"));
> > > > std::swap(arr1, tmp);
> > > > Py_XDECREF(tmp);
> > > > tmp =
> > > > reinterpret_cast(PyArray_FromArray(arr1,
> > > > PyArray_DescrFromType(NPY_INT64), NPY_ARRAY_IN_ARRAY));
> > > > std::swap(arr1, tmp);
> > > > Py_XDECREF(tmp);
> > > > }
> > > > 
> > > > First, if something is wrong with my code let me known. Then I
> > > > wonder
> > > > if I can have a safe shortcut to avoid converting datetime64 to
> > > > i8.
> > > > I
> > > > guess the internal data of datetime64[ms] is i8 thus copying
> > > > and
> > > > casting the array may be avoided.
> > > 
> > > Yes, you can assume datetime64 is stored as an i8 with the unit
> > > and
> > > possible byteswapping.  Both of which, your initial cast will
> > > ensure.
> > > 
> > > The internal data is i8, except for the special NaT value.
> > > 
> > > Code-wise, you can avoid calling `astype`, but if you do (also in
> > > python), I suggest to pass `copy=False`, so that it does not copy
> > > if
> > > it
> > > clearly is not necessary (I am hoping to improve on the "clearly"
> > > here
> > > at some point).
> > > 
> > > The last call again seems to be a no-op?  Just the last call with
> > > the
> > > correct `datetime64[ms]` descriptor could be enough.
> > > 
> > > Cheers,
> > > 
> > > Sebastian
> > >  
> > > 
> > > > 
> > > > Thanks by advance
> > > > Best regards.
> > > > 
> > > > 
> > > > ___
> > > > NumPy-Discussion mailing list -- numpy-discussion@python.org
> > > > To unsubscribe send an email to
> > > > numpy-discussion-le...@python.org
> > > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > > > Member address: sebast...@sipsolutions.net
> > > > 
> > > 
> > > ___
> > > NumPy-Discussion mailing list -- numpy-discussion@python.org
> > > To unsubscribe send an email to numpy-discussion-le...@python.org
> > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > > Member address: gschw...@gnu-log.net
> > 
> > 
> > ___
> > NumPy-Discussion mailing list -- numpy-discussion@python.org
> > To unsubscribe send an email to numpy-discussion-le...@python.org
> > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > Member address: sebast...@sipsolutions.net
> 
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: gschw...@gnu-log.net


___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com


[Numpy-discussion] Re: advice for using datetime64 in C binding

2022-01-20 Thread Benoit Gschwind
Hello,

How can I create np.dtype("datetime64[ms]") in C to get the
coresponding PyArray_Descr ?

Thank you by advance

On Wed, 2022-01-19 at 10:08 +0100, Benoit Gschwind wrote:
> Hello Sebastian,
> 
> Thanks for the precision 
> 
> Best regards
> 
> On Tue, 2022-01-18 at 11:52 -0600, Sebastian Berg wrote:
> > On Tue, 2022-01-18 at 18:29 +0100, Benoit Gschwind wrote:
> > > Hello Sebastian,
> > > 
> > > Thanks for detail.
> > > 
> > > The last call has the NPY_ARRAY_C_CONTIGUOUS and
> > > NPY_ARRAY_ALIGNED,
> > > thus I guess it can be no-op most of the time but for some
> > > unknown
> > > case
> > > it's may be safer ?
> > 
> > Ah, yes, you are right, and it should indeed by very quick,
> > anyway. 
> > My
> > guess is, that you can do _only_ the last call with the appropriate
> > `datetime64[ms]` descriptor passed in.
> > (Since whatever C-code that follows is allowed to work with
> > datetime64
> > as if it were int64.)
> > 
> > Cheers,
> > 
> > Sebastian
> > 
> > 
> > > 
> > > Best regards
> > > 
> > > On Tue, 2022-01-18 at 09:22 -0600, Sebastian Berg wrote:
> > > > On Tue, 2022-01-18 at 14:56 +0100, Benoit Gschwind wrote:
> > > > > Hello,
> > > > > 
> > > > > I using the following code:
> > > > > 
> > > > > if (PyArray_TYPE(arr1) == NPY_DATETIME) {
> > > > > // Ensure datetime64[ms]
> > > > > auto tmp =
> > > > > reinterpret_cast(PyObject_CallMethod(reinterp
> > > > > re
> > > > > t_
> > > > > ca
> > > > > st
> > > > > (arr1), "astype", "(s)", "datetime64[ms]"));
> > > > > std::swap(arr1, tmp);
> > > > > Py_XDECREF(tmp);
> > > > > // Ensure integer
> > > > > tmp =
> > > > > reinterpret_cast(PyObject_CallMethod(reinterp
> > > > > re
> > > > > t_
> > > > > ca
> > > > > st
> > > > > (arr1), "astype", "(s)", "i8"));
> > > > > std::swap(arr1, tmp);
> > > > > Py_XDECREF(tmp);
> > > > > tmp =
> > > > > reinterpret_cast(PyArray_FromArray(arr1,
> > > > > PyArray_DescrFromType(NPY_INT64), NPY_ARRAY_IN_ARRAY));
> > > > > std::swap(arr1, tmp);
> > > > > Py_XDECREF(tmp);
> > > > > }
> > > > > 
> > > > > First, if something is wrong with my code let me known. Then
> > > > > I
> > > > > wonder
> > > > > if I can have a safe shortcut to avoid converting datetime64
> > > > > to
> > > > > i8.
> > > > > I
> > > > > guess the internal data of datetime64[ms] is i8 thus copying
> > > > > and
> > > > > casting the array may be avoided.
> > > > 
> > > > Yes, you can assume datetime64 is stored as an i8 with the unit
> > > > and
> > > > possible byteswapping.  Both of which, your initial cast will
> > > > ensure.
> > > > 
> > > > The internal data is i8, except for the special NaT value.
> > > > 
> > > > Code-wise, you can avoid calling `astype`, but if you do (also
> > > > in
> > > > python), I suggest to pass `copy=False`, so that it does not
> > > > copy
> > > > if
> > > > it
> > > > clearly is not necessary (I am hoping to improve on the
> > > > "clearly"
> > > > here
> > > > at some point).
> > > > 
> > > > The last call again seems to be a no-op?  Just the last call
> > > > with
> > > > the
> > > > correct `datetime64[ms]` descriptor could be enough.
> > > > 
> > > > Cheers,
> > > > 
> > > > Sebastian
> > > >  
> > > > 
> > > > > 
> > > > > Thanks by advance
> > > > > Best regards.
> > > > > 
> > > > > 
> > > > > ___
> > > > > NumPy-Discussion mailing list -- numpy-discussion@python.org
> > > > > To unsubscribe send an email to
> > > 

[Numpy-discussion] Re: advice for using datetime64 in C binding

2022-02-18 Thread Benoit Gschwind
Hello,

I found my ankser in own code ^^

static PyArray_Descr * create_datetime64_ms_dtype()
{
// Extrapolated from numpy sources
PyArray_Descr * dtype = PyArray_DescrFromType(NPY_DATETIME);
reinterpret_cast(dtype->c_metadata)->meta.base = NPY_FR_ms;
return dtype;
}



On Thu, 2022-01-20 at 09:20 +0100, Benoit Gschwind wrote:
> Hello,
> 
> How can I create np.dtype("datetime64[ms]") in C to get the
> coresponding PyArray_Descr ?
> 
> Thank you by advance
> 
> On Wed, 2022-01-19 at 10:08 +0100, Benoit Gschwind wrote:
> > Hello Sebastian,
> > 
> > Thanks for the precision 
> > 
> > Best regards
> > 
> > On Tue, 2022-01-18 at 11:52 -0600, Sebastian Berg wrote:
> > > On Tue, 2022-01-18 at 18:29 +0100, Benoit Gschwind wrote:
> > > > Hello Sebastian,
> > > > 
> > > > Thanks for detail.
> > > > 
> > > > The last call has the NPY_ARRAY_C_CONTIGUOUS and
> > > > NPY_ARRAY_ALIGNED,
> > > > thus I guess it can be no-op most of the time but for some
> > > > unknown
> > > > case
> > > > it's may be safer ?
> > > 
> > > Ah, yes, you are right, and it should indeed by very quick,
> > > anyway. 
> > > My
> > > guess is, that you can do _only_ the last call with the appropriate
> > > `datetime64[ms]` descriptor passed in.
> > > (Since whatever C-code that follows is allowed to work with
> > > datetime64
> > > as if it were int64.)
> > > 
> > > Cheers,
> > > 
> > > Sebastian
> > > 
> > > 
> > > > 
> > > > Best regards
> > > > 
> > > > On Tue, 2022-01-18 at 09:22 -0600, Sebastian Berg wrote:
> > > > > On Tue, 2022-01-18 at 14:56 +0100, Benoit Gschwind wrote:
> > > > > > Hello,
> > > > > > 
> > > > > > I using the following code:
> > > > > > 
> > > > > > if (PyArray_TYPE(arr1) == NPY_DATETIME) {
> > > > > > // Ensure datetime64[ms]
> > > > > > auto tmp =
> > > > > > reinterpret_cast(PyObject_CallMethod(reinterp
> > > > > > re
> > > > > > t_
> > > > > > ca
> > > > > > st
> > > > > > (arr1), "astype", "(s)", "datetime64[ms]"));
> > > > > > std::swap(arr1, tmp);
> > > > > > Py_XDECREF(tmp);
> > > > > > // Ensure integer
> > > > > > tmp =
> > > > > > reinterpret_cast(PyObject_CallMethod(reinterp
> > > > > > re
> > > > > > t_
> > > > > > ca
> > > > > > st
> > > > > > (arr1), "astype", "(s)", "i8"));
> > > > > > std::swap(arr1, tmp);
> > > > > > Py_XDECREF(tmp);
> > > > > > tmp =
> > > > > > reinterpret_cast(PyArray_FromArray(arr1,
> > > > > > PyArray_DescrFromType(NPY_INT64), NPY_ARRAY_IN_ARRAY));
> > > > > > std::swap(arr1, tmp);
> > > > > > Py_XDECREF(tmp);
> > > > > > }
> > > > > > 
> > > > > > First, if something is wrong with my code let me known. Then
> > > > > > I
> > > > > > wonder
> > > > > > if I can have a safe shortcut to avoid converting datetime64
> > > > > > to
> > > > > > i8.
> > > > > > I
> > > > > > guess the internal data of datetime64[ms] is i8 thus copying
> > > > > > and
> > > > > > casting the array may be avoided.
> > > > > 
> > > > > Yes, you can assume datetime64 is stored as an i8 with the unit
> > > > > and
> > > > > possible byteswapping.  Both of which, your initial cast will
> > > > > ensure.
> > > > > 
> > > > > The internal data is i8, except for the special NaT value.
> > > > > 
> > > > > Code-wise, you can avoid calling `astype`, but if you do (also
> > > > > in
> > > > > python), I suggest to pass `copy=False`, so that it does not
> > > > > copy
> > > > > if
> > > > > it
> > > > > clearly is not necessary (I am hoping to improve on the
>

[Numpy-discussion] Re: advice for using datetime64 in C binding

2022-02-18 Thread Benoit Gschwind

Thank you for fixing my code ! :)

On Fri, 2022-02-18 at 09:00 -0600, Sebastian Berg wrote:
> On Fri, 2022-02-18 at 15:53 +0100, Benoit Gschwind wrote:
> > Hello,
> > 
> > I found my ankser in own code ^^
> > 
> > static PyArray_Descr * create_datetime64_ms_dtype()
> > {
> > // Extrapolated from numpy sources
> > PyArray_Descr * dtype =
> > PyArray_DescrFromType(NPY_DATETIME);
> > reinterpret_cast(dtype-
> > > c_metadata)->meta.base = NPY_FR_ms;
> > return dtype;
> > }
> > 
> 
> Oh sorry, yeah, I guess that works, I am not sure we have anything
> better in NumPy.
> 
> The code itself is wrong though, you must make use of
> `PyArray_DescrNewFromType`:  *never* mutate the result returned by
> `PyArray_DescrFromType`.
> 
> After replacing, you should also check for `dtype == NULL` since
> errors
> could happen (not that it is relevant in practice, it only fails if
> Python fails to allocate that small descriptor object).
> 
> Cheers,
> 
> Sebastian
> 
> 
> > 
> > 
> > On Thu, 2022-01-20 at 09:20 +0100, Benoit Gschwind wrote:
> > > Hello,
> > > 
> > > How can I create np.dtype("datetime64[ms]") in C to get the
> > > coresponding PyArray_Descr ?
> > > 
> > > Thank you by advance
> > > 
> > > On Wed, 2022-01-19 at 10:08 +0100, Benoit Gschwind wrote:
> > > > Hello Sebastian,
> > > > 
> > > > Thanks for the precision 
> > > > 
> > > > Best regards
> > > > 
> > > > On Tue, 2022-01-18 at 11:52 -0600, Sebastian Berg wrote:
> > > > > On Tue, 2022-01-18 at 18:29 +0100, Benoit Gschwind wrote:
> > > > > > Hello Sebastian,
> > > > > > 
> > > > > > Thanks for detail.
> > > > > > 
> > > > > > The last call has the NPY_ARRAY_C_CONTIGUOUS and
> > > > > > NPY_ARRAY_ALIGNED,
> > > > > > thus I guess it can be no-op most of the time but for some
> > > > > > unknown
> > > > > > case
> > > > > > it's may be safer ?
> > > > > 
> > > > > Ah, yes, you are right, and it should indeed by very quick,
> > > > > anyway. 
> > > > > My
> > > > > guess is, that you can do _only_ the last call with the
> > > > > appropriate
> > > > > `datetime64[ms]` descriptor passed in.
> > > > > (Since whatever C-code that follows is allowed to work with
> > > > > datetime64
> > > > > as if it were int64.)
> > > > > 
> > > > > Cheers,
> > > > > 
> > > > > Sebastian
> > > > > 
> > > > > 
> > > > > > 
> > > > > > Best regards
> > > > > > 
> > > > > > On Tue, 2022-01-18 at 09:22 -0600, Sebastian Berg wrote:
> > > > > > > On Tue, 2022-01-18 at 14:56 +0100, Benoit Gschwind wrote:
> > > > > > > > Hello,
> > > > > > > > 
> > > > > > > > I using the following code:
> > > > > > > > 
> > > > > > > > if (PyArray_TYPE(arr1) == NPY_DATETIME) {
> > > > > > > > // Ensure datetime64[ms]
> > > > > > > > auto tmp =
> > > > > > > > reinterpret_cast(PyObject_CallMethod(re
> > > > > > > > in
> > > > > > > > terp
> > > > > > > > re
> > > > > > > > t_
> > > > > > > > ca
> > > > > > > > st
> > > > > > > > (arr1), "astype", "(s)", "datetime64[ms]"));
> > > > > > > > std::swap(arr1, tmp);
> > > > > > > > Py_XDECREF(tmp);
> > > > > > > > // Ensure integer
> > > > > > > > tmp =
> > > > > > > > reinterpret_cast(PyObject_CallMethod(re
> > > > > > > > in
> > > > > > > > terp
> > > > > > > > re
> > > > > > > > t_
> > > > > > > > ca
> > > > > > > > st
> > > > > > > > (arr1), "astype", "(s)", "i8"));
> > > > > > > > std::swap(arr1,