On Fri, Jun 10, 2011 at 1:54 AM, Mark Wiebe wrote:
> On Thu, Jun 9, 2011 at 5:21 PM, Ralf Gommers
> wrote:
>
>>
>>
>> On Thu, Jun 9, 2011 at 11:54 PM, Mark Wiebe wrote:
>>
>>> On Thu, Jun 9, 2011 at 4:27 PM, Ralf Gommers <
>>> ralf.gomm...@googlemail.com> wrote:
>>>
On Thu, Jun 9
On Thu, Jun 9, 2011 at 19:25, Paul Anton Letnes
wrote:
> Dear numpy developers, users, and fans:
>
> I wish for a numpy that will magically detect all my errors. Barring the
> invention of a numpy version which knows what I need, not what I ask of it, I
> have the following, simpler wish: if one
Dear numpy developers, users, and fans:
I wish for a numpy that will magically detect all my errors. Barring the
invention of a numpy version which knows what I need, not what I ask of it, I
have the following, simpler wish: if one takes myarray.real or myarray.imag of
a float (or possibly inte
On Thu, Jun 9, 2011 at 5:21 PM, Ralf Gommers wrote:
>
>
> On Thu, Jun 9, 2011 at 11:54 PM, Mark Wiebe wrote:
>
>> On Thu, Jun 9, 2011 at 4:27 PM, Ralf Gommers > > wrote:
>>
>>>
>>>
>>> On Thu, Jun 9, 2011 at 10:58 PM, Mark Wiebe wrote:
>>>
On Thu, Jun 9, 2011 at 3:41 PM, Christopher Barker
On Thu, Jun 9, 2011 at 6:28 PM, Robert Kern wrote:
> On Thu, Jun 9, 2011 at 16:27, Robert Kern wrote:
> > On Thu, Jun 9, 2011 at 15:01, Mark Wiebe wrote:
> >> I've replaced the previous two pull requests with a single pull request
> >> rolling up all the changes so far. The newest changes inclu
On Thu, Jun 9, 2011 at 16:27, Robert Kern wrote:
> On Thu, Jun 9, 2011 at 15:01, Mark Wiebe wrote:
>> I've replaced the previous two pull requests with a single pull request
>> rolling up all the changes so far. The newest changes include finishing the
>> generic unit and np.arange function suppo
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 fu
On Thu, Jun 9, 2011 at 11:54 PM, Mark Wiebe wrote:
> On Thu, Jun 9, 2011 at 4:27 PM, Ralf Gommers
> wrote:
>
>>
>>
>> On Thu, Jun 9, 2011 at 10:58 PM, Mark Wiebe wrote:
>>
>>> On Thu, Jun 9, 2011 at 3:41 PM, Christopher Barker <
>>> chris.bar...@noaa.gov> wrote:
>>>
>>> Your branch works fine f
On Thu, Jun 9, 2011 at 3:27 PM, Robert Kern wrote:
> On Thu, Jun 9, 2011 at 15:01, Mark Wiebe wrote:
> > I've replaced the previous two pull requests with a single pull request
> > rolling up all the changes so far. The newest changes include finishing
> the
> > generic unit and np.arange functi
On Thu, Jun 9, 2011 at 4:27 PM, Ralf Gommers wrote:
>
>
> On Thu, Jun 9, 2011 at 10:58 PM, Mark Wiebe wrote:
>
>> On Thu, Jun 9, 2011 at 3:41 PM, Christopher Barker > > wrote:
>>
>> Your branch works fine for me (OS X, py2.6), no failures. Only a few
> deprecation warnings like:
> /Library/Framew
What would it take to automatically detect which flavor of fortran to
use to build numpy on linux?
The unit tests are clever enough to detect a mis-build (though
surprisingly that is not done as part of the build process), so surely
it can be done.
Even if there is no interest in putting this
On Thu, Jun 9, 2011 at 15:01, Mark Wiebe wrote:
> I've replaced the previous two pull requests with a single pull request
> rolling up all the changes so far. The newest changes include finishing the
> generic unit and np.arange function support.
> https://github.com/numpy/numpy/pull/87
> Because
On Thu, Jun 9, 2011 at 10:58 PM, Mark Wiebe wrote:
> On Thu, Jun 9, 2011 at 3:41 PM, Christopher Barker
> wrote:
>
> Your branch works fine for me (OS X, py2.6), no failures. Only a few
deprecation warnings like:
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py:336:
D
On Thu, Jun 9, 2011 at 3:41 PM, Christopher Barker
wrote:
> Mark Wiebe wrote:
> > Because of the nature of datetime and timedelta, arange has to be
> > slightly different than with all the other types. In particular, for
> > datetime the primary signature is np.arange(datetime, datetime,
> timed
Mark Wiebe wrote:
> Because of the nature of datetime and timedelta, arange has to be
> slightly different than with all the other types. In particular, for
> datetime the primary signature is np.arange(datetime, datetime, timedelta).
>
> I've implemented a simple extension which allows for anot
On Wed, Jun 8, 2011 at 8:53 PM, Mark Wiebe wrote:
> 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
>
Not much time, here, but since you got no replies earlier:
> > 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
is the matrix multiplication, or element-wise? If matrix,
On Thu, Jun 9, 2011 at 4:17 AM, Dave Hirschfeld
wrote:
> Mark Wiebe gmail.com> writes:
>
> >
> > Here are some current behaviors that are inconsistent with the
> microsecond
> default, but consistent with the "generic time unit" idea:
> >
> > >>> np.timedelta64(10, 's') + 10
> > numpy.timedelta64
On Thu, Jun 9, 2011 at 1:38 AM, Pierre GM wrote:
>
> 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 sec
I've replaced the previous two pull requests with a single pull request
rolling up all the changes so far. The newest changes include finishing the
generic unit and np.arange function support.
https://github.com/numpy/numpy/pull/87
Because of the nature of datetime and timedelta, arange has to be
Hello all,
Since I haven't heard back, I decided to simplify my problem even more. I'm
attaching two files which demonstrate the problem very clearly. My original
message is below. The script can be run with "python shared_mem.py".
Thanks,
Brandt
> > Hello,
> > I'm parallelizing some code I've wr
Mark Wiebe wrote:
> Because datetime64 is a NumPy data type, it needs a well-defined rule
> for these kinds of conversions. Treating datetimes as moments in time
> instead of time intervals makes a very nice rule which appears to be
> very amenable to a variety of computations, which is why I li
On Thu, Jun 9, 2011 at 3:39 AM, Yoshi Rokuko wrote:
> + Mark Wiebe ---+
> >
> > I believe what you may want is PyArray_ContiguousFromAny instead of
> > PyArray_ContiguousFromObject.
> >
>
> are you sure that there is a difference? i think its ju
Thu, 09 Jun 2011 09:37:36 -0400, martin smith wrote:
[clip]
> I'm game to go on with this but I'm concerned that the effort will be
> futile for the reason that Ralf suggested: duplication of some fftpack
> code in my module. Does anyone have a clear idea whether or not this
> issue will be fatal
On 6/5/2011 5:46 PM, martin smith wrote:
> On 6/3/2011 5:15 AM, Ralf Gommers wrote:
>>
>> ...
>> Coming back to #608, that means there is no chance that the C version
>> will land in scipy, correct? We're not going to ship two copies of
>> FFTPACK. So the answer should be "rewrite in Python, if th
Mark Wiebe gmail.com> writes:
>
> Here are some current behaviors that are inconsistent with the microsecond
default, but consistent with the "generic time unit" idea:
>
> >>> np.timedelta64(10, 's') + 10
> numpy.timedelta64(20,'s')
>
>
That is what I would expect (and hope) would happen. IM
+ Mark Wiebe ---+
>
> I believe what you may want is PyArray_ContiguousFromAny instead of
> PyArray_ContiguousFromObject.
>
are you sure that there is a difference? i think its just the new
name for the same thing right?
best regards, yoshi
__
27 matches
Mail list logo
