Steve Lianoglou wrote:
> ===
> import numpy as N
> mat = N.zeros((10,10))
> rows = [0,1,2]
> cols = [4,5,6]
>
> for row in rows:
> mat[row,cols] += 1
>
>
>
> I found something on the lists from a few years back that was in
> reference to numeric or numarray that suggested doing some g
On 1/29/07, Steve Lianoglou <[EMAIL PROTECTED]> wrote:
> For example, say I have a 10x10 array and only want to add some
> number to the elements in the submatrix that consists of the [0,1,2]
> th rows, and [4,5,6]th colums.
Here's one way to do it:
i,j = N.mgrid[0:3,4:7]
mat[i,j] += 1
__
How about
mat[0:3, 4:7] += 1
-Sebastian
On 1/29/07, Steve Lianoglou <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I was just curious what the "correct" (fast) way to select and alter
> > a submatrix.
> >
> > For example, say I have a 10x10 array and only want to add some
> > number to the elements
How about
mat[0:3, 4:7] += 1
-Sebastian
On 1/29/07, Steve Lianoglou <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I was just curious what the "correct" (fast) way to select and alter
> a submatrix.
>
> For example, say I have a 10x10 array and only want to add some
> number to the elements in the submatr
Hi,
I was just curious what the "correct" (fast) way to select and alter
a submatrix.
For example, say I have a 10x10 array and only want to add some
number to the elements in the submatrix that consists of the [0,1,2]
th rows, and [4,5,6]th colums.
You can imagine that those rows/cols sele
| Date: Mon, 29 Jan 2007 15:55:06 -0700
| From: Travis Oliphant <[EMAIL PROTECTED]>
|
| James A. Bednar wrote:
|
| >Hi,
| >
| >Does anyone know whether it is possible to pickle and unpickle numpy
| >ufuncs?
| >
| Not directly. Ufuncs are a built-in type and do not have the required
Travis Oliphant wrote:
> Why don't you store the name of the ufunc instead:
>
> def __init__(self, a):
> self._a = a.__name__
>
> Then, whenever you are going to use the ufunc you do
>
> import numpy
> func = getattr(numpy,self._a)
>
> Then, pickle should work.
Or you can register pickle
I think it's time for the 1.0.2 release of NumPy.
What outstanding issues need to be resolved before we do it?
Hopefully, we can do it by the end of the week.
-Travis
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scip
James A. Bednar wrote:
>Hi,
>
>Does anyone know whether it is possible to pickle and unpickle numpy
>ufuncs?
>
Not directly. Ufuncs are a built-in type and do not have the required
__reduce__ method needed to be pickleable. It could be added, but
hasn't been.
> I can't find anything about
On a 64-bit Intel Core2 Duo running Debian unstable with atlas3 (there
is no specific atlas3-sse2 for AMD64 Debian, although I think that it
is included) everything checks out fine:
eiger:~$ uname -a
Linux eiger 2.6.18-3-amd64 #1 SMP Sun Dec 10 19:57:44 CET 2006 x86_64
GNU/Linux
eiger:~$ cat /
On 1/29/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> Keith Goodman wrote:
> > Here's a unit test for the problem. I am distributing it in hopes of
> > raising awareness of the problem. (What color should I make the
> > Repeatability Wristbands?)
> >
> > I am sure others are having this problem with
Hi,
Does anyone know whether it is possible to pickle and unpickle numpy
ufuncs? I can't find anything about that on scipy.org or the mailing
list archives. I have several important pieces of code that accept a
numpy ufunc as an argument and later apply it to some data, while
keeping a copy of t
Keith Goodman wrote:
> Here's a unit test for the problem. I am distributing it in hopes of
> raising awareness of the problem. (What color should I make the
> Repeatability Wristbands?)
>
> I am sure others are having this problem without even knowing it.
Another datapoint using atlas3-base on U
On 1/29/07, Russell E. Owen <[EMAIL PROTECTED]> wrote:
> On a PPC MacOS X box I don't see an error. If I append
> if __name__ == "__main__":
> run()
> to your test code and then run it I get:
>
> repeatability #1 ... ok
> repeatability #2 ... ok
> repeatability #3 ... ok
>
> ---
On a PPC MacOS X box I don't see an error. If I append
if __name__ == "__main__":
run()
to your test code and then run it I get:
repeatability #1 ... ok
repeatability #2 ... ok
repeatability #3 ... ok
--
Ran 3 tests in 0.156s
Keith Goodman wrote:
> On 1/29/07, Keith Goodman <[EMAIL PROTECTED]> wrote:
>> On 1/29/07, Keith Goodman <[EMAIL PROTECTED]> wrote:
>>> On 1/29/07, Charles R Harris <[EMAIL PROTECTED]> wrote:
>>>
That's odd, the LSB bit of the double precision mantissa is only about
2.2e-16, so you can'
On 1/29/07, Keith Goodman <[EMAIL PROTECTED]> wrote:
> On 1/29/07, Keith Goodman <[EMAIL PROTECTED]> wrote:
> > On 1/29/07, Keith Goodman <[EMAIL PROTECTED]> wrote:
> > > On 1/29/07, Charles R Harris <[EMAIL PROTECTED]> wrote:
> > >
> > > > That's odd, the LSB bit of the double precision mantissa
On 1/29/07, Keith Goodman <[EMAIL PROTECTED]> wrote:
> On 1/29/07, Keith Goodman <[EMAIL PROTECTED]> wrote:
> > On 1/29/07, Charles R Harris <[EMAIL PROTECTED]> wrote:
> >
> > > That's odd, the LSB bit of the double precision mantissa is only about
> > > 2.2e-16, so you can't *get* differences as
On 1/29/07, Keith Goodman <[EMAIL PROTECTED]> wrote:
> On 1/29/07, Charles R Harris <[EMAIL PROTECTED]> wrote:
>
> > That's odd, the LSB bit of the double precision mantissa is only about
> > 2.2e-16, so you can't *get* differences as small as 8.4e-22 without about
> > 70 bit mantissa's. Hmmm, a
On 1/29/07, Charles R Harris <[EMAIL PROTECTED]> wrote:
> That's odd, the LSB bit of the double precision mantissa is only about
> 2.2e-16, so you can't *get* differences as small as 8.4e-22 without about
> 70 bit mantissa's. Hmmm, and extended double precision only has 63 bit
> mantissa's. Are
On 1/29/07, Keith Goodman <[EMAIL PROTECTED]> wrote:
On 1/27/07, Charles R Harris <[EMAIL PROTECTED]> wrote:
> Oddly, the relative error is always the same:
>
> 98 z different 2.0494565872e-16
> 99 z different 2.0494565872e-16
>
> Which is nearly the same as the double precision 2.220446049250
On 1/27/07, Charles R Harris <[EMAIL PROTECTED]> wrote:
> Oddly, the relative error is always the same:
>
> 98 z different 2.0494565872e-16
> 99 z different 2.0494565872e-16
>
> Which is nearly the same as the double precision 2.2204460492503131e-16, the
> difference being due to the fact that th
On 1/27/07, Keith Goodman <[EMAIL PROTECTED]> wrote:
I get slightly different results when I repeat a calculation. In a
long simulation the differences snowball and swamp the effects I am
trying to measure.
Here's a unit test for the problem. I am distributing it in hopes of
raising awareness o
Sorry...this somehow ended up in the wrong place. Apologies...I'm still getting
a feel for how this query system works!
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Thanks to all that responded. Yes...I need to look into pre-generating
all of the random numbers that may be needed. It will not be trivial in
the case of this particular application I am implementing, but is
absolutely worth considering.
Robert Kern's response was more along the lines of wha
25 matches
Mail list logo