On Wed, Jun 15, 2011 at 5:16 PM, Derek Homeier < [email protected]> wrote:
> On 15.06.2011, at 1:34AM, Mark Wiebe wrote: > > > These functions are now fully implemented and documented. As always, code > reviews are welcome here: > > > > https://github.com/numpy/numpy/pull/87 > > > > and for those that don't want to dig into review C code, the commit for > the documentation is here: > > > > > https://github.com/m-paradox/numpy/commit/6b5a42a777b16812e774193b06da1b68b92bc689 > > > > This is probably also another good place to do a merge to master, so if > people could test it on Mac/Windows/other platforms that would be much > appreciated. > > > Probaby not specifically related to the business day, but to this month's > general datetime fix-up, > under Python3 there are a number of test failures of the kinds quoted > below. > You can review a fix (plus a number of additional test extensions and > proposed fix for other > failures on master) at > https://github.com/dhomeier/numpy/compare/master...dt_tests_2to3 Thanks for the testing and proposed fixes, I've added some comments to the commits. > Plus on Mac OS X 10.5 PPC there is a failure due to the fact that the new > datetime64 appears > to _always_ return 0 for the year part on this architecture: > > >>> date='1970-03-23 20:00:00Z' > >>> np.datetime64(date) > np.datetime64('0000-03-23T21:00:00+0100','s') > >>> np.datetime64(date, 'Y') > np.datetime64('0000','Y') > >>> np.datetime64('2011-06-16 02:03:04Z', 'D') > np.datetime64('0000-06-16','D') > > I've tried to track this down in datetime.c, but unsuccessfully so (i.e. I > could not connect it > to any of the dts->year assignments therein). > This is definitely perplexing. Probably the first thing to check is whether it's breaking during parsing or printing. This should always produce the same result: >>> np.datetime64('1970-03-23 20:00:00Z').astype('i8') 7070400 But maybe the test_days_creation is already checking that thoroughly enough. Then, maybe printf-ing the year value at various stages of the printing, like in set_datetimestruct_days, after convert_datetime_to_datetimestruct, and in make_iso_8601_date. This would at least isolate where the year is getting lost. For the record, all tests pass with Python2.5-2.7 on OS X 10.5/10.6 i386 and > x86_64. > Great! Cheers, Mark > Cheers, > Derek > > > FAIL: test_datetime_as_string (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/Users/derek/lib/python3.2/site-packages/numpy/core/tests/test_datetime.py", > line 970, in test_datetime_as_string > '1959') > File "/Users/derek/lib/python3.2/site-packages/numpy/testing/utils.py", > line 313, in assert_equal > raise AssertionError(msg) > AssertionError: > Items are not equal: > ACTUAL: b'0000' > DESIRED: '1959' > > ====================================================================== > FAIL: test_days_creation (test_datetime.TestDateTime) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File > "/Users/derek/lib/python3.2/site-packages/numpy/core/tests/test_datetime.py", > line 287, in test_days_creation > (1900-1970)*365 - (1970-1900)/4) > File "/Users/derek/lib/python3.2/site-packages/numpy/testing/utils.py", > line 256, in assert_equal > return assert_array_equal(actual, desired, err_msg, verbose) > File "/Users/derek/lib/python3.2/site-packages/numpy/testing/utils.py", > line 706, in assert_array_equal > verbose=verbose, header='Arrays are not equal') > File "/Users/derek/lib/python3.2/site-packages/numpy/testing/utils.py", > line 635, in assert_array_compare > raise AssertionError(msg) > AssertionError: > Arrays are not equal > > (mismatch 100.0%) > x: array(-25567, dtype='int64') > y: array(-25567.5) > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
