Dave Reed did an extensive Croquet demo at the Freenix Track of the Usenix ATC this year. Seemed really cool, but at the time was too buggy to be usable. Basically, Croquet lets you put all kinds of interesting workspaces in a collaborative 3D virtual world: sort of the logical completion of the virtual world description languages that were popular some years ago. Must be a Smalltalk guru to play, it looks like. Has a fancy synchronization protocol that takes care of most lag issues.
Let's hope that the bugs are sufficiently out that we can have big fun with this. I'm looking forward to trying it.
I have equipment with absurdly overkill Super-Bright LEDs in it too. The two solutions I have used are to put multiple layers of masking tape over the LED colored with a dark felt marker, or to put black electrical tape over the LED and put a pinhole in it. Either one will let you still monitor the LED without blinding yourself. Sigh.
The Condorcet website says " It [Condorcet] allows voters to vote for the candidate they agree with most rather than against the major-party candidate they disagree with most. In other words, it eliminates the need for defensive or strategic voting." Unfortunately, this is wrong, and demonstrates a lack of understanding on someone's part.
Nobel prizewinning economist Kenneth Arrow proved a neat little theorem in the 1950s. He showed that, under some very minimal and reasonable requirements for what a voting system is supposed to do, any voting system will sometimes require strategic voting in a 3 (or more) candidate election.
Almost no one seriously involved in quantum computing and/or cryptography believes that shared-secret encryption will be threatened by a working quantum computer. There is currently no known quantum-computing algorithm that will crack (e.g.) AES any faster than conventional computing, and there are good theoretical reasons to believe no such algorithm exists.
Public-key crypto, at least that based on factoring, is out the window: this will be a major pain, but really will just put us back where we were before RSA, not that long ago.
IANAL, but from a common-sense legal point of view this is nonsense. Basic contract law says that two parties can negotiate an enforceable contract to do anything that is not illegal. "Not transmitting from my residence in the 802.11 band" is surely a legal activity: therefore I should be able to agree to do it in return for, e.g., housing or an education. I liked the analogy of an earlier poster, who likened this to prohibiting hot plates in your dorm room. Is this somehow not OK because the UL has certified the hot plate as a legal device?
It's hard to identify any constitutional right that this contract would abrogate. People sign contracts that require them to restrict their speech (presumably the relevant clause) all the time. I don't think the FCC can or wants to prevent folks from doing this.
IMHO (again, IANAL) the University in question needs to spend some serious time with quality legal counsel.
Thanks for the windows advice! Sure enough, I'm running XP on AMD/VIA. Tends to make me a "Linux bigot" rather than an "Intel bigot":-), but your point is well taken.
The box is my wife's, and she runs all kinds of my kids' games on it, commercial and from Yahoo. No viruses or spyware that I can find, and it runs behind a firewall. It could be the games themselves that are at fault. Your reference to blackviper.com is quite welcome: I'll meditate more on the material there.
If X crashes (locks up, etc) often for you, you should get some help with it. I run X on a variety of random hardware, and I've found it to be darn reliable. Often, upgrading your server or paying attention to its (hideous) configuration can solve your problems: contact an X guru e.g. on the freedesktop.org IRC.
Advice on what to do about my frequent XP crashes would be highly appreciated:-).
The reason you use QC atop traditional crypto is that you don't want to make your ciphertext available for offline attack. With a traditional channel, I can passively eavesdrop on the line. I can then crack the crypto, do traffic analysis, etc. at my leisure. With a QC, once I've authenticated the endpoints using traditional crypto, I am confident that my ciphertext of the entire session is secure.
This is not a trivial advantage of the QC approach. Imagine that the Germans had QCs during WWII. We'd probably still not have any of their traffic, even though Enigma was broken during the war: we couldn't crack it in anything like realtime AFAIK. Imagine again that the WWII Japanese traffic to Midway was protected by a QC. No traffic analysis = no battle plan. QC protects your ciphertext in a way that other methods simply do not.
Right. (Why did you post AC?) The traditional method of using a quantum channel is to exchange authentication data OOB as part of the setup process (the channel has to be physically set up anyway:-). You then can do either public-key or secret-key tradtional crypto stuff at connection setup time to generate a crypto-secure random sequence for the polarization bits. If you somehow have managed to set up a quantum channel with someone with absolutely no out-of-band data, or if you don't trust traditional crypto at all, QC doesn't really help you against an MIM attack.
AFAIK (I am not a quantum cryptographer by trade, but I have degrees in physics and computer science), a quantum channel is secure against MIM attacks. You can make the probability that you are talking to an endpoint with the shared secret arbitrarily close to 1 by exchanging a series of authentication bits. (Or are you referring to the fact that you may leak a few bits before the MIM is caught? I think conventional crypto and unicity distance makes this not an effective attack in practice.)
This is why you need a full mesh to provide a secure network. This is indeed unrealistic for applications with very many nodes involved, limiting the use of quantum channels.
No, I actually did mean "perfectly secure" against physical eavesdropping. The laws of quantum physics are odd; they guarantee (with probability arbitrarily close to 1) that if you try to listen to the message in transit, you'll wreck it. The Patriot Act may let the eavesdropper mess with the endpoints of the channel, but the channel itself is secure against everything but attacks on the fundamental laws of nature:-).
This might be the end of the hacked by Chinese index pages!
Uh, no. Quantum communication is not magic. (OK, maybe, but not that kind of magic.) What it is, is perfectly secure against physical eavesdropping. An attacker can't "tap the wire", as it were. The name "quantum encryption" is something of a misnomer, though: this technology is just a communication channel, albeit an uber-cool one.
Keep in mind that the servers shipped running Linux may be a miniscule fraction of the total Linux servers deployed or being deployed at this point. Presumably one reason for the relative growth of Linux preloads vs Windows preloads will be more competitive prices of Linux preloads and a decline in Windows unloads.
(BTW, when you directly quote an article, it is a good idea to use quotation marks. Otherwise people might think the text was yours.)
Isn't there one of those science discovery betting pools that has "cold fusion" as one of the things to bet on? I desperately want to bet against it, at whatever odds they'll give me. Easy money at 100000:1. Looks like gullible/.-ers alone would put the book at more like 10:1 though, meaning that if it had a two-year window it would be a 5% investment even if I had to put the money in escrow up front. Heck, if it weren't illegal in the US, I would make book on it myself. Advantages of a physics degree and a wide reading list, dontcha know.
Yes, even the discovery of an algorithm doesn't imply that it has an easy implementation. But I know of no realistic polytime examples where the provably best worst-case running time is worse than cubic, or where the algorithm commonly used is dramatically worse in practice than the best algorithm because no one can implement the good one.
The obvious example is LP, where everyone used Simplex for a long time because Kachian's method is such a pain to implement and has lousy constants. However, Simplex was used precisely because its expected running time in practice is small, whereas in practice naive Kachian's tends to achieve its worst-case bound. When improvements on Kachian's method made it more efficient for very large problems, a lot of folks implemented it and switched. You'll see both kinds out there now.
You can implement priority queues in a fairly complicated way to get insertion to be O(1): this constitutes a fairly dramatic improvement over O(log n) to some ways of thinking:-). When I ran into a situation where it mattered, I spent a long time doing this. You do what you've got to do.
Of course, you might correctly point out that the proof that P=NP might be non-constructive, in the sense that it might not come with an algorithm. But wait...
Of course, this still doesn't give you a feasible answer.
It is considered likely by many that a polytime algorithm for deciding instances of NP-complete problems would also provide efficient keyspace search for cryptanalysis. This is a consequence of the "polytime thesis" (sorry about the crufty link, but I didn't spot anything better offhand: look way down near the end), which states that any real-world problem that has a polytime algorithm has a feasible algorithm. Note that this is both fuzzy and a thesis rather than a theorem, but I am not aware of any counter-examples. So, based on empirical evidence of past discoveries, we might well expect that if we can find a polytime algorithm for keyspace search, we can also find a feasible algorithm.
Consider the problem of deciding whether a number is prime. This problem was recently shown to be in P, but the algorithm given requires around |n|**12 steps in practice. Obviously, this is still not a feasible algorithm. Proponents of the polytime thesis, however, are not concerned: they believe that a low-order polytime algorithm will soon be found. I tend to agree with them.
Thanks for the insightful comment! The Nickle frontpage really could use some help as you suggest.
Part of the problem is that Nickle has evolved over 20 years from being a bc-like thing to being a language that you really can answer "yes" to for everything in your next-to-the-last paragraph.:-)
Common use cases for Nickle:
Calculate in a reasonable calculator language featuring arbitrary precision rationals, settable high-precision floats, and nice calculational features. (Competes with e.g. bc, expr.)
Prototype some tricky functions in a PL that looks a lot like C but with no limits, GC, a nice subtyping system, and an interactive environment. When the code works, translate easily to C for performance and integration. (Competes with e.g. Scheme, Matlab.)
Script in situations requiring real datatypes and advanced algorithms with clean syntax and semantics. (Competes with e.g. Python, Perl.)
Learn about advanced programming features and techniques like continuations and threads in a friendly, rich interactive environment. (Competes with e.g. Scheme, ML, Haskell.)
Most of my use falls into one of these categories.
Based on what scant studies have been done, 1 misclassified message per 25K is indeeded significantly better than a human being. It is also dramatically better than any spam filter evaluation I've ever believed has reported.
My rule of thumb, after doing a bunch of this stuff, is that you can achieve about 0.5% total error rates for a straight ham/spam machine-learning filter, with 0.05% false positives. I'd really have to be convinced that there's ML tech out there that does better than that on real mail streams today. Most of the existing evaluations are atrociously bad, to the point of being meaningless.
When blinking text was made part of HTML in the 90s, it was universally despised by users and competent webmasters alike. It's distracting, annoying, and can even be dangerous to those prone to epilepsy. Eventually, for the most part browsers quit supporting it, webmasters quit using it, and users quit visiting sites where it appeared.
As far as I'm concerned, the fact that the Server Beach ad is a blinking flash animation doesn't make it substantially different. I'm getting it again as I type this, and finding it just as annoying as obnoxious as I did the first time. Professional web advertisers and site admins should know better.
It's mostly a metric of multiplication speed. There are lots of times you need to do a lot of large multiplications in a fraction of a second.
That said, my students were recently working on an ICPC problem in which they needed to find the last non-zero digit of large factorials. "How will we check our solutions?" they asked. Heh...
As someone who's done some research on machine learning for spam filtering, this sure looks to me from their 8-page paper like yet another simplistic ML algorithm advocated by folks who don't know the field and tested using techniques of questionable sensitivity. Their "novel" method sounds an awful lot like feature set construction by clustering, a method that is widely used in the spam filtering literature, but with a somewhat novel clustering technique from biology.
Message filtering starts by throwing away line breaks for no obvious reason, then optionally removing the known ham from the training set for no obvious reason. Message headers are then thrown away, for no obvious reason.
No general method is given for corpus allocation. In the experiment reported later, the original corpus appears to have been split roughly in half. (For unreported reasons, none of these splits are exact. No rationale is given for the various corpus allocations.) The training corpus is then split into ham and spam, and the ham portion is split in half. The spam training corpus is used for "positive training": determining a complex feature set as described below. One half of the ham training corpus is then used for "negative training": filtering out complex features that are common in ham. The remainder of the ham corpus is used as a validation set to select thresholds described below. No justification is given as to the failure of the validation set to include spam messages, and the procedure is vague on this point.
The description of the key "positive training" phase is difficult to follow: it seems to assume the pre-existence of the "SPAM vocabulary" [sic] being constructed. The key idea seems to
be to use positional index of words within the body as base features, and construct complex features by using a pattern recognition algorithm to find correspondences between sets of base features across spam messages. Patterns that appear across many spam messages are treated as indicating spam.
The final training step is to set thresholds for (1) minimum number of complex features in the spam message and (2) fraction of the message text covered by the complex features. One would expect these two criteria to be highly correlated: no effort appears to have been made to enforce or explore their orthogonality.
The classification phase proceeds by simply counting the number of patterns in a given test message and the percent coverage of the message by the patterns. If the result exceeds both thresholds, the message is classified as spam.
For the empirical evaluation, the corpus used seems to have consisted of approximately 130,000 messages, roughly 1/4 ham and 3/4 spam. No details of the construction or acquisition of this large corpus were given. Because of its volume, one would suspect a synthetic corpus from high volume sources. The details of this corpus construction are critical to the evaluation of the method, so no useful conclusions can really be drawn from the empirical evaluation other than that, like most machine learning methods, this method works well on some problem set.
The claimed accuracies from the technique are at a level that is highly suspect from previous experience: there are fundamental bounds on how well any ML algorithm can do in real situations that don't appear to be met here. Indeed, messages found to be misclassified as spam in the test corpus were manually reclassified, but no effort seems to have been made to identify messages that were "correctly" classified by the algorithm but misclassified in the corpus. The error rate before manual manipulation of the results (!) appears to be about 97%, which is well within the normal expected range. Computational efficiency appears to be good.
The vocabulary used in the paper is not particularly consistent with the vocabulary normally used in the spam filtering or machine learning literature. A few spam filtering and machine learning papers are cited, but not many: citations are primarily from the
Note that Nickle will quite happily compute 10,000! (exactly) in a fraction of a second on a similar machine, through the miracle of Karatsuba multiplies. It also supports arbitrary-precision rationals and definable-precision floats (default 256b mantissa) with arbitrary exponent, and features a calculator-like interactive mode. I don't use much of anything else for numeric calculations anymore. (Of course, I co-wrote it.)
The fact that you believe that public defenders might be, as a class, passionate and competent means that you have had insufficient contact with your local (assuming US) criminal justice system. Go find someone who is a criminal lawyer, police officer, or judge who sees the courtroom on a regular basis. Ask them what the public defenders are like. Go look at the track record of PDs compared to private attorneys---counting a plea bargain as a conviction (because it is). Then check back here and let us know what you found out.
IMHO this is the natural consequence of (a) massively underfunding the PDs, and (b) not giving defendants any power in the selection of their PD.
If you ever are a criminal defendant, I strongly urge you to pay for private counsel, by any means necessary.
I have a doctorate in AI from a world class research lab, work as a University professor, and have published papers in machine learning, general-purpose planning, and combinatorial search applications. I also help my students build intelligent vehicles, namely medium-altitude autonomous sounding rockets.
Intelligence is on a continuum, and the core concept of IQ (i.e., intellectual ability in one area correlating with ability in others) doesn't seem to apply to animals or machines the way it does to people. The "retarded cockroach" quote earlier on would be more convincing if someone could show me a chess-playing cockroach, or for that matter a 30-kyu go-playing cockroach. By contrast, AI control systems don't seem to let modern robots move with the agility and skill of a cockroach (although we've made a lot of progress in the past 20 years). Go figure.
In the area of autonomous exploration, which is, after all, the topic here, there have been both successes and failures. A notable recent failure was the autonomous vehicle "race" covered in/; the CMU Dante bot has had some limited success in hostile-environment exploration.
An important thing to keep in mind is that the desired artifact here is a system, albeit a software-intensive one. It is customary to solve many of the problems in such a system with a combination of much brute force and little intelligence: expect to see proposals for highly-robust vehicle with limited "intelligent" guidance.
I think the view that AI = machine learning is shortsighted. I think that the NASA CFP is forward-looking, but not obviously infeasible. I also have a physics degree, but I'd certainly rather try to build one of these rovers than a space elevator!
Slashdot Mirror
Dave Reed did an extensive Croquet demo at the Freenix Track of the Usenix ATC this year. Seemed really cool, but at the time was too buggy to be usable. Basically, Croquet lets you put all kinds of interesting workspaces in a collaborative 3D virtual world: sort of the logical completion of the virtual world description languages that were popular some years ago. Must be a Smalltalk guru to play, it looks like. Has a fancy synchronization protocol that takes care of most lag issues.
Let's hope that the bugs are sufficiently out that we can have big fun with this. I'm looking forward to trying it.
I have equipment with absurdly overkill Super-Bright LEDs in it too. The two solutions I have used are to put multiple layers of masking tape over the LED colored with a dark felt marker, or to put black electrical tape over the LED and put a pinhole in it. Either one will let you still monitor the LED without blinding yourself. Sigh.
The Condorcet website says " It [Condorcet] allows voters to vote for the candidate they agree with most rather than against the major-party candidate they disagree with most. In other words, it eliminates the need for defensive or strategic voting." Unfortunately, this is wrong, and demonstrates a lack of understanding on someone's part.
Nobel prizewinning economist Kenneth Arrow proved a neat little theorem in the 1950s. He showed that, under some very minimal and reasonable requirements for what a voting system is supposed to do, any voting system will sometimes require strategic voting in a 3 (or more) candidate election.
Almost no one seriously involved in quantum computing and/or cryptography believes that shared-secret encryption will be threatened by a working quantum computer. There is currently no known quantum-computing algorithm that will crack (e.g.) AES any faster than conventional computing, and there are good theoretical reasons to believe no such algorithm exists.
Public-key crypto, at least that based on factoring, is out the window: this will be a major pain, but really will just put us back where we were before RSA, not that long ago.
IANAL, but from a common-sense legal point of view this is nonsense. Basic contract law says that two parties can negotiate an enforceable contract to do anything that is not illegal. "Not transmitting from my residence in the 802.11 band" is surely a legal activity: therefore I should be able to agree to do it in return for, e.g., housing or an education. I liked the analogy of an earlier poster, who likened this to prohibiting hot plates in your dorm room. Is this somehow not OK because the UL has certified the hot plate as a legal device?
It's hard to identify any constitutional right that this contract would abrogate. People sign contracts that require them to restrict their speech (presumably the relevant clause) all the time. I don't think the FCC can or wants to prevent folks from doing this.
IMHO (again, IANAL) the University in question needs to spend some serious time with quality legal counsel.
Thanks for the windows advice! Sure enough, I'm running XP on AMD/VIA. Tends to make me a "Linux bigot" rather than an "Intel bigot" :-), but your point is well taken.
The box is my wife's, and she runs all kinds of my kids' games on it, commercial and from Yahoo. No viruses or spyware that I can find, and it runs behind a firewall. It could be the games themselves that are at fault. Your reference to blackviper.com is quite welcome: I'll meditate more on the material there.
Thanks again.
If X crashes (locks up, etc) often for you, you should get some help with it. I run X on a variety of random hardware, and I've found it to be darn reliable. Often, upgrading your server or paying attention to its (hideous) configuration can solve your problems: contact an X guru e.g. on the freedesktop.org IRC.
Advice on what to do about my frequent XP crashes would be highly appreciated :-).
The reason you use QC atop traditional crypto is that you don't want to make your ciphertext available for offline attack. With a traditional channel, I can passively eavesdrop on the line. I can then crack the crypto, do traffic analysis, etc. at my leisure. With a QC, once I've authenticated the endpoints using traditional crypto, I am confident that my ciphertext of the entire session is secure.
This is not a trivial advantage of the QC approach. Imagine that the Germans had QCs during WWII. We'd probably still not have any of their traffic, even though Enigma was broken during the war: we couldn't crack it in anything like realtime AFAIK. Imagine again that the WWII Japanese traffic to Midway was protected by a QC. No traffic analysis = no battle plan. QC protects your ciphertext in a way that other methods simply do not.
Right. (Why did you post AC?) The traditional method of using a quantum channel is to exchange authentication data OOB as part of the setup process (the channel has to be physically set up anyway :-). You then can do either public-key or secret-key tradtional crypto stuff at connection setup time to generate a crypto-secure random sequence for the polarization bits. If you somehow have managed to set up a quantum channel with someone with absolutely no out-of-band data, or if you don't trust traditional crypto at all, QC doesn't really help you against an MIM attack.
AFAIK (I am not a quantum cryptographer by trade, but I have degrees in physics and computer science), a quantum channel is secure against MIM attacks. You can make the probability that you are talking to an endpoint with the shared secret arbitrarily close to 1 by exchanging a series of authentication bits. (Or are you referring to the fact that you may leak a few bits before the MIM is caught? I think conventional crypto and unicity distance makes this not an effective attack in practice.)
This is why you need a full mesh to provide a secure network. This is indeed unrealistic for applications with very many nodes involved, limiting the use of quantum channels.
They're still really cool, though.
No, I actually did mean "perfectly secure" against physical eavesdropping. The laws of quantum physics are odd; they guarantee (with probability arbitrarily close to 1) that if you try to listen to the message in transit, you'll wreck it. The Patriot Act may let the eavesdropper mess with the endpoints of the channel, but the channel itself is secure against everything but attacks on the fundamental laws of nature :-).
This might be the end of the hacked by Chinese index pages!
Uh, no. Quantum communication is not magic. (OK, maybe, but not that kind of magic.) What it is, is perfectly secure against physical eavesdropping. An attacker can't "tap the wire", as it were. The name "quantum encryption" is something of a misnomer, though: this technology is just a communication channel, albeit an uber-cool one.
Keep in mind that the servers shipped running Linux may be a miniscule fraction of the total Linux servers deployed or being deployed at this point. Presumably one reason for the relative growth of Linux preloads vs Windows preloads will be more competitive prices of Linux preloads and a decline in Windows unloads.
(BTW, when you directly quote an article, it is a good idea to use quotation marks. Otherwise people might think the text was yours.)
Isn't there one of those science discovery betting pools that has "cold fusion" as one of the things to bet on? I desperately want to bet against it, at whatever odds they'll give me. Easy money at 100000:1. Looks like gullible /.-ers alone would put the book at more like 10:1 though, meaning that if it had a two-year window it would be a 5% investment even if I had to put the money in escrow up front. Heck, if it weren't illegal in the US, I would make book on it myself. Advantages of a physics degree and a wide reading list, dontcha know.
Yes, even the discovery of an algorithm doesn't imply that it has an easy implementation. But I know of no realistic polytime examples where the provably best worst-case running time is worse than cubic, or where the algorithm commonly used is dramatically worse in practice than the best algorithm because no one can implement the good one.
The obvious example is LP, where everyone used Simplex for a long time because Kachian's method is such a pain to implement and has lousy constants. However, Simplex was used precisely because its expected running time in practice is small, whereas in practice naive Kachian's tends to achieve its worst-case bound. When improvements on Kachian's method made it more efficient for very large problems, a lot of folks implemented it and switched. You'll see both kinds out there now.
You can implement priority queues in a fairly complicated way to get insertion to be O(1): this constitutes a fairly dramatic improvement over O(log n) to some ways of thinking :-). When I ran into a situation where it mattered, I spent a long time doing this. You do what you've got to do.
Of course, you might correctly point out that the proof that P=NP might be non-constructive, in the sense that it might not come with an algorithm. But wait... Of course, this still doesn't give you a feasible answer.
Funny world.
It is considered likely by many that a polytime algorithm for deciding instances of NP-complete problems would also provide efficient keyspace search for cryptanalysis. This is a consequence of the "polytime thesis" (sorry about the crufty link, but I didn't spot anything better offhand: look way down near the end), which states that any real-world problem that has a polytime algorithm has a feasible algorithm. Note that this is both fuzzy and a thesis rather than a theorem, but I am not aware of any counter-examples. So, based on empirical evidence of past discoveries, we might well expect that if we can find a polytime algorithm for keyspace search, we can also find a feasible algorithm.
Consider the problem of deciding whether a number is prime. This problem was recently shown to be in P, but the algorithm given requires around |n|**12 steps in practice. Obviously, this is still not a feasible algorithm. Proponents of the polytime thesis, however, are not concerned: they believe that a low-order polytime algorithm will soon be found. I tend to agree with them.
Part of the problem is that Nickle has evolved over 20 years from being a bc-like thing to being a language that you really can answer "yes" to for everything in your next-to-the-last paragraph. :-)
Common use cases for Nickle:
- Calculate in a reasonable calculator language featuring arbitrary precision rationals, settable high-precision floats, and nice calculational features. (Competes with e.g. bc, expr.)
- Prototype some tricky functions in a PL that looks a lot like C but with no limits, GC, a nice subtyping system, and an interactive environment. When the code works, translate easily to C for performance and integration. (Competes with e.g. Scheme, Matlab.)
- Script in situations requiring real datatypes and advanced algorithms with clean syntax and semantics. (Competes with e.g. Python, Perl.)
- Learn about advanced programming features and techniques like continuations and threads in a friendly, rich interactive environment. (Competes with e.g. Scheme, ML, Haskell.)
Most of my use falls into one of these categories.Based on what scant studies have been done, 1 misclassified message per 25K is indeeded significantly better than a human being. It is also dramatically better than any spam filter evaluation I've ever believed has reported.
My rule of thumb, after doing a bunch of this stuff, is that you can achieve about 0.5% total error rates for a straight ham/spam machine-learning filter, with 0.05% false positives. I'd really have to be convinced that there's ML tech out there that does better than that on real mail streams today. Most of the existing evaluations are atrociously bad, to the point of being meaningless.
When blinking text was made part of HTML in the 90s, it was universally despised by users and competent webmasters alike. It's distracting, annoying, and can even be dangerous to those prone to epilepsy. Eventually, for the most part browsers quit supporting it, webmasters quit using it, and users quit visiting sites where it appeared.
As far as I'm concerned, the fact that the Server Beach ad is a blinking flash animation doesn't make it substantially different. I'm getting it again as I type this, and finding it just as annoying as obnoxious as I did the first time. Professional web advertisers and site admins should know better.
It's mostly a metric of multiplication speed. There are lots of times you need to do a lot of large multiplications in a fraction of a second.
That said, my students were recently working on an ICPC problem in which they needed to find the last non-zero digit of large factorials. "How will we check our solutions?" they asked. Heh...
As someone who's done some research on machine learning for spam filtering, this sure looks to me from their 8-page paper like yet another simplistic ML algorithm advocated by folks who don't know the field and tested using techniques of questionable sensitivity. Their "novel" method sounds an awful lot like feature set construction by clustering, a method that is widely used in the spam filtering literature, but with a somewhat novel clustering technique from biology.
Message filtering starts by throwing away line breaks for no obvious reason, then optionally removing the known ham from the training set for no obvious reason. Message headers are then thrown away, for no obvious reason.
No general method is given for corpus allocation. In the experiment reported later, the original corpus appears to have been split roughly in half. (For unreported reasons, none of these splits are exact. No rationale is given for the various corpus allocations.) The training corpus is then split into ham and spam, and the ham portion is split in half. The spam training corpus is used for "positive training": determining a complex feature set as described below. One half of the ham training corpus is then used for "negative training": filtering out complex features that are common in ham. The remainder of the ham corpus is used as a validation set to select thresholds described below. No justification is given as to the failure of the validation set to include spam messages, and the procedure is vague on this point.
The description of the key "positive training" phase is difficult to follow: it seems to assume the pre-existence of the "SPAM vocabulary" [sic] being constructed. The key idea seems to be to use positional index of words within the body as base features, and construct complex features by using a pattern recognition algorithm to find correspondences between sets of base features across spam messages. Patterns that appear across many spam messages are treated as indicating spam.
The final training step is to set thresholds for (1) minimum number of complex features in the spam message and (2) fraction of the message text covered by the complex features. One would expect these two criteria to be highly correlated: no effort appears to have been made to enforce or explore their orthogonality.
The classification phase proceeds by simply counting the number of patterns in a given test message and the percent coverage of the message by the patterns. If the result exceeds both thresholds, the message is classified as spam.
For the empirical evaluation, the corpus used seems to have consisted of approximately 130,000 messages, roughly 1/4 ham and 3/4 spam. No details of the construction or acquisition of this large corpus were given. Because of its volume, one would suspect a synthetic corpus from high volume sources. The details of this corpus construction are critical to the evaluation of the method, so no useful conclusions can really be drawn from the empirical evaluation other than that, like most machine learning methods, this method works well on some problem set.
The claimed accuracies from the technique are at a level that is highly suspect from previous experience: there are fundamental bounds on how well any ML algorithm can do in real situations that don't appear to be met here. Indeed, messages found to be misclassified as spam in the test corpus were manually reclassified, but no effort seems to have been made to identify messages that were "correctly" classified by the algorithm but misclassified in the corpus. The error rate before manual manipulation of the results (!) appears to be about 97%, which is well within the normal expected range. Computational efficiency appears to be good.
The vocabulary used in the paper is not particularly consistent with the vocabulary normally used in the spam filtering or machine learning literature. A few spam filtering and machine learning papers are cited, but not many: citations are primarily from the
Note that Nickle will quite happily compute 10,000! (exactly) in a fraction of a second on a similar machine, through the miracle of Karatsuba multiplies. It also supports arbitrary-precision rationals and definable-precision floats (default 256b mantissa) with arbitrary exponent, and features a calculator-like interactive mode. I don't use much of anything else for numeric calculations anymore. (Of course, I co-wrote it.)
(Yeah, yeah: -1 OT. Big deal.)
The fact that you believe that public defenders might be, as a class, passionate and competent means that you have had insufficient contact with your local (assuming US) criminal justice system. Go find someone who is a criminal lawyer, police officer, or judge who sees the courtroom on a regular basis. Ask them what the public defenders are like. Go look at the track record of PDs compared to private attorneys---counting a plea bargain as a conviction (because it is). Then check back here and let us know what you found out.
IMHO this is the natural consequence of (a) massively underfunding the PDs, and (b) not giving defendants any power in the selection of their PD.
If you ever are a criminal defendant, I strongly urge you to pay for private counsel, by any means necessary.
Just think of the logistics in doing the same thing for a crashed plane. The "building" is 2,000 miles out at sea (and 300m under).
When my US domestic flight is 2,000 miles out at sea, something has already gone horribly, horribly wrong.
I have a doctorate in AI from a world class research lab, work as a University professor, and have published papers in machine learning, general-purpose planning, and combinatorial search applications. I also help my students build intelligent vehicles, namely medium-altitude autonomous sounding rockets.
Intelligence is on a continuum, and the core concept of IQ (i.e., intellectual ability in one area correlating with ability in others) doesn't seem to apply to animals or machines the way it does to people. The "retarded cockroach" quote earlier on would be more convincing if someone could show me a chess-playing cockroach, or for that matter a 30-kyu go-playing cockroach. By contrast, AI control systems don't seem to let modern robots move with the agility and skill of a cockroach (although we've made a lot of progress in the past 20 years). Go figure.
In the area of autonomous exploration, which is, after all, the topic here, there have been both successes and failures. A notable recent failure was the autonomous vehicle "race" covered in /; the CMU Dante bot has had some limited success in hostile-environment exploration.
An important thing to keep in mind is that the desired artifact here is a system, albeit a software-intensive one. It is customary to solve many of the problems in such a system with a combination of much brute force and little intelligence: expect to see proposals for highly-robust vehicle with limited "intelligent" guidance.
I think the view that AI = machine learning is shortsighted. I think that the NASA CFP is forward-looking, but not obviously infeasible. I also have a physics degree, but I'd certainly rather try to build one of these rovers than a space elevator!