Mark P. Miller wrote:
Robert: Just a thought on this topic:
Would it be possible for the Scipy folks to add a new module based
solely off your old mtrand code (pre-broadcast)? I have to say that the
mtrand code from numpy 0.9.8 has some excellent advantages over the core
python random
Travis Oliphant wrote:
I've just added a faster path through the random-number generators for
scalar parameters to the SVN code tree.
It would be great if those who use this could check to see if
1) it is correct
2) it is indeed faster for scalar parameters
It's faster, certainly. I'll
On 3/19/07, Travis Oliphant [EMAIL PROTECTED] wrote:
Mark P. Miller wrote:
Robert: Just a thought on this topic:
Would it be possible for the Scipy folks to add a new module based
solely off your old mtrand code (pre-broadcast)? I have to say that the
mtrand code from numpy 0.9.8 has some
On 3/12/07, Travis Oliphant [EMAIL PROTECTED] wrote:
I'm not convinced that the broadcasting is causing the slow-downs.
Currently, the code has two path-ways. One gets called when the inputs
are scalars which is equivalent to the old code and the second gets
called when broadcasting is
On 3/14/07, Daniel Mahler [EMAIL PROTECTED] wrote:
On 3/12/07, Travis Oliphant [EMAIL PROTECTED] wrote:
I'm not convinced that the broadcasting is causing the slow-downs.
Currently, the code has two path-ways. One gets called when the inputs
are scalars which is equivalent to the old code
Mark P. Miller wrote:
Robert: Just a thought on this topic:
Would it be possible for the Scipy folks to add a new module based
solely off your old mtrand code (pre-broadcast)? I have to say that the
mtrand code from numpy 0.9.8 has some excellent advantages over the core
python random
Robert: Just a thought on this topic:
Would it be possible for the Scipy folks to add a new module based
solely off your old mtrand code (pre-broadcast)? I have to say that the
mtrand code from numpy 0.9.8 has some excellent advantages over the core
python random number generators.
This
Mark P. Miller wrote:
Robert: Just a thought on this topic:
Would it be possible for the Scipy folks to add a new module based
solely off your old mtrand code (pre-broadcast)? I have to say that the
mtrand code from numpy 0.9.8 has some excellent advantages over the core
python random
This discussion has much in common with a previous thread that I started
(When and where to use Numpy...).
I fully admit to being a naive numpy user, but it seems to me that it
would be helpful if the documentation provided some explicit statements
to inform potential users about the best
Mark P. Miller wrote:
As an aside, are the random number generators from scipy.random the same
as those for numpy.random? If not, will those of us who need to just
use a few random numbers here and there throughout our code (we don't
need arrays of random numbers or broadcasting abilities)
On 09/03/07, Robert Kern [EMAIL PROTECTED] wrote:
Mark P. Miller wrote:
As an aside, are the random number generators from scipy.random the same
as those for numpy.random? If not, will those of us who need to just
use a few random numbers here and there throughout our code (we don't
need
Robert Kern wrote:
scipy.random is not a package. scipy/__init__.py does a from numpy
import *
and thus pulls in numpy.random.
Got it...and one more question:
What about using something like
from numpy.random import mtrand
And then using mtrand.seed and mtrand.normal in code?
Would this
Mark P. Miller wrote:
Robert Kern wrote:
scipy.random is not a package. scipy/__init__.py does a from numpy
import *
and thus pulls in numpy.random.
Got it...and one more question:
What about using something like
from numpy.random import mtrand
And then using mtrand.seed and
Anne Archibald wrote:
On 09/03/07, Robert Kern [EMAIL PROTECTED] wrote:
Mark P. Miller wrote:
As an aside, are the random number generators from scipy.random the same
as those for numpy.random? If not, will those of us who need to just
use a few random numbers here and there throughout our
Oh dear, sorry, I should have read your email more carefully.
Matthew
On 3/8/07, Daniel Mahler [EMAIL PROTECTED] wrote:
On 3/8/07, Matthew Brett [EMAIL PROTECTED] wrote:
My problem is not space, but time.
I am creating a small array over and over,
and this is turning out to be a
On 3/8/07, Charles R Harris [EMAIL PROTECTED] wrote:
The slow down is probably related to this from a previous thread:
In [46]: def test1() :
: x = normal(0,1,1000)
:
In [47]: def test2() :
: for i in range(1000) :
: x = normal(0,1)
In [50]:
Daniel Mahler wrote:
On 3/8/07, Charles R Harris [EMAIL PROTECTED] wrote:
Robert thought this might relate to Travis' changes adding broadcasting to
the random number generator. It does seem certain that generating small
arrays of random numbers has a very high overhead.
Does that mean
On 3/8/07, Robert Kern [EMAIL PROTECTED] wrote:
Daniel Mahler wrote:
On 3/8/07, Charles R Harris [EMAIL PROTECTED] wrote:
Robert thought this might relate to Travis' changes adding broadcasting
to
the random number generator. It does seem certain that generating small
arrays of random
Is there an efficient way to fill an existing array with random
numbers without allocating a new array?
thanks
Daniel
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Daniel Mahler wrote:
Is there an efficient way to fill an existing array with random
numbers without allocating a new array?
No, sorry.
--
Robert Kern
I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as
My problem is not space, but time.
I am creating a small array over and over,
and this is turning out to be a bottleneck.
My experiments suggest that problem is the allocation,
not the random number generation.
Allocating all the arrays as one n+1 dim and grabbing rows from it
is faster than
On 07/03/07, Daniel Mahler [EMAIL PROTECTED] wrote:
My problem is not space, but time.
I am creating a small array over and over,
and this is turning out to be a bottleneck.
My experiments suggest that problem is the allocation,
not the random number generation.
Allocating all the arrays as
My problem is not space, but time.
I am creating a small array over and over,
and this is turning out to be a bottleneck.
How about making one large random number array and taking small views?
Matthew
___
Numpy-discussion mailing list
On 3/7/07, Daniel Mahler [EMAIL PROTECTED] wrote:
My problem is not space, but time.
I am creating a small array over and over,
and this is turning out to be a bottleneck.
My experiments suggest that problem is the allocation,
not the random number generation.
Allocating all the arrays as one
24 matches
Mail list logo
