Chris Toczycki wrote:
> I am looking to find a solution to a problem and believe that Numpy may
> help. I'd appreciate some advice and/or direction and I'll pursue from
> there.
>
> The problem is that I am looking for a most efficient solution where I
> have to select 25 solutions where the high
I made a few minor adjustments to make sure that Pyrex 0.9.5 builds mtrand.pyx
cleanly. It's a bit pickier than previous versions.
However, it also generates C code that compiles without warnings! Consequently,
I recommend that all numpy developers should upgrade to Pyrex 0.9.5 and cease
using the
I am looking to find a solution to a problem and believe that Numpy may
help. I'd appreciate some advice and/or direction and I'll pursue from
there.
The problem is that I am looking for a most efficient solution where I have
to select 25 solutions where the highest pair-covariance value is th
Theres also numpy.tile which is like a repmat generalized to N-dim.
--bb
On 1/27/07, Sven Schreiber <[EMAIL PROTECTED]> wrote:
> Sven Schreiber schrieb:
> > Hi,
> >
> > the kron(a,b) function seems to allow shapes such as (0,x) or (y,0) only
> > for the second argument b, not for the first argumen
On 1/27/07, Fernando Perez <[EMAIL PROTECTED]> wrote:
> It's definitely looking like something SMP related: on my laptop, with
> everything other than the hardware being identical (Linux distro,
> kernel, numpy build, etc), I can't make it fail no matter how I muck
> with it. I always get '0 diffe
On 1/27/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> Fernando Perez wrote:
>
> > That's it. One comment char removed, and something that's done
> > /after/ the tests are actually executed.
> >
> > That kind of 'I add a printf() call and the bug disappears' is
> > unpleasantly reminiscent of lurkin
Fernando Perez wrote:
> That's it. One comment char removed, and something that's done
> /after/ the tests are actually executed.
>
> That kind of 'I add a printf() call and the bug disappears' is
> unpleasantly reminiscent of lurking pointer errors in C code...
Heh. Fantastic. It might be wort
On Sat, Jan 27, 2007 at 03:11:58PM -0700, Charles R Harris wrote:
> So this looks like an error in the LSB of the floating number. Could be
> rounding, could be something not reset quite right. I'm thinking possibly
> hardware at this time, maybe compiler.
>
> Linux fedora 2.6.19-1.2895.fc6 #1 SMP
On Sat, Jan 27, 2007 at 04:11:59PM -0700, Fernando Perez wrote:
> OK, this is weird. I modified the repeat code a little to ease
> collecting of results, and all of a sudden the differences went away.
> If you look at the attached code, here's what happens for me:
>
> a) If I have line 77 like th
Charles R Harris wrote:
> Hmmm, and your problem machine is running smp linux. As is mine; fedora
> uses smp even on single processor machines these days. I think we could
> use more data here comparing
>
> OSX
[today]$ python repeat.py
---
On 1/27/07, Fernando Perez <[EMAIL PROTECTED]> wrote:
On 1/27/07, Fernando Perez <[EMAIL PROTECTED]> wrote:
> On 1/27/07, Charles R Harris <[EMAIL PROTECTED]> wrote:
>
> > Hmmm, and your problem machine is running smp linux. As is mine;
fedora uses
> > smp even on single processor machines these
On Sat, Jan 27, 2007 at 04:00:33PM -0700, Charles R Harris wrote:
> Hmmm, and your problem machine is running smp linux. As is mine; fedora uses
> smp even on single processor machines these days. I think we could use more
> data here comparing
It runs fine on this Ubuntu/Edgy machine, though:
Li
On 1/27/07, Fernando Perez <[EMAIL PROTECTED]> wrote:
> On 1/27/07, Charles R Harris <[EMAIL PROTECTED]> wrote:
>
> > Hmmm, and your problem machine is running smp linux. As is mine; fedora uses
> > smp even on single processor machines these days. I think we could use more
> > data here comparing
On 1/27/07, Charles R Harris <[EMAIL PROTECTED]> wrote:
Hmmm, and your problem machine is running smp linux. As is mine; fedora uses
smp even on single processor machines these days. I think we could use more
data here comparing
OSX
Linux (single, smp)
Window
OK, this is weird. I modified th
On 1/27/07, Stefan van der Walt <[EMAIL PROTECTED]> wrote:
On Sat, Jan 27, 2007 at 03:11:58PM -0700, Charles R Harris wrote:
> Does anyone else see this happening?
>
>
> Yes,
>
> test1: 0 differences
> test2: 51 differences
> test3: 0 differences
>
> Oddly, the relative error is alway
Sven Schreiber schrieb:
> Hi,
>
> the kron(a,b) function seems to allow shapes such as (0,x) or (y,0) only
> for the second argument b, not for the first argument a. (See below for
> examples.)
>
> Maybe it's too harsh to call it a bug because the result is typically
> not defined mathematically.
On Sat, Jan 27, 2007 at 03:11:58PM -0700, Charles R Harris wrote:
> Does anyone else see this happening?
>
>
> Yes,
>
> test1: 0 differences
> test2: 51 differences
> test3: 0 differences
>
> Oddly, the relative error is always the same:
>
> 98 z different 2.0494565872e-16
> 99 z di
Hi Mark
On Fri, Jan 26, 2007 at 10:17:58AM -0700, Mark P. Miller wrote:
> I've recently been working with numpy's random number generators and
> noticed that python's core random number generator is faster than
> numpy's for the uniform distribution.
>
> In other words,
>
> for a in range(1000
On 1/27/07, Stefan <[EMAIL PROTECTED]> wrote:
I can't reproduce this under Linux, r3510. Output is
test1: 0 differences
test2: 0 differences
test3: 0 differences
Does anyone else see this happening?
Yes,
test1: 0 differences
test2: 51 differences
test3: 0 differences
Oddly, t
Mark P. Miller wrote:
> Greetings:
>
> I've recently been working with numpy's random number generators and
> noticed that python's core random number generator is faster than
> numpy's for the uniform distribution.
>
> In other words,
>
> for a in range(100):
> b = random.random()
Martin Spacek schrieb:
> Just a note that I've copied over the 1.0.1 release notes from SourceForge:
>
> http://sourceforge.net/project/shownotes.php?group_id=1369&release_id=468153
>
> over to the wiki:
>
> http://scipy.org/ReleaseNotes/NumPy_1.0
Thank you!
>
> Should 1.0.1 get its own page,
On Fri, 26 Jan 2007 10:17:58 -0700
"Mark P. Miller" <[EMAIL PROTECTED]> wrote:
>
> for a in range(100):
> b = numpy.random.rand()#numpy code
what about numpy.random.rand(100) ?
Simon.
___
Numpy-discussion mailing list
Numpy-discussion
Greetings:
I've recently been working with numpy's random number generators and
noticed that python's core random number generator is faster than
numpy's for the uniform distribution.
In other words,
for a in range(100):
b = random.random()#core python code
is substantially faste
I can't reproduce this under Linux, r3510. Output is
test1: 0 differences
test2: 0 differences
test3: 0 differences
Does anyone else see this happening?
Regards
Stéfan
On Sat, Jan 27, 2007 at 12:25:18PM -0800, Keith Goodman wrote:
> I get slightly different results when I repeat a calcul
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.
In the attach script there are three tests.
In test1, I construct matrices x and y and then repeatedly calculate z
= calc(x,y). The result z i
25 matches
Mail list logo
