On Fri, Jun 10, 2011 at 9:55 PM, Benjamin Root wrote:
>
>
> On Fri, Jun 10, 2011 at 8:51 PM, Keith Goodman wrote:
>
>> On Fri, Jun 10, 2011 at 6:35 PM, Charles R Harris
>> wrote:
>> > On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau
>> wrote:
>>
>> >> But isn't it a bug if numpy.dtype('i') !=
On Fri, Jun 10, 2011 at 10:34 PM, Olivier Delalleau wrote:
> 2011/6/10 Benjamin Root
>
>>
>>
>> On Fri, Jun 10, 2011 at 9:29 PM, Olivier Delalleau wrote:
>>
>>>
>>> 2011/6/10 Olivier Delalleau
>>>
2011/6/10 Charles R Harris
>
>
> On Fri, Jun 10, 2011 at 5:19 PM, Olivier
On Fri, Jun 10, 2011 at 9:10 PM, Benjamin Root wrote:
>
>
> On Fri, Jun 10, 2011 at 9:29 PM, Olivier Delalleau wrote:
>
>>
>> 2011/6/10 Olivier Delalleau
>>
>>> 2011/6/10 Charles R Harris
>>>
On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau wrote:
> 2011/6/10 Charles
2011/6/10 Benjamin Root
>
>
> On Fri, Jun 10, 2011 at 9:29 PM, Olivier Delalleau wrote:
>
>>
>> 2011/6/10 Olivier Delalleau
>>
>>> 2011/6/10 Charles R Harris
>>>
On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau wrote:
> 2011/6/10 Charles R Harris
>
>>
>>
On Fri, Jun 10, 2011 at 9:29 PM, Olivier Delalleau wrote:
>
> 2011/6/10 Olivier Delalleau
>
>> 2011/6/10 Charles R Harris
>>
>>>
>>>
>>> On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau wrote:
>>>
2011/6/10 Charles R Harris
>
>
> On Fri, Jun 10, 2011 at 3:43 PM, Benjami
On Fri, Jun 10, 2011 at 9:03 PM, Pauli Virtanen wrote:
> On Fri, 10 Jun 2011 18:51:14 -0700, Keith Goodman wrote:
> [clip]
> > Maybe this is the same question, but are you maybe yes, maybe no on this
> > too:
> >
> > >>> type(np.sum([1, 2, 3], dtype=np.int32)) == np.int32
> > False
>
> No
On Fri, Jun 10, 2011 at 8:51 PM, Keith Goodman wrote:
> On Fri, Jun 10, 2011 at 6:35 PM, Charles R Harris
> wrote:
> > On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau
> wrote:
>
> >> But isn't it a bug if numpy.dtype('i') != numpy.dtype('l') on a 32 bit
> >> computer where both are int32?
>
2011/6/10 Olivier Delalleau
> 2011/6/10 Charles R Harris
>
>>
>>
>> On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau wrote:
>>
>>> 2011/6/10 Charles R Harris
>>>
On Fri, Jun 10, 2011 at 3:43 PM, Benjamin Root wrote:
>
>
> On Fri, Jun 10, 2011 at 3:24 PM, Char
On Fri, 10 Jun 2011 18:51:14 -0700, Keith Goodman wrote:
[clip]
> Maybe this is the same question, but are you maybe yes, maybe no on this
> too:
>
> >>> type(np.sum([1, 2, 3], dtype=np.int32)) == np.int32
> False
Note that this is a comparison between two Python types...
> Ben, what hap
On Fri, 10 Jun 2011 19:35:30 -0600, Charles R Harris wrote:
[clip]
> Maybe yes, maybe no ;) They have different descriptors, so from numpy's
> perspective they are different, but at the hardware/precision level they
> are the same. It's more of a decision as to what != means in this case.
> Since
On Fri, Jun 10, 2011 at 6:35 PM, Charles R Harris
wrote:
> On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau wrote:
>> But isn't it a bug if numpy.dtype('i') != numpy.dtype('l') on a 32 bit
>> computer where both are int32?
>>
>
> Maybe yes, maybe no ;) They have different descriptors, so from
2011/6/10 Charles R Harris
>
>
> On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau wrote:
>
>> 2011/6/10 Charles R Harris
>>
>>>
>>>
>>> On Fri, Jun 10, 2011 at 3:43 PM, Benjamin Root wrote:
>>>
On Fri, Jun 10, 2011 at 3:24 PM, Charles R Harris <
charlesr.har...@gmail.com>
On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau wrote:
> 2011/6/10 Charles R Harris
>
>>
>>
>> On Fri, Jun 10, 2011 at 3:43 PM, Benjamin Root wrote:
>>
>>>
>>>
>>> On Fri, Jun 10, 2011 at 3:24 PM, Charles R Harris <
>>> charlesr.har...@gmail.com> wrote:
>>>
On Fri, Jun 10, 201
On Jun 11, 2011, at 1:03 AM, Mark Wiebe wrote:
>
> I don't think you would want to extend the datetime with more metadata, but
> rather use it as a tool to create the timeseries with. You could create a
> lightweight wrapper around datetime arrays which exposed a
> timeseries-oriented interfac
On Jun 11, 2011, at 12:57 AM, Mark Wiebe wrote:
> The other issue is how do you define the np.arange step argument since that
> can be in different scales such as month, years, seconds? Can a user specific
> days and get half-days (like 1.5 days) or must these be 'integer' days?
>
> The dateti
2011/6/10 Charles R Harris
>
>
> On Fri, Jun 10, 2011 at 3:43 PM, Benjamin Root wrote:
>
>>
>>
>> On Fri, Jun 10, 2011 at 3:24 PM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Jun 10, 2011 at 2:17 PM, Benjamin Root wrote:
>>>
On Fri, Jun 10, 2011
On Thu, Jun 9, 2011 at 3:17 PM, Wes McKinney wrote:
> 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 / pa
On Thu, Jun 9, 2011 at 1:27 PM, Christopher Barker wrote:
> 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
On Thu, Jun 9, 2011 at 1:44 AM, Pierre GM wrote:
> >
> > 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 betwee
On Fri, Jun 10, 2011 at 3:43 PM, Benjamin Root wrote:
>
>
> On Fri, Jun 10, 2011 at 3:24 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Fri, Jun 10, 2011 at 2:17 PM, Benjamin Root wrote:
>>
>>>
>>>
>>> On Fri, Jun 10, 2011 at 3:02 PM, Charles R Harris <
>>> charlesr.har
On Fri, Jun 10, 2011 at 10:03 AM, Bruce Southey wrote:
> **
>
>
> I have following the multiple date/time discussions with some interest as
> it is clear there is not 'one way' (perhaps it's Dutch). But, I do keep
> coming back to Chris's concepts of time as a strict unit of measure and time
>
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 wrote:
> Here's a possible design for a busine
On Fri, Jun 10, 2011 at 3:24 PM, Charles R Harris wrote:
>
>
> On Fri, Jun 10, 2011 at 2:17 PM, Benjamin Root wrote:
>
>>
>>
>> On Fri, Jun 10, 2011 at 3:02 PM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Jun 10, 2011 at 1:50 PM, Benjamin Root wrote:
>>>
On Fri, Jun 10, 2011 at 2:17 PM, Benjamin Root wrote:
>
>
> On Fri, Jun 10, 2011 at 3:02 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Fri, Jun 10, 2011 at 1:50 PM, Benjamin Root wrote:
>>
>>> Came across an odd error while using numpy master. Note, my system is
>>> 3
On Friday, June 10, 2011, Olivier Delalleau wrote:
> It's ok to have two different dtypes (in the sense that "d1 is not d2") such
> that they represent the same kind of data (in the sense that d1 == d2).
Note that the memory addresses for int64, float32 and float64
accumulators did match the exp
2011/6/10 Benjamin Root
>
>
> On Fri, Jun 10, 2011 at 3:02 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Fri, Jun 10, 2011 at 1:50 PM, Benjamin Root wrote:
>>
>>> Came across an odd error while using numpy master. Note, my system is
>>> 32-bits.
>>>
>>> >>> import num
On Fri, Jun 10, 2011 at 3:02 PM, Charles R Harris wrote:
>
>
> On Fri, Jun 10, 2011 at 1:50 PM, Benjamin Root wrote:
>
>> Came across an odd error while using numpy master. Note, my system is
>> 32-bits.
>>
>> >>> import numpy as np
>> >>> type(np.sum([1, 2, 3], dtype=np.int32)) == np.int32
>>
It's ok to have two different dtypes (in the sense that "d1 is not d2") such
that they represent the same kind of data (in the sense that d1 == d2).
However I think your very first test should have returned True (for what
it's worth, it returns true with 1.5.1 on Windows 32 bit).
-=- Olivier
201
On Fri, Jun 10, 2011 at 1:50 PM, Benjamin Root wrote:
> Came across an odd error while using numpy master. Note, my system is
> 32-bits.
>
> >>> import numpy as np
> >>> type(np.sum([1, 2, 3], dtype=np.int32)) == np.int32
> False
> >>> type(np.sum([1, 2, 3], dtype=np.int64)) == np.int64
> True
>
Came across an odd error while using numpy master. Note, my system is
32-bits.
>>> import numpy as np
>>> type(np.sum([1, 2, 3], dtype=np.int32)) == np.int32
False
>>> type(np.sum([1, 2, 3], dtype=np.int64)) == np.int64
True
>>> type(np.sum([1, 2, 3], dtype=np.float32)) == np.float32
True
>>> typ
Dear folks,
I have some code that stopped working with 1.6.0 and I'm wondering if
there's a better way to replace it than what I came up with. Here's a
condensed version:
x = [()] # list containing an empty tuple; this isn't the only case,
but it's one that must be handled correctly
y = np
On Wed, Jun 8, 2011 at 9:49 PM, Travis Oliphant wrote:
> 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.
Thanks, Travis. I now know a l
On 06/10/2011 09:18 AM, Mark Wiebe wrote:
On Fri, Jun 10, 2011 at 12:56 AM, Ralf Gommers
mailto:ralf.gomm...@googlemail.com>> wrote:
On Fri, Jun 10, 2011 at 1:54 AM, Mark Wiebe mailto:mwwi...@gmail.com>> wrote:
On Thu, Jun 9, 2011 at 5:21 PM, Ralf Gommers
mailto:ralf.gomm
Unfortunately I can't flatten the arrays. I'm writing a library where the
user supplies an inner product function for two generic objects, and almost
always the inner product function does large array multiplications at some
point. The library doesn't get to know about the underlying arrays.
Thanks
On Fri, Jun 10, 2011 at 12:56 AM, Ralf Gommers
wrote:
>
>
> 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 <
>>
It may not work for you depending on your specific problem constraints, but
if you could flatten the arrays, then it would be a dot, and you could maybe
compute multiple such dot products by storing those flattened arrays into a
matrix.
-=- Olivier
2011/6/10 Brandt Belson
> Hi,
> Thanks for get
Hi,
Thanks for getting back to me.
I'm doing element wise multiplication, basically innerProduct =
numpy.sum(array1*array2) where array1 and array2 are, in general,
multidimensional. I need to do many of these operations, and I'd like to
split up the tasks between the different cores. I'm not using
ooh , my bad your right
didnt see that thank you
Olivier Delalleau-2 wrote:
>
> You are overriding your f1 function with a float (with
> "f1=f1(self.ptdata[i])"), so trying to call f1(xul) later will raise this
> exception.
>
> -=- Olivier
>
> 2011/6/10 jonasr
>
>>
>> Hello,
>> i have t
You are overriding your f1 function with a float (with
"f1=f1(self.ptdata[i])"), so trying to call f1(xul) later will raise this
exception.
-=- Olivier
2011/6/10 jonasr
>
> Hello,
> i have the following problem, the following code doesnt work
>
> def f1(x): return self.lgdata[2*i][0]*float(x)+s
Hello,
i have the following problem, the following code doesnt work
def f1(x): return self.lgdata[2*i][0]*float(x)+self.lgdata[2*i][1]
def f2(x): return self.lgdata[2*i+1][0]*float(x)+self.lgdata[2*i+1][1]
f1=f1(self.ptdata[i])
f2=f2(self.ptdata[i])
t=abs(f1-f2)
deltat.append(t)
temptot.append(f1
Hello,
i have the following problem, the following code doesnt work
def f1(x): return self.lgdata[2*i][0]*float(x)+self.lgdata[2*i][1]
def f2(x): return self.lgdata[2*i+1][0]*float(x)+self.lgdata[2*i+1][1]
f1=f1(self.ptdata[i])
2=f2(self.ptdata[i])
t=abs(f1-f2)
deltat.append(t)
temptot.append(f1)
41 matches
Mail list logo
