hasley

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.

[1] https://en.wikipedia.org/wiki/Double_Fourier_sphere_method

I was thinking of X11 as well, but did not feel old - until I read your text. ;)

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.

Location: Germany, Thuringia

Remote: yes

Willing to relocate: no

Technologies:

Digital signal processing, linear algebra, array signal processing, radar, C++, C#, Python, JupyterLab, Octave/Matlab, Git, Jenkins etc.

Résumé/CV:

1) PhD in direction of arrival estimation using antenna arrays

2) 8+ years as senior and/or lead developer in different environments (e.g. Music recognition, embedded devices)

3) Currently researcher in the field of Integrated Communications & Sensing (ICAS) bringing together wireless communications and radar functionalities

Email: quaternion {at} web {dot} de

What about poor people that live in areas in the world that will become completely uninhabitable?

Location: Germany (Thuringia)

Remote: Yes

Willing to relocate: No

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.

Email: quaternion [at] web [dot] de

The problem is not the abstraction itself.

The problem is that your code has to work within this abstraction and can only solve problems covered by the inventors of the abstraction.

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).

Why do you think, that it is not fair?

You can even use these algorithms with a single snapshot (spatial smoothing).

FFT/DFT is not precise if you do not have the exact harmonic in you signal. If you are also (or only) interested in phases you might use a maximum likelihood estimator (which brings other problems though).

And as the previous answer said: compressed sensing (or compressive sensing) can help as well for some non-standard cases.

I have not read the whole article. But, what is shown at the beginning is not the Fourier Transform, it is the Discrete Fourier Transform (DFT).

Though the DFT can be implemented efficiently using the Fast Fourier Transform (FFT) algorithm, the DFT is far from being the best estimator for frequencies contained in a signal. Other estimators (like Maximum Likelihood [ML], [Root-]MUSIC, or ESPRIT) are in general far more accurate - at the cost of higher computational effort.

I consider myself to be a slow-thinker too. I have several above-average people as friends. New stuff (usually some mathematical topic) that takes me a whole day to internalize the basics, I can tell to them in 15 minutes and they will be able to understand it and to immediately connect it with other topics they know. I have not attended a special school for mathematically gifted like some of them. In school and during my first year at the university, I used to think that I am just intelligent enough to have an idea how true intellegent one could be...

I was always bad at solving equations with more than 3 unknowns, since this includes enough steps to have a significant probability that I forget a sign or mix something up - even though the algorithm itself was completely clear to me.

Today I acceppted myself much more: I think my real advantages are that I am a) interested in a lot of things and b) I am enduring in reading about a topic. Even if I need to read explanations of 5 different authors to grasp something, I do so. And I care much less today than ealier. However, I still like to be faster at times.

While I think I am a decent programmer/SWE, I do not like pair programming. My path of coding is not linear and most of the stuff I type will be erased until I am confident about my solution.

And getting enough sleep is also a big issue.

I am thinking more about Julia here - which I would use if Python was not that common in several communities.

Thanks!

Related question: What resources are there that might teach one about Maxwell‘s equations and the electromagnetic field tensor arisig from relativity? The magnetic field is a description of the electric field with relativistic effects. Is there a way of describing electromagnetism without the magnetic field?

When I worked at the university, this used to be my go-to reference about matrix identities (including matrix calculus).

Still today, I tend to increase my motivation of writing unit tests by using some non-serious names and strings in the tests.

Woa, CodeWarrior was one of the worst compilers (and IDEs) I had to use so far.

When I started learning Turbo Pascal I came across a problem where an if-statement was obviously decided wrong. I saw the values in the debugger.

My rescue was that I had a more experienced friend who knew that IIRC the compiler would choose the data type of the left operand of a comparison also for the right operand leading to potential sign switches.

Nice, thank you!

Do you have any references for that? I used to avoid exceptions on small Cortex M0/M3 devices as well.

Now I need a new abbreviation for the Quaternion Fourier Transform (QFT)...