Re: [Numpy-discussion] fixing up datetime

> > The fact that it's a NumPy dtype probably is the biggest limiting factor > preventing parameters like 'start' and 'end' during conversion. Having a > datetime represent an instant in time neatly removes any ambiguity, so > converting between days and seconds as a unit is analogous to conver

Re: [Numpy-discussion] Default unit for datetime/timedelta

On Jun 9, 2011, at 2:22 AM, Mark Wiebe wrote: > > > >>> np.array(['2011-03-12T13', '2012'], dtype='M8') > > > array(['2011-03-12T13:00:00.00-0600', > > > '2011-12-31T18:00:00.00-0600'], dtype='datetime64[us]') > > > > Why is the second one not '2012-01-01T00:00:00-0600' ? > > > > This is

Re: [Numpy-discussion] Returning the same dtype in Cython as np.argmax

On Jun 7, 2011, at 3:17 PM, Keith Goodman wrote: > What is the rule to determine the dtype returned by numpy functions > that return indices such as np.argmax? The return type of indices will be np.intp. I don't know if Cython provides that type or not. If not, then it is either np.int32 or

Re: [Numpy-discussion] Current datetime pull requests ready for review

On Wed, Jun 8, 2011 at 6:53 PM, Charles R Harris wrote: > > > On Wed, Jun 8, 2011 at 4:09 PM, Benjamin Root wrote: > >> On Wednesday, June 8, 2011, Mark Wiebe wrote: >> > I've been trying to separate out the features I've been doing into >> separate branches so I can split up into multiple pull,

Re: [Numpy-discussion] fixing up datetime

On Wed, Jun 8, 2011 at 4:57 AM, Wes McKinney wrote: > > > > So in summary, w.r.t. time series data and datetime, the only things I > care about from a datetime / pandas point of view: > > - Ability to easily define custom timedeltas > Can you elaborate on this a bit? I'm guessing you're not ref

Re: [Numpy-discussion] fixing up datetime

On Wed, Jun 8, 2011 at 5:59 AM, Dave Hirschfeld wrote: > Mark Wiebe gmail.com> writes: > > > > > > It appears to me that a structured dtype with some further NumPy > extensions > > could entirely replace the 'events' metadata fairly cleanly. If the > ufuncs > > are extended to operate on structur

Re: [Numpy-discussion] fixing up datetime

On Tue, Jun 7, 2011 at 7:28 PM, Pierre GM wrote: > > > > It supports .astype(), with a truncation policy. This is motivated > partially because that's how Pythons integer division works, and partially > because if you consider a full datetime '2011-03-14T13:22:16', it's natural > to think of the

Re: [Numpy-discussion] Default unit for datetime/timedelta

On Wed, Jun 8, 2011 at 6:31 PM, Pierre GM wrote: > > On Jun 9, 2011, at 1:10 AM, Mark Wiebe wrote: > > > > > >>> np.timedelta64(10, 's') + 10 > > > numpy.timedelta64(20,'s') > > > > Here, the unit is defined: 's' > > > > For the first operand, the inconsistency is with the second. Here's the > r

Re: [Numpy-discussion] Current datetime pull requests ready for review

On Wed, Jun 8, 2011 at 4:09 PM, Benjamin Root wrote: > On Wednesday, June 8, 2011, Mark Wiebe wrote: > > I've been trying to separate out the features I've been doing into > separate branches so I can split up into multiple pull, but the development > I'm doing works pretty poorly with this work

Re: [Numpy-discussion] Default unit for datetime/timedelta

On Jun 9, 2011, at 1:10 AM, Mark Wiebe wrote: > > > >>> np.timedelta64(10, 's') + 10 > > numpy.timedelta64(20,'s') > > Here, the unit is defined: 's' > > For the first operand, the inconsistency is with the second. Here's the > reasoning I didn't spell out: > We're adding a timedelta + int, s

Re: [Numpy-discussion] Default unit for datetime/timedelta

On Wed, Jun 8, 2011 at 5:48 PM, Pierre GM wrote: > > On Jun 8, 2011, at 11:05 PM, Mark Wiebe wrote: > > > The NEP and current implementation of the datetime specifies microseconds > as the default unit when constructing and converting to datetimes and > timedeltas. > > AFAIU, the default is [us]

Re: [Numpy-discussion] Default unit for datetime/timedelta

On Jun 8, 2011, at 11:05 PM, Mark Wiebe wrote: > The NEP and current implementation of the datetime specifies microseconds as > the default unit when constructing and converting to datetimes and timedeltas. AFAIU, the default is [us] when otherwise unspecified. > Here are some current behavior

Re: [Numpy-discussion] Current datetime pull requests ready for review

On Wednesday, June 8, 2011, Mark Wiebe wrote: > I've been trying to separate out the features I've been doing into separate > branches so I can split up into multiple pull, but the development I'm doing > works pretty poorly with this workflow. Nearly every step of development > builds on or us

Re: [Numpy-discussion] numpy : error with cc compiler

On Wed, Jun 8, 2011 at 11:21 PM, akshar bhosale wrote: > Hi, > > we have RHEL 5.2 x86_64, python 2.6, intel compilers 11.0.69, intel mkl > 10.1. We are trying to configure numpy 1.6.0 and we are getting below > errors. > our site.cfg is : > - > [mkl] > #mkl_libs = mkl_blacs

[Numpy-discussion] Current datetime pull requests ready for review

I've been trying to separate out the features I've been doing into separate branches so I can split up into multiple pull, but the development I'm doing works pretty poorly with this workflow. Nearly every step of development builds on or uses changes from previous features. Since github doesn't do

[Numpy-discussion] numpy : error with cc compiler

Hi, we have RHEL 5.2 x86_64, python 2.6, intel compilers 11.0.69, intel mkl 10.1. We are trying to configure numpy 1.6.0 and we are getting below errors. our site.cfg is : - [mkl] #mkl_libs = mkl_blacs_intelmpi_ilp64, mkl_blacs_intelmpi_lp64, mkl_core, mkl_def, mkl_gf_ilp64

[Numpy-discussion] Default unit for datetime/timedelta

The NEP and current implementation of the datetime specifies microseconds as the default unit when constructing and converting to datetimes and timedeltas. Having the np.arange function work in a general, intuitive way for a wide variety of datetime/timedelta/integer inputs is turning out to be ver

Re: [Numpy-discussion] merging datetime progress

On Wed, Jun 8, 2011 at 1:55 PM, Mark Wiebe wrote: > On Wed, Jun 8, 2011 at 1:04 PM, Bruce Southey wrote: >> >> >> >> I am sorry but github pull requests do not appear to be sent to the numpy >> dev list. So you are not going to get many people to respond to that type of >> 'closed' request. Furt

Re: [Numpy-discussion] import numpy fails on dev build

This is due to a mismatch of the UCS mode of Python and the C extension you build. Python has a configure option to let you choose whether unicode symbols are represented as 2 of 4 bytes, i.e. UCS2 or UCS4. - Ilan On Wed, Jun 8, 2011 at 3:07 PM, Raymond Roberts wrote: > numpy.__version__ == 2.

[Numpy-discussion] import numpy fails on dev build

numpy.__version__ == 2.0.0.dev-76ca55f python version 2.7.1 Gentoo Linux 2.6.38-r6 installed inside of VMWare fusion on Mac OS X 10.6.7 gcc (Gentoo 4.4.5 p1.2, pie-0.4.5) 4.4.5 Build is successful. Import of numpy dev build results in the following error message ImportError: ~/numpy/lib/python/n

Re: [Numpy-discussion] merging datetime progress

On Wed, Jun 8, 2011 at 13:55, Mark Wiebe wrote: > Requiring that amount of overhead before committing a change into master, > which is the unstable development branch, sounds very unreasonable to me. Ah, that's the source of the misunderstanding, then. master is not the unstable development bran

Re: [Numpy-discussion] merging datetime progress

On Wed, Jun 8, 2011 at 1:04 PM, Bruce Southey wrote: > ** > > > > I am sorry but github pull requests do not appear to be sent to the numpy > dev list. So you are not going to get many people to respond to that type of > 'closed' request. Further any discussion for things that get merged into t

Re: [Numpy-discussion] Using multiprocessing (shared memory) with numpy array multiplication

sorry but github pull requests do not appear to be sent to the > numpy dev list. So you are not going to get many people to respond to > that type of 'closed' request. Further any discussion for things that > get merged into the master really should be on the list especially as >

[Numpy-discussion] Using multiprocessing (shared memory) with numpy array multiplication

Hello, I'm parallelizing some code I've written using the built in multiprocessing module. In my application, I need to multiply many large arrays together and sum the resulting product arrays (inner products). I noticed that when I parallelized this with myPool.map(...) with 8 processes (on an 8-c

Re: [Numpy-discussion] merging datetime progress

On 06/08/2011 10:26 AM, Mark Wiebe wrote: On Tue, Jun 7, 2011 at 11:52 PM, Fernando Perez @gmail.com > wrote: On Tue, Jun 7, 2011 at 4:35 PM, Mark Wiebe mailto:mwwi...@gmail.com>> wrote: > I went ahead and did the merge today as I said I wanted to, th

Re: [Numpy-discussion] numpy c api general array handling

Mark Wiebe wrote: > I believe what you may want is PyArray_ContiguousFromAny instead of > PyArray_ContiguousFromObject. I would also strongly encourage you to take a look at Cython: http://cython.org/ It has built-in support for numpy arrays, so it can take care of a lot of this bookkeeping fo

Re: [Numpy-discussion] git source datetime build error

On 8 June 2011 17:27, Mark Wiebe wrote: > I've committed a fix for x86_64 as well now. Sorry for the breakage! Works for me. (numpy-master-2.7)scott@godzilla:~$ python -c "import numpy; numpy.test()" Running unit tests for numpy NumPy version 2.0.0.dev-76ca55f NumPy is installed in /home/scott/.

Re: [Numpy-discussion] numpy c api general array handling

I believe what you may want is PyArray_ContiguousFromAny instead of PyArray_ContiguousFromObject. Cheers, Mark On Wed, Jun 8, 2011 at 2:58 AM, Yoshi Rokuko wrote: > hey, > > i'm writing my first python module in c using numpy/arrayobject.h > and i have some problems with different platforms (bo

Re: [Numpy-discussion] git source datetime build error

I've committed a fix for x86_64 as well now. Sorry for the breakage! -Mark On Tue, Jun 7, 2011 at 7:53 PM, Angus McMorland wrote: > On 7 June 2011 17:57, Mark Wiebe wrote: > > Hi Angus, > > Thanks for reporting that, I've committed a fix so it builds in the > > monolithic mode again. > > Thank

Re: [Numpy-discussion] merging datetime progress

On Tue, Jun 7, 2011 at 11:52 PM, Fernando Perez wrote: > On Tue, Jun 7, 2011 at 4:35 PM, Mark Wiebe wrote: > > I went ahead and did the merge today as I said I wanted to, that pull > > request is some further development for someone to code-review if they > have > > time. > > I'm curious as to wh

Re: [Numpy-discussion] fixing up datetime

Mark Wiebe gmail.com> writes: > > > It appears to me that a structured dtype with some further NumPy extensions > could entirely replace the 'events' metadata fairly cleanly. If the ufuncs > are extended to operate on structured arrays, and integers modulo n are > added as a new dtype, a dtyp

Re: [Numpy-discussion] fixing up datetime

On Wed, Jun 8, 2011 at 6:37 AM, Dave Hirschfeld wrote: > Wes McKinney gmail.com> writes: > >> >> > >> > - Fundamental need to be able to work with multiple time series, >> > especially performing operations involving cross-sectional data >> > - I think it's a bit hard for lay people to use (read:

Re: [Numpy-discussion] fixing up datetime

Wes McKinney gmail.com> writes: > > > > > - Fundamental need to be able to work with multiple time series, > > especially performing operations involving cross-sectional data > > - I think it's a bit hard for lay people to use (read: ex-MATLAB/R > > users). This is just my opinion, but a few yea

Re: [Numpy-discussion] fixing up datetime

On Wed, Jun 8, 2011 at 11:57 AM, Wes McKinney wrote: > On Wed, Jun 8, 2011 at 7:36 AM, Chris Barker wrote: >> On 6/7/11 4:53 PM, Pierre GM wrote: >>>  Anyhow, each time yo >>> read 'frequency' in scikits.timeseries, think 'unit'. >> >> or maybe "precision" -- when I think if unit, I think of some

Re: [Numpy-discussion] fixing up datetime

On Wed, Jun 8, 2011 at 7:36 AM, Chris Barker wrote: > On 6/7/11 4:53 PM, Pierre GM wrote: >>  Anyhow, each time yo >> read 'frequency' in scikits.timeseries, think 'unit'. > > or maybe "precision" -- when I think if unit, I think of something that > can be represented as a floating point value --

[Numpy-discussion] numpy c api general array handling

hey, i'm writing my first python module in c using numpy/arrayobject.h and i have some problems with different platforms (both linux but really different setup) so i suspect my array handling is not cor- rect. i'm used to c arrays and want to access large numpy arrays from within my c module with