Reply by Rob Gaddi ●March 30, 20152015-03-30
On Thu, 26 Mar 2015 16:24:56 -0400, Max wrote:


> On Mon, 23 Mar 2015 23:45:34 +0000 (UTC), Rob Gaddi
> <rgaddi@technologyhighland.invalid> wrote:
> 
>>On Mon, 23 Mar 2015 16:46:19 -0400, Randy Yates wrote:
>  ...
>>> Or that GNU Octave doesn't?
> 
>>Everything but math.  I used to use Octave for most of my numerical
>>analysis stuff, but god is all the stuff around the numerical analysis a
>>kick in the teeth.
> 
> Rob, are you saying that Python's math libs (NumPy, SciPy) fall short in
> that respect?
> 


No no, that Octave's tools for things outside of numerical analysis fall 
short.  I find Python's math libs handle all of the math side of things 
as well as Octave ever did, and as fast as Octave ever did, while letting 
me take advantage of the fact that Python's language and standard library 
are infinitely superior to Octave's for all the ancillary stuff.


>>Simple things like reading all the .csv files in a directory, inferring
>>the sample rate from the file name, and graphing the resultant waveform
>>force you into areas like file and string handling that Octave (and
>>Matlab with it) are completely crippled in.
> 
> Yeah, I'm reminded of everything that good old Visual Basic was
> -supposed- to be back in the day (I really hated that language), but
> Python has structure, more elegant object-orientation, and of course the
> language and libs have a very pragmatic focus.  Reading CSV files is a
> good example.
> 



>>Python is NOT the be all and end all of languages.  The interpreter is
>>slow, the runtime enormous, and when people talk about using it in an
>>embedded environment my eyes roll hard enough to hurt.
> 
> I had just mentioned in another post that it runs on a lot of micros,
> like Raspberry Pi and Arduino. But maybe you're referring to
> DSP-oriented processors?
> 


The RPi is a bit of a different story; it's got the aggregate horsepower 
of every PC I owned for the first 2/3 of my life.  But yes, I'm talking 
Blackfins, or Cortex-Ms, or cute little power-sipping MSP430s.  The sorts 
of things that madmen keep trying to run Linux on due to abject terror 
that they might be forced to write a state machine.


>>And please don't get me started on the disaster that actually
>>distributing applications written in Python has turned out to be.
> 
> I've been wondering about that.  Again, I'm new to Python, but I
> understand that the compilers do a decent job.  Is that not your own
> experience?  Or maybe there's a significant runtime lib that needs to
> ship with them?


The compilers don't compile, the compilers bundle; you basically get a 
ball that's the interpreter and the runtime and (hopefully) all the 
libraries and either the source or the byte-code.  It's fine when all you 
need is things in the standard library, but bigger libraries (matplotlib 
notoriously) start having exciting corner cases.

I'm coming at this specifically from a Linux (Ubuntu) standpoint, where 
we wasted the better part of a month trying to get cx_Freeze to actually 
lock an entire package down, finding one place after another where the 
system needed to be massaged into submission until we finally realized 
that our result was more bailing wire and duct tape than steel, and was 
predicated on so many assumptions that there wasn't any point anymore and 
scrapped the entire idea.

There is now a dedicated Python Packaging Authority (https://www.pypa.io), 
because things have gotten so bad with various approaches spawning and 
forking and dying and being abandoned.  Hopefully by mid-2016 or so the 
situation will be better.  But right now it's a pretty glaring hole in my 
ability to recommend people to "just use Python".

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.
Reply by Max ●March 27, 20152015-03-27
On Thu, 26 Mar 2015 21:06:46 -0700, Mac Decman
<dearman.mark@gmail.com> wrote:


>On Thu, 26 Mar 2015 16:14:32 -0400, Max <Max@sorrynope.com> wrote:



>>Mark, you mentioned using an Intel C library in conjunction with the
>>standard Python libs.  Is it DSP-oriented?  What does it do that the
>>standard Python libs don't do?



>The Intel Math Kernel Library and the Intel compiler just offer CPU
>targeting for optimization.  So you're going to see a significant
>speed improvement for some types of DSP applications on certain CPUs.
>Normally NumPy is built with MKL also.  It does two things when used
>in combination with Python and NumPy.  For speed critical algorithms,
>you can build them in C with MKL and then just return the result as a
>NumPy array for further interactive processing in Python.  Second, it
>can protect the source code for commercial algorithms.  The end-user
>can use your algorithm interactively with in Python to perform some
>processing task.
>
>Mark


Thanks for the info, Mark.  I'll look into that. Thanks.
Reply by Mac Decman ●March 27, 20152015-03-27
On Thu, 26 Mar 2015 16:14:32 -0400, Max <Max@sorrynope.com> wrote:


>On Mon, 23 Mar 2015 18:33:27 -0700 (PDT), Mark DeArman
><s.d.m@ieee.org> wrote:
>
>>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.
>
>Mark, you mentioned using an Intel C library in conjunction with the
>standard Python libs.  Is it DSP-oriented?  What does it do that the
>standard Python libs don't do?
> 


The Intel Math Kernel Library and the Intel compiler just offer CPU
targeting for optimization.  So you're going to see a significant
speed improvement for some types of DSP applications on certain CPUs.
Normally NumPy is built with MKL also.  It does two things when used
in combination with Python and NumPy.  For speed critical algorithms,
you can build them in C with MKL and then just return the result as a
NumPy array for further interactive processing in Python.  Second, it
can protect the source code for commercial algorithms.  The end-user
can use your algorithm interactively with in Python to perform some
processing task.

Mark
Reply by Wolfgang Sörgel ●March 26, 20152015-03-26
On 03/24/2015 12:45 AM, Rob Gaddi wrote:
[...]

> Everything but math.  I used to use Octave for most of my numerical
> analysis stuff, but god is all the stuff around the numerical analysis a
> kick in the teeth.  Simple things like reading all the .csv files in a
> directory, inferring the sample rate from the file name, and graphing the
> resultant waveform force you into areas like file and string handling
> that Octave (and Matlab with it) are completely crippled in.
>


Sure, Matlab (and probably Octave) is mainly a tool for numeric / DSP
computations and simulations. But to me file and string handling are quite
OK. We even use it for a complete framework of C++ code generation, i.e.
Matlab code is prducing C++ code. Of course one could do that in Perl or
python as well. But overall we see it as advantage to have one tool 
everybody is familiar with for use as shell, for visualization, 
simulations, algorithm development (mainly Simulink),... Expensive? Yes, 
no doubt. But i see no real alternative overall, just for single 
applications which would result in a more fragmented development 
environment. May be OK, if you work for yourself but not in environments 
with double digit numbers of developers.
And of course Matlab does not run on any target hardware, it is used to 
develop the target hardware or programs running there!

Servus
Wolfgang
Reply by Max ●March 26, 20152015-03-26
On Mon, 23 Mar 2015 23:45:34 +0000 (UTC), Rob Gaddi
<rgaddi@technologyhighland.invalid> wrote:


>On Mon, 23 Mar 2015 16:46:19 -0400, Randy Yates wrote:

 ...

>> Or that GNU Octave doesn't?



>Everything but math.  I used to use Octave for most of my numerical 
>analysis stuff, but god is all the stuff around the numerical analysis a 
>kick in the teeth.


Rob, are you saying that Python's math libs (NumPy, SciPy) fall short
in that respect?


>Simple things like reading all the .csv files in a 
>directory, inferring the sample rate from the file name, and graphing the 
>resultant waveform force you into areas like file and string handling 
>that Octave (and Matlab with it) are completely crippled in.


Yeah, I'm reminded of everything that good old Visual Basic was
-supposed- to be back in the day (I really hated that language), but
Python has structure, more elegant object-orientation, and of course
the language and libs have a very pragmatic focus.  Reading CSV files
is a good example.


>Python is NOT the be all and end all of languages.  The interpreter is 
>slow, the runtime enormous, and when people talk about using it in an 
>embedded environment my eyes roll hard enough to hurt. 


I had just mentioned in another post that it runs on a lot of micros,
like Raspberry Pi and Arduino. But maybe you're referring to
DSP-oriented processors?


>And please don't 
>get me started on the disaster that actually distributing applications 
>written in Python has turned out to be.


I've been wondering about that.  Again, I'm new to Python, but I
understand that the compilers do a decent job.  Is that not your own
experience?  Or maybe there's a significant runtime lib that needs to
ship with them?
Reply by Max ●March 26, 20152015-03-26
On Mon, 23 Mar 2015 18:33:27 -0700 (PDT), Mark DeArman
<s.d.m@ieee.org> wrote:


>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.


Mark, you mentioned using an Intel C library in conjunction with the
standard Python libs.  Is it DSP-oriented?  What does it do that the
standard Python libs don't do?
Reply by Max ●March 26, 20152015-03-26
On Wed, 25 Mar 2015 12:54:09 -0500, Tim Wescott
<seemywebsite@myfooter.really> wrote:


>On Tue, 24 Mar 2015 21:19:17 -0700, gyansorova wrote:



>> I'm not following the Matlab argument. Matlab is a tool to design and
>> simulate problems, you don't program a micro in it. Unless you mean
>> those cross-compiler things that go from Simulink to machine code. Or
>> are you saying that Python is like Matlab, an interpretive language with
>> a huge library?
>
>Python is like Matlab: an interpretive language with a huge library.
>
>You don't program a micro in Python unless the micro in question is 
>running Linux or Windoze.


There are a lot of micros that run Python though (often under
mini-Linux kernels).  Raspberry Pi, Arduino, etc.  I don 't think
Matlab will be running on those any time soon.  Any micro that has a C
compiler should also be able to host the libraries that form the
Matlab-like DSP core (Numpy, SciPy, MatplotLib)

Python has been making serious inroads into a lot of branches of
science. Within a few years, it seems to have displaced Perl from
bioinformatics (there's some points in Python's favor! :-)

Since it's free, and a favorite of academia,  it's only a matter of
time before it filters down to many more platforms and apps.  I'm
presuming that it will continue to gain popularity in DSP.  It will be
difficult to resist that.

Another difference: Python has been featured in books and courses on
object-oriented software design, including "Design patterns"
(mainstream software approach).  That's not likely to happen with
Matlab.

I'm not a Python evangelist. I barely know the language yet, and as I
mentioned, I miss my curly braces.  But at this point, I think
widespread adoption in my favorite areas is inevitable, so I'm working
on it.  There's such a vast bank of existing DSP code for Matlab, that
its venerable position is safe for a while though.
Reply by Eric Jacobsen ●March 26, 20152015-03-26
On Thu, 26 Mar 2015 08:22:44 -0500, Christopher Felton
<nospam@nowhere.com> wrote:


>On 3/24/2015 5:07 PM, Nasser M. Abbasi wrote:
>> 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.
>
>All?  Many of the MIT OCW ECE are in Python or both.  The
>Oppenheim DSP course mentioned here not too long ago: Python.
>
>>
>> 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
>
>That kinda summarizes why you one would be better starting
>fresh with Python.  Python's design goal is to be a simple
>high-level language and it just happened to be flexible
>enough to be a great control language for numerical and
>scientific computing.
>
>>
>> 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.
>>
>
>It doesn't sound like there is any reasons to start fresh
>with Octave; it is neither a well designed language (or
>missing modern features) and is not fully Matlab compatible.
>
>Regards,
>Chris


Not sure why you think it's not well-designed, but it is still a very
powerful and effective tool and it gives an easy bridge to working in
Matlab.   Octave code, if you're just a little bit careful, can still
easily port to Matlab.   

And Matlab is still very widely used.

So if you want to have a good, powerful, effective tool with an easy
way to step up to Matlab, that's a good path.

If you don't care about Matlab, it's still a powerful (and free) tool.

I still do a lot of work in it and I make a lot of test/verification
source code available to clients and customers, since it will run fine
in Matlab.

I think it's good that there are options, like Python, and C,  and
everything else.


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

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
Reply by Randy Yates ●March 26, 20152015-03-26
Christopher Felton <nospam@nowhere.com> writes:


> It doesn't sound like there is any reasons to start fresh
> with Octave; it is neither a well designed language (or
> missing modern features) and is not fully Matlab compatible.


I've found Octave that has been great for my projects over the past 10
years. I don't know what "well-designed language" issues you're
referring to. By far, my simulation/rapid-algorithm development-life has
been made better with it than without it.
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com
Reply by Christopher Felton ●March 26, 20152015-03-26
On 3/24/2015 5:07 PM, Nasser M. Abbasi wrote:

> 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.


All?  Many of the MIT OCW ECE are in Python or both.  The
Oppenheim DSP course mentioned here not too long ago: Python.


>
> 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


That kinda summarizes why you one would be better starting
fresh with Python.  Python's design goal is to be a simple
high-level language and it just happened to be flexible
enough to be a great control language for numerical and
scientific computing.


>
> 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.
>


It doesn't sound like there is any reasons to start fresh
with Octave; it is neither a well designed language (or
missing modern features) and is not fully Matlab compatible.

Regards,
Chris