They're called "corner reflectors", and are extremely simple. Arrange three reflecting planes perpendicular to each other, forming eight square corners. Such a reflector will always bounce a beam back in the exact direction from which it came.
See Heinlein's Have Spacesuit, Will Travel (IIRC) for a nice account of this.
With this technology, I can get any color I want by varying the plate distance continuously!
I can also get (visible) black by varying the plate distance to one extreme or the other. So the red-green-blue thing is a trichromatic herring: to get a given intensity of a given hue, I can just dither between pixels of that hue and black pixels. This doesn't require many bits. For pastels, I need four pixels to dither with, but they don't have to be rgb: I can play with colors that combine in the right proportion against the human eye response curve.
Better yet, humans don't distinguish colors that are very light or very dark pastel very well, so a lot of my dither space can be effectively fudged.
The upshot of all this? I can get a lot higher effective bpp by dithering with this thing than I can from dithering with a fixed RGB color palette, and that means that I can use fewer bits of dither per pixel to get a wide range of colors. In principle.
Yes, of course Ask Slashdot serves a useful function: sometimes information isn't readily available via Google and/or the library, but is readily available through the minds of this audience. This is where the category shines.
To pick the first example that came up, this is a pretty good question to Ask Slashdot. There's probably some web sites for geek Halloween stuff, but there's probably no easy, organized way to find the cool ones, and there's probably a lot that hasn't been webified by the/. crowd. Thus, the question and answers are interesting to the/. audience. I'd really like to read this, IOW, but not the millionth recap of bog-standard software disaster stories.
Could we have a new Slashdot category entitled Ask Slashdot To Do My Research/Homework For Me?
Then I could mark this category unread and avoid some annoyance.
There is so much information readily available on the subject of software failures online and in scientific and popular publications. (See other responses to this question for examples.)
IMHO, the questioner should go look for the answer to this kind of question directly before bugging the entire Slashdot audience; the editors should enforce this policy.
And wait, there's still more. The proof fails if you fix the number of columns in the game board! In other words, this is not just offline Tetris on a normal-width Tetris board: the complexity is a function of the fact that as the piece sequence gets longer, the board width also increases.
I was excited about this paper half an hour ago: now, not so much.
Only proven hard if started screwed up enough...
on
Tetris Is Hard: NP-Hard
·
· Score: 5, Insightful
Uh, I was just reading the full paper and came to this comment which summarizes an important fact omitted in the abstract:
An essential part of our reduction is a complicated initial gameboard from which the player must start. A major open question is whether Tetris can be played efficiently with an empty initial configuration: What is the complexity of Tetris when the initial gameboard is empty?
In other words, "normal offline Tetris" (whatever that means) may still be in P. (And, BTW, when they say "complicated", they really mean it: check out the full paper for details.) Sigh.
Technically, it's 'NP-hard,' meaning that there is no efficient way to calculate the necessary moves to "win"
It is more correct to say that "there is no known efficient way to calculate the necessary moves to win, and it is unlikely that one will be discovered." Technically, there is no efficient method unless P = NP. See Garey and Johnson for details.
At least there's one geek classic that refuses to fall to the scrutiny of mathematicians.
Actually, even the (surprising, novel, and cool) approximation results only tell us about the asymptotic complexity of the game, and then only of the "offline" game in which you know the sequence of pieces that will be coming. Note that optimal restacking of blocks is also asymptotically NP-hard and inapproximable [Gupta and Nau], but quite tractable for humans and machines even for very large stacks in practice.
Short version: in spite of these results, a good AI programmer can easily build a Tetris-playing program that will kick your sorry human behind:-).
One assumption in the paper that I disagree with is that "intuitively" the offline version (full knowledge of piece sequence) should be easier than the version in which the piece sequence is not known. My intuition says the opposite: in the online version, the most one can do is optimize one's probability of a win. This more modest goal should be easier to attain than the loftier goal of "prove a win if one exists".
For kit hardware that implements the ideas of Braitenberg et. al., check out the BYO-bot.
I've had one for several years, and they're a great classroom demo.
More to the point, Slashdot is going to get sued sooner or later for actual damages in bandwidth cost plus punitive damages for negligence plus legal fees. It isn't like the editors don't know about the problems they're inflicting on others: they just don't choose to care. That's usually civilly actionable one way or another, at least in the US.
Yes, yes, I know, off-topic and insufficiently Slashdot rah-rah. But I host a site at my public University that carries a bunch of free software and useful information, and I suspect it's only a matter of time under the current regime until I'm forced to take it down because it gets Slashdotted one time too many. (It has been up two months, and has already been hit once. It has a lot more content now than it did then.) If this were a hard problem to solve for some reason, it would be one thing...
As a practicing AI researcher, I can only say that you have stumbled into some very deep waters here. Certainly, I can build a chess-playing program that will easily beat me every time, using moves I cannot understand or explain. To say that "I programmed it to play that way" is to raise the question: how did I do that, when I don't even understand what "that way" is? And how can someone who is even a worse chess player than I (OK, hardly possible) write a program that will play in a way that consistently beats my program?
The issue of assigning credit for machine chess play is far from settled, but I think there's a strong case for identifying the emergent behaviour of the chess machine as a kind of intelligence or "smarts" that is independent of the intelligence or smarts of the program's creator.
What ever happened to Magnetohydrodynamic (MHD) engines? It seems like they'd be perfect for a locomotive application, inasmuch as they can take fuel directly to electricity with no moving parts. A quick Google search shows one old but promising article on an LMMHD auto engine, and that's about it: comments on the infeasibility of this approach would be appreciated.
Go buy any old digital camera and try to download the pics on a RedHat system. Do it every day, works fine.
Go buy a DVD-R and try to burn a disc. Can't afford a DVD-R, but I'll bet it works great. I know every CD burner I ever tried does.
Go to any old website showing media (RealPlayer, QuickTime, Windows Media) and see how successful you are at viewing content. View RealPlayer and Windows Media regularly. Can do any kind of QuickTime except Sorenson, and could do that with either Crossover Plugin or a pirate solution if I actually cared.
Buy a Firewire DV Video Camera and see how successful you are in getting the video off and editing it. Hey, how rich do you think I am? But I have software that claims to do this job fine, and I have no reason to disbelieve it.
Try to visit a site that's made for IE. I can think of one site I've visited in the last 6 months that I needed IE to view. I can think of far more that could only be viewed with Mozilla, actually. Pop-ups, you know.
Go to the store and buy a game. Did it yesterday. They sell Linux games at Fry's now, you know.
Buy a PDA and get it to synch up. I've never synced with anything but my Linux box.
Your network card doesn't work, find somebody you know willing to come over and fix it. OK, you've got me there. All my network cards have worked:-). But seriously, I've helped a bunch of my friends with card problems under Linux: they don't seem any worse than with Windows to me. At least they don't ship outdated broken driver CDs for Linux: saves being suckered into installing them.
Overall, I think you've made a pretty good case that Linux is ready for the consumer.
Not that I'm an expert, but wasn't the stitching software aided? These days, it seems like the whole thing could be auto-stitched without any human intervention...
The average American (and probably European too, but I can't say) consumer can run word, e-mail, the web, e-mail, and probably a few games. They are blissful on Windows...
Have you ever even talked to an average consumer? Most of the Windows users I've talked to hate much of it. Things crash and break randomly, there's always some new expensive piece of software to buy, the interfaces are baffling. They put up with it because they
have no idea there's any choice, but "blissful"
is a blissfully ignorant description of their state. Why else would they be so excited every time a new version of Windows comes out?
For a fairly "average" Windows user's view, try this
Dave Barry column. It jives much better with
my experience than your observations do.
Many of the criticisms of off-site electronic
voting systems, while completely valid in general,
are moot in Oregon. We have vote-by-mail here.
Thus, most of the putative problems with electronic off-site voting are already here, but at least folks mis-mark ballots and the post office loses
things.
I have always thought that putting a properly-written open-source voting package on a
Knoppix CD and instructing voters to boot their PC off it would solve most of the problems. The advantages would be automatic tabulation of a large percentage of the vote, saving a bunch of p-mail, and clearer, easier-to-mark ballots. Those who couldn't make this solution work could always vote by mail as they do currently.
For state-run voting kiosks, this also
seems a sensible solution. A printer could be added
to the system to provide an audit trail.
What am I missing here? None of this seems
hard, and the security risks seem less severe than
those of the current non-electronic systems, which
as we know suffer from frequent failures and occasional serious fraud. Is it just a question
of insufficient experience with "new-fangled" systems? Or is there something deeper?
It's a great way of seeing how secure a TCP stack really is.
Yeah, right.
Try the following:
plot 500 points with point i
having x coordinate Fib(i + 37) % 97
and y coordinate Fib(i + 97) % 97
(where Fib(i) is the i-th Fibonacci number).
They look random, but in fact are totally predictable!
Now imagine that someone got this right,
and uses a crypto-secure PRNG to generate
their TCP ISNs, seeding it with known-good
random data. It would be nice to believe
that this defeats all known TCP attacks! In
fact, of course, their stack may be completely
open to all kinds of attacks not involving
ISN spoofing.
The graphics are amusing, but not particularly informative except in the negative case.
There is no substitute for real
security. Testing can only prove a system
insecure. ISN attacks are not the biggest
worry in most TCP applications.
For a couple of hundred US dollars I can
get a PCI card with an FPGA or some such field-programmable logic device. Isn't this the right way to do most of the signal processing for
"software" radio? Why or why not?
Always fashionable to pile on the cellphone users. Here's my contributions:
It's not like you ever saw anyone step out into traffic without looking before there were cellphones. (You did? Huh.)
Certainly the non-cellphone conversations of those around us in
public places are notable for their erudition and cogency. (They're not? Huh.)
It isn't like talking on a cellphone in traffic could make driving safer in any
way. (You use it for what? Checking road conditions? Reporting drunk drivers? Huh.)
People were the same way at the dawn of the automobile age. The funny part is, they were mostly right. Cars are more dangerous[1] than horses and buggies, and an annoyance to civilized society. They also transformed civilization, in most ways for the better. (Try taking someone to the hospital on a horse sometime and see how it works out.)
The cellphone is here to stay. If costs come down just a bit more, everyone in the civilized world will have one. Might as well just enjoy it. If the conversations of those around you are bugging you, call a friend of your own and drown it out, or listen to that next technological marvel: the portable MP3 player.
-------------
1. Although folks forget how dangerous horses and buggies were, per road mile travelled. Horses are irrational: they buck riders off, run away with carriages, etc. It would actually be interesting to see a risk study sometime.
Interested parties will find lots of neat stuff in here... including the idea of storing kernel panic info in NVRAM and writing it to a logfile on reboot.
Huh? Except for writing into RAM instead of NVRAM (which is almost always sufficient), versions of UNIX and other OSes in the 1980s always did this. This is essentially what dmesg(8) is for.
Please stop making me feel old. Kids these days...:-)
The article claims that the drivers, not the HW, are causing the performance problem. Based on my conversations with a premier graphics programmer and some x86 experts, I don't believe that it is this simple. In particular, note that XFree86 2D, which uses its own drivers, also has pathetic readback rates.
I barely understand the technical details, but it seems like there are some serious misfeatures in the way that the AGP bus interacts with CPUs and caches on both Intel and AMD during
readback; it is going to be hard for card vendors to fix this problem (even if they decide to care). It may be that a new bus and/or new CPU glue will be needed for high-readback-rate applications.
Slashdot Mirror
They're called "corner reflectors", and are extremely simple. Arrange three reflecting planes perpendicular to each other, forming eight square corners. Such a reflector will always bounce a beam back in the exact direction from which it came.
See Heinlein's Have Spacesuit, Will Travel (IIRC) for a nice account of this.
With this technology, I can get any color I want by varying the plate distance continuously! I can also get (visible) black by varying the plate distance to one extreme or the other. So the red-green-blue thing is a trichromatic herring: to get a given intensity of a given hue, I can just dither between pixels of that hue and black pixels. This doesn't require many bits. For pastels, I need four pixels to dither with, but they don't have to be rgb: I can play with colors that combine in the right proportion against the human eye response curve.
Better yet, humans don't distinguish colors that are very light or very dark pastel very well, so a lot of my dither space can be effectively fudged.
The upshot of all this? I can get a lot higher effective bpp by dithering with this thing than I can from dithering with a fixed RGB color palette, and that means that I can use fewer bits of dither per pixel to get a wide range of colors. In principle.
WMD = Weapon of Mass Destruction. Not obvious, IMHO.
We're badly off-topic here, but hey...
Yes, of course Ask Slashdot serves a useful function: sometimes information isn't readily available via Google and/or the library, but is readily available through the minds of this audience. This is where the category shines.
To pick the first example that came up, this is a pretty good question to Ask Slashdot. There's probably some web sites for geek Halloween stuff, but there's probably no easy, organized way to find the cool ones, and there's probably a lot that hasn't been webified by the /. crowd. Thus, the question and answers are interesting to the /. audience. I'd really like to read this, IOW, but not the millionth recap of bog-standard software disaster stories.
Could we have a new Slashdot category entitled Ask Slashdot To Do My Research/Homework For Me? Then I could mark this category unread and avoid some annoyance.
There is so much information readily available on the subject of software failures online and in scientific and popular publications. (See other responses to this question for examples.) IMHO, the questioner should go look for the answer to this kind of question directly before bugging the entire Slashdot audience; the editors should enforce this policy.
And wait, there's still more. The proof fails if you fix the number of columns in the game board! In other words, this is not just offline Tetris on a normal-width Tetris board: the complexity is a function of the fact that as the piece sequence gets longer, the board width also increases.
I was excited about this paper half an hour ago: now, not so much.
Uh, I was just reading the full paper and came to this comment which summarizes an important fact omitted in the abstract:
In other words, "normal offline Tetris" (whatever that means) may still be in P. (And, BTW, when they say "complicated", they really mean it: check out the full paper for details.) Sigh.Technically, it's 'NP-hard,' meaning that there is no efficient way to calculate the necessary moves to "win"
It is more correct to say that "there is no known efficient way to calculate the necessary moves to win, and it is unlikely that one will be discovered." Technically, there is no efficient method unless P = NP. See Garey and Johnson for details.
At least there's one geek classic that refuses to fall to the scrutiny of mathematicians.
Actually, even the (surprising, novel, and cool) approximation results only tell us about the asymptotic complexity of the game, and then only of the "offline" game in which you know the sequence of pieces that will be coming. Note that optimal restacking of blocks is also asymptotically NP-hard and inapproximable [Gupta and Nau], but quite tractable for humans and machines even for very large stacks in practice. Short version: in spite of these results, a good AI programmer can easily build a Tetris-playing program that will kick your sorry human behind :-).
One assumption in the paper that I disagree with is that "intuitively" the offline version (full knowledge of piece sequence) should be easier than the version in which the piece sequence is not known. My intuition says the opposite: in the online version, the most one can do is optimize one's probability of a win. This more modest goal should be easier to attain than the loftier goal of "prove a win if one exists".
For kit hardware that implements the ideas of Braitenberg et. al., check out the BYO-bot. I've had one for several years, and they're a great classroom demo.
We appear to have /.ed the South Florida District Courts web site. Court-ordered mirroring, anyone?
More to the point, Slashdot is going to get sued sooner or later for actual damages in bandwidth cost plus punitive damages for negligence plus legal fees. It isn't like the editors don't know about the problems they're inflicting on others: they just don't choose to care. That's usually civilly actionable one way or another, at least in the US.
Yes, yes, I know, off-topic and insufficiently Slashdot rah-rah. But I host a site at my public University that carries a bunch of free software and useful information, and I suspect it's only a matter of time under the current regime until I'm forced to take it down because it gets Slashdotted one time too many. (It has been up two months, and has already been hit once. It has a lot more content now than it did then.) If this were a hard problem to solve for some reason, it would be one thing...
As a practicing AI researcher, I can only say that you have stumbled into some very deep waters here. Certainly, I can build a chess-playing program that will easily beat me every time, using moves I cannot understand or explain. To say that "I programmed it to play that way" is to raise the question: how did I do that, when I don't even understand what "that way" is? And how can someone who is even a worse chess player than I (OK, hardly possible) write a program that will play in a way that consistently beats my program?
The issue of assigning credit for machine chess play is far from settled, but I think there's a strong case for identifying the emergent behaviour of the chess machine as a kind of intelligence or "smarts" that is independent of the intelligence or smarts of the program's creator.
What ever happened to Magnetohydrodynamic (MHD) engines? It seems like they'd be perfect for a locomotive application, inasmuch as they can take fuel directly to electricity with no moving parts. A quick Google search shows one old but promising article on an LMMHD auto engine, and that's about it: comments on the infeasibility of this approach would be appreciated.
Go buy any old digital camera and try to download the pics on a RedHat system. Do it every day, works fine.
Go buy a DVD-R and try to burn a disc. Can't afford a DVD-R, but I'll bet it works great. I know every CD burner I ever tried does.
Go to any old website showing media (RealPlayer, QuickTime, Windows Media) and see how successful you are at viewing content. View RealPlayer and Windows Media regularly. Can do any kind of QuickTime except Sorenson, and could do that with either Crossover Plugin or a pirate solution if I actually cared.
Buy a Firewire DV Video Camera and see how successful you are in getting the video off and editing it. Hey, how rich do you think I am? But I have software that claims to do this job fine, and I have no reason to disbelieve it.
Try to visit a site that's made for IE. I can think of one site I've visited in the last 6 months that I needed IE to view. I can think of far more that could only be viewed with Mozilla, actually. Pop-ups, you know.
Go to the store and buy a game. Did it yesterday. They sell Linux games at Fry's now, you know.
Buy a PDA and get it to synch up. I've never synced with anything but my Linux box.
Your network card doesn't work, find somebody you know willing to come over and fix it. OK, you've got me there. All my network cards have worked :-). But seriously, I've helped a bunch of my friends with card problems under Linux: they don't seem any worse than with Windows to me. At least they don't ship outdated broken driver CDs for Linux: saves being suckered into installing them.
Overall, I think you've made a pretty good case that Linux is ready for the consumer.
Not that I'm an expert, but wasn't the stitching software aided? These days, it seems like the whole thing could be auto-stitched without any human intervention...
Since we intended GNU to be a Unix-like operating system...
...and to make this intention clear, they named their creation "GNU's Not UNIX". I don't understand how people are so easily confused by this stuff.
Update: 09/25 17:51 GMT by M: Link removed at the request of the site maintainers because it's killing their server.
Great, now we'll be discussing the article without ever having read it!
Oh, wait, that's what we do anyway. Nevermind.
The average American (and probably European too, but I can't say) consumer can run word, e-mail, the web, e-mail, and probably a few games. They are blissful on Windows...
Have you ever even talked to an average consumer? Most of the Windows users I've talked to hate much of it. Things crash and break randomly, there's always some new expensive piece of software to buy, the interfaces are baffling. They put up with it because they have no idea there's any choice, but "blissful" is a blissfully ignorant description of their state. Why else would they be so excited every time a new version of Windows comes out?
For a fairly "average" Windows user's view, try this Dave Barry column. It jives much better with my experience than your observations do.
Is this wrong? Or do those with power get to do whatever they want?
Both are true. Duh.
Many of the criticisms of off-site electronic voting systems, while completely valid in general, are moot in Oregon. We have vote-by-mail here. Thus, most of the putative problems with electronic off-site voting are already here, but at least folks mis-mark ballots and the post office loses things.
I have always thought that putting a properly-written open-source voting package on a Knoppix CD and instructing voters to boot their PC off it would solve most of the problems. The advantages would be automatic tabulation of a large percentage of the vote, saving a bunch of p-mail, and clearer, easier-to-mark ballots. Those who couldn't make this solution work could always vote by mail as they do currently.
For state-run voting kiosks, this also seems a sensible solution. A printer could be added to the system to provide an audit trail.
What am I missing here? None of this seems hard, and the security risks seem less severe than those of the current non-electronic systems, which as we know suffer from frequent failures and occasional serious fraud. Is it just a question of insufficient experience with "new-fangled" systems? Or is there something deeper?
It's a great way of seeing how secure a TCP stack really is.
Yeah, right.
Try the following: plot 500 points with point i having x coordinate Fib(i + 37) % 97 and y coordinate Fib(i + 97) % 97 (where Fib(i) is the i-th Fibonacci number). They look random, but in fact are totally predictable!
Now imagine that someone got this right, and uses a crypto-secure PRNG to generate their TCP ISNs, seeding it with known-good random data. It would be nice to believe that this defeats all known TCP attacks! In fact, of course, their stack may be completely open to all kinds of attacks not involving ISN spoofing.
The graphics are amusing, but not particularly informative except in the negative case. There is no substitute for real security. Testing can only prove a system insecure. ISN attacks are not the biggest worry in most TCP applications.
For a couple of hundred US dollars I can get a PCI card with an FPGA or some such field-programmable logic device. Isn't this the right way to do most of the signal processing for "software" radio? Why or why not?
Always fashionable to pile on the cellphone users. Here's my contributions:
People were the same way at the dawn of the automobile age. The funny part is, they were mostly right. Cars are more dangerous[1] than horses and buggies, and an annoyance to civilized society. They also transformed civilization, in most ways for the better. (Try taking someone to the hospital on a horse sometime and see how it works out.)
The cellphone is here to stay. If costs come down just a bit more, everyone in the civilized world will have one. Might as well just enjoy it. If the conversations of those around you are bugging you, call a friend of your own and drown it out, or listen to that next technological marvel: the portable MP3 player.
-------------
1. Although folks forget how dangerous horses and buggies were, per road mile travelled. Horses are irrational: they buck riders off, run away with carriages, etc. It would actually be interesting to see a risk study sometime.
Interested parties will find lots of neat stuff in here... including the idea of storing kernel panic info in NVRAM and writing it to a logfile on reboot.
Huh? Except for writing into RAM instead of NVRAM (which is almost always sufficient), versions of UNIX and other OSes in the 1980s always did this. This is essentially what dmesg(8) is for.
Please stop making me feel old. Kids these days... :-)
The article claims that the drivers, not the HW, are causing the performance problem. Based on my conversations with a premier graphics programmer and some x86 experts, I don't believe that it is this simple. In particular, note that XFree86 2D, which uses its own drivers, also has pathetic readback rates.
I barely understand the technical details, but it seems like there are some serious misfeatures in the way that the AGP bus interacts with CPUs and caches on both Intel and AMD during readback; it is going to be hard for card vendors to fix this problem (even if they decide to care). It may be that a new bus and/or new CPU glue will be needed for high-readback-rate applications.