I concur: the Python shell is a very very powerful calculator given that you can define functions in the interpreter. There are many graphics packages for Python; Matplotlib is perhaps the most complete albeit not the symplest. As suggested above, installing Python with the IPython shell, NumPy and SciPy, enables the "PyLab" IPython mode, which is similar to what Matlab would offer in terms of graphics and computation integration.

Simpler to install and learn is perhaps Octave (with plots using GnuPlot), which would behave similarly. Although for the long term, I'd say learning the Python shell is more useful than learning Octave.

That would be the median person, of course.

That got me thinking. Would a turn-based exchange be feasible? You know, with transactions all executed at predefined intervals? I guess the problem would still be who called dibs first on some offer, so the low ping advantage would remain when the offers are published. Maybe there could be a way in which the offers are propagated randomly as to not give any timing advantage?

What about SCO? Strange it wasn't mentioned at all.

Same thing here. Home theater stuff can generally be found at half the price in the US vs Canada. Same thing with kitchen and bathroom hardware. Also bizarrely I found some stuff that is "designed in Canada" and is distributed in the US but not in Canada. Using www.kinek.com and other border mail services, Canadians can benefit from free shipping (e.g. from Amazon.com) up to the border. Buying cars (typically a few $k less after taxes and duty and import regulations are taken care of) and tires (easily half the price) in the US is also popular.

While 3dB represents a factor 3 in *power*, sound pressure level (which is felt by the air) is proportional to displacement, not power. Thus it takes 6dB to double SPL. As previously mentioned, the human ear is not linear and will instead notice 10dB as a factor 2 in loudness.

In REAMDE, one of Stephenson's character is a prolific writer who is constantly active. He litterally lives on a threadmill. Being rich, he works in a room equipped with an industrial robot that supports keyboard, displays, and a head-tracking camera so that the whole setup is bobbing exactly in synchronicity with his head and arms.

I guess it *is* a solution. I'm just not sure anybody tried it for real yet.

so they're really only Alcubierre drive-equipped ships slowing down in our direction.

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.