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/6b5a42a777b16812e774193b06da1b68b9...
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.
Thanks, Mark
On Fri, Jun 10, 2011 at 5:49 PM, Mark Wiebe mwwiebe@gmail.com wrote:
I've implemented the busday_offset function with support for the weekmask and roll parameters, the commits are tagged 'datetime-bday' in the pull request here:
https://github.com/numpy/numpy/pull/87
-Mark
On Thu, Jun 9, 2011 at 5:23 PM, Mark Wiebe mwwiebe@gmail.com wrote:
Here's a possible design for a business day API for numpy datetimes:
The 'B' business day unit will be removed. All business day-related calculations will be done using the 'D' day unit.
A class *BusinessDayDef* to encapsulate the definition of the business week and holidays. The business day functions will either take one of these objects, or separate weekmask and holidays parameters, to specify the business day definition. This class serves as both a performance optimization and a way to encapsulate the weekmask and holidays together, for example if you want to make a dictionary mapping exchange names to their trading days definition.
The weekmask can be specified in a number of ways, and internally becomes a boolean array with 7 elements with True for the days Monday through Sunday which are valid business days. Some different notations are for the 5-day week include [1,1,1,1,1,0,0], "1111100" "MonTueWedThuFri". The holidays are always specified as a one-dimensional array of dtype 'M8[D]', and are internally used in sorted form.
A function *is_busday*(datearray, weekmask=, holidays=, busdaydef=) returns a boolean array matching the input datearray, with True for the valid business days.
A function *busday_offset*(datearray, offsetarray, roll='raise', weekmask=, holidays=, busdaydef=) which first applies the 'roll' policy to start at a valid business date, then offsets the date by the number of business days specified in offsetarray. The arrays datearray and offsetarray are broadcast together. The 'roll' parameter can be 'forward'/'following', 'backward'/'preceding', 'modifiedfollowing', 'modifiedpreceding', or 'raise' (the default).
A function *busday_count*(datearray1, datearray2, weekmask=, holidays=, busdaydef=) which calculates the number of business days between datearray1 and datearray2, not including the day of datearray2.
For example, to find the first Monday in Feb 2011,
np.busday_offset('2011-02', 0, roll='forward', weekmask='Mon')
or to find the number of weekdays in Feb 2011,
np.busday_count('2011-02', '2011-03')
This set of three functions appears to be powerful enough to express the business-day computations that I've been shown thus far.
Cheers, Mark
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/6b5a42a777b16812e774193b06da1b68b9...
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
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).
For the record, all tests pass with Python2.5-2.7 on OS X 10.5/10.6 i386 and x86_64.
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)
On Wed, Jun 15, 2011 at 5:16 PM, Derek Homeier < derek@astro.physik.uni-goettingen.de> 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/6b5a42a777b16812e774193b06da1b68b9...
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 NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi Mark,
On 16.06.2011, at 5:40PM, Mark Wiebe wrote:
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.
ok, that was a lengthy hunt, but it's in printing the string in make_iso_8601_date:
tmplen = snprintf(substr, sublen, "%04" NPY_INT64_FMT, dts->year); fprintf(stderr, "printed %d[%d]: dts->year=%lld: %s\n", tmplen, sublen, dts->year, substr);
produces
np.datetime64('1970-03-23 20:00:00Z', 'D')
printed 4[62]: dts->year=1970: 0000 numpy.datetime64('0000-03-23','D')
It seems snprintf is not using the correct format for INT64 (as I happened to do in fprintf before realising I had to use "%lld" ;-) - could it be this is a general issue, which just does not show up on little-endian machines because they happen to pass the right half of the int64 to printf? BTW, how is this supposed to be handled (in 4 digits) if the year is indeed beyond the 32bit range (i.e. >~ 0.3 Hubble times...)? Just wondering if one could simply cast it to int32 before print.
Cheers, Derek
On Thu, Jun 16, 2011 at 5:52 PM, Derek Homeier < derek@astro.physik.uni-goettingen.de> wrote:
Hi Mark,
On 16.06.2011, at 5:40PM, Mark Wiebe wrote:
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.
ok, that was a lengthy hunt, but it's in printing the string in make_iso_8601_date:
tmplen = snprintf(substr, sublen, "%04" NPY_INT64_FMT, dts->year); fprintf(stderr, "printed %d[%d]: dts->year=%lld: %s\n", tmplen, sublen, dts->year, substr);
produces
np.datetime64('1970-03-23 20:00:00Z', 'D')
printed 4[62]: dts->year=1970: 0000 numpy.datetime64('0000-03-23','D')
It seems snprintf is not using the correct format for INT64 (as I happened to do in fprintf before realising I had to use "%lld" ;-) - could it be this is a general issue, which just does not show up on little-endian machines because they happen to pass the right half of the int64 to printf? BTW, how is this supposed to be handled (in 4 digits) if the year is indeed beyond the 32bit range (i.e. >~ 0.3 Hubble times...)? Just wondering if one could simply cast it to int32 before print.
I'd prefer to fix the NPY_INT64_FMT macro. There's no point in having it if it doesn't work... What is NumPy setting it to for that platform?
-Mark
Cheers, Derek
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 17.06.2011, at 2:02AM, Mark Wiebe wrote:
ok, that was a lengthy hunt, but it's in printing the string in make_iso_8601_date:
tmplen = snprintf(substr, sublen, "%04" NPY_INT64_FMT, dts->year); fprintf(stderr, "printed %d[%d]: dts->year=%lld: %s\n", tmplen, sublen, dts->year, substr);
produces
np.datetime64('1970-03-23 20:00:00Z', 'D')
printed 4[62]: dts->year=1970: 0000 numpy.datetime64('0000-03-23','D')
It seems snprintf is not using the correct format for INT64 (as I happened to do in fprintf before realising I had to use "%lld" ;-) - could it be this is a general issue, which just does not show up on little-endian machines because they happen to pass the right half of the int64 to printf? BTW, how is this supposed to be handled (in 4 digits) if the year is indeed beyond the 32bit range (i.e. >~ 0.3 Hubble times...)? Just wondering if one could simply cast it to int32 before print.
I'd prefer to fix the NPY_INT64_FMT macro. There's no point in having it if it doesn't work... What is NumPy setting it to for that platform?
Of course (just felt somewhat lost among all the #defines). It clearly seems to be mis-constructed on PowerPC 32: NPY_SIZEOF_LONG is 4, thus NPY_INT64_FMT is set to NPY_LONGLONG_FMT - "Ld", but this does not seem to handle int64 on big-endian Macs - explicitly printing "%Ld", dts->year also produces 0. Changing the snprintf format to "%04" "lld" produces the correct output, so if nothing else avails, I suggest to put something like
# elseif (defined(__ppc__) || defined(__ppc64__)) #define LONGLONG_FMT "lld" #define ULONGLONG_FMT "llu" # else
into npy_common.h (or possibly simply "defined(__APPLE__)", since %lld seems to work on 32bit i386 Macs just as well).
Cheers, Derek
On Thu, Jun 16, 2011 at 8:18 PM, Derek Homeier < derek@astro.physik.uni-goettingen.de> wrote:
On 17.06.2011, at 2:02AM, Mark Wiebe wrote:
ok, that was a lengthy hunt, but it's in printing the string in
make_iso_8601_date:
tmplen = snprintf(substr, sublen, "%04" NPY_INT64_FMT, dts->year); fprintf(stderr, "printed %d[%d]: dts->year=%lld: %s\n", tmplen,
sublen, dts->year, substr);
produces
np.datetime64('1970-03-23 20:00:00Z', 'D')
printed 4[62]: dts->year=1970: 0000 numpy.datetime64('0000-03-23','D')
It seems snprintf is not using the correct format for INT64 (as I
happened to do in fprintf before
realising I had to use "%lld" ;-) - could it be this is a general issue,
which just does not show up
on little-endian machines because they happen to pass the right half of
the int64 to printf?
BTW, how is this supposed to be handled (in 4 digits) if the year is
indeed beyond the 32bit range
(i.e. >~ 0.3 Hubble times...)? Just wondering if one could simply cast
it to int32 before print.
I'd prefer to fix the NPY_INT64_FMT macro. There's no point in having it
if it doesn't work... What is NumPy setting it to for that platform?
Of course (just felt somewhat lost among all the #defines). It clearly seems to be mis-constructed on PowerPC 32: NPY_SIZEOF_LONG is 4, thus NPY_INT64_FMT is set to NPY_LONGLONG_FMT - "Ld", but this does not seem to handle int64 on big-endian Macs - explicitly printing "%Ld", dts->year also produces 0. Changing the snprintf format to "%04" "lld" produces the correct output, so if nothing else avails, I suggest to put something like
# elseif (defined(__ppc__) || defined(__ppc64__)) #define LONGLONG_FMT "lld" #define ULONGLONG_FMT "llu" # else
into npy_common.h (or possibly simply "defined(__APPLE__)", since %lld seems to work on 32bit i386 Macs just as well).
Probably a minimally invasive change is best, also this kind of thing deserves a comment explaining the problem that was encountered with the specific platforms, so that in the future when people examine this part they can understand why this is there. Do you want to make a pull request for this change?
-Mark
Cheers, Derek
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 17.06.2011, at 8:05PM, Mark Wiebe wrote:
On Thu, Jun 16, 2011 at 8:18 PM, Derek Homeier derek@astro.physik.uni-goettingen.de wrote:
On 17.06.2011, at 2:02AM, Mark Wiebe wrote:
ok, that was a lengthy hunt, but it's in printing the string in make_iso_8601_date:
tmplen = snprintf(substr, sublen, "%04" NPY_INT64_FMT, dts->year); fprintf(stderr, "printed %d[%d]: dts->year=%lld: %s\n", tmplen, sublen, dts->year, substr);
produces
> np.datetime64('1970-03-23 20:00:00Z', 'D')
printed 4[62]: dts->year=1970: 0000 numpy.datetime64('0000-03-23','D')
It seems snprintf is not using the correct format for INT64 (as I happened to do in fprintf before realising I had to use "%lld" ;-) - could it be this is a general issue, which just does not show up on little-endian machines because they happen to pass the right half of the int64 to printf? BTW, how is this supposed to be handled (in 4 digits) if the year is indeed beyond the 32bit range (i.e. >~ 0.3 Hubble times...)? Just wondering if one could simply cast it to int32 before print.
I'd prefer to fix the NPY_INT64_FMT macro. There's no point in having it if it doesn't work... What is NumPy setting it to for that platform?
Of course (just felt somewhat lost among all the #defines). It clearly seems to be mis-constructed on PowerPC 32: NPY_SIZEOF_LONG is 4, thus NPY_INT64_FMT is set to NPY_LONGLONG_FMT - "Ld", but this does not seem to handle int64 on big-endian Macs - explicitly printing "%Ld", dts->year also produces 0. Changing the snprintf format to "%04" "lld" produces the correct output, so if nothing else avails, I suggest to put something like
# elseif (defined(__ppc__) || defined(__ppc64__)) #define LONGLONG_FMT "lld" #define ULONGLONG_FMT "llu" # else
into npy_common.h (or possibly simply "defined(__APPLE__)", since %lld seems to work on 32bit i386 Macs just as well).
Probably a minimally invasive change is best, also this kind of thing deserves a comment explaining the problem that was encountered with the specific platforms, so that in the future when people examine this part they can understand why this is there. Do you want to make a pull request for this change?
I'd go with the defined(__APPLE__) then, since %Ld produces wrong results on both 32bit platforms. More precisely, this print "%Ld - %Ld", dts->year, dts->year produces "0 - 1970" on ppc and "1970 - 0" on i386, while "%lld - %lld" prints "1970 - 1970" on both archs. There still is an issue (I now remember this came up with a different test a few months ago), that none of the formats seems to be able to actually print numbers > 2**32 (or 2**31, don't remember), but this seemed out of reach for anyone on this list.
Cheers, Derek
On Fri, Jun 17, 2011 at 2:46 PM, Derek Homeier < derek@astro.physik.uni-goettingen.de> wrote:
On 17.06.2011, at 8:05PM, Mark Wiebe wrote:
On Thu, Jun 16, 2011 at 8:18 PM, Derek Homeier <
derek@astro.physik.uni-goettingen.de> wrote:
On 17.06.2011, at 2:02AM, Mark Wiebe wrote:
ok, that was a lengthy hunt, but it's in printing the string in
make_iso_8601_date:
tmplen = snprintf(substr, sublen, "%04" NPY_INT64_FMT, dts->year); fprintf(stderr, "printed %d[%d]: dts->year=%lld: %s\n", tmplen,
sublen, dts->year, substr);
produces
>> np.datetime64('1970-03-23 20:00:00Z', 'D')
printed 4[62]: dts->year=1970: 0000 numpy.datetime64('0000-03-23','D')
It seems snprintf is not using the correct format for INT64 (as I
happened to do in fprintf before
realising I had to use "%lld" ;-) - could it be this is a general
issue, which just does not show up
on little-endian machines because they happen to pass the right half
of the int64 to printf?
BTW, how is this supposed to be handled (in 4 digits) if the year is
indeed beyond the 32bit range
(i.e. >~ 0.3 Hubble times...)? Just wondering if one could simply
cast it to int32 before print.
I'd prefer to fix the NPY_INT64_FMT macro. There's no point in having
it if it doesn't work... What is NumPy setting it to for that platform?
Of course (just felt somewhat lost among all the #defines). It clearly
seems to be mis-constructed
on PowerPC 32: NPY_SIZEOF_LONG is 4, thus NPY_INT64_FMT is set to NPY_LONGLONG_FMT -
"Ld",
but this does not seem to handle int64 on big-endian Macs - explicitly
printing "%Ld", dts->year
also produces 0. Changing the snprintf format to "%04" "lld" produces the correct output,
so if nothing else
avails, I suggest to put something like
# elseif (defined(__ppc__) || defined(__ppc64__)) #define LONGLONG_FMT "lld" #define ULONGLONG_FMT "llu" # else
into npy_common.h (or possibly simply "defined(__APPLE__)", since %lld
seems to
work on 32bit i386 Macs just as well).
Probably a minimally invasive change is best, also this kind of thing
deserves a comment explaining the problem that was encountered with the specific platforms, so that in the future when people examine this part they can understand why this is there. Do you want to make a pull request for this change?
I'd go with the defined(__APPLE__) then, since %Ld produces wrong results on both 32bit platforms. More precisely, this print "%Ld - %Ld", dts->year, dts->year produces "0 - 1970" on ppc and "1970 - 0" on i386, while "%lld - %lld" prints "1970 - 1970" on both archs. There still is an issue (I now remember this came up with a different test a few months ago), that none of the formats seems to be able to actually print numbers > 2**32 (or 2**31, don't remember), but this seemed out of reach for anyone on this list.
That proves that it's wrong on i386 as well, and it makes perfect sense for big endian and little endian architectures.
-Mark
Cheers, Derek
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
I've received some good feedback from Chuck and Ralf on the code and documentation, respectively, and build testing with proposed fixes for issues from the previous merge from Derek. I believe the current set of changes are in good shape to merge, so would like to proceed with that later today.
Cheers, Mark
On Tue, Jun 14, 2011 at 6:34 PM, Mark Wiebe mwwiebe@gmail.com 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/6b5a42a777b16812e774193b06da1b68b9...
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.
Thanks, Mark
On Fri, Jun 10, 2011 at 5:49 PM, Mark Wiebe mwwiebe@gmail.com wrote:
I've implemented the busday_offset function with support for the weekmask and roll parameters, the commits are tagged 'datetime-bday' in the pull request here:
https://github.com/numpy/numpy/pull/87
-Mark
On Thu, Jun 9, 2011 at 5:23 PM, Mark Wiebe mwwiebe@gmail.com wrote:
Here's a possible design for a business day API for numpy datetimes:
The 'B' business day unit will be removed. All business day-related calculations will be done using the 'D' day unit.
A class *BusinessDayDef* to encapsulate the definition of the business week and holidays. The business day functions will either take one of these objects, or separate weekmask and holidays parameters, to specify the business day definition. This class serves as both a performance optimization and a way to encapsulate the weekmask and holidays together, for example if you want to make a dictionary mapping exchange names to their trading days definition.
The weekmask can be specified in a number of ways, and internally becomes a boolean array with 7 elements with True for the days Monday through Sunday which are valid business days. Some different notations are for the 5-day week include [1,1,1,1,1,0,0], "1111100" "MonTueWedThuFri". The holidays are always specified as a one-dimensional array of dtype 'M8[D]', and are internally used in sorted form.
A function *is_busday*(datearray, weekmask=, holidays=, busdaydef=) returns a boolean array matching the input datearray, with True for the valid business days.
A function *busday_offset*(datearray, offsetarray, roll='raise', weekmask=, holidays=, busdaydef=) which first applies the 'roll' policy to start at a valid business date, then offsets the date by the number of business days specified in offsetarray. The arrays datearray and offsetarray are broadcast together. The 'roll' parameter can be 'forward'/'following', 'backward'/'preceding', 'modifiedfollowing', 'modifiedpreceding', or 'raise' (the default).
A function *busday_count*(datearray1, datearray2, weekmask=, holidays=, busdaydef=) which calculates the number of business days between datearray1 and datearray2, not including the day of datearray2.
For example, to find the first Monday in Feb 2011,
np.busday_offset('2011-02', 0, roll='forward', weekmask='Mon')
or to find the number of weekdays in Feb 2011,
np.busday_count('2011-02', '2011-03')
This set of three functions appears to be powerful enough to express the business-day computations that I've been shown thus far.
Cheers, Mark
On Thu, Jun 16, 2011 at 2:00 PM, Mark Wiebe mwwiebe@gmail.com wrote:
I've received some good feedback from Chuck and Ralf on the code and documentation, respectively, and build testing with proposed fixes for issues from the previous merge from Derek. I believe the current set of changes are in good shape to merge, so would like to proceed with that later today.
Go for it.
<snip>
Chuck
Hey all,
On Tue, Jun 14, 2011 at 4:34 PM, Mark Wiebe mwwiebe@gmail.com wrote:
These functions are now fully implemented and documented. As always, code reviews are welcome here: https://github.com/numpy/numpy/pull/87
I haven't been keeping up with the datetime developments, but I noticed the introduction of more names into the root numpy namespace. About a year (or two?) ago at SciPy, there were discussions about organising the NumPy namespace for 2.0, and halting the introduction of new functions into the root namespace. What is the status quo?
Regards Stéfan
2011/7/25 Stéfan van der Walt stefan@sun.ac.za
Hey all,
On Tue, Jun 14, 2011 at 4:34 PM, Mark Wiebe mwwiebe@gmail.com wrote:
These functions are now fully implemented and documented. As always, code reviews are welcome here: https://github.com/numpy/numpy/pull/87
I haven't been keeping up with the datetime developments, but I noticed the introduction of more names into the root numpy namespace. About a year (or two?) ago at SciPy, there were discussions about organising the NumPy namespace for 2.0, and halting the introduction of new functions into the root namespace. What is the status quo?
I'm trying to make things fit into the existing system as naturally as possible. The discussion you're talking about ideally should have resulted in some guideline documentation about namespaces, but I don't recall seeing something like that in a prominent place anywhere.
-Mark
Regards Stéfan _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Jul 25, 2011 at 12:35 PM, Mark Wiebe mwwiebe@gmail.com wrote:
I'm trying to make things fit into the existing system as naturally as possible. The discussion you're talking about ideally should have resulted in some guideline documentation about namespaces, but I don't recall seeing something like that in a prominent place anywhere.
Probably should have! Either way, it's something to consider: if we introduce those functions now, people will start to use them where they are (np.xyz), introducing another change in usage comes 2.0 (or 3.0 or whichever).
Regards Stéfan
2011/7/25 Stéfan van der Walt stefan@sun.ac.za
On Mon, Jul 25, 2011 at 12:35 PM, Mark Wiebe mwwiebe@gmail.com wrote:
I'm trying to make things fit into the existing system as naturally as possible. The discussion you're talking about ideally should have
resulted
in some guideline documentation about namespaces, but I don't recall
seeing
something like that in a prominent place anywhere.
Probably should have! Either way, it's something to consider: if we introduce those functions now, people will start to use them where they are (np.xyz), introducing another change in usage comes 2.0 (or 3.0 or whichever).
Absolutely, do you have any suggestions about organizing the datetime functionality? It's as good a place as any to try applying a good namespace convention.
-Mark
Regards Stéfan _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Jul 25, 2011 at 1:02 PM, Mark Wiebe mwwiebe@gmail.com wrote:
Probably should have! Either way, it's something to consider: if we introduce those functions now, people will start to use them where they are (np.xyz), introducing another change in usage comes 2.0 (or 3.0 or whichever).
Absolutely, do you have any suggestions about organizing the datetime functionality? It's as good a place as any to try applying a good namespace convention.
The first thought that comes to mind is simply to keep them in a submodule, so that users can do something like:
from numpy.datetime import some_date_func
That convention should be very easy to support across the restructuring. The important thing then is to document clearly that these functions are available.
Regards Stéfan
2011/7/25 Stéfan van der Walt stefan@sun.ac.za
On Mon, Jul 25, 2011 at 1:02 PM, Mark Wiebe mwwiebe@gmail.com wrote:
Probably should have! Either way, it's something to consider: if we introduce those functions now, people will start to use them where they are (np.xyz), introducing another change in usage comes 2.0 (or 3.0 or whichever).
Absolutely, do you have any suggestions about organizing the datetime functionality? It's as good a place as any to try applying a good
namespace
convention.
The first thought that comes to mind is simply to keep them in a submodule, so that users can do something like:
from numpy.datetime import some_date_func
That convention should be very easy to support across the restructuring. The important thing then is to document clearly that these functions are available.
Can't use numpy.datetime, since that conflicts with Python's datetime library, especially in pylab. Can't use numpy.datetime64, since that's already the name of the scalar type. I don't like numpy.dt, that name belongs to a delta t variable in Python. I'm not sure what a good name for the namespace is, actually.
-Mark
Regards Stéfan _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Jul 25, 2011 at 03:52:48PM -0500, Mark Wiebe wrote:
Can't use numpy.datetime, since that conflicts with Python's datetime library, especially in pylab.
I don't understand that: isn't the point of namespaces to avoid those naming conflicts. To me that's just like saying that numpy.sum shouldn't be named sum because it would conflict with the sum builtin.
My 2 euro cents (a endangered currency)
Gael
On Mon, Jul 25, 2011 at 3:00 PM, Gael Varoquaux < gael.varoquaux@normalesup.org> wrote:
On Mon, Jul 25, 2011 at 03:52:48PM -0500, Mark Wiebe wrote:
Can't use numpy.datetime, since that conflicts with Python's datetime library, especially in pylab.
I don't understand that: isn't the point of namespaces to avoid those naming conflicts. To me that's just like saying that numpy.sum shouldn't be named sum because it would conflict with the sum builtin.
It's just asking for import problems and general confusion to shadow a Python module, that's why we renamed io to npyio.
I'm curious as to what would be in the module.
My 2 euro cents (a endangered currency)
Aren't they all?
Chuck
On Mon, Jul 25, 2011 at 2:11 PM, Charles R Harris charlesr.harris@gmail.com wrote:
It's just asking for import problems and general confusion to shadow a Python module, that's why we renamed io to npyio.
Why? Users can simply do
import numpy.io as npyio ?
Stéfan
2011/7/25 Stéfan van der Walt stefan@sun.ac.za:
On Mon, Jul 25, 2011 at 2:11 PM, Charles R Harris charlesr.harris@gmail.com wrote:
It's just asking for import problems and general confusion to shadow a Python module, that's why we renamed io to npyio.
Why? Users can simply do
import numpy.io as npyio ?
IIRC this was changed because of a (now fixed) bug in 2to3.
Skipper
2011/7/25 Stéfan van der Walt stefan@sun.ac.za
On Mon, Jul 25, 2011 at 2:11 PM, Charles R Harris charlesr.harris@gmail.com wrote:
It's just asking for import problems and general confusion to shadow a Python module, that's why we renamed io to npyio.
Why? Users can simply do
import numpy.io as npyio ?
It caused problems with 2to3 for one thing because it was getting imported as io in the package. It is just a bad idea to shadow python modules and best avoided.
Chuck
On Mon, Jul 25, 2011 at 2:29 PM, Charles R Harris charlesr.harris@gmail.com wrote:
Why? Users can simply do
import numpy.io as npyio ?
It caused problems with 2to3 for one thing because it was getting imported as io in the package. It is just a bad idea to shadow python modules and best avoided.
Call me hard-headed, but I feel that "just a bad idea" is not a precise enough justification for obfuscating module names. But then, you are the one working on the code at the moment, so you get to say that :)
Cheers Stéfan
On Monday, July 25, 2011, Gael Varoquaux gael.varoquaux@normalesup.org wrote:
On Mon, Jul 25, 2011 at 03:52:48PM -0500, Mark Wiebe wrote:
Can't use numpy.datetime, since that conflicts with Python's datetime library, especially in pylab.
I don't understand that: isn't the point of namespaces to avoid those naming conflicts. To me that's just like saying that numpy.sum shouldn't be named sum because it would conflict with the sum builtin.
My 2 euro cents (a endangered currency)
Gael
I think the problem is that numpy's datetime might not be a drop-in replacement for python's datetime. For operations in python where one would use python's sum, numpy's sum would produce effectively identical results.
We even have a few bug reports in our tracker for the use of all and any being ever-so-slightly different than python's, and it can cause some confusion in pylab mode.
Admittedly, though, I can't come up with a better name, either.
My two cents (also endangered)...
Ben Root
On Mon, Jul 25, 2011 at 1:52 PM, Mark Wiebe mwwiebe@gmail.com wrote:
Can't use numpy.datetime, since that conflicts with Python's datetime library, especially in pylab.
We're allowed to name the modules under numpy whatever we like--people know that doing "from numpy import *" can (and already does) cause havoc. But maybe "numpy.time" would suffice as a grouping.
Regards Stéfan
2011/7/25 Stéfan van der Walt stefan@sun.ac.za
Hey all,
On Tue, Jun 14, 2011 at 4:34 PM, Mark Wiebe mwwiebe@gmail.com wrote:
These functions are now fully implemented and documented. As always, code reviews are welcome here: https://github.com/numpy/numpy/pull/87
I haven't been keeping up with the datetime developments, but I noticed the introduction of more names into the root numpy namespace. About a year (or two?) ago at SciPy, there were discussions about organising the NumPy namespace for 2.0, and halting the introduction of new functions into the root namespace. What is the status quo?
Datetime is now a numpy type, so to that extent is in the base namespace. One could maybe argue that the calender functions belong in another namespace, and some of what is in numpy/lib (poly1d, financial functions) should have been in separate namespaces to begin with. I'm not sure what else in datetime might belong in its own namespace.
Chuck
-
Benjamin Root -
Charles R Harris -
Derek Homeier -
Gael Varoquaux -
Mark Wiebe -
Skipper Seabold -
Stéfan van der Walt