Like I said, most of the software is available completely free, just not directly from Enthought; they are responsible for much of SciPy, which is 100% FOSS. MayaVi 1.x is completely free. NumPy is completely free. Documentation for these is completely free.

The Enthought package that they put together, which includes MayaVi 2.x, is not free. But the parent poster wanted paid-for support, so I recommended the Enthought package. For another good free bundled package, check out python(x,y).

Wait, wait, wait. Are you saying "Yes, NumPy and Matlab work the same way, so no advantage to Matlab," or are you saying "the comparison isn't fair because compiled-C/Fortran routines being called by Numpy are being compared to compiled-C/Fortran routines being called by Matlab?"

If you're saying the latter, you need to know that the two software packages pretty much work the same way, you write a quick script and the array (vector) data is passed into a compiled routine to munch on and only when the routine is done operating over all of the data does the result get passed back up to the script (hence both use the "vectorized" coding style). In this sense, Matlab and NumPy are THE SAME.

And lest you be confused, Matlab used Atlas-compiled BLAS routines as of a few releases ago, and as of late they were using the Intel-compiled Netlib-like routines (BLAS, LAPACK, LINPACK, etc.). There is no Mathworks special sauce that makes these fast. Mathworks just passes data down to these routines like NumPy does.

Oh, and I think you meant to say "interpreted," not "interpretive."

Check out Enthought's Python package, it includes amazing 3D visualization (on par with Matlab or superior, I think), the IDE you like from Matlab, good support, good documentation, etc. I don't think that Matlab has much advantage except for certain application-specific software that has just happened to be designed to interoperate with Matlab.

The Enthought pricing page: http://www.enthought.com/products/epd_sublevels.php
(But note that you can get most of the functionality of the software for free, just you mentioned paying for support as an advantage of Matlab.)

Check your comparison facts:

1) Near-compiled speed with a scripting front-end? Try NumPy out, it works the SAME WAY as Matlab (vectorize your code and it runs at near-compiled speed). There isn't any secret to how Matlab does things, it's just what they've put together into one package and the loyal userbase that keeps them going.

2) UI's: iPython or Spyder are user interfaces achieving similar goals to that of Matlab (I prefer the former as I'm a command-line junkie, but the latter will make you believe you're in Matlab: lint and debugger are integrated).

3) Bugs: maybe somebody codes like their job depended on it, but the bugs I've seen got fixed with their 6-month release cycle. That didn't help me a damn bit.

4) Price "up-front": hahahaha, you're joking, right? So if you want your bugs fixed, like I said, most get fixed in their semi-yearly releases, but you only get THOSE if you have an active (a recurring cost) support contract. And then you find that one of your toolboxes or another sw requires the Matlab version that still has the bug in it. Now you're SOL. Commercial software ain't all roses, especially if you aren't a fortune 100 company or a big research institution. I update my Python, NumPy, SciPy, and Matplotlib whenever they have a release OR bugfix/patch, for free, now until doomsday.

Look into the libraries that Sage Math uses for near-Mathematica symbolic manipulation. Or just use Sage (which is built on top of Python).

Simulink I haven't found a great replacement for within Python, but graphical programming is often more of an impediment than a help for me. For layout of one-off control systems, it was nice, but I've just gotten too efficient with text editing (and I'm to the point that I can visualize what's going on) to want to worry about connecting wires, double-clicking, changing properties, etc. (To wit, last time I used Simulink, I auto-generated all of the block diagrams and set all block properties with an m-file script.)

like... vim (or gvim for a more Windows-like UI)? Easy & robust syntax highlighting, awesome find and replace (with regex, too) and column select.

vim was the first editor where I discovered block editing. Such a handy feature. And, like someone said of UltraEdit (I have no experience with that), I've learned not to ask whether VI has a feature, but to ask how to access the feature. And the features of a good text editor that people often miss, that make coding/editing significantly faster, are the navigation features. There are so many ways to shortcut to a place in a file in VIM (as well as other good editors), it'll cut serious time out of editing files.

If you do go in the direction of VI, find a good .vimrc file from the internet, and check out the tips and tricks web page for VIM. And I'm fairly certain that EMACS has all features you could want, also; another situation of just discovering how.

There are 4 kinds of devices, I believe, that make any sense for the FCC to care about:

1. Passive antennas

2. Radios intended to transmit (which do not include an antenna)

3. Radios intended to transmit (which include an antenna)

4. Electronic devices not intended to transmit but that, nonetheless, do radiate (EMI)

Passive antennas are the only category where what you said makes sense. But I think all the FCC cares about passive antennas is what the FAA cares about passive antennas: that they aren't so tall as to knock an airplane out of the sky. An antenna receives as well (that is, with equal gain) as it transmits, so characterizing their gain is important when matching an antenna to device type (2). Typically the FCC wants to approve the entire system (devices in the third category), because it is virtually impossible to know the consequences (including increases in EMI and harmonics that suddenly pop up) of attaching, for example, a 6 dBi antenna to a 100 mW 2.4 GHz WiFi card. But the FCC also must approve the radio (category 2 above) if it is sold separately and then put together by somebody else. A radio will get an advisory that it should only be coupled with antennas equal to or below a certain gain.

Otherwise, a radio in receive mode essentially falls into category (4), which, in other words, needs to pass the same requirements as the computer sitting on your desk does. But the FCC doesn't care if you put a 60 dBi antenna, sensitive to a restricted band, with a receive-only radio.

The PURPOSE of the FCC regs is to keep people playing well together. And it isn't like you listening on a frequency causes somebody else to NOT be able to listen in on that frequency.