Ctrl-Alt-Del's review is a graphical representation of Ars Technica's review.

A top-end BFG card would cost as much as I spent recently on a PS3 + 3 games bundle; no wonder the market for expensive video cards tanks: the current-gen consoles are now half their initial prices and a lot of people want to experience gaming on their new HD television set, which also cost a fraction of what it did a few years ago.

I'm not sure about ActionPython -- why pay for a bundle of free components? But I for one am a long-time Matlab user, and I am slowly migrating towards Python (using numpy, scipy, matplotlib, ipython, etc.). Migration is slow mainly because I have to recode some of my own Matlab tools, but so far it's been succesful. Not painless mind you, as the differences in numpy and Matlab can cause really subtle bugs.

So while it's great that ActivePython now gets numpy and matplotlib, I wouldn't say there is one less reason to use Matlab since those components were already available anyway...

Well this D-Drive resembles the Thompson coupling in that they both seem new but they're really not. The Thomson coupling is a (admittedly nicely packaged) double cardan joint, while the D-Drive is a powered-planetary, already used in infinitely variable transmissions before. I'm not sure if that particular arrangement existed before, and it's nice to see that novelty is still possible in basic mechanics, but similar devices with powered neutral already exist (for example in tractors).

A few quick comments on this well-informed post...

Price: you're right here, Matlab is expensive and is locking you down, but at least you get very decent support from The MathWorks.

Graphics: Matlab has a huge library of very usable graphics functions. However it is nonetheless lacking in certain areas. GUIs is one of them (you can only embed Matlab graphics in a Matlab GUI, and the various methods to build a GUI in Matlab mostly sucks compared to what is possible outside of Matlab). Also, while Matlab figures exported to other format (PDF, EPS, bitmaps) are fine, on-screen Matlab figures are not anti-aliased and sometimes present quirks that are not really there. Matplotlib uses the Antigrain library for screen output, so the end result is much more pleasing to the eye.

Speed: Using numpy, you benefit from the binary linear algebra subroutine (BLAS) speed, much as Matlab. Generic loops tends to be slower than Matlab because of Matlab's Just-in-Time (JIT) optimizer.

Documentation: I'll give you this one hands-down: Matlab has *excellent* documentation, written by experts in the field. This is an often neglected area, but clean and profuse documentation and examples allows you to do more things, much quicker.

Dev environment: very good in Matlab, but using any Python syntax-aware text editor + the IPython shell, I don't miss much when developing Python. Python is generally more consistent (e.g. you can define a multi-statement function interactively in the Python shell), which speeds up development. Also, Matlab is beginning to feel a namespace crunch. All functions in all toolboxes are in the same namespace in Matlab, and it's beginning hard to find creative new names for my own function, all the most if they replicate some Matlab's built-in capability. Python's namespace / module imports solves this problem very nicely.

Speed in interpreted languages such as Python and Matlab depends strongly on what it is doing exactly, and how it is done. For example, both Matlab and the numpy Python module use external, pre-compiled, and highly optimized basic linear algebra subroutines (BLAS) for things like matrix multiplication. Matlab ships with several different BLAS, but it's even possible for Matlab to use the ATLAS BLAS which numpy uses.

So the speed would be the same in that case, assuming both your Matlab installation and numpy are configured to use the same number of processors (linear algebra is typically highly parallel, and in huge matrix operations, multi-thread overhead will be negligible).

If you code your own matrix multiplication naively in C, you may end up with a factor of 6 or 7 in speed *below* that of Matlab.

However if we're talking about generic loops for example, C is then much, much faster. Matlab has a Just-in-Time (JIT) optimizer which vectorizes straightforward loops; the same for Python is not ready yet (this would be the Unladen Swallow project from Google I think). Depending on the precise morphology of a loop, very different speeds would be obtained in Matlab, C or Python. The lesson here is to use numpy or scipy precompiled and pre-optimized code whenever this is possible. But when it's done right, there's generally much less difference between Matlab, Python and optimized C than many people think.

Probably not; hopefully they would spell "Aperture" correctly.