wwalker3

It's harder than you might think to model real physics with a cellular automaton.

Cellular automata are simulated on regular grids of cells, which gives them anisotropic (direction-dependent) behavior. For example, moving patterns in most automata can only travel in certain preferred directions (like gliders in Conway's game of life). And patterns that can move in multiple directions usually travel with different speeds in each direction.

In the real world, we don't observe any anisotropy in space, so none of the cellular automata I've seen proposed up to this point can model real physics, even in principle.

Lattice gas automata use hexagonal grids instead of square grids to alleviate this problem somewhat, but the anisotropy never really goes away, it's just reduced.

It sounds like the control system is the expensive part. It uses a Vicon motion capture system to track the quadrotor using 20 cameras arranged around the room, plus custom control software running on a laptop, and an XBee wireless link from the laptop to the quadrotor to send the control signals.

The interesting part to me is the overshoot you see when the quadrotor shoots through the window, then pulls back nearer into a resting position. This implies that the control software can work out a dynamic trajectory (one where the quadrotor wouldn't be able to hover at every point along the trajectory), then reconcile it with a desired end point that won't fit onto the trajectory.

That sounds simple, but many walking robots still can't do that -- their gaits are designed so they could freeze in place at any time and still not fall over.

I've seen this too. OpenGL performance inside VMWare is much slower than native, and there are graphical artifacts in some cases (like lines across the diagonals of quads).

Some small details (like the apparent lack of line anti-aliasing inside VMWare OGL, and differences in the rendering of translucent polys) make me think it's partially or completely software emulated.

They also mention running for Vice President of the US, so it's not exactly subtle.

I just don't see the upside to bringing in such a polarizing political figure. Regardless of what you think of Sarah Palin, it hits a sour note to find her in a product pitch.

Totally true. HDMI takes many steps to try to reduce errors to a reasonable rate. In practice, this rate is usually low enough to ignore, even with cheap cables.

I was just making the point that there is indeed a progressive degradation in image quality with increasing error rate, even in HDMI.

That's still not correct.

For HDMI in particular, there's no error correction at all on the video data (though there is on the audio and control data).

So if one bit gets flipped in the video data as it goes through the cable, you're going to see that wrong bit on screen. You'd have to have an insanely high bit error rate for your eyes to notice it, but it's there, and it gradually gets worse as the error rate increases.

What could flip a bit in a cable? Any number of things. EM interference from outside a badly shielded cable. EM crosstalk between conductors inside a badly designed cable. Signal reflections at badly designed connectors. Basically anything that can happen to any other cable, whether the signal that goes over it is considered to be analog or digital.

I assume the reason HDMI applies EC to the audio and control data is that errors in those channels are more noticeable to the user, whereas errors at reasonable rates in the video will mostly sneak by.

The HDMI spec at http://www.hdmi.org/download/HDMI_Spec_1.3_GM1.pdf is a great source of information about this.

Back in the late 90s, my partner and I were getting a startup game development company funded. I pitched quite a few VCs, and ran into this same problem. The typical objection was "The game business is like the music business -- it's based on hits, and we're not confident we can predict those."

And it's true, from the VC perspective. A game developer often creates each new game from scratch, so it's not like a traditional product that is created once, then enhanced and refined over time. Each new game is a fresh new chance to fail.

Maybe these days a middleware startup could get VC funding, since they create a product that's used to make games, but not the games themselves.

In the end, after I accumulated a stack of more than 60 rejections from VCs, we got our funding from a traditional computer game publisher.

That's a good point -- to avoid confusing people, I should mention that my explanations above are sort of the mirror image of how most physicists would think about this situation. I was trying to be careful to say "appears to be" instead of "is" to leave this interpretive door open :)

As you say, the most common interpretation is that time itself slows down as you enter a gravity well, leaving all the physical constants the same (since their locally measured values will appear the same to you).

But if you look at things from an imaginary "absolute" viewpoint outside of spacetime, you could think of spacetime itself as a sort of fluid that's denser in regions of high gravity. Light travels more slowly in this denser fluid, and since epsilon zero is inversely proportional to the square of the speed of light, you could interpret it as being larger where gravity is higher.

I guess you can tell that fluid dynamics was always easier for me than differential geometry -- whenever I see a system of nonlinear partial differential equations (like general relativity), it's just easier for me to think of them this way.

I'm not a physicist, but here's why I think the energy appears to be less at the top of the tower than at the bottom.

If you send energy up the tower as a light beam, gravitational redshift reduces the energy of each photon as it travels up out of the gravity well.

If you send energy up the tower as electron current in a wire, the electrons spread out from each other slightly as they go up, due to the lower value of the electric constant (epsilon sub zero) in lower gravity, which makes the voltage appear to be lower.

If you send energy up the tower by rotating a shaft, with a motor at the bottom driving a generator at the top, then the energy produced by the generator at the top will appear to be less than that put into the motor at the bottom, again due to the lower value of the electric constant in lower gravity.

In all three cases, if you send the energy back down the gravity well (in whatever form), it'll appear to increase back to its original value, so you can't make a perpetual motion machine this way. And of course I'm assuming perfect conversion efficiency, lack of friction, perfectly rigid materials, et cetera in all three cases.

That brings back memories. I used THINK Pascal back in the late '80s in an undergrad computer graphics class, and it did take a little while to get used to proportional fonts. But once I got the hang of indenting with tabs instead of spaces, it was actually kind of nice. As the article says, the text was much easier to read, especially the comments.

EDIT: I checked my dev environments, and it turns out both Eclipse and Visual Studio support proportional fonts in the code editors. I had just never thought to look.

Do you really have to have severe ADD to be a nerd? I'm super-nerdy by any measure, but have a very long attention span. Most nerds I know are similar -- that's how those ambitious nerd projects actually get finished.

The guys with the long line of abandoned projects behind them aren't true nerds, they're just dilettantes. Like raccoons, compelled to collect shiny things, but never doing anything useful with them.

I also watch one TV show at a time (OK maybe two, so I can avoid commercials), read one book at a time, and don't switch conversational topics in mid-sentence. Can non-ADD nerds like me get any props on the Internet, or are we hopelessly outnumbered?

Indeed -- the whole point of projects like that is they make you a better programmer. The program itself is just a nice side effect.

I think functional programming never took off because the world around us is made of stateful, interacting objects.

Pure FP uses a completely different paradigm, so there's a huge impedance mismatch when you try to connect FP programs to the real world or run them on real hardware.

I've written my share of Lisp code, but it never seemed to be a good fit for things other than AI and propositional calculus.

The article points out an interesting quirk in C#/.Net: the algorithm the C# compiler uses to convert numeric literals like "3.14159" to 64-bit IEEE binary may be different from the algorithm used by .Net framework APIs to do the same conversion. So if you mix the two types of conversion in your code, you may get unexpected results.

Nice tip about Door64 -- I live here in Austin but hadn't run across them.

He may be using the wrong debugger. When I recreate and run his project in Visual Studio, I get this error:

Unhandled exception at 0x00b31747 in Bogus.exe: 0xC00000FD: Stack overflow.

The debugger points you to the offending line in a well-commented assembly routine described as ";_chkstk - check stack upon procedure entry".

It's immediately obvious this is a stack overflow, which takes you past the first half of his long article. However the second part of the article is still valid -- you still have to track down which of your objects is the big one.

The investigators themselves are slightly more temperate than Science Daily. They used the name "classical magnetic monopoles" in a presentation a couple of years back (http://www-thphys.physics.ox.ac.uk/people/ClaudioCastelnovo/...), and explicitly said they're not elementary particles (though they did bury that bit towards the middle of the presentation).

Probably the same as a normal text undo. You store the "actions" the user performs against the document on a stack. Each action is a replacement of one text string in the document with another (where strings can be zero-length and can start and end at any point).

Actions can "do" and "undo" themselves against the document trivially. Then to save space, you compress adjacent actions into single actions (e.g. add('a', 0) and add('b', 1) compress to add("ab", 0)).

Phototoshop has apparently had this feature for some time. They call it "non-linear history". You can go back to earlier revisions, try new things starting from there, then if you don't like it, erase that history path and go back to your first one. You can also "snapshot" your history so points on it have intuitive labels.

They don't display it as a tree, but it's logically identical -- just flattened out into a list form with the inactive branches grayed out.

If you read through the whole article and the comments, the author adds more nuance to this advice than the title suggests.

It boils down to "shopping your terms verbally is fine, just don't flash your actual physical term sheet around town."

I've considered doing that, but I always worry that if I put too much of a barrier up front, I'll lose the superstars who know they can get a job somewhere else with less effort.

Is this company a very famous or desirable place to work? Up-front screening could work very well in that situation. But for less well-known companies like mine, candidates are less willing to go through a lengthy process to interview with us (except the desperate ones, and we don't want those).

I've tried it three ways: having interviewees write code on paper, on a whiteboard, and on a computer.

Of the three, the computer fares worst. Many developers work in highly customized dev environments with special keyboards or monitor layouts. Using an unfamiliar setup, cold, in a stressful situation can make them sieze up or perform poorly.

Paper is no good because you can't watch their problem-solving process without hovering over their shoulder, and they get no feedback from you if they're going into the weeds.

The whiteboard seems to work best, because you get a good give-and-take effect between the candidate and interviewer.

So true. I learned this the hard way just like the author, by making some very bad hires.

I had always thought it was insulting to ask interviewees to write a simple two-line strcopy() function. Of course they can -- they've got a CS degree! So I would take that as given and move straight to more abstract non-coding questions.

It took me a long time to accept the fact that many people can talk about programming very glibly but can't actually do it. At first I felt like a jerk by making people write so much simple code in interviews, but it's led to much better hiring results.

I like many of these principles, it's just hard to apply more than a few of them to a given program.

Vim and emacs have captive user interfaces. MP3 encoders like LAME write binary data files. That doesn't mean they're bad programs, but it does make the principles tricky to apply, since they seem to be useful in some cases but not others.

I'm on the Linux command line all day at work, without any sort of GUI frontend. It's got its strengths and weaknesses, just like anything else.

These rules don't seem to apply to the modern age very well. The rules "Avoid captive user interfaces" and "Make every program a filter" mean that you can't write a text editor. The rule "Store data in flat text files" means you can't write a (reasonable) MP3 player or video editing program.

"Build a prototype as soon as possible" is pretty general, but most of these rules are just good guidelines for writing command shells and compilers -- not coincidentally, two of the main concerns of early Unix developers.

I think that's the key to my confusion here -- I wasn't thinking of language constructs like functions or loops as patterns, I was only including things like "factory objects" or "visitors".

Of course, if a function definition is a pattern, does that mean that Lisp (chock-full of function definitions) is a lower-level language than Prolog (which doesn't need functions at all and therefore abstracts away that whole idea)?

Could you give me a concrete example? Say, a pattern that can't be abstracted away in assembly language, but can be abstracted away in C++?

Serious question, not a troll -- I've always felt like I'm missing some key point here.

The "human compiler" bit never made sense to me. When I start to write something for the second time, I stop and make it a function (or a class, interface, library, or whatever's appropriate). "Don't repeat yourself" is good advice in any programming universe.

Patches grow on our code because it's easier to patch than it is to figure out the paradigm-changing code simplification that will encompass all previous functionality plus the new thing we want to add. That's hard work!

I'm elbow-deep in patch remediation right now, and even though I'm not worried about breaking anything (I have good code coverage and a big automated test suite), it's still mentally draining to do it right.

They said it was a 20-hour scan, at 5K, with the AFM tip 0.5 nanometers from the pentacene molecule. The molecule itself is 1.4 nm long, so they were only about 30% of its length away from it in the vertical direction.