On Tue, 24 Mar 2015 17:07:41 -0500, "Nasser M. Abbasi" <nma@12000.org> 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. > >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 >I agree with that sentiment, and Randy's. Octave is still a very productive tool, especially for the price, and it is not difficult to write Octave code that will run without much trouble on Matlab. Going the other way is a little problematic when people are taking advantage of new features in Matlab, but it is still very possible for Octave users to collaborate with people using Matlab. Matlab's biggest hurdle is still their price. In the past I've inadvertently converted clients to Octave users because 1) they just weren't aware it existed, 2) they could afford to put it in a lot more seats than Matlab. Often what happens is that a small company will maintain a few Matlab seats and everybody else who needs it uses Octave. These days other tools proliferate, too, like, apparently, Python. Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com
Python for DSP
Started by ●March 22, 2015
Reply by ●March 24, 20152015-03-24
Reply by ●March 25, 20152015-03-25
On Wednesday, March 25, 2015 at 11:07:45 AM UTC+13, 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. > > 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. > > --NasserI'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?
Reply by ●March 25, 20152015-03-25
On Tue, 24 Mar 2015 21:19:17 -0700, gyansorova wrote:> On Wednesday, March 25, 2015 at 11:07:45 AM UTC+13, 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. >> >> 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 > > 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. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●March 25, 20152015-03-25
On Tue, 24 Mar 2015 17:16:37 +0000, Eric Jacobsen wrote:> 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.In which case one may as well just use Scilab. The only reason I've ever been interested in Octave was for Matlab compatibility. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●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 featureThat 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
Reply by ●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 ●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, >ChrisNot 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 ●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 ●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 ●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?
