wwalker3

It sounded like a broad-spectrum communications monitor.

If you want to know who's broadcasting anywhere in the range from 1MHz to 10GHz (example only -- I don't know the real range for this device), that's a bandwidth of 9.999 GHz.

You could scan freqencies sequentially, but it's slow and you might miss something. You can't afford to build a 20 GHz A-to-D converter, and even if you could, you don't want to build a computer big enough to process the resulting 80 GB/s data stream (assuming a 40 GHz sample rate with 16-bit samples).

The compressive sampling process is what allows you to sample at a lower rate (as long as you can assume that the signal you're looking for doesn't use too much of the total bandwidth). The convex optimization is apparently used to decide how to do the sampling in a way that's guaranteed to recover your signal.

I know a guy who's using convex optimization as part of a project to sample an ultra-wide range of frequencies looking for a hidden narrowband signal (I leave it up to you to guess who would need that kind of device).

Apparently they use "compressive sampling" (http://en.wikipedia.org/wiki/Compressed_sensing) in conjunction with the convex optimization so they can avoid building the superfast A-to-D that you'd normally need to cover such a frequency range.

You can apparently prove that it'll always find the narrowband signal, as long as it's narrow enough.

They've derived exact mathematical expressions for the shapes and locations of those flow separations, and it sounded like the whole derivation was based on the assumption of incompressibility, so I'm not sure how extensible their approach is to compressible flow.

That said, it's totally true that you could use this sort of code in gasdynamics situations where the compressibility doesn't matter much, as you pointed out.

The experimental setup they validated their code with used three liquids -- Fluorinert, glycerol, and vegetable oil -- shearing past each other and the walls of a container while being stirred slowly. All incompressible, true, but perhaps chosen for experimental convenience rather than any problem with their theory's handling of compressibility.

The gist is that they've created a better theory of flow separation (roughly speaking, where a flowing fluid "tears loose" from a boundary surface of some sort to make a sheet of fluid that folds up and projects out into the main flow).

Their theory deals only with incompressible flow, so I'm not sure how much this would help aerodynamic simulations, but it's probably got lots of applications in hydrodynamics and industrial process simulation.

You can see the original papers at http://web.mit.edu/ghaller/www/papers.html.

This article is better than I thought it would be. It's written by Neil Davidson, co-CEO of Red Gate software. I used their C# profiling tool a few years back, so my ears perked up a bit when I saw the author's affiliation.

The takeaway seems to be that if you've written your product on a platform (in their case VB6) that you can't take forward for whatever reason, then it might make sense to rewrite it.

Davidson freely admits that they rewrote their code for the wrong reasons -- they just couldn't think of anything else to do at the time -- but that it turned out well in the end for them.

Ironically, they were right about competitors nipping at their heels. I now use the profiler built into Vistal Studio .NET 2008 instead of the Red Gate profiler.

I agree that there should be sufficient drill, but it sounds like the Chinese have taken it too far, and are eating up time that might be more profitably spent learning more advanced theories.

I could spend a year practicing simple dynamics problems using F=ma and force diagrams if my goal is to do well in the Physics Olympiad. But if I want to be a physicist, most of that time would be better spent going on to Lagrangian and Hamiltonian mechanics once I've got the basics solid.

Doing well in the Physics Olympiad is not the same as doing well in physics.

In the Physics Olympiad, you solve simple problems based on well-understood formulae. In physics, you create new knowledge. It may be telling that China has won only three physics Nobel prizes, and all three of the winners got their PhDs in the US.

I admire your dedication to working hard on physics, but I think that creative, effortful practice is the key, not relentless drill.

Not necessarily. The square root hardware could be heavily pipelined to get each stage short enough for one cycle. This increases latency, but lets you keep a one-per-cycle throughput without slowing down the clock.

It seems like there are only two kinds of economists, "stopped clocks" and "wind socks".

The stopped clocks are ecstatic that their doomful (or glorious) predictions are finally right -- never mind the fact that they've been wrong nine years out of ten.

The wind socks just take whatever's happening now, good or bad, and say it'll keep on happening forever.

No wonder they call economics "the dismal science".

- Technicians implement others' designs using skills

- Engineers create new designs using knowledge

- Scientists create new knowledge

"Pure" programmers are technicians. Computer scientists are engineers or scientists.

Plumbing, like programming, offers immediate feedback, is cheap to try on your own, and is useful even if you're not an expert. But plumbers aren't the same as hydraulic engineers or fluid dynamics experts.

Faraday taught himself physics by reading the books he was binding as a journeyman, but he was a rare specimen. I'm sure engineering Faradays must exist, but as an electrical engineer I've never seen one.

I'd say "Build One To Improve" instead of "Build One To Throw Away".

Software is infinitely malleable, so there's no need to start from scratch. You can morph your code from its present state to any desired state smoothly, keeping it working (and passing all its unit tests) the whole time.

"Throwing one away" usually also throws away lots of hard-won corner case fixes and QA testing.

The only elegant way I can think of to solve the toasting non-uniformity problem requires a breakthrough in materials science.

If you could make the toaster's heating coils out of a substance that increases its resistance with increased light influx, then the bright areas of the toast would increase the coil resistance nearby, thereby producing more heat locally and tending to even out the toast.

Of course, this is probably a lot of work just to make a toaster.

Another strategy I considered was using an infrared photodiode instead of a visible light photodiode. That way, the diode effectively reads the toast temperature rather than color, which would address the issues you mention. But I was a bit worried that the infrared emission of the heating coils would swamp that of the toast.

For my original design, you'd definitely have to set the control to only slightly darker than your rye bread, or you'd get burned rye toast.

There are lots of engineering PhD's in industry, but you have to pick the right industry. For example, there are many other electrical engineering PhD's at my current workplace (a microprocessor design company), but PhD's were very thin on the ground at my previous job (a software startup).

It's actually quite hard to move from industry back to academia as an engineering PhD. According to some academic friends, unless you've been publishing tons of papers while in industry, you're looking at an adjunct faculty position at best.

Good point. You'd have to make the darkness control an offset from the initial darkness, rather than an absolute darkness level. Not hard, but you'd need an extra bit of analog circuitry to store the initial value of the toast's reflectance.

The supposed EE's design is too complex by half. Indexing into an array of precomputed timer values? No. That's digital "CS thinking" :)

All you need is a photodetector. The heating coils illuminate the toast, and the photodetector shuts the toaster off once it's dark enough. The darkness knob adjusts the photodetector's cutoff threshold.

This system is even adaptive -- if it's cold that day, or your bread is frozen, it'll still get toasted to the same color.

Interesting essay, but it sounds like to the author, programming is merely glueing together things that someone else has written, or writing a few pages of code to translate some text from one format to another.

For small-scale projects like that, scripting languages are great. But on larger projects, the advantages of scripting languages turn into disadvantages.

For example, say you're writing a short program in Perl that just has to work right now. If you discover that in some corner case, you need to shove another data member into one of your objects, you don't have to go back and fix your object definition -- you can just cram it into an instance and have done with it.

But large programs are very hard to understand if objects don't have a coherent identity over time. Scripting languages give you the freedom to "just make it work now", but they don't give you the ability to make decisions about your program's inner structure and enforce them. This inner structure is what makes a large program understandable and maintainable.

Brooks is confusing collectivism with dictatorship, and they're not related. You can have a collectivist democracy, like Japan, or an individualist dictatorship, like Saddam's Iraq or Nazi Germany.

China's recent economic improvements have nothing to do with its collectivism. They're due to more freedom, both economic and personal, for its citizens. Taiwan, whose people are arguably very similar to the Chinese in cultural outlook, started prospering as they emerged from martial law under the Kuomintang to democracy. Hopefully China will follow the same path as Taiwan and South Korea in this respect.

I get the sense that Brooks wants to prove that dictatorships are just as morally legitimate as democracies, and that the people of Asia (or the Middle East, or wherever) are somehow culturally programmed to thrive under a dictatorship. He's got it backwards -- the people thrive not because of the dictatorship, but in spite of it. Once they're freed, they'll thrive all the more.

Great reference. It's got tons of hard numbers about subjects that I generally only see unsupported assertions about.

I think his comment about IMP might apply to a few of the terser modern languages (emphasis mine):

"The second thing about IMP was that it was an extremely terse language. For example, where in PASCAL you would say "IF X > 0 THEN...", in IMP you say "X+=>". In other words, your program was very short. You felt like you were writing elegant programs, because there were only a few characters, but you couldn't read them the next day! Being very terse meant that you couldn't fathom this bunch of marks on the page..."

It's always nice to learn something I'd never even heard of before that's so simple. The article is about how you can use a neat trick (space-filling curves) to turn a multidimensional search into a set of one-dimensional searches, which could come in handy in many areas, not just geospatial ones.