
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<PyArray_DatetimeDTypeMetaData *>(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<PyArrayObject*>(PyObject_CallMethod(rein > terp > re > t_ > ca > st > <PyObject*>(arr1), "astype", "(s)", "datetime64[ms]")); > std::swap(arr1, tmp); > Py_XDECREF(tmp); > // Ensure integer > tmp = > reinterpret_cast<PyArrayObject*>(PyObject_CallMethod(rein > terp > re > t_ > ca > st > <PyObject*>(arr1), "astype", "(s)", "i8")); > std::swap(arr1, tmp); > Py_XDECREF(tmp); > tmp = > reinterpret_cast<PyArrayObject*>(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-leave@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: sebastian@sipsolutions.net >
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: gschwind@gnu-log.net
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: gschwind@gnu-log.net
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: gschwind@gnu-log.net
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: gschwind@gnu-log.net
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: sebastian@sipsolutions.net