I got a hall-effect ampmeter for the purpose of measuring power usage. It works pretty well, you just clamp it around the wire you want to measure.
The one caveat, though, which makes it far less convenient to use than it would otherwise be, is that it doesn't work if it surrounds both the positive and negative wires at the same time. I ended up modifying a power strip by cutting open the rubberized outer coating of the power cord so I could clamp the meter around just the postive cord.
In retrospect, the kill-a-watt would have been about equally useful, and I wouldn't have to convert amps to watts.
If I were having a new house wired, I would perhaps ask to have the main power cables into the circuit breaker box routed through some kind of enclosure that would allow me to use a hall-effect sensor directly.
Another interesting device if you just want to know how much power your computer is using: the power supply I'm currently using has an analog watt meter that fits in one of 3.5" drive bays in the front of my computer. It pretty much sits at 100-120 watts day or night. If I'm stressing the graphics card, it sometimes goes up to 180 or so.
I got it at a garage sale. I don't think the company sells them anymore, but here's a link. (Click on "gallery" to see the power meter.) I wish more power supplies were made this way.
Except that Doctorow generally has a poor grasp of the technology that is the subject of his writing..
I don't find this to be the case at all. He doesn't go into sufficient detail, perhaps, to be particularly educational (because, let's face it, these are novels not technical references, and he tends to focus on the social impact of technology more than the specific implementation details), but I haven't come across any indication in any of his books that I have read that he just doesn't understand technology.
I would consider Doctorow to be one of the good science fiction writers who aren't just inventing whatever technology is going to drive the plot but are looking at present technology and extrapolating. (Other authors I include in this category: Verner Vinge, Arthur C. Clarke.)
That's the best recommendation I could think of, and you beat me to it.
Educational novels may be in some respects a better fit than actual technical references and how-to books, since prisoners can't really try out anything they learn. (My own experience contradicts this, though, as I read about half of a phonebook-sized tome on C++ programming before I ever compiled "hello world", thanks to the book shipping with a broken compiler.) I don't know of many novels that are as informative as Cuckoo's Egg, though. Maybe Cryptonomicon.
I'd recommend getting a foosball table (or similar) instead. It's a group activity. If it's in a common area, any employee can play whenever they like and you won't have a lot of employees bitter that some of the others have their own personal game station, and games are generally pretty short. Most employees aren't going to waste half the day playing foosball the way they might playing a game console.
Though I don't disagree that latency is an important issue, I would say it's the game developers and designers (and, by extension, their extremely risk-adverse employers) who are the main barrier to decent gameplay.
They discuss creating liquid fuels from carbon dioxide and (here's what the article linked from slashdot is missing) hydrogen (from electrolysis or natural gas).
You've pretty much described the form of many Haskell programs:
Acquire data, command-line arguments, etc.. in the IO monad using hGetContents or similar
Process data using some pure computation
Return the result to the IO monad, and then output it
With laziness, Haskell can defer the IO until it's actually needed, so you can use this approach to process large amounts of data that don't fit in memory all at one time.
I wrote a ray tracer that essentially functions this way: It reads in a text file describing the scene as a lazy string, then it feeds the string into a scene parser that accepts a string and returns a scene, then it invokes a ray intersection test on the scene for each pixel, using OpenGL to output the result.
The nice part of all this is that the scene parser and ray intersection routines are all pure: they do no IO whatsoever, nor do they write to global data structures. Side effects are all contained in the relatively short IO code that reads from the files and handles the OpenGL calls.
That was sort of my initial impression: how does anyone get anything done in a language where you can't even write to local variables or call printf most of the time?
After using it for awhile, I'm starting to see that it really can be used for ordinary programming tasks, not just pure computation. For some problems, the Haskell way of doing things can make things hard that would be easy in other languages. On the other hand, some things that would be hard in other languages are quite easy in Haskell.
It's just a matter of using the right tool for the job. However, I think there are a lot of C++ and Java projects that would have been a lot better off if they had been written in Haskell.
Probably not what you're looking for, but Real World Haskell is soon to be released and has chapters on concurrent and multicore programming and software transactional memory. Even if you're not interested in Haskell per se, STM is kind of an interesting idea.
My experience with math professors is that most of them are able to present clear explanations of the subjects they're teaching without referring extensively to topics that are more advanced than the topics at hand.
On wikipedia, however, "obtuse/esoteric dialogue" seems to be the norm, and I have very rarely been able to understand a math article about a topic that I didn't already understand. I hope that this trend will eventually correct itself by better editing.
I don't thing $70 is cheap for a graphics card, but I'm a tightwad and don't play a lot of games. (I do a bit of graphics programming, but it's all ray tracing and the GPU doesn't help for that.)
One particularly opaque error message I've encountered several times but haven't seen mentioned here is the DriveReady SeekComplete error in Linux. It doesn't sound at all dire, but it usually means its time to buy a new hard drive.
At a distance of (iirc) about 2/3rds of the way to geosynchronous orbit, an object dropped off the elevator will be in an elliptical orbit that just barely misses the atmosphere. Anything lower than that will re-enter. With rockets, of course, you could drop things lower and/or achieve round orbits.
Launching from beyond geosynchronous orbit ultimately robs the earth of its rotational energy (something that happens all the time anyways because of tides), so that's not really a big deal for the elevator as long as it can handle the additional tension. It would be a great way to launch things towards the rest of the solar system without wasting fuel.
I've still got concerns about how one would deal with large programs, persistence, etc., but those were secondary, and I never got as far as checking them out the last time I looked at Haskell.
I don't know about very large programs, but I've written a ~3500 line ray tracer and the code hasn't become unwieldy. It's broken up into a lot of small modules. The compiler is definitely very slow; that might be an issue if you had a project that was tens or hundreds of thousands of lines.
There's an easy way to do persistence. Whenever you create a new data type, just add "deriving Show" to the end of the definition, and then you can convert it to a string with the "show" function. There's a corresponding "reads" function that turns a string back into the object. (I'm not sure if you have to do a "deriving Reads" as well or what; in my ray tracer, I manually overrode the standard read routines so I could parse a particular common graphics format instead.) Once the object is in string form, you can dump it to disk and retrieve it later. (A binary format may be more space efficient, but I'm less familiar with manipulating binary files in haskell.)
If you want to get programmers to use Haskell, you should make sure that they are exposed to that book.
It actually hasn't been published yet; it's scheduled to come out in November. It's being published by O'reilly, which is (in my mind, at least) a big deal since O'reilly traditionally doesn't do books about functional programming languages. I hope the language will be taken more seriously as a result.
I've never heard of Hackage until I read this post, even though I've been reading about Haskell and other functional languages on and off for several years now.
Hackage is well known to haskell programmers. It is linked to directly from the front page of haskell.org, it is mentioned frequently on the haskell-cafe mailing list, and that's where hundreds of haskell projects are hosted. If you're an average passer-by and not an active haskell developer, it's not necessarily going to jump out and say "boo!", but it isn't hiding under a rock, either.
Note: hackage is not the standard libraries. Those are documented elsewhere.
When I look into a language, the first thing I check is "How do I do random IO to fixed size blocks on a disk file?" Most functional languages don't document any answer to that at all. (With Erlang it's "Use our custom database", so they've an answer, of sorts.)
For haskell, you might want to look at System.Posix.IO. I haven't had to do arbitrary seeking in haskell, but that's what I'd probably try first if I did. Of course, all this has to happen inside the IO monad, so you'll need to be prepared to deal with monads. You might find the IO chapter in real world haskell helpful.
The second thing I look for is "How do I draw pictures on the screen, and get user responses?" Gtk is an acceptable answer. So is SDL. Erlang has a custom approach that is decent for drawing buttons in boxes, etc., but not really sufficient for what I want. Most functional languages don't seem to even consider the matter. (Perhaps they do, but it doesn't seem to appear in the documentation.)
Both haskell and ocaml have pretty good OpenGL bindings, called Hopengl (tutorial) and LablGL respectively. Ocaml also has a simpler built-in graphics library, and haskell has an (I believe) windows-only graphics library that is used extensively for examples in the book "The Haskell School of Expression".
The same way they should measure the productivity of any team of programmers: are they able to solve the problem they're given within time and budget constraints. "Lines of code" is not a good measure of productivity in any language.
Here's a graph of ISS altitude for the last year, if anyone is interested in hard data. (The steady downward slope is due to atmospheric drag, and the sharp increases are from firing maneuvering thrusters to maintain altitude. Presumably, the recent abrupt drop was the maneuver described in the article.)
I was actually thinking about ordering it just yesterday. I haven't seen it, but it seemed to get good reviews on Amazon, and sounded like the science was pretty sound.
Technically, raw fish is "sashimi", but is often combined with rice and seaweed and other ingredients to make sushi. Not all sushi contains sashimi, but most does. I don't think rice by itself counts as sushi.
A subsidy is very different from a tax cut. Of course, one shouldn't be surprised that Lessig makes this confusion as his political leanings...
Lessig first refers to them as tax cuts; he obviously is not "confused" about the distinction, he quite deliberately equates tax cuts with subsidies, and the end result of a selective tax cut and a subsidy (assuming the subsidy is not larger than the amount taxed) is the same thing, as you well know.
If you don't see the distinction... imagine calling a decrease in your personal income tax a subsidy:)
I would have no problem calling a tax reduction on a demographic I don't belong to a "subsidy" rather than a tax cut, especially if the tax cut seems to have been applied arbitrarily. If it applied to myself, I might be able to fool myself into calling it a tax cut, but the only one fooled would be myself; to everyone else who didn't qualify, it would be a subsidy.
his political leanings tend to assume that tax money originates and belongs to the government, not the originating source of the income.
...
The word subsidy also makes it sound like McCain wants to fill evil telecoms' pockets with undeserved cash.
You seem to be basing your arguments on the notion that the money rightly belongs to the taxpayer, and than it is wrong for the government to take it. However, McCain is not proposing to repeal taxes altogther, but to take tax money from some and not from others. Supposing we were to agree that taxes are a necessary evil in order to support a civil society. Which would you consider in general to be the best policy: tax everyone equally, or tax some people and not others? (And I am aware that current tax policy does not tax equally, but that's an issue for another time.)
Slashdot Mirror
I thought of "monopoly" (and "reverberated" for left hand) back in high school typing class, but you've got me beat by 1 letter.
Thanks, I didn't know that.
I got a hall-effect ampmeter for the purpose of measuring power usage. It works pretty well, you just clamp it around the wire you want to measure.
The one caveat, though, which makes it far less convenient to use than it would otherwise be, is that it doesn't work if it surrounds both the positive and negative wires at the same time. I ended up modifying a power strip by cutting open the rubberized outer coating of the power cord so I could clamp the meter around just the postive cord.
In retrospect, the kill-a-watt would have been about equally useful, and I wouldn't have to convert amps to watts.
If I were having a new house wired, I would perhaps ask to have the main power cables into the circuit breaker box routed through some kind of enclosure that would allow me to use a hall-effect sensor directly.
Another interesting device if you just want to know how much power your computer is using: the power supply I'm currently using has an analog watt meter that fits in one of 3.5" drive bays in the front of my computer. It pretty much sits at 100-120 watts day or night. If I'm stressing the graphics card, it sometimes goes up to 180 or so.
I got it at a garage sale. I don't think the company sells them anymore, but here's a link. (Click on "gallery" to see the power meter.) I wish more power supplies were made this way.
I don't find this to be the case at all. He doesn't go into sufficient detail, perhaps, to be particularly educational (because, let's face it, these are novels not technical references, and he tends to focus on the social impact of technology more than the specific implementation details), but I haven't come across any indication in any of his books that I have read that he just doesn't understand technology.
I would consider Doctorow to be one of the good science fiction writers who aren't just inventing whatever technology is going to drive the plot but are looking at present technology and extrapolating. (Other authors I include in this category: Verner Vinge, Arthur C. Clarke.)
That's the best recommendation I could think of, and you beat me to it.
Educational novels may be in some respects a better fit than actual technical references and how-to books, since prisoners can't really try out anything they learn. (My own experience contradicts this, though, as I read about half of a phonebook-sized tome on C++ programming before I ever compiled "hello world", thanks to the book shipping with a broken compiler.) I don't know of many novels that are as informative as Cuckoo's Egg, though. Maybe Cryptonomicon.
I'd recommend getting a foosball table (or similar) instead. It's a group activity. If it's in a common area, any employee can play whenever they like and you won't have a lot of employees bitter that some of the others have their own personal game station, and games are generally pretty short. Most employees aren't going to waste half the day playing foosball the way they might playing a game console.
Though I don't disagree that latency is an important issue, I would say it's the game developers and designers (and, by extension, their extremely risk-adverse employers) who are the main barrier to decent gameplay.
That is quite an important (and occasionally overlooked) point; the most dangerous people in the world are those with nothing left to lose.
I don't know if this is related, but there was a similar Google tech talk recently:
Carbon Neutral Synthetic Hydrocarbon Fuels
They discuss creating liquid fuels from carbon dioxide and (here's what the article linked from slashdot is missing) hydrogen (from electrolysis or natural gas).
You've pretty much described the form of many Haskell programs:
With laziness, Haskell can defer the IO until it's actually needed, so you can use this approach to process large amounts of data that don't fit in memory all at one time.
I wrote a ray tracer that essentially functions this way: It reads in a text file describing the scene as a lazy string, then it feeds the string into a scene parser that accepts a string and returns a scene, then it invokes a ray intersection test on the scene for each pixel, using OpenGL to output the result.
The nice part of all this is that the scene parser and ray intersection routines are all pure: they do no IO whatsoever, nor do they write to global data structures. Side effects are all contained in the relatively short IO code that reads from the files and handles the OpenGL calls.
That was sort of my initial impression: how does anyone get anything done in a language where you can't even write to local variables or call printf most of the time?
After using it for awhile, I'm starting to see that it really can be used for ordinary programming tasks, not just pure computation. For some problems, the Haskell way of doing things can make things hard that would be easy in other languages. On the other hand, some things that would be hard in other languages are quite easy in Haskell.
It's just a matter of using the right tool for the job. However, I think there are a lot of C++ and Java projects that would have been a lot better off if they had been written in Haskell.
Why do you say that? I only learned about STM recently and haven't used it in anything, so it may have defects I'm not aware of.
Probably not what you're looking for, but Real World Haskell is soon to be released and has chapters on concurrent and multicore programming and software transactional memory. Even if you're not interested in Haskell per se, STM is kind of an interesting idea.
My experience with math professors is that most of them are able to present clear explanations of the subjects they're teaching without referring extensively to topics that are more advanced than the topics at hand.
On wikipedia, however, "obtuse/esoteric dialogue" seems to be the norm, and I have very rarely been able to understand a math article about a topic that I didn't already understand. I hope that this trend will eventually correct itself by better editing.
I don't thing $70 is cheap for a graphics card, but I'm a tightwad and don't play a lot of games. (I do a bit of graphics programming, but it's all ray tracing and the GPU doesn't help for that.)
One particularly opaque error message I've encountered several times but haven't seen mentioned here is the DriveReady SeekComplete error in Linux. It doesn't sound at all dire, but it usually means its time to buy a new hard drive.
At a distance of (iirc) about 2/3rds of the way to geosynchronous orbit, an object dropped off the elevator will be in an elliptical orbit that just barely misses the atmosphere. Anything lower than that will re-enter. With rockets, of course, you could drop things lower and/or achieve round orbits.
Launching from beyond geosynchronous orbit ultimately robs the earth of its rotational energy (something that happens all the time anyways because of tides), so that's not really a big deal for the elevator as long as it can handle the additional tension. It would be a great way to launch things towards the rest of the solar system without wasting fuel.
I don't know about very large programs, but I've written a ~3500 line ray tracer and the code hasn't become unwieldy. It's broken up into a lot of small modules. The compiler is definitely very slow; that might be an issue if you had a project that was tens or hundreds of thousands of lines.
There's an easy way to do persistence. Whenever you create a new data type, just add "deriving Show" to the end of the definition, and then you can convert it to a string with the "show" function. There's a corresponding "reads" function that turns a string back into the object. (I'm not sure if you have to do a "deriving Reads" as well or what; in my ray tracer, I manually overrode the standard read routines so I could parse a particular common graphics format instead.) Once the object is in string form, you can dump it to disk and retrieve it later. (A binary format may be more space efficient, but I'm less familiar with manipulating binary files in haskell.)
It actually hasn't been published yet; it's scheduled to come out in November. It's being published by O'reilly, which is (in my mind, at least) a big deal since O'reilly traditionally doesn't do books about functional programming languages. I hope the language will be taken more seriously as a result.
Hackage is well known to haskell programmers. It is linked to directly from the front page of haskell.org, it is mentioned frequently on the haskell-cafe mailing list, and that's where hundreds of haskell projects are hosted. If you're an average passer-by and not an active haskell developer, it's not necessarily going to jump out and say "boo!", but it isn't hiding under a rock, either.
Note: hackage is not the standard libraries. Those are documented elsewhere.
For haskell, you might want to look at System.Posix.IO. I haven't had to do arbitrary seeking in haskell, but that's what I'd probably try first if I did. Of course, all this has to happen inside the IO monad, so you'll need to be prepared to deal with monads. You might find the IO chapter in real world haskell helpful.
Both haskell and ocaml have pretty good OpenGL bindings, called Hopengl (tutorial) and LablGL respectively. Ocaml also has a simpler built-in graphics library, and haskell has an (I believe) windows-only graphics library that is used extensively for examples in the book "The Haskell School of Expression".
The same way they should measure the productivity of any team of programmers: are they able to solve the problem they're given within time and budget constraints. "Lines of code" is not a good measure of productivity in any language.
Here's a graph of ISS altitude for the last year, if anyone is interested in hard data. (The steady downward slope is due to atmospheric drag, and the sharp increases are from firing maneuvering thrusters to maintain altitude. Presumably, the recent abrupt drop was the maneuver described in the article.)
I was actually thinking about ordering it just yesterday. I haven't seen it, but it seemed to get good reviews on Amazon, and sounded like the science was pretty sound.
Technically, raw fish is "sashimi", but is often combined with rice and seaweed and other ingredients to make sushi. Not all sushi contains sashimi, but most does. I don't think rice by itself counts as sushi.
Lessig first refers to them as tax cuts; he obviously is not "confused" about the distinction, he quite deliberately equates tax cuts with subsidies, and the end result of a selective tax cut and a subsidy (assuming the subsidy is not larger than the amount taxed) is the same thing, as you well know.
I would have no problem calling a tax reduction on a demographic I don't belong to a "subsidy" rather than a tax cut, especially if the tax cut seems to have been applied arbitrarily. If it applied to myself, I might be able to fool myself into calling it a tax cut, but the only one fooled would be myself; to everyone else who didn't qualify, it would be a subsidy.
...
You seem to be basing your arguments on the notion that the money rightly belongs to the taxpayer, and than it is wrong for the government to take it. However, McCain is not proposing to repeal taxes altogther, but to take tax money from some and not from others. Supposing we were to agree that taxes are a necessary evil in order to support a civil society. Which would you consider in general to be the best policy: tax everyone equally, or tax some people and not others? (And I am aware that current tax policy does not tax equally, but that's an issue for another time.)