标签: gaussian

It's not news that engineering design and debug is an exercise in investigation and problem solving. After all, if it were not for the constraints of price, time to market, and performance, all afflicted by bugs, unexpected issues, and mysterious observations, engineering would be "simple", relatively speaking.   But, to steal a phrase, there are problems, and then there are problems. In Volume 1 of his classic textbook Detection, Estimation, and Modulation Theory (full disclosure: I barely made it through this first volume of the three-volume set), Harry L. Van Trees identified three classes of signal theory problems:   Detection: Finding a known signal in noise; where "known" means the signal is binary and you just need to know if it if there or not Estimation: Assessing the one-time value of an unknown signal in noise, where the value is analogand its value can be anywhere within a specified range Continuous estimation: where the challenge is to demodulate a continuous, unknown (analog) signal, again in noise   Van Trees also emphasized that the more we know about the nature of the random noise, the better job we can do at any with these three classes. Often, we assume the noise is Gaussian, either because it really is, or because it's all we can deal with. In reality, noise can also be impulse, pink, or have time-varying or cyclostationary mean and other parameters, to cite a few of the many possible variations. (Let's be honest: it wasn't for noise, our engineering lives would be oh-so-much easier.)   Even though many of us do not have to deal directly with detection, estimation or continuous estimation, we do have to deal with problems that are analogous. When reading about the Apollo space program (one of my favorite pastimes), I found that the project teams also divided problems in three groups: the knowns, the unknowns, and the unknown unknowns.   Known problems were those that were well understood, and the solution was relatively easy and cost-free, such as changing a component value in a circuit. Unknown problems were those which were understood fairly well, but the available solutions were unpleasant and involved serious trade-offs and costs in time, performance, and execution.   But the most challenging of all were the unknown unknown problems , where you did not understand the nature of the problem, or that you even had one—at least, not yet. And that was the class that worried the project team the most.   Of the three, what kinds of problem experience do you have? Are they mostly in the known category? Or is your project rife with unknown unknowns? And if the latter, what can you do to minimise their number or severity?

It's not news that engineering design and debug is an exercise in investigation and problem solving. After all, if it were not for the constraints of price, time to market, and performance, all afflicted by bugs, unexpected issues, and mysterious observations, engineering would be "simple", relatively speaking.   But, to steal a phrase, there are problems, and then there are problems. In Volume 1 of his classic textbook Detection, Estimation, and Modulation Theory (full disclosure: I barely made it through this first volume of the three-volume set), Harry L. Van Trees identified three classes of signal theory problems:   Detection: Finding a known signal in noise; where "known" means the signal is binary and you just need to know if it if there or not Estimation: Assessing the one-time value of an unknown signal in noise, where the value is analogand its value can be anywhere within a specified range Continuous estimation: where the challenge is to demodulate a continuous, unknown (analog) signal, again in noise   Van Trees also emphasized that the more we know about the nature of the random noise, the better job we can do at any with these three classes. Often, we assume the noise is Gaussian, either because it really is, or because it's all we can deal with. In reality, noise can also be impulse, pink, or have time-varying or cyclostationary mean and other parameters, to cite a few of the many possible variations. (Let's be honest: it wasn't for noise, our engineering lives would be oh-so-much easier.)   Even though many of us do not have to deal directly with detection, estimation or continuous estimation, we do have to deal with problems that are analogous. When reading about the Apollo space program (one of my favorite pastimes), I found that the project teams also divided problems in three groups: the knowns, the unknowns, and the unknown unknowns.   Known problems were those that were well understood, and the solution was relatively easy and cost-free, such as changing a component value in a circuit. Unknown problems were those which were understood fairly well, but the available solutions were unpleasant and involved serious trade-offs and costs in time, performance, and execution.   But the most challenging of all were the unknown unknown problems , where you did not understand the nature of the problem, or that you even had one—at least, not yet. And that was the class that worried the project team the most.   Of the three, what kinds of problem experience do you have? Are they mostly in the known category? Or is your project rife with unknown unknowns? And if the latter, what can you do to minimise their number or severity?