I suspect with "orthogonalization" they mean to find vectors that form an orthogonal bases (same subspace) for the vectors in the source matrix.
I wonder what would be the result if they used a matrix that is orthogonal and closest to the source matrix.
Usually one uses the Frobenius norm (root of the sum of all squared matrix entries). Maybe, one could even try another norm that gives a sparser matrix.
The Cramér-Rao bound (CRB) is a fundamental bound in estimation theory. "Estimation" refers here to finding the parameters of a random process.
The CRB shows that for estimators (algorithms) that on average estimate a the correct value (unbiased estimators), there is a lower bound on the accuracy. Accuracy refers here to the variance (or equivalently to the mean squared error).
So, whatever fancy unbiased algorithm you will come up with, its average variance cannot be lower than the CRB.
So, the CRB tells you something about your measurement setup at hand. It can even show possibilities to improve estimation of certain parameters without being specific about the used algorithm.
The multi-parameter CRB gives a kind of "minimal" covariance matrix whose uncertainty ellipsoid is always inside the uncertainty ellipsoid of any unbiased multi-parameter estimator.
I am using type hints in Python as much as possible for my hand-coding. And it catches a lot of bugs (especially during code refactoring) that I would not have noticed so easily.
If you define frequency as the derivative of the phase with respect to time, then you also have an instantaneous frequency which (at least formally) also has Hz as unit - even though it does not necessarily describe some real periodicity.
To measure discrete events, I would prefer as unit "events per second" instead of Hz.
Yeah, that is really something that bothers me from time to time. For instance, in communications we count symbols per second and people still use the unit Hz. But, as it was said before, Hz is revelations per second.
There is a problem in general: Units do not refer to what they count. For instance, when you have dashed road markings and you want to quantify the length of the dashes per road length you get as unit "meters per meters". And then people go and say this is unitless since the units "cancel". But for me, they do not: It stays "dash meter per road meter".
If one needs to describe (and maybe compress) functions or data on a sphere, spherical harmonics are really a thing.
An alternative would be to construct a new function (or matrix) that is not only periodic in azimuth, but also in elevation (i.e., extend elevation to a full circle -pi to +pi). Then, one can simply compute two independent Fourie r transforms: along azimuth and along elevation. [1]
The same idea works on matrices using the Discrete Fourier transform (DFT/FFT).
However, you then have to accept things like that your data points are all equal at the poles.
The "zero copy substring" in C is in general not a valid C string since it is not guaranteed to be zero-terminated. For both languages one could define a string view as a struct with a pointer plus size information. So, I do not see why Pascal is worse in this regard than C.
Because you may have fun working in a scientific environment and doing research.
I liked my job at the university - independent of the final PhD. I enjoyed what I was doing. Most of the time I also enjoyed writing my dissertation, since I was given the opportunity to write about my stuff. And mostly I could write it in a way how I felt things are supposed to be explained.
I did my PhD with Octave. Sure, I did not have this nice convex optimization toolbox. But I had everything else I needed and did not need to wait because people arrived earlier in the lab and grabbed all floating licenses of, for instance, the communications toolbox.
However, I switched to Python during the last years.
Technologies:
- Digital signal processing: linear algebra, estimation theory, statistical/Bayesian signal processing, compressed sensing and others
- Programming: C++, C, C#, ARM assembly, AVX/SSE, Python, Bash, PowerShell 5/7.x, GNU Octave, Matlab
- Used libraries: Boost (C++), ffmpeg, gSOAP, gRPC, libcurl, NumPy, SciPy, Pandas, PyTorch and others
- Target platforms: x64, ARM Cortex M0/M3
- Tools: Git, Mercurial, SVN, CMake, GNU Make, Jenkins, Gitlab, rpmbuild
- OS: GNU Linux (eg., Arch), Windows
Résumé/CV:
- PhD and diploma in Electrical Engineering and Information Technology.
- PhD study about digital signal processing applied to antenna arrays.
I am a software engineer and researcher with a strong background in digital signal processing. I worked in the field of music recognition (C++ & Python), in embedded systems (esp. ARM Cortex) and in the communication between control centers (ITCS systems) and public transportation vehicles. Currently I am into Integrated Communications and Sensing (ICAS) which brings together Radar and mobile communications.
I like to solve challenging problems - via software engineering, via signal processing, or via a combination of both. Linux and algorithms are topics I have a strong interest in. While I educate myself regarding other technologies like transformers and deep neural networks (e.g. applied to OFDM), and cyber security ("playing" OWASP Juice Shop).
In past jobs, I worked as a Senior Software Engineer and as a Lead Software Developer, respectively. Currently, I am a post-doc researcher at a German university.
In case "framework" is understood as something that calls my code and that forces me to write my code in a certain way, I totally agree.
And I think twice before I use a framework. Frameworks enforce a certain way of programming which you can never be sure to match the problems you will have to solve in the future. Libraries don't do this - at least not to the extent of a framework. Libraries are composable building blocks.
Nevertheless, there may be applications where frameworks are beneficial (e.g. GNU Radio).
Zero-padding gives you a smoother curve, i.e., more points to look at. But it does not add new peaks. So, if you have two very close frequencies that produce a single peak in the DFT (w/o zero-padding), you would not get two peaks after zero-padding. In the field, were I work, resolution is understood as the minimum distance between two frequencies such that you are able to detect them individually (and not as a single frequency).
Zero-padding helps you to find the true position (frequency) of a peak in the DFT-spectrum. So, your frequency estimates can get better.
However, the peaks of a DFT are the summits of hills that are usually much wider than compared to other techniques (like Capon or MUSIC) whose spectra tend to have much narrower hills. Zero-padding does not increase the sharpness of these hills (does not make them narrower).
Likewise the DFT tends to be more noisy in the frequency domain compared to other techniques which could lead to false detections (e.g. with a CFAR variant).