Hi all, On Thu, Oct 29, 2009 at 12:43 PM, Pierre GM <[email protected]> wrote: > Oh yes, I saw that... Marty Fuhry, one of our GSoC students, had > written some pretty extensive series of tests to allocate datetime/ > strings to elements of a ndarray with datetime64 dtype. He also had > written some functions allowing conversion from one frequency to > another. Unfortunately, I don't think his work has been incorporated > yet. Maybe Jarrod M. and Travis O. will shed some light on that > matter. I for one would be quite interested into checking what's > happening on that front.
we're starting to use these tools more and more, and with the 1.4 release coming out, we're a bit lost here... A few specific questions we have: - It seems the original spec that was written by Francesc with a lot of community feedback, whose final form (updated by Travis recently) is: http://projects.scipy.org/numpy/browser/trunk/doc/neps/datetime-proposal.rst was implemented differently in the final committed code. Are the differences and rationale for this documented somewhere? I'm not saying the current code is a bad idea, simply that we'd like to understand the differences and why they came about, I'm sure there were good reasons behind it... - Are there any tests for the current code, that will go in before 1.4 is out? We'd like to know if we can rely on 1.4 as a dependency for nitime, but for that we'd like to know what the code can actually do, and also to have checks for what appear to be segfault problems: >>> s = np.zeros((10),dtype=np.timedelta64) >>> s array([0:00:00.000001, 0:00:00.000001, 0:00:00.000001, 0:00:00.000001, 0:00:00.000001, 0:00:00.000001, 0:00:00.000001, 0:00:00.000001, 0:00:00.000001, 0:00:00.000001], dtype=timedelta64[ns]) >>> s.dtype = 'timedelta64[s]' >>> s array([0:01:00, 0:01:00, 0:01:00, 0:01:00, 0:01:00, 0:01:00, 0:01:00, 0:01:00, 0:01:00, 0:01:00], dtype=timedelta64[s]) >>> s.dtype = 'timedelta64[m]' Segmentation fault - From our experimenting with the code it appears that the following code is not accepted: a = np.array([0.1, 0.5, 0.9, 1.4], dtype='some form of spelling seconds, nothing we've tried has worked') while it would appear to be a very natural way to use such an object: "here are a bunch of floats, treat them like seconds"... Is there a reason for this? This variant appears to work, but I'm not sure why the need for the nested array call: In [22]: a = np.array([0,0.1,0.5, 1.5]); a Out[22]: array([ 0. , 0.1, 0.5, 1.5]) In [23]: np.array(a, dtype='timedelta64[s]') Out[23]: array([0:00:00, 0:00:00, 0:00:00, 0:01:00], dtype=timedelta64[s]) and the input is not being interpreted in seconds as one would intuitively think, instead there's a truncation I'm not sure I understand... - I know that the name numpy.datetime() was in the spec above (Francesc's NEP) but we're wondering if having this is a good idea... This is a name clash with a stdlib python name that has existed for a long time; while I know that we all advocate against 'from import *' for many good reasons, but at least I think that staying clear of known stdlib name conflicts would be a good practice. It will reduce the surprise factor for someone using numpy interactively, for example (ipython -pylab) in situations like: dateime.foo() # this is np.datetime %run foo.py # script with 'import datetime' in it # now datetime at the top level is the one in the stdlib... - Sources of information? Docstrings and tests haven't gotten us very far, and googling points to the original spec as udpated by Travis: http://projects.scipy.org/numpy/browser/trunk/doc/neps/datetime-proposal.rst But even the examples in that document don't actually work. All of these copied from the spec, and run with: In [7]: np.__version__ Out[7]: '1.4.0.dev7421' In [2]: t = numpy.ones(3, dtype='M8[s]') --------------------------------------------------------------------------- ValueError Traceback (most recent call last) /home/fperez/teach/code_review/<ipython console> in <module>() /usr/local/lib/python2.5/site-packages/numpy/core/numeric.pyc in ones(shape, dtype, order) 1656 a = empty(shape, dtype, order) 1657 try: -> 1658 a.fill(1) 1659 # Above is faster now after addition of fast loops. 1660 #a = zeros(shape, dtype, order) ValueError: Must be a datetime.date or datetime.datetime object In [5]: numpy.datetime64(42, 'us') --------------------------------------------------------------------------- TypeError Traceback (most recent call last) /home/fperez/teach/code_review/<ipython console> in <module>() TypeError: function takes at most 1 argument (2 given) In [6]: numpy.timedelta64(10, 'us') --------------------------------------------------------------------------- TypeError Traceback (most recent call last) /home/fperez/teach/code_review/<ipython console> in <module>() TypeError: function takes at most 1 argument (2 given) Thanks for any clarity on the status of this code... Sorry if we've missed the obvious, but we've honestly tried to find information and to understand this, and we're pretty lost. Any help will be appreciated. Cheers, f _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
