-
Notifications
You must be signed in to change notification settings - Fork 86
/
Copy pathaliasing.html
176 lines (145 loc) · 9.22 KB
/
aliasing.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
<html>
<head>
<title>Circles Sines and Signals - Aliasing</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<script type="text/javascript" src="third_party/d3/d3.min.js"></script>
<script type="text/x-mathjax-config">
MathJax.Hub.Config({
jax: ["input/TeX","input/MathML","output/SVG"],
extensions: ["tex2jax.js","mml2jax.js","MathMenu.js","MathZoom.js"],
TeX: {
extensions: ["AMSmath.js","AMSsymbols.js","noErrors.js","noUndefined.js"]
}
});
</script>
<script type="text/x-mathjax-config">
MathJax.Hub.Config({ TeX: { extensions: ["color.js"] }});
</script>
<script type="text/x-mathjax-config">
MathJax.Hub.Config(
{
SVG: {linebreaks: { automatic:true }},
displayAlign: "center"
}
);
</script>
<script type="text/javascript"
src="//cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.1/MathJax.js?config=TeX-AMS-MML_SVG">
</script>
<link href='//fonts.googleapis.com/css?family=Lato:400,700' rel='stylesheet' type='text/css'>
<link href='//fonts.googleapis.com/css?family=Vollkorn:400italic,400' rel='stylesheet' type='text/css'>
<style>
@import url("fontello-b1d57784/css/fontello.css");
@import url("style.css");
</style>
<link rel="icon" type="" href="favicon.ico"></head>
<body>
<div class="title">
<table width="900">
<tr>
<td width="90%">
<div class="bigheader" id="titleinfo">
</div>
</td>
</tr>
<tr>
<td width="70%">
<br/>
<div id="menu" class="menu" style="margin-left: 45; ">
<table> <tr id="menurow"> </tr> </table>
</div>
<!-- -->
</td>
</tr>
</table>
</div>
<div class="littleheader"> INTERPRETING DISCRETE SIGNALS
<div class="subheader" style="font-size: 14px">DON'T CONNECT THE DOTS! </div>
</div>
<table class="figureTable">
<tr>
<td style="vertical-align: top;">
<div class="text" style="margin-left: 0px">
<p>
You must always avoid the temptation to “connect the dots” (to naively interpolate between samples) when working with discrete signals.<sup>1</sup> Let’s recall the example from the <a href="discrete_signals.html">previous section</a>, and see how connecting the dots can get us into trouble.
</p>
<p>
Imagine someone asks you what the altitude of the plane was at 65 minutes into the flight. How should you respond? You don’t actually have a sample for the altitude at 65 minutes, but you <i>do</i> have measurements for the altitude at 60 minutes and 70 minutes. You might feel tempted to draw a line between these two samples, perform some simple linear interpolation, and infer that the altitude was about 31,000 feet. This sort of temptation is completely natural, but <i>really unhealthy</i> when working with discrete signals. The most appropriate response is simply to say, “I don’t know”. Anything else would be a fib.
</p>
<p>
Given our measurements and context, we cannot confidently report an altitude for 65 minutes into the flight. Our discrete signal tells us nothing about the altitude of the plane at 65 minutes into the flight. Think about it like this: our discrete signal can actually represent many potential flight histories, most of which have different altitudes at 65 minutes into the flight. In actuality, there are an <i>infinite</i> number of possible flight histories which intersect with the samples of our discrete signal but assume decidedly different altitudes at the 65 minute mark. Click the Play button to see four examples. I hope you’ll notice that connecting the dots in a naive way can be extremely misleading.
</p>
<br/><br/><br/>
<table>
<tr class="figureCaption">
<td width="100%">
<b>Figure 1.</b> Altitude of a Plane as it Traveled from Paris to Berlin<br/><sub>Samples connected dubiously with a grey line</sub><br/>
</td>
</tr>
<tr>
<td>
<div id="animatedWrapperAliases" class="animation" style="position: relative;">
<svg id="planealiases" class="svgWithText" width="700" height="200" style="padding-top: 0px; margin-left: 30px;"></svg>
<script type="text/javascript" src="js/plane_aliases.js"></script>
</div>
</td>
</tr>
</table>
<p>
We would call the red, blue, green, and orange curves <i>aliases</i> of one another since they are indistinguishable from one another when sampled with a period of <span class="inlineexample">10 minutes per sample</span>. In other words, the red, green, blue, and orange signals all look <i>exactly</i> the same after being sampled every ten minutes.
</p>
<br/>
<div style="color: #999">
<span class="icon-attention-1 bigicon" style="color: #999; font-size: 15px"></span> I’ve strongly advised that you should not, “connect the dots” when working with discrete signals. Over the next thirty or so pages I will break this rule. I’m breaking the rule because all of the signals in this document are contrivances, and I feel that showing the continuous counterpart to each discrete signal makes the visualizations more readable and easier to understand. Always remember that I’m being naughty when you see connected dots. Do as I say, and not as I do when you’re out there practicing DSP out in the real world.
</div>
</td>
<td class="figureExplanation" style="">
<b>1.</b>
If you <i>properly</i> sample, it is possible to confidently interpolate between samples. The point I'm trying to make here is that naïve sampling will almost always get you into a situation where your discrete signal doesn't represent the signal you measured with very good fidelity.<br/><br/><b>P.S.</b> If you’re feeling eager to point out the contradictory and awkward nature of presenting continuous signals using a computer program and digital screen, I'm way ahead of you, and fully aware of the embarrassing meta concerns here.<br/><br/>
</td>
</tr>
</table>
<div class="littleheader"> REMOVING UNCERTAINTY
<div class="subheader" style="font-size: 14px">FREQUENCY AND CONTEXT</div>
</div>
<table class="figureTable">
<tr>
<td style="vertical-align: top;">
<div class="text" style="margin-left: 0px">
<p>
Whenever there is a gap between samples, uncertainty can creep into our measurements. As the gaps get larger, we become less confident that our discrete signal faithfully represents the physical phenomenon that it was meant to measure. Rapid fluctuations and movements which occur between samples will be lost. We can improve the fidelity of our discrete signals by shortening the gap between samples - by reducing the sampling period.
</p>
<p>
Imagine that instead of sampling every ten minutes, we had decided to sample the plane’s altitude every 5 minutes. This simple choice would allow us to rule out the orange, green, and red curves as possible aliases of our true signal based upon the sample at 65 minutes. It would be clear that the blue curve is the only possible candidate which still intersects with our samples.
</p>
<br/>
<table>
<tr class="figureCaption">
<td width="100%">
<b>Figure 2.</b> Decreasing the Sampling Period to 5 Minutes.
</td>
</tr>
<tr>
<td>
<svg id="plane5" class="svgWithText" width="700" height="180" style="padding-top: 0px; margin-left: 30px;"></svg>
<script type="text/javascript" src="js/plane_lower_period.js"></script><br/><br/>
</td>
</tr>
</table>
<p>
Unfortunately, there is a cost associated with sampling. Each sample must be stored somewhere, and space (e.g. memory) is not free. We cannot reduce our sampling period without incurring some overhead. The fundamental trick to sampling is understanding <i>precisely</i> how often you must sample in order to avoid information loss. When we sample more often than is necessary, we say that we are <i>oversampling</i>. Generally, oversampling implies that memory or computational resources are being wasted.<sup>2</sup> When we sample too infrequently and lose information we say that we are <i>undersampling</i>.
</p>
<p>
Proper understanding of sampling theory is much easier when we understand the notion of <i>frequency</i>. In the next few sections we'll leave altitudes behind and look at a class of signals for which frequency is a more natural concept. Sound waves.
</p>
</td>
<td class="figureExplanation" style="">
<br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/><br/>
<b>2.</b>
Oversampling and undersampling are sometimes done deliberately. For example, audio plugins will often deliberately oversample to ensure that they don't produce audible artifacts as a result of their processing. In this case you’re trading memory and computation resources for better audio quality.<br/><br/>
</td>
</tr>
</table>
<br/><br/><br/>
<div class="title" id="footer"></div><script type="text/javascript" src="menu.js"></script></body>
</html>