Hello,
currently [random] uses a fixed value for initialisation. This leads to the same sequence of values all the time.
https://github.com/pure-data/pure-data/blob/c0cd34924a50bdd1cc37dfb6b01f9be0...
My guess is, that most users probably expect at least different seed values every time.
Maybe the help file should explicitely state the behaviour or a different way for deriving the initial seed should be used, e.g. taking the local time. Or a better PRNG could be used as well.
If we take the solution to initialize [random] with a different seed each time, an explanation on how to revert to the old behaviour of a seed value of 1489853723 should be mentioned in the help.
I could tackle that, but would like a discussion about that before coding.
Thanks, Thomas
Hi Thomas,
- Thomas Mayer thomas@residuum.org [2022-12-11 21:20]:
[...]
My guess is, that most users probably expect at least different seed values every time.
Maybe the help file should explicitely state the behaviour or a different way for deriving the initial seed should be used, e.g. taking the local time. Or a better PRNG could be used as well.
If we take the solution to initialize [random] with a different seed each time, an explanation on how to revert to the old behaviour of a seed value of 1489853723 should be mentioned in the help.
I think the main thing to worry about is if any of the patches written in the last 20+ years will stop working in the way intended by a such a modification.
I loosely remember that someone somewhen showed how to get a different seed every time using an abstraction. If such a solution exists in vanilla Pd, it could be added as a solution to the docs perhaps?
well it used to be the case that it was difficult to save per-abstraction parameters. with the addition of [savestate]I don't think that's as much of a factor anymore.
In the past you could have a simple abstraction that could increment a value held in a message box to supply a different seed everytime a patch was loaded. But now you could do basically the same with [savestate] I think. (and don't have to store save state outside the abstraction yourself) of course the most common suggestion is to use [date] and [time] from zexy. maybe the better solution is to put those objects into vanilla.. because such an abstraction would be very simple also.
-seb -----Original Message----- From: Peter P. peterparker@fastmail.com To: pd-list@lists.iem.at Sent: Sun, Dec 11, 2022 2:22 pm Subject: Re: [PD] [random] and seed value
Hi Thomas,
- Thomas Mayer thomas@residuum.org [2022-12-11 21:20]:
[...]
My guess is, that most users probably expect at least different seed values every time.
Maybe the help file should explicitely state the behaviour or a different way for deriving the initial seed should be used, e.g. taking the local time. Or a better PRNG could be used as well.
If we take the solution to initialize [random] with a different seed each time, an explanation on how to revert to the old behaviour of a seed value of 1489853723 should be mentioned in the help.
I think the main thing to worry about is if any of the patches written in the last 20+ years will stop working in the way intended by a such a modification.
I loosely remember that someone somewhen showed how to get a different seed every time using an abstraction. If such a solution exists in vanilla Pd, it could be added as a solution to the docs perhaps?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
it seems like this would also depend on automatically saving the parent at loadtime or closetime though
-----Original Message----- From: Sebastian Shader sebfumaster@aol.com To: pd-list@lists.iem.at pd-list@lists.iem.at Sent: Sun, Dec 11, 2022 2:34 pm Subject: Re: [PD] [random] and seed value
well it used to be the case that it was difficult to save per-abstraction parameters. with the addition of [savestate]I don't think that's as much of a factor anymore.
In the past you could have a simple abstraction that could increment a value held in a message box to supply a different seed everytime a patch was loaded. But now you could do basically the same with [savestate] I think. (and don't have to store save state outside the abstraction yourself) of course the most common suggestion is to use [date] and [time] from zexy. maybe the better solution is to put those objects into vanilla.. because such an abstraction would be very simple also.
-seb -----Original Message----- From: Peter P. peterparker@fastmail.com To: pd-list@lists.iem.at Sent: Sun, Dec 11, 2022 2:22 pm Subject: Re: [PD] [random] and seed value
Hi Thomas,
- Thomas Mayer thomas@residuum.org [2022-12-11 21:20]:
[...]
My guess is, that most users probably expect at least different seed values every time.
Maybe the help file should explicitely state the behaviour or a different way for deriving the initial seed should be used, e.g. taking the local time. Or a better PRNG could be used as well.
If we take the solution to initialize [random] with a different seed each time, an explanation on how to revert to the old behaviour of a seed value of 1489853723 should be mentioned in the help.
I think the main thing to worry about is if any of the patches written in the last 20+ years will stop working in the way intended by a such a modification.
I loosely remember that someone somewhen showed how to get a different seed every time using an abstraction. If such a solution exists in vanilla Pd, it could be added as a solution to the docs perhaps?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi,
On 12.12.22 00:39, Sebastian Shader via Pd-list wrote:
of course the most common suggestion is to use [date] and [time] from zexy. maybe the better solution is to put those objects into vanilla.. because such an abstraction would be very simple also.
That is my current solution as well, using an abstraction [rand] with [time] to set the seed on loadbang, and [inlet]s and [outlet] for the respective ones in [random].
I have no opinion on the inclusion of these objects into vanilla Pd, I use them exclusively for setting the seed of [random], while I always use [z~] and [limiter~] from zexy, as well as often [list2symbol] and [symbol2list], e.g. for converting symbols to float.
Thanks, Thomas
On 11.12.22 23:22, Peter P. wrote:
Hi Thomas,
- Thomas Mayer thomas@residuum.org [2022-12-11 21:20]:
[...]
My guess is, that most users probably expect at least different seed values every time.
Maybe the help file should explicitely state the behaviour or a different way for deriving the initial seed should be used, e.g. taking the local time. Or a better PRNG could be used as well.
If we take the solution to initialize [random] with a different seed each time, an explanation on how to revert to the old behaviour of a seed value of 1489853723 should be mentioned in the help.
I think the main thing to worry about is if any of the patches written in the last 20+ years will stop working in the way intended by a such a modification.
I loosely remember that someone somewhen showed how to get a different seed every time using an abstraction. If such a solution exists in vanilla Pd, it could be added as a solution to the docs perhaps?
if backwards-compatibility is the main factor, then I will create a pull request with an update to the help file and explain a way to generate a good seed value with Pd vanilla, where I actually do not have a good idea for now, because I am using [time] from zexy right now.
Thanks, Thomas
The fact that you don't get different seeds is arguably something to mention in the help files.
One thing is that this is not a real feature as I see it, because you can't really control the number of [random] objects that were created before opening a particular patch.
On the other hand, I can't believe people do rely on a [random] object giving the same output every time you open the patch. We have it in the documentation that using 'seed' is what you need for this and this is the only thing that can actually be done to guarantee the same sequence.
You can use externals like zexy's (ELSE also has [datetime] because someone requested) but if yo're gonna have to use externals, you might just end up using an external for a random number generator that has this function built in it already, and ALL random/noise generators in ELSE do this.
Now, I believe Pd Vanilla's random number generators should have an actual unpredictable seed and I already have a PR for this, see --> https://github.com/pure-data/pure-data/pull/1719
I don't think this will break anything but worst case scenario, we can have those 'compatibilty flags' IOhaness is not much a fan of :)
Vanilla could also have something like [date]/[time] one way or another, but adding it just for the case of managing seeds in [random] seems like a bad idea to me.
cheers
Em dom., 11 de dez. de 2022 às 21:37, Thomas Mayer thomas@residuum.org escreveu:
On 11.12.22 23:22, Peter P. wrote:
Hi Thomas,
- Thomas Mayer thomas@residuum.org [2022-12-11 21:20]:
[...]
My guess is, that most users probably expect at least different seed
values
every time.
Maybe the help file should explicitely state the behaviour or a
different
way for deriving the initial seed should be used, e.g. taking the local time. Or a better PRNG could be used as well.
If we take the solution to initialize [random] with a different seed
each
time, an explanation on how to revert to the old behaviour of a seed
value
of 1489853723 should be mentioned in the help.
I think the main thing to worry about is if any of the patches written in the last 20+ years will stop working in the way intended by a such a modification.
I loosely remember that someone somewhen showed how to get a different seed every time using an abstraction. If such a solution exists in vanilla Pd, it could be added as a solution to the docs perhaps?
if backwards-compatibility is the main factor, then I will create a pull request with an update to the help file and explain a way to generate a good seed value with Pd vanilla, where I actually do not have a good idea for now, because I am using [time] from zexy right now.
Thanks, Thomas -- "It seems to me, Golan, that the advance of civilization is nothing but an exercise in the limiting of privacy." (Janov Pelorat in: Isaac Asimov - Foundation's Edge) http://www.residuum.org/
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 12/12/22 06:47, Alexandre Torres Porres wrote:
The fact that you don't get different seeds is arguably something to mention in the help files.
One thing is that this is not a real feature as I see it, because you can't really control the number of [random] objects that were created before opening a particular patch.
this might be a problem in a live-coding context, but not otherwise (where you open your pre-built patch).
On the other hand, I can't believe people do rely on a [random] object
i can. easily. people are often not aware of their implicit assumptions. and there are quite a lot of implicit assumptions when it comes to random generators (e.g. most people will turn away in disgust when it their random generator will produce a totally random series that happens to have the same number repeated; see https://xkcd.com/221/)
in the actual context of [random] (which i've never seen repeat a random number "too often"), I think there are definitely pieces out there where the composer expects the "random" piece to sound like "that", and which will no longer be true if [random] uses different seeds for each instance).
giving the same output every time you open the patch. We have it in the documentation that using 'seed' is what you need for this and this is the only thing that can actually be done to guarantee the same sequence.
yes. (note, that i'm definitely not advocating to keep the fixed seed for [random].)
I don't think this will break anything but worst case scenario, we can have those 'compatibilty flags' IOhaness is not much a fan of :)
indeed (both that we can have one; and that i'm not a fan thereof)
gmadsr IOhannes
Le 12/12/2022 à 01:35, Thomas Mayer a écrit : ...
if backwards-compatibility is the main factor, then I will create a pull request with an update to the help file and explain a way to generate a good seed value with Pd vanilla, where I actually do not have a good idea for now, because I am using [time] from zexy right now.
I do also use time from zexy, but there are other possible solutions. When I really need to be vanilla friendly, I use adc~ LSB : the noise on the audio input is impredictable, but one need an audio input configured and dsp running, so it's not generic.
The [realtime] of a simple operation like a netsend/netreceive pair can be use, but it's not possible to have the seed ready at loadbang, and it look overkill.
The best solution is to ask the OS for a random value (reading /dev/random on linux), but it's OS dependant...
cheers c
Thanks, Thomas
"there are definitely pieces out there where the composer expects the "random" piece to sound like "that", and which will no longer be true if [random] uses different seeds for each instance)."
Yes, I'm one of those...
[random] seems to rear its head now & then. My memory is that when asked on here, Miller was a little coy about the algo (when was highlighted on-list as an 'interesting' [non-standard] implementation:)
Seasons greets J
------- Original Message ------- On Sunday, December 11th, 2022 at 15:55, Thomas Mayer thomas@residuum.org wrote:
Hello,
currently [random] uses a fixed value for initialisation. This leads to the same sequence of values all the time.
https://github.com/pure-data/pure-data/blob/c0cd34924a50bdd1cc37dfb6b01f9be0...
My guess is, that most users probably expect at least different seed values every time.
Maybe the help file should explicitely state the behaviour or a different way for deriving the initial seed should be used, e.g. taking the local time. Or a better PRNG could be used as well.
If we take the solution to initialize [random] with a different seed each time, an explanation on how to revert to the old behaviour of a seed value of 1489853723 should be mentioned in the help.
I could tackle that, but would like a discussion about that before coding.
Thanks, Thomas -- "Prisons are needed only to provide the illusion that courts and police are effective. They're a kind of job insurance." (Leto II. in: Frank Herbert, God Emperor of Dune) http://www.residuum.org/
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 12/14/22 23:55, Julian Brooks wrote:
Yes, I'm one of those...
then i think you should start setting an explicit seed right now.
the simplest way i've found to force the currently hardcoded seed (for the first instantiated random generater), is something like this:
- seed the random generator with 255406
- discard the first 3186 random numbers
like so: #N canvas 2082 640 533 344 12; #X msg 307 69 seed 255406; #X msg 327 123 3186; #X obj 327 148 until; #X obj 230 246 spigot; #X msg 307 174 1; #X obj 230 271 print; #X msg 202 166 bang; #X obj 307 94 t b b a b; #X msg 367 172 0; #X obj 230 221 random 100; #X obj 281 197 t a; #X obj 367 200 t f; #X text 311 45 reset; #X connect 0 0 7 0; #X connect 1 0 2 0; #X connect 2 0 10 0; #X connect 3 0 5 0; #X connect 4 0 11 0; #X connect 6 0 9 0; #X connect 7 0 4 0; #X connect 7 1 1 0; #X connect 7 2 10 0; #X connect 7 3 8 0; #X connect 8 0 11 0; #X connect 9 0 3 0; #X connect 10 0 9 0; #X connect 11 0 3 1;
[random] seems to rear its head now & then.
of course it loops. it's a pseudo random generator. however, i find that the underlying algorithm is somewhat perfect with regard to repetition (last time i checked, it required about 4294967295 iterations to repeat, which is pretty good for a 32bit integer number).
that's not to say that the distribution for small ranges as output by [random] might *not* be ideal.
My memory is that when asked on here, Miller was a little coy about the algo (when was highlighted on-list as an 'interesting' [non-standard] implementation:)
iirc, miller always claimed that he was just blindly hitting the number keys to generate large numbers.
i don't fully trust this statement for the actual random generator (given that it consumes all possible numbers before repeating), but for the seed generator this is somewhat plausible, as this one only takes 536870912 iterations to repeat itself (so the PRNG itself has an 8-times longer period)
Thx for fix & additional info IOhannes - not too shabby then...
------- Original Message ------- On Thursday, December 15th, 2022 at 11:23, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 12/14/22 23:55, Julian Brooks wrote:
Yes, I'm one of those...
then i think you should start setting an explicit seed right now.
the simplest way i've found to force the currently hardcoded seed (for the first instantiated random generater), is something like this:
- seed the random generator with 255406
- discard the first 3186 random numbers
like so: #N canvas 2082 640 533 344 12; #X msg 307 69 seed 255406; #X msg 327 123 3186; #X obj 327 148 until; #X obj 230 246 spigot; #X msg 307 174 1; #X obj 230 271 print; #X msg 202 166 bang; #X obj 307 94 t b b a b; #X msg 367 172 0; #X obj 230 221 random 100; #X obj 281 197 t a; #X obj 367 200 t f; #X text 311 45 reset; #X connect 0 0 7 0; #X connect 1 0 2 0; #X connect 2 0 10 0; #X connect 3 0 5 0; #X connect 4 0 11 0; #X connect 6 0 9 0; #X connect 7 0 4 0; #X connect 7 1 1 0; #X connect 7 2 10 0; #X connect 7 3 8 0; #X connect 8 0 11 0; #X connect 9 0 3 0; #X connect 10 0 9 0; #X connect 11 0 3 1;
[random] seems to rear its head now & then.
of course it loops. it's a pseudo random generator. however, i find that the underlying algorithm is somewhat perfect with regard to repetition (last time i checked, it required about 4294967295 iterations to repeat, which is pretty good for a 32bit integer number).
that's not to say that the distribution for small ranges as output by [random] might not be ideal.
My memory is that when asked on here, Miller was a little coy about the algo (when was highlighted on-list as an 'interesting' [non-standard] implementation:)
iirc, miller always claimed that he was just blindly hitting the number keys to generate large numbers.
i don't fully trust this statement for the actual random generator (given that it consumes all possible numbers before repeating), but for the seed generator this is somewhat plausible, as this one only takes 536870912 iterations to repeat itself (so the PRNG itself has an 8-times longer period) _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
cyrille henry -
IOhannes m zmoelnig -
Julian Brooks -
Peter P. -
Sebastian Shader -
Thomas Mayer