Python for DSP

On Sunday, March 22, 2015 at 10:09:00 AM UTC-4, Max wrote:
> Seems that Python is catching on for some DSP work. The recent
> Coursera course co-sponsored by Julius Smith III used Python rather
> than Matlab.
> 
> I've searched for DSP libraries but there's kind of a confusing
> jumble. Some are just using SciPy.  Does anyone know of specific
> Python libs that would extend SciPy's scope?

I actually _do_ use python for DSP prototyping & development, as I've found it's orders of magnitude faster than doing the same thing in c or c++, but mostly using SciPy and Matplotlib.  Since I don't have (can't afford) a matlab license and since Octave is not quite compatible enough to actually use .m files, I decided to try a more general-purpose language that was more broadly applicable, and have been very happy with it.  YMMV.
-Mike

On Sunday, March 22, 2015 at 7:09:00 AM UTC-7, Max wrote:
> Seems that Python is catching on for some DSP work. The recent
> Coursera course co-sponsored by Julius Smith III used Python rather
> than Matlab.
> 
> I've searched for DSP libraries but there's kind of a confusing
> jumble. Some are just using SciPy.  Does anyone know of specific
> Python libs that would extend SciPy's scope?

I'm in the process of changing our "DSP" Post-Processing application over to a python/NumPy based scripting language interface from hard coded menu items. It was pretty easy to integrate Python 2.7.3 and a custom NumPy with  the Windows WPF front end interface and Intel C fast closed source DSP backend stuff.  I also put together a IPython test system to start experimenting with.  Right now I still use MATLAB for all prototyping, but I think the NumPy tools have come a long way, and you can't beat the licensing.

On Mon, 23 Mar 2015 16:19:01 -0500, Tim Wescott
<seemywebsite@myfooter.really> wrote:

>On Mon, 23 Mar 2015 12:53:58 -0700, gyansorova wrote:
>
>> On Tuesday, March 24, 2015 at 5:04:29 AM UTC+13, Tim Wescott wrote:
>>> On Mon, 23 Mar 2015 10:22:41 -0400, Max wrote:
>>> 
>>> > On Sun, 22 Mar 2015 10:08:29 -0400, Max <Max@sorrynope.com> wrote:
>>> > 
>>> >>Seems that Python is catching on for some DSP work. The recent
>>> >>Coursera course co-sponsored by Julius Smith III used Python rather
>>> >>than Matlab.
>>> >>
>>> >>I've searched for DSP libraries but there's kind of a confusing
>>> >>jumble.
>>> >>Some are just using SciPy.  Does anyone know of specific Python libs
>>> >>that would extend SciPy's scope?
>>> > 
>>> > Tap tap....Is this thing on?
>>> > 
>>> > Well, I guess the deafening silence answers that question; no one is
>>> > using Python!  :-)
>>> > 
>>> > If anyone is curious, I found a paper, Python for Audio Signal
>>> > Processing (Glover, Lazzarini, and Timoney)  that outlines some
>>> > libraries. I believe there is also a code library at the Coursera
>>> > site that I  mentioned above, but I haven't checked it yet to find
>>> > out the scope.
>>> > 
>>> > Please check in if you find anything later.
>>> 
>>> No one here, at least.  There's someone who comes on and mentions it
>>> occasionally, but that's as far as it goes.
>>> 
>>> I'm past the age where I'm willing to learn a new language just for
>>> fun,
>>> so learning Python is low on my list of priorities.
>>> 
>>> --
>>> www.wescottdesign.com
>> 
>> I couldn't agree more! What the hell is wrong with a simple c compiler?
>> Is there something that Python gives us that c doesn't? Don't get me
>> wrong, I am open to new things, I program FPGAs in LabView language even
>> for rapid prototyping. Python doesn't hit the spot with me though.
>
>I can't answer why Python may be better than C, but between Scilab and C 
>I've got my own bases covered.
>
>There's a lot of PC applications being written in languages other than C, 
>because the development can go quicker.  I could see a place for Python 
>there -- I'm just not ready to go run out and learn it yet, though.


We have 3 engineers that use Python for automated testing and burn-in
of our products.  It works great for that.  Lots of communications and
fancy readout and GUI libraries available  that makes that kind of
thing work great and in pretty short order.  It's also fairly
transportable to other OS's like PC--Linux-- OSX, et.     It ~can~ be
compiled as well, sort of.  

I can't see Python doing much for the embedded or DSP world though.


boB
K7IQ

On 23/03/15 19:53, gyansorova@gmail.com wrote:
> On Tuesday, March 24, 2015 at 5:04:29 AM UTC+13, Tim Wescott wrote:
>> I'm past the age where I'm willing to learn a new language just for fun,
>> so learning Python is low on my list of priorities.
>
> I couldn't agree more! What the hell is wrong with a simple c compiler?
 > Is there something that Python gives us that c doesn't?

I agree too, and have applied that sentiment for a quarter of a
century. I would, however, claim that you aren't asking the
best question...

You also need to take into account the availability of /relevant/
*libraries* - arguably they are more important than the language
itself. (Of course a good language encourages the /rapid/ development
of good libraries, e.g. in 1998 Java had better libraries in 2 years
than C++ had failed to get in 10).

You also need to take into account the vibrancy of the community
and the development environment.

The analogy with processors is clear: the processor matters less
than tool the ecosystem surrounding it. Ditto FPGAs

On Mon, 23 Mar 2015 16:46:19 -0400, Randy Yates
<yates@digitalsignallabs.com> wrote:

>gyansorova@gmail.com writes:
>
>> I couldn't agree more! What the hell is wrong with a simple c
>> compiler? Is there something that Python gives us that c doesn't?

I said something similar about Matlab at first.  I came from C/C++, so
I didn't get why anyone would want to use a primitive looking slow
environment with arrays that start at 1 rather than 0.  It took me a
while to appreciate Matlab's charms.

Same with Python so far.  My own simplistic take on it:

C/C++  =  code slowly, run fast
Python = code fast, run slowly

Python is used often to glue atomic C and Fortran code together.
Python's numeric and scientific (DSP, etc) libs were written in C/C++.

I do miss my curl-braces, and I find Python's indent-based groupings
tedious and error-prone. But there's no denying that it is sweeping
through the academic world, which often is an indication that it will
be a dominant platform for a long while.  It seems to have wiped Perl
out of the bio-related domain practically overnight (glory be--I
really did not like Perl).  It has made significant inroads in
scientific programming in general.

>Or that GNU Octave doesn't? 

I used Octave before ever running Matlab (a machine learning course).
I assumed that Matlab was also going to run at a snail's pace, so I
was surprised to find out that it was many times faster.  I think
there are problems with compatibility of common Matlab source files as
well, but I haven't run Octave since then.

On 24/03/15 10:47, Max wrote:
> and I find Python's indent-based groupings
> tedious and error-prone.

I'm suspicious of that too, since I don't understand whether/how
refactoring browsers interact with it.

Is there any chance that it "encourages" programmers to write
less deeply "indented" code? If so, that's probably a bonus.

On Tue, 24 Mar 2015 11:06:08 +0000, Tom Gardner wrote:

> On 24/03/15 10:47, Max wrote:
>> and I find Python's indent-based groupings tedious and error-prone.
> 
> I'm suspicious of that too, since I don't understand whether/how
> refactoring browsers interact with it.

I just use a decent text editor and maintain my indents myself (4 spaces, 
each time, always, per the PEP8 style guide), but one of my officemates 
uses the Python aware features of Eclipse and quite likes the refactoring 
tools available.  I'm just more comfortable cutting and pasting myself.

The one thing I find really handy is that my editor (Geany) will put 
little dotted lines dropping down from indent levels, which helps keep 
things visually lined up.

> 
> Is there any chance that it "encourages" programmers to write less
> deeply "indented" code? If so, that's probably a bonus.

Not in my experience.  The bigger limitation on that is, again, PEP8 with 
it's highly sensible recommendation to not go past 79 characters per 
line, but folks will do what folks will do.

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

On Tue, 24 Mar 2015 06:47:27 -0400, Max <Max@sorrynope.com> wrote:

>On Mon, 23 Mar 2015 16:46:19 -0400, Randy Yates
><yates@digitalsignallabs.com> wrote:
>
>>gyansorova@gmail.com writes:
>>
>>> I couldn't agree more! What the hell is wrong with a simple c
>>> compiler? Is there something that Python gives us that c doesn't?
>
>I said something similar about Matlab at first.  I came from C/C++, so
>I didn't get why anyone would want to use a primitive looking slow
>environment with arrays that start at 1 rather than 0.  It took me a
>while to appreciate Matlab's charms.
>
>Same with Python so far.  My own simplistic take on it:
>
>C/C++  =  code slowly, run fast
>Python = code fast, run slowly
>
>Python is used often to glue atomic C and Fortran code together.
>Python's numeric and scientific (DSP, etc) libs were written in C/C++.
>
>I do miss my curl-braces, and I find Python's indent-based groupings
>tedious and error-prone. But there's no denying that it is sweeping
>through the academic world, which often is an indication that it will
>be a dominant platform for a long while.  It seems to have wiped Perl
>out of the bio-related domain practically overnight (glory be--I
>really did not like Perl).  It has made significant inroads in
>scientific programming in general.
>
>>Or that GNU Octave doesn't? 
>
>I used Octave before ever running Matlab (a machine learning course).
>I assumed that Matlab was also going to run at a snail's pace, so I
>was surprised to find out that it was many times faster.  I think
>there are problems with compatibility of common Matlab source files as
>well, but I haven't run Octave since then.

Octave is very compatible with Matlab code written probably ten years
ago or more, but doesn't, and understandably can't, keep up with how
Matlab evolves.   I tried to port some recent Matlab code to Octave so
that I could help a client, but it was a fool's errand.   The two have
diverged a bit too much.


Eric Jacobsen
Anchor Hill Communications
http://www.anchorhill.com

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

eric.jacobsen@ieee.org (Eric Jacobsen) writes:

> On Tue, 24 Mar 2015 06:47:27 -0400, Max <Max@sorrynope.com> wrote:
>
>>On Mon, 23 Mar 2015 16:46:19 -0400, Randy Yates
>><yates@digitalsignallabs.com> wrote:
>>
>>>gyansorova@gmail.com writes:
>>>
>>>> I couldn't agree more! What the hell is wrong with a simple c
>>>> compiler? Is there something that Python gives us that c doesn't?
>>
>>I said something similar about Matlab at first.  I came from C/C++, so
>>I didn't get why anyone would want to use a primitive looking slow
>>environment with arrays that start at 1 rather than 0.  It took me a
>>while to appreciate Matlab's charms.
>>
>>Same with Python so far.  My own simplistic take on it:
>>
>>C/C++  =  code slowly, run fast
>>Python = code fast, run slowly
>>
>>Python is used often to glue atomic C and Fortran code together.
>>Python's numeric and scientific (DSP, etc) libs were written in C/C++.
>>
>>I do miss my curl-braces, and I find Python's indent-based groupings
>>tedious and error-prone. But there's no denying that it is sweeping
>>through the academic world, which often is an indication that it will
>>be a dominant platform for a long while.  It seems to have wiped Perl
>>out of the bio-related domain practically overnight (glory be--I
>>really did not like Perl).  It has made significant inroads in
>>scientific programming in general.
>>
>>>Or that GNU Octave doesn't? 
>>
>>I used Octave before ever running Matlab (a machine learning course).
>>I assumed that Matlab was also going to run at a snail's pace, so I
>>was surprised to find out that it was many times faster.  I think
>>there are problems with compatibility of common Matlab source files as
>>well, but I haven't run Octave since then.
>
> Octave is very compatible with Matlab code written probably ten years
> ago or more, but doesn't, and understandably can't, keep up with how
> Matlab evolves.   I tried to port some recent Matlab code to Octave so
> that I could help a client, but it was a fool's errand.   The two have
> diverged a bit too much.

I would second that. 

However, why would STARTING OUT FRESH in Octave be less advantageious
than STARTING OUT FRESH in Python?

(Not saying you said or implied that Eric, just posing the question)

--Randy

>
>
> Eric Jacobsen
> Anchor Hill Communications
> http://www.anchorhill.com
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> http://www.avast.com
>

-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com

On 3/24/2015 4:32 PM, Randy Yates wrote:

> I would second that.
>
> However, why would STARTING OUT FRESH in Octave be less advantageious
> than STARTING OUT FRESH in Python?
>
> (Not saying you said or implied that Eric, just posing the question)
>
> --Randy
>

good question. Given that Matlab is used in all of engineering
courses I know about (at least in all of signal processing I've
seen), so students are all familiar with Matlab syntax.

speaking of Octave: Biggest blunder the developers there are
making, is trying to improve the syntax and add features not in
Matlab.  But most people do not care about that, they just
want 100% Matlab compatibility. The more they try to make
Octave better than Matlab and change syntax to do so, the less
it becomes attractive (at least to me). (for one example,
this broadcasting feature

https://www.gnu.org/software/octave/doc/interpreter/Broadcasting.html

Sure, it is very nice, but it is not in Matlab. So if I use
it, it means my code will not run in Matlab anymore.

--Nasser