[PD] [random] and seed value

[Alexandre Torres Porres]

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 at residuum.org>
escreveu:

> On 11.12.22 23:22, Peter P. wrote:
> > Hi Thomas,
> >
> > * Thomas Mayer <thomas at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20221212/e6762fa5/attachment.htm>