I'm willing to bet driving a cab in London is quite a bit more challenging than driving a cab in Manhattan, at least when it comes to plotting the course. I remember hearing a joke while I was there: The only straight roads in England were built by the Romans.
Out of curiosity, how do semantic and episodic memory relate to procedural memory? It seems like many mnemonic schemes (such as rhymes etc. to help you remember a given sequence) rely on using procedural memory to augment semantic memory. It's somewhat of a blend of the two.
You mention re-coding episodic memory into semantic memory. How often do we see blends of those two for supporting a memory? How long do they tend to be linked while the brain "re-codes?"
I'm lost: How is "grep somepattern * >filename" any different in tcsh versus bash, except in the case where the directory's empty? It seems like both shells should set up the redirection before forking off the grep, which means it should be equally disasterous in either shell. I guess tcsh does the glob after setting up the redirection, whereas bash does it before?
Interestingly, this steps near the one thing I think tcsh gets right over bash: If a wildcard matches nothing it should not return itself (as it does in bash), it should generate a trappable error. Is there a way to configure bash to generate an error on a wildcard that matches nothing?
Bash is intended to be a conformant implementation of the IEEE POSIX
Shell and Tools specification (IEEE Working Group 1003.2). Bash can be
configured to be POSIX-conformant by default.
I should also add that in many of these different disciplines, aspects of the program architecture and implementation are purely arbitrary. One thing I discovered I needed to do to make progress on particular projects and ideas was to whip up a simple prototype, and rather than obsess on the "best" way to do something (because there may be no "best,") make some arbitrary choices, sufficient to get a working prototype. They might not be good choices, but if it's new territory for you, you won't understand why they're bad choices until later.
As Fred Brooks once put it: "Plan to throw one away. You will anyway."
Think of this aspect as being a corollary or companion to the "subdivide until you get to something you know" advice so many others have given. This is more of a "It's ok to baling-wire-and-chewing-gum the bits you don't know when you're prototyping." Once you have a working prototype, you have two very important things: A sense of accomplishment because you have something that works, and a sense of what you might do entirely differently the next time.
I had some vague notions, and had even written some toy programs that implemented those notions. But otherwise I sorta jumped head first into writing my emulator, jzIntv. What made that even more exciting is that there wasn't much documentation out there, and basically only one person, Carl Mueller Jr., who had done any real reverse engineering work on it.
I built from his documentation and experiments using his emulator to produce my own. (His emulator was a closed-source, DOS-only implementation. Mine is open source and cross platform.) I think for me, the most interesting parts were in learning the system, reverse engineering it in the areas that were still quite grey, and documenting it for everyone. I also put together a development kit for the machine, because Carl's tools were, again, DOS-only and closed source.
It's been a hell of a trip, and I managed to learn a lot doing it. It's been my background project. As part of that, I've also written a couple of games, and am about to release probably my second largest non-work programming project, Space Patrol, pretty soon. (I consider jzIntv/SDK-1600 to be one very large project, although Space Patrol will get absorbed into that megaproject after it's released.)
Nobody taught me how to do any of that. I'm an EE by training. But, you pick up on things if you read and ask questions. It's what you gotta do. And if it's going to be a meaningful hobby, it's gotta hold your attention. So, on those points I highly agree w/ the parent to this comment.
In terms of hardware hacking, I've built a couple of cartridge dumpers for the Intellivision, and assisted in reverse engineering some of the system's hardware behavior. I also interfaced the Intellivoice peripheral to my PC (via the cartridge dumper) and used that interface to reverse engineer the Intellivoice. I wrote the world's first working emulation of the Intellivoice from that reverse engineering. And then there were a couple fun projects I did as an EE student that I thought were pretty cool as compared to what the rest of the class did:
Designed and built an ISA bus card that interfaced Intel and Motorola serial, parallel and timer chips to the PC, along with software drivers for accessing them from C.
(There's some more, but you'd have to be an EE to appreciate some of the cool hacks we did.)
TI was even stupider than that. The TI BASIC was purposefully crippled. They actually had delay loops in there to slow it down so it "wouldn't be too fast for children." Furthermore, the machine was a study in bottlenecks. The BASIC interpreter was itself intepreted. All the program RAM was stored in video RAM, behind the VDP. It was not directly CPU addressable. That machine could have been sooooo much more than it was. But TI insisted on making it a Speak and Spell with video.
I still have a couple TI-99/4As and all my cartridges and tapes.:-) And I currently work at TI. But man....
Had Commodore pushed the Amiga and dropped the C64 (or figured out how to move its code-base to the Amiga, perhaps with dual modes as the C128 did), and decided that it needed to do something more than video games, it would have survived. Amiga blew everything out of the water, but few here in the US knew much about it. Commodore was too busy pushing the C64 long after it was leading edge.
As I see it, Commodore needed to do two things and it did neither: Push its best (in terms of features, not profit margin) products hardest, and remember its roots as Commodore Business Machines and figure out how to get into the office. In the end, I think the PC won because the PC is what business bought. If you had PC skills you were more employable. Commodore's limp embrace of the PC (the Colt) was just a joke. It practically admitted defeat.
The fact of the matter is, by the end of the 80s we figured out: If you want a game, you get a dedicated game console. (Nintendo, Sega, etc.) If you want a computer, you buy whatever your employer uses so it works the same. (By 1990, clearly an IBM or clone.) And education can just "do its own thing." (Apple.)
The Great Depression is coming. Would you rather be John Doe, or John D. Rockefeller? One saw enduring hardship. The other invested in the stock market for pennies on the dollar, further multiplying his wealth when the market recovered. If you're going to fall, it's nice to have a cushion.
Oh, I'm not trying to minimize the importance of when we run out. I was merely stating that no matter how quickly we get there, we will reach the same endpoint. Therefore, it's informative to consider the meaningful differences between the path to that endpoint. My post specifically concerns itself with this tightly constrained question: Given that there are only so many barrels of oil and that they will all be sold, what should the seller do to maximize his profit in terms of net present value.
Society should concern itself with different questions that revolve around standard of living, longevity, stability and sustainability. An undue reliance on oil could trade short term standard of living for shortened longevity (of society, that is) and decreased world stability due to its unsustainability. I don't think you'll find many who disagree with that statement. Where you'll see the most debate is in what defines "undue reliance."
So, don't read into what I said something I did not say. Don't put words in my mouth.
The way I see it, whether we suck the world's oil reserves dry quickly or we suck them dry slowly, we're still going to suck them dry. There's more profit associated with large demand than small demand, however. Indeed, for a fixed supply, the price vs. demand curve is anything but linear. Furthermore, the time value of money indicates that a given sum of money is more valuable the sooner you have it. If we proactively shift energy demand away from oil, this lengthens the timespan across which we'll deplete the world's oil reserves. This will reduce demand, reduce average prices, and the money will arrive later (and therefore not be as valuable).
Thus, oil companies have strong economic reasons for wanting to keep demand high. They want to maximize their total profit.
Peak oil and alternative energy proponents seek to move energy demand away from oil, either by increasing efficiency or by drawing energy from other sources. Either approach reduces the demand for oil, which is what the petroleum industry wants to avoid.
When I heard it described to me some time ago, they used 3 copies of the primary system that operate via a voting system. If all three fail due to a shared glitch, a 4th machine, independently implemented to the same specs takes over. The idea of the 3 primaries is that a hardware failure can be addressed through votes, but an incorrect implementation cannot. The 4th machine is a hedge against incorrect implementation. If the specifications were wrong, you're just simply hosed and no amount of redundancy can help you there.
This PDF file describes the system somewhat differently. It sounds as if in this system all four GPCs run the same implementation of the task. The description I received back in college may have been inaccurate, or accurate at the time but no longer so. Anyway... interesting stuff.
I don't think Debian Stable is of any relevance. For the problems this computer is asked to compute, you need a very simple, very deterministic control-oriented environment that may not even have what most would consider a "full OS." Rather, you want something that with deterministic latency and periodicity accepts a set of sensor inputs and produces a set of control outputs. I don't think fancy networking stacks and a full *nix userspace have any place there.
You realize you're full of it, right? A one time pad is a random string equal in length to the cleartext. Thus, a ciphertext of length N can decode to any message of length N with equal likelihood. Well, there *is* a bias, but the bias is of the form "sensible decodings are more likely than unsensible decodings." But the semantic meaning of the decoded message could be anything. Your decoder should do no better than a high quality random number generator driving a statistical model of your cleartext in a manner similar to Mark V. Chaney.
Actually, law enforcement can subpoena individual subscriber location records and updates already, so that line has already been crossed. They typically do this for missing persons cases and emergencies and so on, as I recall, but I'm sure it can be (and is) used for other purposes. The part they haven't done yet (and I don't think this can provide as yet) is a database of where every subscriber has traveled that can be queried ex post facto. That's the truly scary end point.
I'm not sure I see an issue. The subscriber motion data would be reported in aggregate. It's not like someone could hop on a website and see that subscriber 214-555-1212 is doing 80 in the show-off lane. And it's not like it's any sort of proprietary marketing data either, such as your personal preference for pimento loaf. It really is pretty much the same data they're collecting from road sensors, as long as the data's aggregated and reported as totals.
Actually, I think these are intended to make it easier for Unisys to get on the calendars of the VPs and CIOs below the CEO. Chances are, Unisys probably isn't interested in meeting with the CEO. But, when they call the CIO or one of the lower levels of management that might need to get approval from above, it becomes easier if the folks above have heard of Unisys and what it's offering and how it's relevant.
Nice straw man. Can I play? How about, consider someone who is openly critical of the President through online forums. W decides to declare that person an "illegal combatant" and sics Alberto Gonzales on him. Gonzales then subpoenas identifying information from Google. (Hmmm... sounds a little like what happened to some dissidents in China wrt. to Yahoo, doesn't it?)
Which is more evil: Google complying with the dubious request of the US Executive Branch (which may end up being "law" here in a moment), or Google fighting the request?
After all, under that little Constitution thingy ("Just a goddamned piece of paper!"), we have those silly rights like the right to Due Process, the right to be free from unreasonable search and seizure, the right to a speedy trial, etc...
We were technically supposed to "do our own homework," but everyone I knew did not take that to mean they couldn't work together to understand how to work the homework. As you say, it's not the same as copying answers. Rather it's about understanding the procedure. I fail to see how it's cheating if you and a friend work it out, vs. if you go to the TA or to the professor's office hours and do the same.
That said, I do have direct data from a friend of mine pursuing a BSME at a local school, and she has complained multiple times about students sharing solutions manuals, actively copying each others' homework answers, etc. These people openly admit that they don't care that they're not doing what the professor asked of them.
Actually, most engineering students don't go on to take the FE and become RPEs. Very few people I know did, at least. I have a BSEE and I'm a CPU architect these days. (Well, co-architect if you want to get nit-picky about it.)
I didn't say to exist. I said to be successful. After all, imagine the network effects involved in a room full of developers instantiating and throwing chairs at each other?
Which question is it begging, and what is it begging of that question? Enquiring minds want to know!
And to those of you who say "language evolves:" Keep in mind that the phrase "{beg|begs|begging} the question" derives from the realm of formal logic. People who didn't really understand at all what they were saying used the phrase, thinking it meant "{raise|raises|raising} the question," but really they were just saying it to try to sound smart, without actually being smart. In other words, it's the mark of a poseur.
Compare this to skript kiddiez who mangle computer terminology in an attempt to sound like they know something. Do you really want to encourage that sort of lameness?
Well, as someone else pointed out, and I agree, that coal plant doesn't necessarily need to be there forever. Personally, I get my electricity from Green Mountain Energy, so theoretically I wouldn't be adding as much to the load for the dirty coal-fired plants.
More important is getting clean plants onto the grid. Governor "Good Hair" Perry has fast-tracked 17 low-tech coal plants to get them past environmental review. I'd rather they look into coal gassification or other technology for new plants they bring on the grid.
I didn't say hybrids were measured differently. I said that the in-the-lab tests tend to overstate a hybrid's fuel economy. Or at least did. My information is older than 2006. I saw several reports such as one mentioned in this article that indicated the EPA testing was dodgy for hybrid vehicles. From the article:
Data from Consumer Reports indicates that hybrid cars get less than 60 percent of EPA estimates while navigating city streets. In Consumer Reports' real-world driving test, the Civic Hybrid averaged 26 mpg in the city, while the Toyota Prius averaged 35 mpg, much less than their respective EPA estimates of 47 and 60 mpg. Hybrid cars performed much closer to EPA estimates in Consumer Reports' highway tests.
Consumer Reports' senior auto test engineer Gabriel Shenhar says that while the EPA test is a lab simulation, Consumer Reports puts the cars on the streets and measures the fuel consumed to more accurately reflect gas mileage.
Is your 60MPG number from the onboard computer or from pencil and paper figuring? The article also points out that the Prius' onboard computer reports unreliable MPG figures.
Slashdot Mirror
I'm willing to bet driving a cab in London is quite a bit more challenging than driving a cab in Manhattan, at least when it comes to plotting the course. I remember hearing a joke while I was there: The only straight roads in England were built by the Romans.
--JoeOut of curiosity, how do semantic and episodic memory relate to procedural memory? It seems like many mnemonic schemes (such as rhymes etc. to help you remember a given sequence) rely on using procedural memory to augment semantic memory. It's somewhat of a blend of the two.
You mention re-coding episodic memory into semantic memory. How often do we see blends of those two for supporting a memory? How long do they tend to be linked while the brain "re-codes?"
--JoeI'm lost: How is "grep somepattern * >filename" any different in tcsh versus bash, except in the case where the directory's empty? It seems like both shells should set up the redirection before forking off the grep, which means it should be equally disasterous in either shell. I guess tcsh does the glob after setting up the redirection, whereas bash does it before?
Interestingly, this steps near the one thing I think tcsh gets right over bash: If a wildcard matches nothing it should not return itself (as it does in bash), it should generate a trappable error. Is there a way to configure bash to generate an error on a wildcard that matches nothing?
--JoeProprietary? From the man page:
I should also add that in many of these different disciplines, aspects of the program architecture and implementation are purely arbitrary. One thing I discovered I needed to do to make progress on particular projects and ideas was to whip up a simple prototype, and rather than obsess on the "best" way to do something (because there may be no "best,") make some arbitrary choices, sufficient to get a working prototype. They might not be good choices, but if it's new territory for you, you won't understand why they're bad choices until later.
As Fred Brooks once put it: "Plan to throw one away. You will anyway."
Think of this aspect as being a corollary or companion to the "subdivide until you get to something you know" advice so many others have given. This is more of a "It's ok to baling-wire-and-chewing-gum the bits you don't know when you're prototyping." Once you have a working prototype, you have two very important things: A sense of accomplishment because you have something that works, and a sense of what you might do entirely differently the next time.
--JoeDitto. Throwing my own 2 cents in:
I had some vague notions, and had even written some toy programs that implemented those notions. But otherwise I sorta jumped head first into writing my emulator, jzIntv. What made that even more exciting is that there wasn't much documentation out there, and basically only one person, Carl Mueller Jr., who had done any real reverse engineering work on it.
I built from his documentation and experiments using his emulator to produce my own. (His emulator was a closed-source, DOS-only implementation. Mine is open source and cross platform.) I think for me, the most interesting parts were in learning the system, reverse engineering it in the areas that were still quite grey, and documenting it for everyone. I also put together a development kit for the machine, because Carl's tools were, again, DOS-only and closed source.
It's been a hell of a trip, and I managed to learn a lot doing it. It's been my background project. As part of that, I've also written a couple of games, and am about to release probably my second largest non-work programming project, Space Patrol, pretty soon. (I consider jzIntv/SDK-1600 to be one very large project, although Space Patrol will get absorbed into that megaproject after it's released.)
Nobody taught me how to do any of that. I'm an EE by training. But, you pick up on things if you read and ask questions. It's what you gotta do. And if it's going to be a meaningful hobby, it's gotta hold your attention. So, on those points I highly agree w/ the parent to this comment.
--JoeProbably the most impressive stuff I've done has been in software:
In terms of hardware hacking, I've built a couple of cartridge dumpers for the Intellivision, and assisted in reverse engineering some of the system's hardware behavior. I also interfaced the Intellivoice peripheral to my PC (via the cartridge dumper) and used that interface to reverse engineer the Intellivoice. I wrote the world's first working emulation of the Intellivoice from that reverse engineering. And then there were a couple fun projects I did as an EE student that I thought were pretty cool as compared to what the rest of the class did:
(There's some more, but you'd have to be an EE to appreciate some of the cool hacks we did.)
--JoeTI was even stupider than that. The TI BASIC was purposefully crippled. They actually had delay loops in there to slow it down so it "wouldn't be too fast for children." Furthermore, the machine was a study in bottlenecks. The BASIC interpreter was itself intepreted. All the program RAM was stored in video RAM, behind the VDP. It was not directly CPU addressable. That machine could have been sooooo much more than it was. But TI insisted on making it a Speak and Spell with video.
I still have a couple TI-99/4As and all my cartridges and tapes. :-) And I currently work at TI. But man....
--JoeHad Commodore pushed the Amiga and dropped the C64 (or figured out how to move its code-base to the Amiga, perhaps with dual modes as the C128 did), and decided that it needed to do something more than video games, it would have survived. Amiga blew everything out of the water, but few here in the US knew much about it. Commodore was too busy pushing the C64 long after it was leading edge. As I see it, Commodore needed to do two things and it did neither: Push its best (in terms of features, not profit margin) products hardest, and remember its roots as Commodore Business Machines and figure out how to get into the office. In the end, I think the PC won because the PC is what business bought. If you had PC skills you were more employable. Commodore's limp embrace of the PC (the Colt) was just a joke. It practically admitted defeat.
The fact of the matter is, by the end of the 80s we figured out: If you want a game, you get a dedicated game console. (Nintendo, Sega, etc.) If you want a computer, you buy whatever your employer uses so it works the same. (By 1990, clearly an IBM or clone.) And education can just "do its own thing." (Apple.)
--JoeThe Great Depression is coming. Would you rather be John Doe, or John D. Rockefeller? One saw enduring hardship. The other invested in the stock market for pennies on the dollar, further multiplying his wealth when the market recovered. If you're going to fall, it's nice to have a cushion.
--JoeOh, I'm not trying to minimize the importance of when we run out. I was merely stating that no matter how quickly we get there, we will reach the same endpoint. Therefore, it's informative to consider the meaningful differences between the path to that endpoint. My post specifically concerns itself with this tightly constrained question: Given that there are only so many barrels of oil and that they will all be sold, what should the seller do to maximize his profit in terms of net present value.
Society should concern itself with different questions that revolve around standard of living, longevity, stability and sustainability. An undue reliance on oil could trade short term standard of living for shortened longevity (of society, that is) and decreased world stability due to its unsustainability. I don't think you'll find many who disagree with that statement. Where you'll see the most debate is in what defines "undue reliance."
So, don't read into what I said something I did not say. Don't put words in my mouth.
--JoeThe way I see it, whether we suck the world's oil reserves dry quickly or we suck them dry slowly, we're still going to suck them dry. There's more profit associated with large demand than small demand, however. Indeed, for a fixed supply, the price vs. demand curve is anything but linear. Furthermore, the time value of money indicates that a given sum of money is more valuable the sooner you have it. If we proactively shift energy demand away from oil, this lengthens the timespan across which we'll deplete the world's oil reserves. This will reduce demand, reduce average prices, and the money will arrive later (and therefore not be as valuable).
Thus, oil companies have strong economic reasons for wanting to keep demand high. They want to maximize their total profit.
Peak oil and alternative energy proponents seek to move energy demand away from oil, either by increasing efficiency or by drawing energy from other sources. Either approach reduces the demand for oil, which is what the petroleum industry wants to avoid.
When I heard it described to me some time ago, they used 3 copies of the primary system that operate via a voting system. If all three fail due to a shared glitch, a 4th machine, independently implemented to the same specs takes over. The idea of the 3 primaries is that a hardware failure can be addressed through votes, but an incorrect implementation cannot. The 4th machine is a hedge against incorrect implementation. If the specifications were wrong, you're just simply hosed and no amount of redundancy can help you there.
This PDF file describes the system somewhat differently. It sounds as if in this system all four GPCs run the same implementation of the task. The description I received back in college may have been inaccurate, or accurate at the time but no longer so. Anyway... interesting stuff.
I don't think Debian Stable is of any relevance. For the problems this computer is asked to compute, you need a very simple, very deterministic control-oriented environment that may not even have what most would consider a "full OS." Rather, you want something that with deterministic latency and periodicity accepts a set of sensor inputs and produces a set of control outputs. I don't think fancy networking stacks and a full *nix userspace have any place there.
--JoeYou realize you're full of it, right? A one time pad is a random string equal in length to the cleartext. Thus, a ciphertext of length N can decode to any message of length N with equal likelihood. Well, there *is* a bias, but the bias is of the form "sensible decodings are more likely than unsensible decodings." But the semantic meaning of the decoded message could be anything. Your decoder should do no better than a high quality random number generator driving a statistical model of your cleartext in a manner similar to Mark V. Chaney.
Actually, law enforcement can subpoena individual subscriber location records and updates already, so that line has already been crossed. They typically do this for missing persons cases and emergencies and so on, as I recall, but I'm sure it can be (and is) used for other purposes. The part they haven't done yet (and I don't think this can provide as yet) is a database of where every subscriber has traveled that can be queried ex post facto. That's the truly scary end point.
--JoeI'm not sure I see an issue. The subscriber motion data would be reported in aggregate. It's not like someone could hop on a website and see that subscriber 214-555-1212 is doing 80 in the show-off lane. And it's not like it's any sort of proprietary marketing data either, such as your personal preference for pimento loaf. It really is pretty much the same data they're collecting from road sensors, as long as the data's aggregated and reported as totals.
Actually, I think these are intended to make it easier for Unisys to get on the calendars of the VPs and CIOs below the CEO. Chances are, Unisys probably isn't interested in meeting with the CEO. But, when they call the CIO or one of the lower levels of management that might need to get approval from above, it becomes easier if the folks above have heard of Unisys and what it's offering and how it's relevant.
--JoeElectricity you don't buy is electricity you don't pay tax on.
Nice straw man. Can I play? How about, consider someone who is openly critical of the President through online forums. W decides to declare that person an "illegal combatant" and sics Alberto Gonzales on him. Gonzales then subpoenas identifying information from Google. (Hmmm... sounds a little like what happened to some dissidents in China wrt. to Yahoo, doesn't it?)
Which is more evil: Google complying with the dubious request of the US Executive Branch (which may end up being "law" here in a moment), or Google fighting the request?
After all, under that little Constitution thingy ("Just a goddamned piece of paper!"), we have those silly rights like the right to Due Process, the right to be free from unreasonable search and seizure, the right to a speedy trial, etc...
--JoeAgreed. Mod parent up!
We were technically supposed to "do our own homework," but everyone I knew did not take that to mean they couldn't work together to understand how to work the homework. As you say, it's not the same as copying answers. Rather it's about understanding the procedure. I fail to see how it's cheating if you and a friend work it out, vs. if you go to the TA or to the professor's office hours and do the same.
That said, I do have direct data from a friend of mine pursuing a BSME at a local school, and she has complained multiple times about students sharing solutions manuals, actively copying each others' homework answers, etc. These people openly admit that they don't care that they're not doing what the professor asked of them.
--JoeActually, most engineering students don't go on to take the FE and become RPEs. Very few people I know did, at least. I have a BSEE and I'm a CPU architect these days. (Well, co-architect if you want to get nit-picky about it.)
--JoeI didn't say to exist. I said to be successful. After all, imagine the network effects involved in a room full of developers instantiating and throwing chairs at each other?
Which question is it begging, and what is it begging of that question? Enquiring minds want to know!
And to those of you who say "language evolves:" Keep in mind that the phrase "{beg|begs|begging} the question" derives from the realm of formal logic. People who didn't really understand at all what they were saying used the phrase, thinking it meant "{raise|raises|raising} the question," but really they were just saying it to try to sound smart, without actually being smart. In other words, it's the mark of a poseur.
Compare this to skript kiddiez who mangle computer terminology in an attempt to sound like they know something. Do you really want to encourage that sort of lameness?
All right then. "Raise the question" it is.
--JoeWell, as someone else pointed out, and I agree, that coal plant doesn't necessarily need to be there forever. Personally, I get my electricity from Green Mountain Energy, so theoretically I wouldn't be adding as much to the load for the dirty coal-fired plants.
More important is getting clean plants onto the grid. Governor "Good Hair" Perry has fast-tracked 17 low-tech coal plants to get them past environmental review. I'd rather they look into coal gassification or other technology for new plants they bring on the grid.
--JoeI didn't say hybrids were measured differently. I said that the in-the-lab tests tend to overstate a hybrid's fuel economy. Or at least did. My information is older than 2006. I saw several reports such as one mentioned in this article that indicated the EPA testing was dodgy for hybrid vehicles. From the article:
Is your 60MPG number from the onboard computer or from pencil and paper figuring? The article also points out that the Prius' onboard computer reports unreliable MPG figures.
--Joe