Hi,
I made two generators for Gaussian white noise, one using DSP, the other as message based version. Both use the same algorithm, but the histogram analysis of both shows a defect with the message version: The histogram has a visible "valley" around the central expectation value, so it doesn't look like a real gaussian bell curve anymore.
The message version is based on [random] not [noise~], and I "faked" a true frand by taking and scaling random values from the range 0-100000. Could this be the reason for the valleys or is the reason the custom algorithm [random] uses or is it, that two [random]s are not sufficiently independent?
Ciao
Frank
On 2010-08-10 04:32, Frank Barknecht wrote:
Hi,
I made two generators for Gaussian white noise, one using DSP, the other as message based version. Both use the same algorithm, but the histogram analysis of both shows a defect with the message version: The histogram has a visible "valley" around the central expectation value, so it doesn't look like a real gaussian bell curve anymore.
The message version is based on [random] not [noise~], and I "faked" a true frand by taking and scaling random values from the range 0-100000. Could this be the reason for the valleys or is the reason the custom algorithm [random] uses or is it, that two [random]s are not sufficiently independent?
Yes it is the reason for the valleys. Your random is on [-0.5,0.5] instead of [-1,1]. The random needs to be multiplied by 2 million before subtracting one million then dividing by one million. Then it works. Also an uncertain execution order in the log divide part needs one of those [tff]s. The DSP version looks normal to me if I sample it a few times.
Martin
On Wed, 2010-08-11 at 00:17 -0400, Martin Peach wrote:
On 2010-08-10 04:32, Frank Barknecht wrote:
Also an uncertain execution order in the log divide part needs one of those [tff]s.
HAHAHA, I would have never dreamed that once someone would be saying that to Frank.
(Frank, please get me right: I meant to laugh with you, not at you).
Cheers Roman
On Wed, Aug 11, 2010 at 09:44:13AM +0200, Roman Haefeli wrote:
On Wed, 2010-08-11 at 00:17 -0400, Martin Peach wrote:
On 2010-08-10 04:32, Frank Barknecht wrote:
Also an uncertain execution order in the log divide part needs one of those [tff]s.
HAHAHA, I would have never dreamed that once someone would be saying that to Frank.
(Frank, please get me right: I meant to laugh with you, not at you).
Yeah, it's funny! Lesson learned here: If you start with DSP code and convert it to messages, look very, very closely for fanning connections.
Ciao
Frank
On Wed, 2010-08-11 at 10:01 +0200, Frank Barknecht wrote:
On Wed, Aug 11, 2010 at 09:44:13AM +0200, Roman Haefeli wrote:
On Wed, 2010-08-11 at 00:17 -0400, Martin Peach wrote:
On 2010-08-10 04:32, Frank Barknecht wrote:
Also an uncertain execution order in the log divide part needs one of those [tff]s.
HAHAHA, I would have never dreamed that once someone would be saying that to Frank.
(Frank, please get me right: I meant to laugh with you, not at you).
Yeah, it's funny! Lesson learned here: If you start with DSP code and convert it to messages, look very, very closely for fanning connections.
Ah, I understand. There must have been a plausible explanation for that ;-)
Roman
Hi,
On Wed, Aug 11, 2010 at 12:17:14AM -0400, Martin Peach wrote:
Yes it is the reason for the valleys. Your random is on [-0.5,0.5] instead of [-1,1].
Ah, of course, how silly.
Also an uncertain execution order in the log divide part needs one of those [tff]s.
Oops, I overlooked this while converting the DSP version to floats, thanks for pointing it out. Now the bell sounds like a bell!
Ciao
Frank
-
Frank Barknecht -
Martin Peach -
Roman Haefeli