On Thu, Jul 31, 2014 at 1:30 PM, Markus Neteler wrote:
> On Sun, Jul 27, 2014 at 1:58 AM, Glynn Clements
> wrote:
>> Glynn Clements wrote:
>>> > I wonder if there are any modules in core or addons which need to be
>>> > updated.
>>>
>>> The following are candidates for conversion:
>>
>> Most uses
On Sun, Jul 27, 2014 at 1:58 AM, Glynn Clements
wrote:
> Glynn Clements wrote:
>> > I wonder if there are any modules in core or addons which need to be
>> > updated.
>>
>> The following are candidates for conversion:
>
> Most uses of rand, random, lrand48, etc have been replaced in r61415
> and r
Glynn Clements wrote:
> > I wonder if there are any modules in core or addons which need to be
> > updated.
>
> The following are candidates for conversion:
Most uses of rand, random, lrand48, etc have been replaced in r61415
and r61416.
Many of these modules seeded the RNG from either the clo
Anna Petrášová wrote:
> I wonder if there are any modules in core or addons which need to be
> updated.
The following are candidates for conversion:
lib/gmath/rand1.cdrand48
raster/r.random/creat_rand.c lrand48
vector/v.kcv/main.c
On Tue, Jul 22, 2014 at 10:07 PM, Anna Petrášová
wrote:
>
>
>
> On Tue, Jul 22, 2014 at 8:14 PM, Glynn Clements
> wrote:
>
>>
>> Glynn Clements wrote:
>>
>> > I'm inclined to add both an option (to specify a seed, replacing the
>> > environment variable) and a flag (to seed from the system clock
On Tue, Jul 22, 2014 at 8:14 PM, Glynn Clements
wrote:
> r61353 changes r.mapcalc so that seeding is performed via seed= or -s.
> The seed (whether specified by seed= or generated for -s) is added to
> the history (for r.mapcalc; r3.mapcalc's create_history() function is
> a stub; do 3D rasters h
On Tue, Jul 22, 2014 at 8:14 PM, Glynn Clements
wrote:
>
> Glynn Clements wrote:
>
> > I'm inclined to add both an option (to specify a seed, replacing the
> > environment variable) and a flag (to seed from the system clock or
> > whatever), and having the PRNG generate a fatal error if neither o
Glynn Clements wrote:
> I'm inclined to add both an option (to specify a seed, replacing the
> environment variable) and a flag (to seed from the system clock or
> whatever), and having the PRNG generate a fatal error if neither of
> those are used.
This is now done.
r61350 adds the lrand48/mra
Vaclav Petras wrote:
> Anyway, the reproducibility would be really nice considering GRASS
> scientific audience, however are you sure that different systems will give
> same random number for the same seed?
They will from now on, because I've replaced the use of the system's
PRNG (either rand or
On 22-07-14 23:31, Markus Neteler wrote:
On Tue, Jul 22, 2014 at 11:19 PM, Paulo van Breugel wrote:
On 22-07-14 22:58, Glynn Clements wrote:
And when issue of usability doesn't even get considered until a few
years later when the user (or a colleague) gets an email suggesting
the results can't
On Tue, Jul 22, 2014 at 11:19 PM, Paulo van Breugel wrote:
> On 22-07-14 22:58, Glynn Clements wrote:
>> And when issue of usability doesn't even get considered until a few
>> years later when the user (or a colleague) gets an email suggesting
>> the results can't be be reproduced ...?
>>
>> I'm in
On 22-07-14 22:58, Glynn Clements wrote:
Markus Neteler wrote:
- if the user needs reproducability, then have a env var to enable that.
And when issue of usability doesn't even get considered until a few
years later when the user (or a colleague) gets an email suggesting
the results can't be
On Tue, Jul 22, 2014 at 4:58 PM, Glynn Clements
wrote:
> Markus Neteler wrote:
>
> > - if the user needs reproducability, then have a env var to enable that.
>
> And when issue of usability doesn't even get considered until a few
> years later when the user (or a colleague) gets an email suggesti
On Tue, Jul 22, 2014 at 4:39 PM, Glynn Clements
wrote:
>
> Paulo van Breugel wrote:
>
> > And it seems to be the default behaviour by python/numpy:
>
> It is, but ...
>
> > >>> import numpy as np
> > >>> np.random.random()
> > 0.8351426142559701
> > >>> np.random.random()
> > 0.481382344199839
Markus Neteler wrote:
> - if the user needs reproducability, then have a env var to enable that.
And when issue of usability doesn't even get considered until a few
years later when the user (or a colleague) gets an email suggesting
the results can't be be reproduced ...?
I'm inclined to add bo
Paulo van Breugel wrote:
> And it seems to be the default behaviour by python/numpy:
It is, but ...
> >>> import numpy as np
> >>> np.random.random()
> 0.8351426142559701
> >>> np.random.random()
> 0.4813823441998394
> >>> np.random.random()
> 0.7279314267025369
... this example doesn't de
On 21-07-14 19:01, Markus Neteler wrote:
On Sun, Jul 6, 2014 at 12:25 AM, Glynn Clements
wrote:
Glynn Clements wrote:
...
In ticket #2272, I attached a portable implementation of lrand48(). If
desired, we could add this to libgis and use that in preference to any
implementation-specific PRN
On Sun, Jul 6, 2014 at 12:25 AM, Glynn Clements
wrote:
>> Glynn Clements wrote:
...
> In ticket #2272, I attached a portable implementation of lrand48(). If
> desired, we could add this to libgis and use that in preference to any
> implementation-specific PRNG.
This would be excellent.
>>> If y
On Sun, Jul 6, 2014 at 12:34 AM, Glynn Clements
wrote:
>
> Paulo van Breugel wrote:
>
> > Just a quick additional question, how to set this GRASS_RND_SEED from
> > within a python script (I want to add the option to set the seed with a
> > seed parameter in my script, as suggested in the previous
Paulo van Breugel wrote:
> Just a quick additional question, how to set this GRASS_RND_SEED from
> within a python script (I want to add the option to set the seed with a
> seed parameter in my script, as suggested in the previous email).
You can modify os.environ prior to calling it, e.g.
Vaclav Petras wrote:
> > > Shouldn't the seed not be generated on e.g, OS time,
> > > which would ensure that each run would give a different result?
> >
> > No. The reason is to provide reproducibility. Anyone running the same
> > command with the same data should obtain the same result.
>
> Do
On Thu, Jul 3, 2014 at 9:39 AM, Paulo van Breugel
wrote:
> Just a quick additional question, how to set this GRASS_RND_SEED from
> within a python script (I want to add the option to set the seed with a
> seed parameter in my script, as suggested in the previous email).
>
Concerning the question
Just a quick additional question, how to set this GRASS_RND_SEED from
within a python script (I want to add the option to set the seed with a
seed parameter in my script, as suggested in the previous email).
On Thu, Jul 3, 2014 at 8:55 AM, Paulo van Breugel
wrote:
>
> On 03-07-14 03:43, Vaclav
On 03-07-14 03:43, Vaclav Petras wrote:
On Wed, Jul 2, 2014 at 8:15 PM, Glynn Clements
mailto:gl...@gclements.plus.com>> wrote:
> Shouldn't the seed not be generated on e.g, OS time,
> which would ensure that each run would give a different result?
No. The reason is to provide r
On Wed, Jul 2, 2014 at 8:15 PM, Glynn Clements
wrote:
> > Shouldn't the seed not be generated on e.g, OS time,
> > which would ensure that each run would give a different result?
>
> No. The reason is to provide reproducibility. Anyone running the same
> command with the same data should obtain t
Paulo van Breugel wrote:
> When I run several times e.g., r.mapcalc "a = rand(0,100)"
>
> I am always getting exactly the same layer. In the help file it reads:
>
> "The environment variable GRASS_RND_SEED is read to initialize the random
> number generator"
>
> But what does it mean.
The val
When I run several times e.g., r.mapcalc "a = rand(0,100)"
I am always getting exactly the same layer. In the help file it reads:
"The environment variable GRASS_RND_SEED is read to initialize the random
number generator"
But what does it mean. Shouldn't the seed not be generated on e.g, OS time
27 matches
Mail list logo
