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)
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)
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 jonas.rueb...@web.de
Hello,
i have the following problem, the following code doesnt work
def f1(x): return
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 jonas.rueb...@web.de
Hello,
i
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
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 bbel...@princeton.edu
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.
On 06/10/2011 09:18 AM, Mark Wiebe wrote:
On Fri, Jun 10, 2011 at 12:56 AM, Ralf Gommers
ralf.gomm...@googlemail.com mailto:ralf.gomm...@googlemail.com wrote:
On Fri, Jun 10, 2011 at 1:54 AM, Mark Wiebe mwwi...@gmail.com
mailto:mwwi...@gmail.com wrote:
On Thu, Jun 9, 2011 at
On Wed, Jun 8, 2011 at 9:49 PM, Travis Oliphant oliph...@enthought.com 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,
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 =
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
type(np.sum([1,
On Fri, Jun 10, 2011 at 1:50 PM, Benjamin Root ben.r...@ou.edu 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
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
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 ben.r...@ou.edu 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],
2011/6/10 Benjamin Root ben.r...@ou.edu
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 ben.r...@ou.edu wrote:
Came across an odd error while using numpy master. Note, my system is
32-bits.
import
On Friday, June 10, 2011, Olivier Delalleau sh...@keba.be 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
On Fri, Jun 10, 2011 at 2:17 PM, Benjamin Root ben.r...@ou.edu 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 ben.r...@ou.edu wrote:
Came across an odd error while using numpy master. Note, my
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 ben.r...@ou.edu 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
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 mwwi...@gmail.com wrote:
Here's a possible
On Fri, Jun 10, 2011 at 10:03 AM, Bruce Southey bsout...@gmail.com wrote:
**
snip
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
On Fri, Jun 10, 2011 at 3:43 PM, Benjamin Root ben.r...@ou.edu 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 ben.r...@ou.edu wrote:
On Fri, Jun 10, 2011 at 3:02 PM, Charles R Harris
On Thu, Jun 9, 2011 at 1:44 AM, Pierre GM pgmdevl...@gmail.com 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
On Thu, Jun 9, 2011 at 1:27 PM, Christopher Barker chris.bar...@noaa.govwrote:
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
On Thu, Jun 9, 2011 at 3:17 PM, Wes McKinney wesmck...@gmail.com wrote:
On Wed, Jun 8, 2011 at 8:53 PM, Mark Wiebe mwwi...@gmail.com wrote:
On Wed, Jun 8, 2011 at 4:57 AM, Wes McKinney wesmck...@gmail.com
wrote:
snip
So in summary, w.r.t. time series data and datetime, the only
2011/6/10 Charles R Harris charlesr.har...@gmail.com
On Fri, Jun 10, 2011 at 3:43 PM, Benjamin Root ben.r...@ou.edu 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 ben.r...@ou.edu wrote:
On
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 interface
2011/6/10 Charles R Harris charlesr.har...@gmail.com
On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau sh...@keba.be wrote:
2011/6/10 Charles R Harris charlesr.har...@gmail.com
On Fri, Jun 10, 2011 at 3:43 PM, Benjamin Root ben.r...@ou.edu wrote:
On Fri, Jun 10, 2011 at 3:24 PM,
On Fri, Jun 10, 2011 at 6:35 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau sh...@keba.be 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
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, 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 happens if
2011/6/10 Olivier Delalleau sh...@keba.be
2011/6/10 Charles R Harris charlesr.har...@gmail.com
On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau sh...@keba.be wrote:
2011/6/10 Charles R Harris charlesr.har...@gmail.com
On Fri, Jun 10, 2011 at 3:43 PM, Benjamin Root ben.r...@ou.edu
On Fri, Jun 10, 2011 at 8:51 PM, Keith Goodman kwgood...@gmail.com wrote:
On Fri, Jun 10, 2011 at 6:35 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau sh...@keba.be
wrote:
But isn't it a bug if numpy.dtype('i') != numpy.dtype('l')
On Fri, Jun 10, 2011 at 9:03 PM, Pauli Virtanen p...@iki.fi 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
Note
On Fri, Jun 10, 2011 at 9:29 PM, Olivier Delalleau sh...@keba.be wrote:
2011/6/10 Olivier Delalleau sh...@keba.be
2011/6/10 Charles R Harris charlesr.har...@gmail.com
On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau sh...@keba.bewrote:
2011/6/10 Charles R Harris
2011/6/10 Benjamin Root ben.r...@ou.edu
On Fri, Jun 10, 2011 at 9:29 PM, Olivier Delalleau sh...@keba.be wrote:
2011/6/10 Olivier Delalleau sh...@keba.be
2011/6/10 Charles R Harris charlesr.har...@gmail.com
On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau sh...@keba.bewrote:
On Fri, Jun 10, 2011 at 9:10 PM, Benjamin Root ben.r...@ou.edu wrote:
On Fri, Jun 10, 2011 at 9:29 PM, Olivier Delalleau sh...@keba.be wrote:
2011/6/10 Olivier Delalleau sh...@keba.be
2011/6/10 Charles R Harris charlesr.har...@gmail.com
On Fri, Jun 10, 2011 at 5:19 PM, Olivier
On Fri, Jun 10, 2011 at 10:34 PM, Olivier Delalleau sh...@keba.be wrote:
2011/6/10 Benjamin Root ben.r...@ou.edu
On Fri, Jun 10, 2011 at 9:29 PM, Olivier Delalleau sh...@keba.be wrote:
2011/6/10 Olivier Delalleau sh...@keba.be
2011/6/10 Charles R Harris charlesr.har...@gmail.com
On
On Fri, Jun 10, 2011 at 9:55 PM, Benjamin Root ben.r...@ou.edu wrote:
On Fri, Jun 10, 2011 at 8:51 PM, Keith Goodman kwgood...@gmail.comwrote:
On Fri, Jun 10, 2011 at 6:35 PM, Charles R Harris
charlesr.har...@gmail.com wrote:
On Fri, Jun 10, 2011 at 5:19 PM, Olivier Delalleau
38 matches
Mail list logo
