This function is typical in BMW 1 series Deisels and Mercedes A and B class Diesel cars in Germany. They've been pushing it on TV for a couple of years now. Too bad they don't send those models to N. America. Cars are pathetic here. Do they think we would never buy the good ones? Maybe they're right.

I just moved to the US from Germany. I replaced my Golf I had there with a new one from here. What a let down. Only choice = 170HP ~30 mpg, optimistically speaking - unless you want to spend 27-30 K USD on a diesel.

As for Polos, even the 100HP gas model beats a Prius (OK, just barely), but they are kind of small.

If you check out the Golf models at the above link, you'll see they pretty much all match or beat the Prius. Why don't they offer them here? (And don't give me any BS about tighter emissions regulations here - compared to Northern Europe, our environmental regulations are also sad and embarrassing. Besides, they do actually offer the GTI here -also sad compared to the euro GTI- which is using stratified injection, just like all the other euro models).

I asked my friend who works at the VW lab in Palo Alto about it (i.e. when will we be able to get the good stuff here) and all she said was that everyone asks them that.

Not exactly true. It's running at 40 MHz, so that's 25 ns bunch spacing. Further, you don't exactly have to 'crunch' the data as it comes in, there are multiple triggers that throw lots of data away based momentum cuts and other criteria before it ever makes out of the detectors.

In ATLAS, for example, there are ~ 10e+9 interactions/sec. The Level1 Trigger, consists of fast, custom electronics programmed in terms of adjustable parameters to control filtering algorithms. Input is from summing electronics in the EM and hadron calorimiters, and signals from the fast muon trigger chambers. The info is rather coarse at this point (transverse momentum cuts, narrow jet criteria, etc), and at level one the info rate is decreased in about ~2us (including communication time), from 40MHz to about 75KHz. Level2 now does a closer look, taking more time and focusing on specific regions of interest (RoIs). This process takes about 10ms, and data rate is reduced to about 1KHz for sending to the event filter. Here, the full granularity of the detector (the 'detector means all the bits - Inner detectors: Pixels, strips, Transition Radiation tracker - The calorimiters - The muon tubes at the outside radius) and runs whatever selections algorithms are in use. This takes a few seconds, and output is reduced to about 100Hz and written to disc for a gazillion grad students (like myself) to analyze endlessly and get our PhDs.

There is much more to it of course, but you can find info about it on line if you really are interested in the details. Have a look at the ATLAS Technical Design Report: http://atlas.web.cern.ch/Atlas/GROUPS/PHYSICS/TDR/TDR.html

True, and we should mention that the time resolution on fMRI is on the order of a second or two. This suggests also some significant time walk or smearing in the signal. The point is that minimum brain response time is quite a bit faster than this (a few tens of ms), and this is smaller than the resolution of fMRI.

That being said, if you don't have brain pictures in your grant proposal, your chances of getting a cognitive science grant are greatly diminished. So everyone tries to find some way to use it, whether it makes sense or not.

LabView is kind of an interesting concept I guess, but if you have time critical stuff, where order of operations is important, then you end up with lots of klunky nested loops that take up lots of screen. The overhead on LabView is insane, so forget about speed. You can access shared objects (.so files), dylibs, and dll's though. That helps if you need something to happen in a predictable way, and you can write your own drivers or numerical functions in C++ (like image processing or something, or I once wrote a special driver for a custom piece of hardware where I had to write I2C over two pins on the parallel bus). On the other hand, I have used it to control equipment in experiments (like fire some capacitors, read in the CAMACs, look at probes, etc). It's pretty good for that sort of thing. But I've been tending to scipy + Qt + my own c++ libraries with boost python wrappers lately. I would try different tools, most of the open source things are pretty powerful once you get your groove on (i.e. develop your own typical workflow, this is also true if you spend money. Think of how long it takes to get efficient with Mathematica or MatLab). The best ones IMHO are:

octave
scipy with PyQt
root (with or with out pyhton, and the interpreter is kind of bad)
Qt for easy GUI creation (again, with or with out python)
VTK if you really want to get deep into data visualisation.

Root is good, but I do get 'segmentation violation' errors a lot, accompanied by a core dump. It is often totally untraceable. I wouldn't say it's a "steaming pile if s**t" like the poster below me, by any means. I *RARELY* use the interpreter though, it might actually be a "steaming pile if s**t". But you can use the libraries right in your own C++, and some of the classes are truly great. Great histogramming, really easy to do graphing, easy function fitting (user defined as well as pre-canned functions), integrals, derivatives, you name it. The graphing is quite god. There is a Qt plugin for it too, so you can draw right on a Qt canvas. There is also a comprehensive python wrapper that comes with it, so you could do a PyQt-root analysis if you want, you can set it up kind of like an Igor experiment. It's actually really worth learning if you are a physicist, you'd be at a disadvantage if you didn't. Qtiplot? Ehhh.. klunky, I lose patience every time I try to learn it.

This is the *ONLY* bit of software I have ever used that gives me a consistent kernel panic. Granted, it is a kext, they can be risky. I don't know of another solution for using ext2 or ext3 on a mac.