On Sun, 20 Dec 2009 21:02:02 -0800, Rami Chowdhury wrote:
>
> On Dec 20, 2009, at 17:41 , Peter Pearson wrote:
>
>> Why not use a good cipher, such as AES, to generate a pseudorandom
>> bit stream by encrypting successive integers?
>
> Isn't the Fortuna PRNG based around that approximate concept?
David Cournapeau wrote:
On Sun, Dec 20, 2009 at 6:47 PM, Lie Ryan wrote:
On 12/20/2009 2:53 PM, sturlamolden wrote:
On 20 Des, 01:46, Lie Ryan wrote:
Not necessarily, you only need to be certain that the two streams don't
overlap in any reasonable amount of time. For that purpose, you can u
On 2009-12-21 16:57 PM, r0g wrote:
sturlamolden wrote:
On 19 Des, 16:20, Carl Johan Rehn wrote:
How about mulit-core or (perhaps more exciting) GPU and CUDA? I must
admit that I am extremely interested in trying the CUDA-alternative.
Obviously, cuBLAS is not an option here, so what is the sa
sturlamolden wrote:
On 19 Des, 22:58, sturlamolden wrote:
If you pick two random states (using any PRNG), you need error-
checking that states are always unique, i.e. that each PRNG never
reaches the starting state of the other(s).
Another note on this:
Ideally, we would e.g. know how to fi
sturlamolden wrote:
On 19 Des, 16:20, Carl Johan Rehn wrote:
How about mulit-core or (perhaps more exciting) GPU and CUDA? I must
admit that I am extremely interested in trying the CUDA-alternative.
Obviously, cuBLAS is not an option here, so what is the safest route
for a novice parallel-pro
sturlamolden wrote:
On 19 Des, 14:06, Carl Johan Rehn wrote:
Matlab and numpy have (by chance?) the exact names for the same
functionality,
Common ancenstry, NumPy and Matlab borrowed the name from IDL.
LabView, Octave and SciLab uses the name randn as well.
So the basioc question is, h
sturlamolden wrote:
> On 19 Des, 16:20, Carl Johan Rehn wrote:
>
>> How about mulit-core or (perhaps more exciting) GPU and CUDA? I must
>> admit that I am extremely interested in trying the CUDA-alternative.
>>
>> Obviously, cuBLAS is not an option here, so what is the safest route
>> for a novi
On 2009-12-19 09:14 AM, Carl Johan Rehn wrote:
On Dec 19, 2:49 pm, sturlamolden wrote:
On 19 Des, 11:05, Carl Johan Rehn wrote:
I plan to port a Monte Carlo engine from Matlab to Python. However,
when I timed randn(N1, N2) in Python and compared it with Matlab's
randn, Matlab came out as a c
On 20 Des, 01:46, Lie Ryan wrote:
> Not necessarily, you only need to be certain that the two streams don't
> overlap in any reasonable amount of time. For that purpose, you can use
> a PRNG that have extremely high period like Mersenne Twister and puts
> the generators to very distant states.
E
On Dec 20, 2009, at 17:41 , Peter Pearson wrote:
> On Sun, 20 Dec 2009 07:26:03 +1100, Lie Ryan wrote:
>> On 12/20/2009 4:02 AM, Carl Johan Rehn wrote:
>>
>> Parallel PRNGs are an unsolved problem in computer science.
>>>
>>> Thanks again for sharing your knowledge. I had no idea. This mea
On Sun, 20 Dec 2009 07:26:03 +1100, Lie Ryan wrote:
> On 12/20/2009 4:02 AM, Carl Johan Rehn wrote:
>
> Parallel PRNGs are an unsolved problem in computer science.
>>
>> Thanks again for sharing your knowledge. I had no idea. This means
>> that if I want to speed up my application I have to go
On 12/21/2009 1:13 AM, David Cournapeau wrote:
But the OP case mostly like falls in your estimated 0.01% case. PRNG
quality is essential for reliable Monte Carlo procedures. I don't
think long period is enough to guarantee those good properties for //
random generators - at least it is not obviou
On Sun, Dec 20, 2009 at 6:47 PM, Lie Ryan wrote:
> On 12/20/2009 2:53 PM, sturlamolden wrote:
>>
>> On 20 Des, 01:46, Lie Ryan wrote:
>>
>>> Not necessarily, you only need to be certain that the two streams don't
>>> overlap in any reasonable amount of time. For that purpose, you can use
>>> a PR
On 12/20/2009 2:53 PM, sturlamolden wrote:
On 20 Des, 01:46, Lie Ryan wrote:
Not necessarily, you only need to be certain that the two streams don't
overlap in any reasonable amount of time. For that purpose, you can use
a PRNG that have extremely high period like Mersenne Twister and puts
the
On Sat, 19 Dec 2009 13:58:37 -0800, sturlamolden wrote:
> On 19 Des, 21:26, Lie Ryan wrote:
>
>> you can just start two PRNG at two distinct states
>
> No. You have to know for certain that the outputs don't overlap.
"For certain"? Why?
Presumably you never do a Monte Carlo simulation once, y
On 12/20/2009 8:58 AM, sturlamolden wrote:
On 19 Des, 21:26, Lie Ryan wrote:
you can just start two PRNG at two distinct states
No. You have to know for certain that the outputs don't overlap.
Not necessarily, you only need to be certain that the two streams don't
overlap in any reasonabl
On Sat, 19 Dec 2009 09:02:38 -0800, Carl Johan Rehn wrote:
> Well, in Matlab I used "tic; for i = 1:1000, randn(100, 1), end;
> toc" and in IPython i used a similar construct but with "time" instead
> of tic/(toc.
I don't know if this will make any significant difference, but for the
record
Lie Ryan wrote:
If you don't care about "repeatability" (which is already extremely
difficult in parallel processing even without random number generators),
you can just start two PRNG at two distinct states (and probably from
two different algorithms)
There's no need for different algorithm
On 19 Dec, 23:09, sturlamolden wrote:
> On 19 Des, 22:58, sturlamolden wrote:
>
> > If you pick two random states (using any PRNG), you need error-
> > checking that states are always unique, i.e. that each PRNG never
> > reaches the starting state of the other(s).
>
> Another note on this:
>
> I
On 19 Des, 22:58, sturlamolden wrote:
> If you pick two random states (using any PRNG), you need error-
> checking that states are always unique, i.e. that each PRNG never
> reaches the starting state of the other(s).
Another note on this:
Ideally, we would e.g. know how to find (analytically)
On 19 Des, 21:26, Lie Ryan wrote:
> you can just start two PRNG at two distinct states
No. You have to know for certain that the outputs don't overlap.
If you pick two random states (using any PRNG), you need error-
checking that states are always unique, i.e. that each PRNG never
reaches the s
On 12/20/2009 4:02 AM, Carl Johan Rehn wrote:
How did you time it?
Well, in Matlab I used "tic; for i = 1:1000, randn(100, 1), end;
toc" and in IPython i used a similar construct but with "time" instead
of tic/(toc.
Code?
Parallel PRNGs are an unsolved problem in computer science.
Tha
On Dec 19, 4:47 pm, sturlamolden wrote:
> On 19 Des, 16:20, Carl Johan Rehn wrote:
>
> > How about mulit-core or (perhaps more exciting) GPU and CUDA? I must
> > admit that I am extremely interested in trying the CUDA-alternative.
>
> > Obviously, cuBLAS is not an option here, so what is the safe
On 19 Des, 16:20, Carl Johan Rehn wrote:
> How about mulit-core or (perhaps more exciting) GPU and CUDA? I must
> admit that I am extremely interested in trying the CUDA-alternative.
>
> Obviously, cuBLAS is not an option here, so what is the safest route
> for a novice parallel-programmer?
The
On Sat, 19 Dec 2009 05:06:53 -0800, Carl Johan Rehn wrote:
> so I was very happy with numpy's implementation until I timed it.
How did you time it?
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
On Dec 19, 3:16 pm, sturlamolden wrote:
> On 19 Des, 14:06, Carl Johan Rehn wrote:
>
> > Matlab and numpy have (by chance?) the exact names for the same
> > functionality,
>
> Common ancenstry, NumPy and Matlab borrowed the name from IDL.
>
> LabView, Octave and SciLab uses the name randn as well
On Dec 19, 2:49 pm, sturlamolden wrote:
> On 19 Des, 11:05, Carl Johan Rehn wrote:
>
> > I plan to port a Monte Carlo engine from Matlab to Python. However,
> > when I timed randn(N1, N2) in Python and compared it with Matlab's
> > randn, Matlab came out as a clear winner with a speedup of 3-4 ti
On 19 Des, 14:06, Carl Johan Rehn wrote:
> Matlab and numpy have (by chance?) the exact names for the same
> functionality,
Common ancenstry, NumPy and Matlab borrowed the name from IDL.
LabView, Octave and SciLab uses the name randn as well.
> So the basioc question is, how can I speed up r
On 19 Des, 12:29, Steven D'Aprano wrote:
> Perhaps
> the Matlab random number generator is a low-quality generator which is
> fast but not very random. Python uses a very high quality RNG which is
> not cheap.
Marsaglia and Matlab's implementation of ziggurat uses a slightly
lower quality RNG fo
On 19 Des, 11:05, Carl Johan Rehn wrote:
> I plan to port a Monte Carlo engine from Matlab to Python. However,
> when I timed randn(N1, N2) in Python and compared it with Matlab's
> randn, Matlab came out as a clear winner with a speedup of 3-4 times.
> This was truly disappointing. I ran tthis t
On Dec 19, 12:29 pm, Steven D'Aprano wrote:
> On Sat, 19 Dec 2009 02:05:17 -0800, Carl Johan Rehn wrote:
> > Dear friends,
>
> > I plan to port a Monte Carlo engine from Matlab to Python. However, when
> > I timed randn(N1, N2) in Python and compared it with Matlab's randn,
>
> What's randn? I don
On Sat, 19 Dec 2009 02:05:17 -0800, Carl Johan Rehn wrote:
> Dear friends,
>
> I plan to port a Monte Carlo engine from Matlab to Python. However, when
> I timed randn(N1, N2) in Python and compared it with Matlab's randn,
What's randn? I don't know that function. I know the randint, random, and
Dear friends,
I plan to port a Monte Carlo engine from Matlab to Python. However,
when I timed randn(N1, N2) in Python and compared it with Matlab's
randn, Matlab came out as a clear winner with a speedup of 3-4 times.
This was truly disappointing. I ran tthis test on a Win32 machine and
without t
33 matches
Mail list logo
