05.23.06
Posted in Thermodynamics at 7:12 pm by Brooks
I recently came across a mention of yet another inventor who supposedly has built a car engine that runs on water. The claim is in a video which doesn’t play on my computer, so I don’t know much for details of what he’s actually claiming. But even without watching the video, I can say with almost absolute certainty that this inventor hasn’t built a car powered by water.
I’m sure of this, even though I have no idea how this engine is supposed to work. Why? It’s a matter of applied thermodynamics.
First, imagine that the engine is in a black box. We can’t see into the black box, so it could be any possible type of engine that has been or will be invented. All we can measure is what goes in and out.
What goes in is basically just the “fuel”: room-temperature water. There might be some air with it, too. There are a couple of things that come out: The exhaust from the engine, and the power from the engine — maybe in the form of a shaft coming out of the engine that it’s turning, or something.
According to the First and Second Laws of Thermodynamics, available energy cannot be created, though it can be destroyed by turning available energy into unavailable energy. If we apply that principle to the box with the engine in it, it’s pretty clear that the sum of the available energy that goes into the box and what is in it when we start running it has to be at least as much as the sum of what comes out and what is in it when we finish.
Now, this is an “engine”, not a storage system; it’s not allowed to be running off some sort of hidden internal energy supply that’s also contained in the box. So, if the engine isn’t cheating, the amount of available energy in the box when we start will be the same as the amount when we finish. Thus, we conclude: what goes in must be at least as much as what goes out.
So, look at the available energy that’s in that exhaust. Whatever the exhaust is, it has to contain the same hydrogen and oxygen atoms that came in with the water, along with the atoms that came in with the air. It could hot steam — which has higher available energy than the water that came in. It could be some other compounds of hydrogen and oxygen and stuff in the air — and all of those have higher available energy than water and air do. It could be a cool wet fog, which has slightly higher energy than the water. It could even be ice, but even that has higher available energy than room-temperature water. The best possible case is that it could be room temperature water and air just like what came in, and have the same available energy.
That means that the available energy that comes out in the exhaust is at least as much than the available energy that goes in with the fuel and air. And there’s supposedly even more energy coming out via the power from the engine — thus, the output is claimed to be higher than the input.
This is obviously a contradiction. We just found that, by the laws of thermodynamics, we can’t have more energy coming out in the exhaust and power shaft than what came in with the fuel.
Thus, the engine is impossible.
Permalink
Posted in Programming and People at 1:25 pm by Brooks
Jeff Atwood makes the point that although experts generally don’t follow recipes (such as “best practices”) literally, the recipes are still valuable:
The idea that a recipe (eg, a best practice, a methodology, or a maturity model) is completely worthless is just as wrongheaded as the idea that everything should be based on a strict recipe. In other words, even an expert chef may occasionally find it helpful to refer to a recipe card.
There’s no reason these two models can’t coexist. You should always start with the common denominator recipe, of course, but you may want to provide some alternative guidelines and ideas for those cooks who have outgrown traditional recipes, too.
I strongly agree with his general point, but I think that “guidelines and ideas” are the wrong sort of thing to include.
To take the metaphor literally, for some things, I’m a level 4 cook. (Not necessarily an especially good one — it’s worth noting that these levels are not always parallel to the quality of the output!) A particular example would be some coleslaw I made a couple of weeks ago, when I found myself in an ill-stocked kitchen with a cabbage, an empty stomach, and the Joy of Cooking.
The Joy of Cooking is a pretty good cookbook for this sort of thing, as it turns out. It has a half-page discussion of what coleslaw is, without any recipes at all. It turns out that pretty much the only common factor in slaw is that it has cabbage in it. Everything else is variable. (This was an important point; we had no mayonaisse, and the person I was cooking with insisted that coleslaw has to have mayo.) It went on to describe, in loose terms, some of the common varieties. I skimmed through those, and then went on to look at the actual recipes. The standard recipe format is well-optimized for this sort of thing; there’s a list of ingredients at the top, separate from the instructions, making it very easy to skim to pull out specific bits of data such as the ratio of sugar to vinegar in a sugar-vinegar slaw.
After looking through the cookbook, I’d gleaned the following information: sugar and vinegar are a perfectly sufficient base for a slaw dressing, and it’s common to have them in X ratio, Y is a typical amount of salt, and Z, W, Q, and a dozen other things are some ideas for spices to put it.
Those, you may object, look exactly like “guidelines and ideas”. So, why am I objecting to including guidelines and ideas for experts in the recipe? The same reason that specific instructions are wrong for experts: They are processed information, and the definition of “expert” in this context is someone who does their own information processing. In my case, when I read the recipes, I was mining them for bits of information. Any processing that complicates that information-mining is a detriment, not a benefit.
And so, when writing recipes to be useful beyond basic instructions, the thing to include is facts. Not a guideline of “this squash should be cooked for 20 minutes”, but the fact of “if you cook this squash for more than 25 minutes it will be mushy and begin to lose flavor.” Not the idea of, “You could use peaches in this,” but the fact of “Peaches are also common in this.” The guidelines and ideas are certainly useful because they contain facts, but the parts that make them “guidelines” and “ideas” rather than bare facts rarely are. Often the process of distilling the fact into a guideline or idea loses useful information, too; suppose I wanted mushy squash, or wanted an uncommon alteration?
Permalink
05.12.06
Posted in Programming and People at 10:30 pm by Brooks
I was reading Kristin Abkemeier’s post on what it feels like to be a “geek girl”, and she linked to Matt McIrvin’s post about Nerd Bravado, which is the claim (originally made by an anonymous poster on yet a third blog post that I haven’t read) that in order to have any cred as an engineer, one has to at least once solve a problem in the manner of sitting down and working on it for 20 or 30 hours of continuous independent work, because there are some problems that can’t be solved any other way. (To be clear, that’s a claim that Matt was describing in order to disagree with it.)
I’m going to claim some authority in talking about this, because I’ve done that — and it wasn’t just 20 or 30 hours, either. A year ago, I thought that there was some chance that I could finish my dissertation by the end of the academic year if I got a certain set of simulations done, which required taking a computer program that was currently held together by Duck-brand Fortran Tape, and turning the structurally unsound mass of the core algorithms into a well-oiled robust, solid, machine that would do what I told it. I had two weeks in which to either accomplish it or give up.
So, I sat down on Monday to start working on it, and for all practical purposes, I worked on it straight through until Wednesday of the following week.
This is the first flaw of the Nerd Bravado claim. Hyperfocus doesn’t care if you sleep and eat and take a shower. You can think while you’re eating. Your brain keeps working on things when you sleep, and if you think about a problem when you go to bed and when you get up in the morning, you’ll often find that some tricky bit of it has become a lot clearer in the interim. You don’t have to sit for 25 hours straight to get the benefits.
That’s where the benefit of this style of working is, insofar as there is one: Hyperfocus. After a dozen or so hours into this project, I was so focused on it that I couldn’t really think about anything else — even if I tried, the problems in the code would keep distracting me back to the task. And, because I’d pretty much emptied everything else from short-term memory, quite a lot of stuff about the code could fit in there — enough to contain all the complicated interweavings of how the code all fit together. I could look at the results and see where the problems were coming from and what bits of subroutines wove together to create the particular effect that was happening, and I knew, without having to look, where to prod the program to change it, and when I prodded it, it changed. It’s a heady feeling.
I think that’s what the appeal of Nerd Bravado is, really. It’s like spice, from Dune. Get a bit of it into your system, and the universe opens up before you and whirls at your beck and call, and you have tremendous power at your fingertips to poke exactly the right thing in exactly the right place. But it’s also got downsides; do it a few too many times, and your eyeballs turn funny colors and it completely eats your life.
Now, I said I had two weeks to fix this program, and I stopped a week and a half in. Do you think that means I finished early? Hardly. A week in, and I’d gotten all the easy bugs fixed and most of the complicated ones, and I’d started tangling with the algorithms at the core of it. And they had a problem: The math that I was working with involved solving an equation where significant parts of both sides are multiplied by a factor that goes to zero. Divide that out to solve it, and very small errors in one term become very big errors in the solution, and it stops being well-behaved. There are ways around this, but they have to be designed into the algorithm from the start, not bolted on later. And by about Wednesday, it became quite clear that I was dealing with something that needed to be fixed from the ground up, and there was no way I could come close to that in the three days I had left.
This is the second flaw of the Nerd Bravado claim. It doesn’t actually solve the real big problems. Hyperfocus is a state of working on instincts, of having enough information actively in your brain that you don’t have to work through logic and deductive reasoning to know what the Right Thing To Do Now is. And that’s great, if what you need to accomplish is something that’s a chain of consecutive steps, like debugging a convoluted program or working through a complicated mathematical derivation or even writing a new program that fits a general specification that you’ve already determined.
Real big problems aren’t like that. Flash-of-insight problems aren’t like that — Einstein didn’t have his flash of insight about time dilation on the trolley because he’d been hyperfocusing on the problem for the past few days; he had it because he’d been rolling the problem around in his head for months. (Or years; I don’t actually know that bit of his biography well enough to say for sure.) And hard-work problems aren’t like that, either — writing a fixed version of my program isn’t going to work like that either, because it needs to be designed right from the ground up, and designing something right is a process that requires awareness of the outside world, and of a lot more than what fits in the hyperfocus. Yes, there are the legends of the great designers who sit down and in one day lay out the basic lines of an airplane or a car engine that are more right than their less-great colleagues create with a committee and a month, and that comes from having tremendous amounts of knowledge in their heads, but that’s the sort of knowledge that gets there over years, not hours.
This brings me to the third flaw of the Nerd Bravado claim: It’s not, overall, worth doing. When I’d finished my week-and-a-half of debugging, I was mentally exhausted. I was a week behind on all of the minutiae of daily life, I was emotionally starved for interpersonal interactions, I’d barely talked to my wife about anything that mattered to her, and my brain felt thoroughly fried. (My wife’s ironic laugh when I asked her if she remembered when I did this probably tells you all you need to know about what it was like from the outside.) It took somewhere around a month before my work productivity was anywhere near normal again. All totaled, I’d probably have accomplished as much if I’d simply worked at a reasonable pace for the month and two weeks, and I’m pretty sure the resulting solution would have been worth a bit more, as I’d have had the time to actually work out at least a first cut at a ground-up solution.
And, finally, the fourth flaw of the Nerd Bravado claim: the claim that “you must do it at least once to be a successful engineer … and to gain the respect of your peers” simply doesn’t hold true. The result of this particular experience, for me, was that I had a nicely debugged program that solved the equations the wrong way and didn’t produce useful answers. And all I learned from it was this: That style of working isn’t sustainable, and doesn’t lead to an enjoyable life, and I don’t want to do it again except in very small doses. As for the respect of my peers — well, does this cause any of you to respect me any more? No? I didn’t think so.
Permalink
05.07.06
Posted in Computer Languages at 12:09 pm by Brooks
I’ve been reading a few articles recently about language syntax and semantics, and what makes for a good computer language these days. (For instance, this article by Larry O’Brien.) One theme that struck me was the idea that the power of a language is in its extensibility — that is, in the rules of the language that allow a program to add to the language.
This has interesting ramifications for language design. A language is not defined by all of the syntax and semantics that are in its programs. It is, instead, defined by its primitives and by the structure upon which the programmer can add to the language.
For example, here’s a short Fortran program:
program sample
use vectorModule
real :: b
type(vector) :: V
call loadFromFile(V, ‘myfile.dat’)
b = abs(V)
write(*,*) b
end program
Fortran defines the words that are highlighted in red, and the punctuation; everything else is something that I’ve defined either in this program or in the matrixModule module that gets included by the second line. Some of these definitions are so common that we don’t even think of them as “language extensions” any more — for instance, the function and subroutine definitions. Beyond those, there’s also the user-defined “vector” type, and the extension of the absolute-value intrinsic to apply to it.
The invariants of the language are more interesting, though. Variables are declared with a “::” syntax, and must be declared before any executable statement. User-defined variables must be declared as “type(vector) ::” rather than just “vector ::”. Subroutines cannot be used as statements alone; they are prefixed with a “call” keyword. Expressions, likewise, cannot be used as statements — and an assignment is a statement, not an expression. These requirements are at the core of what can and what cannot be a Fortran program.
One interesting question is: What happens as we reduce the number of syntax invariants of the language?
Consider the TeX typesetting language. What if we had a programming language that worked like TeX?
TeX is, to a rough approximation, a two-level language. The first layer is a macro expansion language; the user’s code (along with some system libraries) is processed through a macro system that converts it into a stream of TeX primitive commands. These primitive commands are then processed through a second layer, which converts them into the typesetting equivalent of machine code. It would be easy enough to imagine a language like this where the second layer produces compiled programs rather than typeset pages.
This has some interesting results in how the TeX is used. Knuth expected that what he had written was largely a proof-of-concept language, and that people would rewrite the basic language processor to add extensions to it. However, the macro expansion language he wrote is sufficiently powerful that nearly any desired language extension can be written as a macro. (There are a few exceptions, surrounding things like file input-output and bits of math typesetting that are implemented largely in the second layer, but they are rare.) And, given the choice of writing a macro that works with the existing system, or creating a new system, people have generally chosen to write macros. Even the LaTeX typesetting langauge, which is sufficiently different from TeX as to be nearly a distinct language, is merely a large set of TeX macros that are treated as a system library.
Another benefit is that it makes experimentation easy, and makes it portable. To write a new bit of language syntax, I simply write a few macro commands and put them at the top of my file — and, so long as those commands go with my file, it will run on anyone else’s TeX system.
These would be good traits to have in a programming language.
Thus, the question is: What is an appropriate set of primitives for a programming language? And what is a good way to structure a TeX-like macro language that will produce them?
Permalink
05.06.06
Posted in Computational Fluid Dynamics, Dissertation Research at 10:21 am by Brooks
I just added the slides from my presentation at the 58th annual November meeting of the APS’s Division of Fluid Dynamics to my publications page. This is largely a modified version of the presentation I gave at the ILASS meeting last May.
Presentations at APS meetings are only 10 minutes long, instead of the 25 at most other conferences, so these slides are much tighter and more concise than the ILASS slides. I think there are definite advantages to the format; most of the presentations still seemed to contain all of the critical aspects of the research, and most of what seemed to get cut was excessive belaboring of points, and recitations of the same justifications and basic background that we’ve all heard dozens of times before. And, of course, it means that there’s time to see more than twice as many presentations in a day; when the conference packs over a thousand talks into a three-day block, that’s quite important.
One unfortunate thing about the APS DFD meeting is that the talks don’t come accompanied by papers that one can look up and read afterwards. For my presentation, though, my paper from the ILASS meeting covers most of the same results.
Oh, and at some point I’ll work out an appropriate Creative Commons license for this stuff. In the interim, if you want to borrow one of the slides or figures for something, just send me an email.
Permalink