Where to draw the line between programming, signal processing, and mathematics?

Question

I just asked this question: What approximation techniques exist for the square super-root function?, and there's some discussion in the comments (which I think is warranted) as to whether it's too purely mathematical to be a signal processing question. I offered a little explanation as to my reasoning in the comments, but thought I'd open the floor here since we're in the process of defining the range of "on-topic" questions for the site.

A more succinct explanation of my reasoning for the question [than I put in the comments] would be that it's about efficient implementation of one part of a nonlinear filter (e.g. in an image/audio effect or a control system). If it were geared to a coding question for a specific language, it might be better suited to stackoverflow (although I can see it getting kicked out of there for being too mathematical as well). I can also see it getting kicked out of math.SE for being too "applied". Most topics in signal processing often involve a mix of both programming and math, but is there a simple "test" we can come up with to determine when a question is too far in either direction?

At the moment, I really don't know of any SE site where questions that mix both math and programming have a true home (if I'm just missing something, let me know), and the solution of almost every problem that comes up in DSP involves some combination of both (e.g. the quintessential question(s) about the FFT).

By way of contrast, if a question about the efficient implementation of a special function isn't in scope for this site, would it be in scope if the question was about transforming some input into some output (e.g. "Efficient implementation of soft-clipping?"), and the answer ended up being the special function (e.g. some sigmoid function like erf(x))?

Answer 1

The six stages of RDM (Research, Development and Marketing)

1. The theory and its streams of thought
2. The mathematics
3. Software (pseudocode, or its generic implementation)
4. Hardware (equipments that are purposely-built to optimize its execution)
5. Practical applications
6. Public awareness

---

To be fair, DSP involves a lot of numerical approximations, but they nearly always fall within the typical "DSP toolbox":

• Quantization
• Alternative ways of computation using transforms
  • A value / function X can be computed in the ordinary way, or transformed via T and then T^-1 to get the same result; which way is faster?
  • Where T would almost always be linear and reversible, and mostly somewhat related to frequency domain, eigen values, or some form of "energy" / "spectrum"
• Approximation by truncation of coefficients after a transform
• Approximation of very basic transcendental functions such as tangent, arctangent, inverse square roots, etc
• Ordinal processing (median filter, etc), which already sounds a bit non-mainstream in DSP.

It is because of this "everyday-ism" that when we see request for some novel transformations or numerical functions, we would be startled - "is this a new paper?" "is this useful for my DSP field of applications?" ...

---

There is one ECE field, namely "optimization (maximization/minimization) of systems and control", and a related CS field of "numerical optimization" which requires heavily use of novel mathematical tools far beyond the typical DSP toolbox. Depending on the applications, some DSP users will deal with this regularly.

---

My suggestions would be:

• Let's learn to be not so easily startled by novel, unconventional, non-mainstream requests for transforms and functionals (i.e. be more open and accepting)
• However, do require the asker to explain its relevance and its application in DSP
  • "relevance and its application in DSP" is subjective and consensus-forming.
• And also explain why off-the-shelf solutions is not an answer
  • If the OP asks about running a DSP simulation on desktop, we assume that the OP has full access to MATLAB/Mathematica/R/Maple/Ocatve/SciPy/SuperPi, hence there is not an actual obstacle to be solved.

---

An example of off-topic question:

• How to find Pi to the duotrigintillion digits using modular arithmetic?
• How to find the duotrigintillion-th prime number using FFT?

In the above two examples,

• [-] It serves no physical purpose for using a highly-precise value of Pi (*) in a calculation. (beyond 39 decimal places; see Wikipedia.)
• [-] Even though huge prime numbers have real applications in cryptography and theoretical mathematics, those two are not typically considered DSP
• [+] Despite the fact that modular aritmetic and FFT are very common DSP mathematical tools.

---

Automatically on-topic because it is rooted in DSP:

• Cepstrum
• Beam-forming
• Carrier detection
• Wavelets

---

Oddballs.

• Anti-aliasing has its origins in sampling theory, but has since become a well-known term thanks to marketing efforts.
• A similar phenomenon is clock speed, which used to be a genuine electrical engineering topic that has since been marketed.

For these oddballs, we would ask question posters to:

• First, consider if there is a more appropriate forum for the question-to-be-asked.
  • https://electronics.stackexchange.com/questions/tagged/sampling
  • https://superuser.com/questions/tagged/anti-aliasing
  • https://photo.stackexchange.com/ (I assume most people there knows anti-aliasing)
  • https://stackoverflow.com/questions/tagged/image-processing (to solve image quality issues when using a particular language/platform/framework)
• If there isn't a more appropriate forum, or if it requires expert attention, then it can be asked in DSP.