Allen: I wish the greatest success to your book, but have a question. Why on earth do people program this type of operations in Python (or on any interpreted programming language)? Aren't they interested in performance? Perhaps Python is great for prototyping DSP stuff? Regards, -Ramon
I am working on a new DSP textbook using Python. Comments are welcome!
Started by ●January 5, 2015
Reply by ●January 12, 20152015-01-12
Reply by ●January 12, 20152015-01-12
On 1/12/2015 12:45 PM, Ramon F Herrera wrote:> > Allen: > > I wish the greatest success to your book, but have a question. > > Why on earth do people program this type of operations in Python (or on > any interpreted programming language)? > > Aren't they interested in performance? Perhaps Python is great for > prototyping DSP stuff? > > Regards, > > -Ramon > >Never mind. I clicked and saw the tremendous user friendliness of Python. Reminds me of C#. After you are done prototyping with it, you can always port to C/C++ for performance (or even to DSP CPUs). -RFH
Reply by ●January 12, 20152015-01-12
On Mon, 12 Jan 2015 13:00:46 -0600 Ramon F Herrera <ramon@patriot.net> wrote:> On 1/12/2015 12:45 PM, Ramon F Herrera wrote: > > > > Allen: > > > > I wish the greatest success to your book, but have a question. > > > > Why on earth do people program this type of operations in Python (or on > > any interpreted programming language)? > > > > Aren't they interested in performance? Perhaps Python is great for > > prototyping DSP stuff? > > > > Regards, > > > > -Ramon > > > > > > Never mind. I clicked and saw the tremendous user friendliness of > Python. Reminds me of C#. After you are done prototyping with it, you > can always port to C/C++ for performance (or even to DSP CPUs). > > -RFH > >A) Yes, I'm usually prototyping. My ultimate deployment platform will be an FPGA, and trying to prototype DSP algorithms in VHDL, using nothing but the analytics tools available in a VHDL simulator, is like pulling teeth with a rusty chainsaw. B) Regarding performance, if you're doing DSP work in Python you're using numpy and scipy, and you request Matlab-style operations be performed on entire vectors/matrices at once. The request itself took the interpretation hit, but the operation gets dropped down to compiled and heavily-optimized libraries under the hood, so when you're up against O(N^2) nonsense at least it's tight. As such, I'm now using Python for offline analytics on the sorts of things I used to use Matlab/Octave for; it's just as fast and doesn't get punched in the face the moment you try to step outside the domain-specific language's specific domain. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
Reply by ●January 14, 20152015-01-14
>To be a little more clear: have them write program which shows acosf+bsinf =Ccos [f+phaseshift] and that the sinusoid is a cos [or sin] with any phase shift>Yes, good suggestion. Thanks! _____________________________ Posted through www.DSPRelated.com
Reply by ●January 14, 20152015-01-14
Hi Rick, Thanks for these. I will have to give them some thought. Allen>On Mon, 05 Jan 2015 12:20:43 -0600, "AllenDowney" <103119@dsprelated> >wrote: > >>I am developing a textbook for a computational (as opposed tomathematical)>>approach to DSP, with emphasis on applications (as opposed to theory). >> >>I have a draft of the first 8 chapters, working on two more. I am >>publishing excepts and the supporting IPython notebooks in my blog,here:>> >>http://thinkdsp.blogspot.com/2015/01/january-is-dsp-month.html >> >>Of if you want to go straight to the book, it is here: >> >>http://think-dsp.com >> >>Comments (and corrections) are welcome! > >Hello Allen, > My compliments to you for preparing tutorial >information. > >[1] I vote that you use "spectra" instead of "spectrums." > >[2] I suggest you go through your material and change > all instances of the word "frame" to the > word "sample." Why use the non-standard, and > possibly confusing, word "frame" for a single number > when the rest of the world of DSP literature uses > the word "sample" to describe a single number? > >[3] I suggest you go through your figures (like > Figure 2.6 for example) and show all discrete > sequences (discrete signals) as a series of dots > rather than as continuous curves. Imagine how confused > a DSP beginner will be when they see a picture of a > continuous (analog) signal and you call it a "sampled > signal" or a "sampled waveform." This is a big deal. > For the sake of your readers, please do not ignore > this suggestion. > >[-Rick-] >_____________________________ Posted through www.DSPRelated.com
Reply by ●January 14, 20152015-01-14
>On Mon, 05 Jan 2015 12:20:43 -0600, "AllenDowney" <103119@dsprelated> >wrote: > >>I am developing a textbook for a computational (as opposed tomathematical)>>approach to DSP, with emphasis on applications (as opposed to theory). >> >>I have a draft of the first 8 chapters, working on two more. I am >>publishing excepts and the supporting IPython notebooks in my blog,here:>> >>http://thinkdsp.blogspot.com/2015/01/january-is-dsp-month.html >> >>Of if you want to go straight to the book, it is here: >> >>http://think-dsp.com >> >>Comments (and corrections) are welcome! > >Hello Allen, > I liked the material in your >Sections 7.1 and 7.2. > >[-Rick-] >Thank you. I feel like Chapter 7 is where it all starts to come together. _____________________________ Posted through www.DSPRelated.com
Reply by ●January 14, 20152015-01-14
>On 1/12/2015 12:45 PM, Ramon F Herrera wrote: >> >> Allen: >> >> I wish the greatest success to your book, but have a question. >> >> Why on earth do people program this type of operations in Python (or on >> any interpreted programming language)? >> >> Aren't they interested in performance? Perhaps Python is great for >> prototyping DSP stuff? >> >> Regards, >> >> -Ramon >> >> > >Never mind. I clicked and saw the tremendous user friendliness of >Python. Reminds me of C#. After you are done prototyping with it, you >can always port to C/C++ for performance (or even to DSP CPUs). > >-RFH > > >Yes, you answered your own question :) I'm also using it primarily for instruction, so performance is not the biggest concern. Also, if most of the computational time is spent doing expensive things (like FFTs) that are implemented in libraries, then Python is going to run pretty close to C speed. And if it doesn't, then as you say, you've got a prototype that would be easy to port. Allen _____________________________ Posted through www.DSPRelated.com
