>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
Reply by AllenDowney●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 to
mathematical)
>>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,
Thank you. I feel like Chapter 7 is where it all starts to come together.
_____________________________
Posted through www.DSPRelated.com
Reply by AllenDowney●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 to
mathematical)
>>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 AllenDowney●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 Rob Gaddi●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 Ramon F Herrera●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 Ramon F Herrera●January 12, 20152015-01-12
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
Reply by Piergiorgio Sartor●January 11, 20152015-01-11
On 2015-01-08 16:14, Eric Jacobsen wrote:
[...]
>> All I know is virii ain't a word in any language.
>
> Apparently it is. It's been used here several times and people
> understood the meaning.
Very likely, using "viruses" or "viria" will be
understood too.
So, we have a situation where a word either does
not have plural, or it has at least 3.
This seems inconsistent.
So, either we do not know, or there is not rule,
at least in English, on how to handle it.
BTW, my spell checker accepts "viruses", but it
rejects "virii" and "viria".
bye,
--
piergiorgio
Reply by Rick Lyons●January 10, 20152015-01-10
On Mon, 05 Jan 2015 12:20:43 -0600, "AllenDowney" <103119@dsprelated>
wrote:
>I am developing a textbook for a computational (as opposed to mathematical)
>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-]
Reply by kaz●January 10, 20152015-01-10
>On Sat, 10 Jan 2015 03:24:37 -0600, "kaz" <37480@dsprelated> wrote:
>
>>>Rick Lyons <R.Lyons@_bogus_ieee.org> wrote:
>>>
>>>(snip)
>>>
>>>> [1] I vote that you use "spectra" instead of "spectrums."
>>>
>>>It might be that some plurals aren't used much, but spectra is
>>>pretty common. (At least in the spectroscopy world.)
>>>
>>>> [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.
>>>
>>>Without having actually looked, I might say that a continuous
>>>curve with dots at sample points could work, but I agree with
>>>Rick, you can't just have the curve. (Unless the sample points
>>>are so close that you can't resolve the dots.)
>>>
>>>-- glen
>>>
>>
>>I see continuous or discrete curve irrelevant.
>
>Are you saying that graphically depicting a
>discrete sequence with what looks like a continuous
>curve is acceptable?
>
yes of course, that is what you realized as well. The plot function moves
linearly from one level to next. That is 1st order interpolator and makes
it look like continuous. Yes all digital values are discrete and so it
can'y be displayed otherwise.
>>All matlab plots (and
>>possibly other tools) produce default continuous curve. e.g. freqz(h,1)
>
>You're joking, right. All of Matlab's plotting
>capabilities consist of plotting straight lines
>from one discrete amplitude value to another discrete
>amplitude value. Zoom in on your freqz(h,1) plot
>and you'll see what I mean.
>
>
>By the way kaz, check out Matlab's 'stem(x)' command.
>
>[-Rick-]
>
or plot with dots. I prefer dots with linear interpolation to see signal
trend, If you zoom in on freqz you will realize that the amplitude levels
(steps) disappear, possibly a false graphics effect to start with. But it
shouldn't matter as all I want is see response.
Kaz
_____________________________
Posted through www.DSPRelated.com