# Notation

The notation we use is somewhat unusual when compared to standard notation in the vast majority of texts on signals and systems. However, we believe that the standard notation is seriously flawed. As a community, we have been able to get away with it for many years because signals and systems dealt only with continuous-time LTI systems. But to be useful, the discipline must be much broader now. Our specific complaints about the standard notation include:

- It is all too common to use the form of the argument of a function to define the function. For example,
*x*(*n*) is a discrete-time signal, while*x*(*t*) is a continuous-time signal. This leads to mathematical nonsense like the*x*(*n*) =*x*(*nT*) to define sampling. Similarly, many authors use ω for frequency in radians per second (unnormalized) and W for frequency in radians per sample (normalized). This means that*X*(W ) ¹*X*(ω ) even when W = ω . The same problem arises when using the form*X*(*jω*) for the continuous-time Fourier transform and*X*(*e*) for the discrete-time Fourier transform. Worse, these latter forms are used specifically to establish the relationship to the Laplace and Z transforms. So^{jω }*X*(*jω*) =*X*(*s*) when*s*=*jω*, but*X*(*jω*) ¹*X*(*e*) when^{jω }*e*=^{jω }*jω*. The intent in using the form of the argument is to indicate what the domain of the function is. However, the form of the argument is not the best way to do this. - Most texts call the expression
*x*(*t*) a function. A better interpretation is that*x*(*t*) is an element in the range of the function*x*. The difficulty with the former interpretation becomes obvious when talking about systems. Many texts pay lip service to the notion that a system is a function by introducing a notation like*y*(*t*) =*T*(*x*(*t*)). This makes no distinction between the value of the function at*t*and the function*y*itself. Why does this matter? Consider our favorite type of system, an LTI system. We write*y*(*t*) =*x*(*t*) **h*(*t*) to indicate convolution. Under any reasonable interpretation of mathematics, this would seem to imply that*y*(*t*- t ) =*x*(*t*- t ) **h*(*t*- t ). But it is not so. How is a student supposed to conclude that*y*(*t*- 2t ) =*x*(*t*- t ) **h*(*t*- t )? This sort of sloppy notation could easily undermine the student's confidence in mathematics. -
We have chosen to use long names for functions and variables when
they have a concrete interpretation. Thus, instead of
*x*we might use*Sound*. This follows a long-standing tradition in software, where readability is considerably improved by long names. By giving us a much richer set of names to use, this helps us avoid the pitfalls we cite above. For example, to define sampling of an audio signal, we might write*SampledSound*=*Sampler*(_{T}*Sound*). It also helps bridge the gap between realizations of systems (which are often software) and their mathematical models. How to manage and understand this gap is a major theme of our approach.