I have some problem when testing FFT from MathNet:
The idea is that if I apply FFT to the characteristic function of a gaussian variable I should find the gaussian density function.
When I plot VectorFFT the figure does seems a density function but in zero it does not have value 1, it has value 1.4689690914109.
There must be some problems with the scaling. I tried out all type of FourierOptions in Fourier.Inverse and all type of divisions/multiplications for PI, 2PI, sqrt(2PI) but nothing gives me the value 1 at the center of the density function.
Also, since various definitions of Fourier Transform and its inverse exists, I was wondering which one is implemented by MathNet, I could not find it in the documentation.
Any ideas?
public void DensityGaussian()
{
double eta = 0.1; //step in discrete integral
int pow2 = 256; // N^2
double mu = 0; // centred gaussian
double sigma = 1; // with unitary variance
//FFT
double lambda = 2 * System.Math.PI / (pow2 * eta);
double b = 0.5 * pow2 * lambda;
Complex[] VectorToFFT = new Complex[pow2];
for (int j = 0; j < pow2; j++)
{
double z = eta * j;
if (z == 0) { z = 0.00000000000001; }
VectorToFFT[j] = System.Numerics.Complex.Exp(new Complex(0, b * z));
VectorToFFT[j] *= (System.Numerics.Complex.Exp(new Complex(
-sigma*sigma*z*z, mu * z))); //char function of gaussian
}
Fourier.Inverse(VectorToFFT, FourierOptions.NoScaling);
//scaling
for (int i = 0; i < pow2; i++)
{
VectorToFFT[i] /= (2 * System.Math.PI); //test
}
Console.WriteLine("Is density?");
Assert.IsTrue(1 == 1);
}
Math.NET Numerics supports all common DFT definitions, controllable with the FourierOptions flags enum. They essentially vary on the exponent and on the scaling.
The FourierOptions docs give some hints on how the options affect the effective definition, essentially:
InverseExponent: use a negative sign in the exponent (default uses a positive sign). A prominent implementation with a negative sign is numerical recipes.
AsymmetricScaling/NoScaling: instead of the default symmetric scaling sqrt(1/N) either only scale in the inverse transformation 1/N (like Matlab) or no scaling at all (like numerical recipes). Obviously, without scaling ifft(fft(x)) != x.
Maybe the answer in Calculating a density from the characteristic function using fft in R can help on the specific use case.
Related
Given a distance (arc length) anticlockwise away from a known point (P_0) on an ellipse, I am trying to find the point at that distance (P_1).
Since I cannot evaluate the t corresponding to a specific arc length analytically, I am forced to iterate through each discrete point until I arrive at an answer.
My initial code is something like this:
// t_0 is the parametric t on the ellipse corresponding to P_0
Point GetPos(double distance, double t_0, double res = 5000, double epsilon = 0.1)
{
for(int i = 0; i < res; ++i)
{
// The minus is to make the point move in an clockwise direction
t = t_0 - (double)(i)/(double)res * t_0;
// Find the integral from t to t_0 to get the arc length
// If arc length is within epsilon, return the corresponding point
}
}
Unfortunately, this code may not converge if the arc length given by the t value just nicely overshoots the epsilon value. And since this is a loop that decreases t, the overshoot will not be corrected.
I was thinking of modelling this as a control problem, using something like a PID controller. However, I realised that since the set point (which is my desired arc length), and my output (which is essentially the parametric t), are referring to different variables, I do not know how to proceed.
Is there a better method of solving this kind of problem or am I missing something from my current approach?
After some thought I used a binary search method instead, since a PID controller is difficult to tune and usually does not converge fast enough for all cases of the ellipses under consideration.
double max = t_0; double min = 0; double result = 0; double mid = 0;
mid = (max - min) / 2.0;
while ((Math.Abs(distance - result) > epsilon))
{
result = // Arc Length from t_0 to mid
if (result > distance)
{
min = mid;
mid = ((max - mid) / 2.0) + min;
}
else
{
max = mid;
mid = (mid - min) / 2.0;
}
}
// Return the point at t = max
The binary search works as the search is always over an ordered range (from t_0 to 0).
I just wrote the implementation of dft. Here is my code:
int T = 2205;
float[] sign = new float[T];
for (int i = 0, j = 0; i < T; i++, j++)
sign[i] = (float)Math.Sin(2.0f * Math.PI * 120.0f * i/ 44100.0f);
float[] re = new float[T];
float[] im = new float[T];
float[] dft = new float[T];
for (int k = 0; k < T; k++)
{
for (int n = 0; n < T; n++)
{
re[k] += sign[n] * (float)Math.Cos(2.0f* Math.PI * k * n / T);
im[k] += sign[n] * (float)Math.Sin(2.0f* Math.PI * k * n / T);;
}
dft[k] = (float)Math.Sqrt(re[k] * re[k] + im[k] * im[k]);
}
So the sampling freguency is 44100 Hz and I have a 50ms segment of a 120Hz sinus wave. According to the result I have a peak of the dft function at pont 7 and 2200. Did I do something wrong and if not, how should I interpret the results?
I tried the FFT method of AFORGE. Heres is my code.
int T = 2048;
float[] sign = new float[T];
AForge.Math.Complex[] input = new AForge.Math.Complex[T];
for (int i = 0; i < T; i++)
{
sign[i] = (float)Math.Sin(2.0f * Math.PI * 125.0f * i / 44100.0f);
input[i].Re = sign[i];
input[i].Im = 0.0;
}
AForge.Math.FourierTransform.FFT(input, AForge.Math.FourierTransform.Direction.Forward);
AForge.Math.FourierTransform.FFT(input, AForge.Math.FourierTransform.Direction.Backward);
I had expected to get the original sign but I got something different (a function with only positive values). Is that normal?
Thanks in advance!
Your code look correct, but it could be more efficient, DFT is often solved by FFT algorithm (fast-fourier transform, it's not a new transform, it's just an algorithm to solve DFT in more efficient way).
Even if you do not want to implement FFT (which is a bit harder to understand and it's harder to make it work on data which is not in form of 2^n) or use some open source code, you can make your implementation a bit fast, for example by seeing that 2.0f * Math.PI * K / T is a constant outside of inner loop, so you can compute it once for each k (move it outside inner loop) and then just multiply it by n in your cos/sin functions.
As for position and interpretation, you have changed your domain, now your X-axis, which is the index of data in table corresponds not to time but frequency. You have sampling of 44100Hz and you have captures 2205 samples, that means that every 1 sample represents a magnitude of your input signal at frequency equal to 44100Hz / 2205 = 20Hz. You have your magnitude peak at 7th point (index 6) because your signal is 120Hz, so 6 * 20Hz = 120Hz which is what you could expect.
Seconds peak might seem to represent some high frequency, but it's just a spurious signal, because your sampling rate is 44100Hz you can not measure frequencies higher than 44100Hz / 2 (Nyquist's law) which if you cut-off point, after that frequency DFT data is not valid. That's why, second half of your table is invalid and it's basically your first half but mirrored and you can ignore it.
Edit//
From your questions I can see that you are interested in audio processing, you might want to google NForge.Net library, which is a great opensource library for audio and visual processing and its author have many good articles on codeproject.com regarding many of it's features.
I have this algorithm that calcuates the mandelbrot value of a point (x0,y0) (x0 and y0 are somewhere between -1 and 1 i thought, not very important). This is all going very well when scale isn't getting too big, but at higher values of scale, the values returned are very inaccurate and my graphic output starts to go freaky. How do i predict from what value of scale this occurs?
public static byte CalculateMandelbrot(double x0, double y0,double scale)
{
x0 /= scale;
y0 /= scale;
double y = 0;
double x = 0;
byte i = 0;
while (x * x + y * y < 4)
{
double tx = x;
x = x * x - y * y + x0;
y = 2 * tx * y + y0;
i++;
if (i == 0xFF) break;
}
return i;
}
A double has 53 bits of precision. This amounts to about 16 decimal places.
If you zoom in on your fractal 10^13 times, and make picture of 1000x1000 pixels, the precision is about the same as the screen resolution: the minimal change possible in a double is a step of one pixel on the screen.
But you will get into trouble before that, because you iterate the mandelbrot formula a hundred times iteratively on the same number. Each calculation adds a roundoff error (multiple ones, probably) of about 1/10^16. It is possible (although tedious) to predict when this gets noticable.
The FPU internally has a higher number of bits than standard double, this will reduce the abovementioned effect.
This is the classic "decimal vs double" pitfall.
Try using 'decimal' for all vars and see if it clicks.
From the C# Reference page:
Compared to floating-point types, the decimal type has a greater
precision and a smaller range
There are also arbitrary precision implementations like BigFloat Class.
From this question: Random number generator which gravitates numbers to any given number in range? I did some research since I've come across such a random number generator before. All I remember was the name "Mueller", so I guess I found it, here:
Box-Mueller transform
I can find numerous implementations of it in other languages, but I can't seem to implement it correctly in C#.
This page, for instance, The Box-Muller Method for Generating Gaussian Random Numbers says that the code should look like this (this is not C#):
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>
double gaussian(void)
{
static double v, fac;
static int phase = 0;
double S, Z, U1, U2, u;
if (phase)
Z = v * fac;
else
{
do
{
U1 = (double)rand() / RAND_MAX;
U2 = (double)rand() / RAND_MAX;
u = 2. * U1 - 1.;
v = 2. * U2 - 1.;
S = u * u + v * v;
} while (S >= 1);
fac = sqrt (-2. * log(S) / S);
Z = u * fac;
}
phase = 1 - phase;
return Z;
}
Now, here's my implementation of the above in C#. Note that the transform produces 2 numbers, hence the trick with the "phase" above. I simply discard the second value and return the first.
public static double NextGaussianDouble(this Random r)
{
double u, v, S;
do
{
u = 2.0 * r.NextDouble() - 1.0;
v = 2.0 * r.NextDouble() - 1.0;
S = u * u + v * v;
}
while (S >= 1.0);
double fac = Math.Sqrt(-2.0 * Math.Log(S) / S);
return u * fac;
}
My question is with the following specific scenario, where my code doesn't return a value in the range of 0-1, and I can't understand how the original code can either.
u = 0.5, v = 0.1
S becomes 0.5*0.5 + 0.1*0.1 = 0.26
fac becomes ~3.22
the return value is thus ~0.5 * 3.22 or ~1.6
That's not within 0 .. 1.
What am I doing wrong/not understanding?
If I modify my code so that instead of multiplying fac with u, I multiply by S, I get a value that ranges from 0 to 1, but it has the wrong distribution (seems to have a maximum distribution around 0.7-0.8 and then tapers off in both directions.)
Your code is fine. Your mistake is thinking that it should return values exclusively within [0, 1]. The (standard) normal distribution is a distribution with nonzero weight on the entire real line. That is, values outside of [0, 1] are possible. In fact, values within [-1, 0] are just as likely as values within [0, 1], and moreover, the complement of [0, 1] has about 66% of the weight of the normal distribution. Therefore, 66% of the time we expect a value outside of [0, 1].
Also, I think this is not the Box-Mueller transform, but is actually the Marsaglia polar method.
I am no mathematician, or statistician, but if I think about this I would not expect a Gaussian distribution to return numbers in an exact range. Given your implementation the mean is 0 and the standard deviation is 1 so I would expect values distributed on the bell curve with 0 at the center and then reducing as the numbers deviate from 0 on either side. So the sequence would definitely cover both +/- numbers.
Then since it is statistical, why would it be hard limited to -1..1 just because the std.dev is 1? There can statistically be some play on either side and still fulfill the statistical requirement.
The uniform random variate is indeed within 0..1, but the gaussian random variate (which is what Box-Muller algorithm generates) can be anywhere on the real line. See wiki/NormalDistribution for details.
I think the function returns polar coordinates. So you need both values to get correct results.
Also, Gaussian distribution is not between 0 .. 1. It can easily end up as 1000, but probability of such occurrence is extremely low.
This is a monte carlo method so you can't clamp the result, but what you can do is ignore samples.
// return random value in the range [0,1].
double gaussian_random()
{
double sigma = 1.0/8.0; // or whatever works.
while ( 1 ) {
double z = gaussian() * sigma + 0.5;
if (z >= 0.0 && z <= 1.0)
return z;
}
}
I am writing a C# function for doing dynamic range compression (an audio effect that basically squashes transient peaks and amplifies everything else to produce an overall louder sound). I have written a function that does this (I think):
alt text http://www.freeimagehosting.net/uploads/feea390f84.jpg
public static void Compress(ref short[] input, double thresholdDb, double ratio)
{
double maxDb = thresholdDb - (thresholdDb / ratio);
double maxGain = Math.Pow(10, -maxDb / 20.0);
for (int i = 0; i < input.Length; i += 2)
{
// convert sample values to ABS gain and store original signs
int signL = input[i] < 0 ? -1 : 1;
double valL = (double)input[i] / 32768.0;
if (valL < 0.0)
{
valL = -valL;
}
int signR = input[i + 1] < 0 ? -1 : 1;
double valR = (double)input[i + 1] / 32768.0;
if (valR < 0.0)
{
valR = -valR;
}
// calculate mono value and compress
double val = (valL + valR) * 0.5;
double posDb = -Math.Log10(val) * 20.0;
if (posDb < thresholdDb)
{
posDb = thresholdDb - ((thresholdDb - posDb) / ratio);
}
// measure L and R sample values relative to mono value
double multL = valL / val;
double multR = valR / val;
// convert compressed db value to gain and amplify
val = Math.Pow(10, -posDb / 20.0);
val = val / maxGain;
// re-calculate L and R gain values relative to compressed/amplified
// mono value
valL = val * multL;
valR = val * multR;
double lim = 1.5; // determined by experimentation, with the goal
// being that the lines below should never (or rarely) be hit
if (valL > lim)
{
valL = lim;
}
if (valR > lim)
{
valR = lim;
}
double maxval = 32000.0 / lim;
// convert gain values back to sample values
input[i] = (short)(valL * maxval);
input[i] *= (short)signL;
input[i + 1] = (short)(valR * maxval);
input[i + 1] *= (short)signR;
}
}
and I am calling it with threshold values between 10.0 db and 30.0 db and ratios between 1.5 and 4.0. This function definitely produces a louder overall sound, but with an unacceptable level of distortion, even at low threshold values and low ratios.
Can anybody see anything wrong with this function? Am I handling the stereo aspect correctly (the function assumes stereo input)? As I (dimly) understand things, I don't want to compress the two channels separately, so my code is attempting to compress a "virtual" mono sample value and then apply the same degree of compression to the L and R sample value separately. Not sure I'm doing it right, however.
I think part of the problem may the "hard knee" of my function, which kicks in the compression abruptly when the threshold is crossed. I think I may need to use a "soft knee" like this:
alt text http://www.freeimagehosting.net/uploads/4c1040fda8.jpg
Can anybody suggest a modification to my function to produce the soft knee curve?
The open source Skype Voice Changer project includes a port to C# of a number of nice compressors written by Scott Stillwell, all with configurable parameters:
Fast attack compressor
Fairly childish (compressor limiter)
Event Horizon (peak eating limiter)
The first one looks like it has the capability to do soft-knee, although the parameter to do so is not exposed.
I think your basic understanding of how to do compression is wrong (sorry ;)). It's not about "compressing" individual sample values; that will radically change the waveform and produce severe harmonic distortions. You need to assess the input signal volume over many samples (I would have to Google for the correct formula), and use this to apply a much-more-gradually-changing multiplier to the input samples to generate output.
The DSP forum at kvraudio.com/forum might point you in the right direction if you have a hard time finding the usual techniques.