Dale Shpak

A consultant in DSP, electronics, embedded systems, and software design and implementation. Started in electronics almost 50 years ago ... I'm not old, I just started a very young age! In addition to consulting and working in industry, I have taught over 30 different post-secondary courses in electrical and computer engineering, computer science, and mechanical engineering and have numerous research publications and some patents. Have written about 1M LoC. I consider myself to be an engineer first and an academic second. B.Sc.EE, M.Eng, PhD, PEng, SMIEEE Beyond the desk, I'm an avid swimmer, cyclist, tenor, and audiophile.

Dale Shpak

's contributions
    • I am always looking for more DSP resources. The info in the 7-part preview is good in that it introduces a large number of DSP topics and applications and will help to pique the curiosity of readers. However, perhaps by trying to be too broad, it falls short in places. As an introduction, it could serve as a launchpad to more rigorous resources. Some comments on the first few parts: - Nyquist should be mentioned for bandlimited signals, not just baseband signals ... but many authors only consider baseband. - FIR filters do not always have linear phase. e.g., there are minimum- and maximum-phase filters. If your application does not need linear phase (constant group delay) then a linear-phase FIR filter wastes resources. - Least-squares isn't the only, nor is it often the most important filter design criterion. - you should always use optimization routines for designing FIR filters and especially when you have limited resources in your DSP chip. You will get a better frequency response and/or lower order than if you simply use windowing functions. - IIR filters are very useful in DSP! Their use requires more care but the benefits can be huge. e.g., you may be able to get considerably fewer multiply/accumulate operations. - although sample-rate conversion is useful, the main thrust in full-fledged multirate DSP is to significantly reduce the total amount of computation required for some DSP systems. e.g., it is useful for low bit-rate coding systems, etc. - It's great to have a book that has good verbal explanations, but more supporting math wouldn't hurt.

    • Welcome to my world, Jack. I started with C/UNIX in 1981, Mac in 1984, Linux in 1995, QNX/POSIX in 2000 and have suffered through many mysterious incantations of Windows. I do my business, internet stuff, and MATLAB, C++ core and Java development in OS X. I like the iWork apps but often have to use lesser tools for compatibility with colleagues. For my embedded tools I run XP SP2 under VMware Fusion. I still use Linux for servers (SVN, file servers, etc.) I value the reliability: I am now on my second laptop in an 8 year period - excellent TCO. Also, you don't have to turf your system every two years due to an irretrievably corrupted "registry". Reboots are very rarely involuntary (normally for kernel/core updates) and the software updates have always worked. Like many, I never went to XP SP3 for fear of clobbering a system that worked OK. To maximize XP's reliability, I install as few apps as possible to avoid registry problems.

    • Well said, Peter. But, you do get used to 1TB, even the "} else {" all on one line. I have used both styles and have no difficulty immediately recognizing scope, nesting, or if-elseif constructs. As a matter of fact, I find it easier to match "if"s to "else"s using 1TB. With 1TB it is also easier to notice that you have the start of a new "if-elseif" in code containing several "if-elseif" blocks since the new "if" will start the line and therefore stand out from all of those "} else if {" constructs. For the history buffs, I believe that PL/M86 used named scopes (which would help to reduce bugs): LABL1: DO; body END LABL1; The important point is that, to date, I have yet to see an example where 1TB can introduce a bug that would be prevented by the Allman style whereas I gave an example of an actual bug that I have seen several times that would be avoided by 1TB. For mission-critical code, any practice that reduces bugs should be employed, even if it only reduces a bug having a probability of 1e-6 to a probability of 1e-9. I therefore use 1TB.

    • Unfortunately, the web site didn't use my multiple spaces (vanilla html). Speaking of which: always set your editor to expand tabs into spaces so that people using other editors can see the structure of your code.

    • Yes Peter, we will have to agree to disagree, although I strongly agree that white space is your friend. However, once you change to 1TB you will find that the structure of your code is probably more visible than it was with the Allman style, as long as you indent your code: while (condition) { indented code line 1 indented code line 2 } The way to think of this is that the right brace ends the while. The indented code is obviously within the scope of the while. Since proper coding style requires that the while aways has a right brace on the same line (no single-line while statements), the structure of the code highly visible and completely unambiguous. It may take a while to get used to the 1TB mindset, but you will never go back. Trust me on this one.

    • Back on my soap box: Please don't counter my inarguable facts with the old "the left brace and right brace nicely line up with the Allman style and show me the scope of my loop". That "prettiness" argument died eons ago with the advent of context-sensitive editors that show you the matching brace. With 1TB you get to see more of your code in the editor window, etc., etc. Notably, the Sun Java style guide wisely uses one-true-brace.

    • Great overview of good coding practices, however ... your examples include a bug-causing practice that is related to your rule #1: The Allman brace style should NEVER be used for languages that use braces for compound statements a semicolon for terminating statements. During my nearly 30 years of C programming, I have debugged millions of lines of code and have encountered the following type of error many times: while (condition); { /* Execute conditional code */ } Of course, the the bug is the semicolon after the while (or if). It is very difficult to notice during code reviews. This bug is very unlikely to occur with the one-true-brace style since a ;{ would be highly visible: while (condition);{ /* Execute conditional code */ } It is because of the automated translation of Pascal texts to C texts and Pascal authors who switched to C that we have this dangerous practice of the Allman style. The only valid reason to ever have a left brace on a line by itself is to limit scope. I have converted hundreds of programmers after convincing them of the many advantages of the one-true-brace style. Once you switch, you will never go back.