>May I respectfully submit that non-repeatable random number generators (or
any
>other opcode) may result in perfectly smooth audio sometimes and awful
digital
>clipping on other times, even on the same implementation ? That's bad :-(
Well, it depends what you do with the random number generators. If I
ask for values between -1 and 1, then I lowpass filter them and use them
to control the frequency of an oscillator (random jitter vibrato), it won't
ever clip because the values, also unpredictable, are
predictably bounded. It's important to have the non-repeatable ones
built-in, because without some kind of system function (get the LSB 16
bits of the clock) it's impossible to write them yourself.
As I said in the last email, if you need repeatability, it's easy to write
these yourself. Here is a simple (bad) example:
kopcode myrand(seed)
ksig state;
if (seed != 0) { state = seed; }
state = state * 1103515245 + 12345;
if (state > pow(2,31)) { state = state - pow(2,31); }
return (mod(state / 65536, 32768));
}
This is taken right from Numerical Recipes (although it's marked
as bad there, and it won't work exactly right in SAOL because SAOL
uses float arithmetic, not integer. But you get the idea).
Maybe someone who is more expert in random numbers can write a
good floating-point seedable random-number generator as a SAOL
opcode that I can put on the web page...?
>Are you telling me that non-repeatability of random number generators in
saol
>implementations is actually _normative_ ? I mean if a particular
>implementation seeded its core noise gens with e.g. absolute time times
>instrument instance number, which would make it random from the user's
point
>of view but repeatable from my point of view, would this implementation be
>illegal ?
No, I don't think so. There is only one implementation note on
random numbers, which I quote:
The following core opcodes generate noise, that is, pseudo-random
sequences of various statistical properties. In order to provide
maximum decorrelation among multiple noise generators, it is important
that all references to pseudo-random generation share a single feedback
state. That is, all random values required by the various states of
various noise generators shall make use of sequential values from a
single “master” pseudo-random sequence.
It is strictly prohibited for an implementation to maintain multiple
pseudo-random sequences to draw from (using the same algorithm) for
various states of noise generation opcodes, because to do so may result
in strong correlations between multiple noise generators.
This point does not apply to implementations that do not use “linear
congruential”, “modulo feedback”, or similar mathematical structures to
generate pseudo-random numbers.
The only normative thing that, say, krand() must do is
"return a random number x chosen according to the pdf
p(x) = 1/2p for x in [-p,p]
0 otherwise."
From this, I conclude that an implementor may choose to do it your way.
But if a content author depends on such platform-specific behavior, it
won't work on other implementations. It's better to assume that krand()
is truly random, and write your own generator for the cases in which
you want pseudo-random numbers that are controllable in some way.
One final note: It's still an open question in MPEG how we should
conformance-test the random number generators, so if anyone has any
suggestions, they should speak up. For example, for a statement like
x = kpoissonrand(1e6)
x should be zero except for one value every 11 1/2 days (on average) which
is 1.
(Maybe this is part of some conceptual installation piece). It's
really hard to tell if an implementation has implemented this right
without waiting around for years to collect statistics!
Best,
-- Eric
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:15:29 EDT