Re:Magnusson Moss Warranty Act
on
Hack Your Car
·
· Score: 1
So you can get more horses if you sacrifice efficiency. Note also, the Dodge viper and the Dodge RAM shared versions of the same V12 engine. One tuned for high horses, other tuned for high torque.
I have one of each.
They are both 488 cubic inch V10's. The truck engine is mostly a "Gen I" V10, which refers to the Viper Gen I engines (1992-1996), but with a very different (and inefficient) intake manifold. My Viper is a 2001, so it's a Gen II engine (1996-2002). The new Viper SRT-10 has the Gen III engine. The truck version is an iron block, whereas the car engines are aluminum blocks. The Gen I/II/III engines are all very similar to each other.
It is incorrect to state that the truck engine is tuned differently for torque. They are both very high torque, low RPM engines. My Viper currently makes about 525 HP / 550 TQ. It has open exhaust (it's mainly a track car) and a mixture controller. My truck makes about 410 HP / 450 TQ (stock except for the same mixture controller) -- very close to the power numbers for a Gen I Viper.
You will not be wearing out your car with the modifications these controllers allow. You are just adjusting variables that the OEMs already have there.
While it's true that you're just changing parameters (to me, this isn't hacking unless you also consider changing channels on your TV "hacking"), you can very easily damage or destroy your engine. For example, if you lean things out too much, you'll burn valves. I've seen it. You can also do things like run it so rich that you burn up O2 sensors or cats. While that isn't catastropic damage, you're still "wearing out" parts.
Sucks up their time and money sorting that stuff out.
No, actually it doesn't. When I was a kid, I worked for a company which did direct-mail advertising. (I dislike it too, but I was 17 and hadn't really received junk mail in my name yet, and this was back when "online" meant a 300 baud connection to CompuServ and spam e-mail was just a glimmer in some evil asshole's eye.)
Anyway, we had people who hated direct mail, and they waste their time doing all sorts of "clever" things, and frankly, it was only noticed by the office staff when somebody did something exceedingly disgusting, strange, or illegal.
You'd waste more of their time by trying to come up with something *creative*. Shit, why not make it fun for the poor asshole opening your envelope? They're working for minimum wage hand-keying response cards; they sure as hell aren't making the big bucks off annual subscriptions or whatever.
In any case, when you send a million direct-mail pieces, you fully expect to get a bunch of junk back (the other stupid one is putting metal washers in the return mail... the postage is PRE-PAID, you won't cost them a single cent in extra charges), and you have hordes of low-paid drones to sort that stuff for you.
*shrug* What else can I say? I wish it worked, too.
The answer is, having them at home is very good. I have Space Duel, Asteroids, a Star Wars excluding the original cabinet. All work except the Space Duel monitor vsync is slowly dying (and sadly, nobody makes vector monitors any more).
My XBOX and many PC's are just fine, but many of those games are just as much fun as they were in the arcades. I'd kill for a real Joust machine. (Yes, I know I can run MAME in a cabinet, but screw that.)
The slashdot article title is very poorly chosen. A game can be extremely logical and yet have absolutely nothing to do with realism. Tic-tac-toe is a great example. The rules are simple, very consistent, and very logical decisions can be made within the framework of the game, but it doesn't have anything to do with reality. And unfortunately for the article submitter, the original author is speaking solely about realism in the context of online role playing games.
So the answer to the slashdot article would appear to be, simply, "No." An illogical game would only be frustrating, but a logical game not based on reality can be fun (Qix is my favorite example). Probably, however, it would have to be fairly simple (again, like Qix) otherwise the player would probably lose interest before the non-reality-based rules were understood well enough to simply play for enjoyment.
Playing devil's advocate here, but who says that the writer has to delineate the rules to the reader/watcher/player?
I don't think he's saying you HAVE TO, I think his point was, that's generally how successful storytelling works -- and for a reason. Pare it down to the basic elements -- setup, execution, closure. This follows well if you see a game as basically an interactive kind of storytelling. That is probably generally true, even though it's easy to cite exceptions (the old arcade game Qix is a good example -- completely abstract).
The problem with that approach is that you're wasting a LOT -- probably MOST of your payload capacity on redundant systems. Each little bot is going to need it's own comm equipment, power supplies, drive system, and so on. I don't think we can build things small enough with a sufficiently reasonable expectation of survival to seriously consider that approach.
Actually, Dali would tip his chair against a wall and hold a key in his hand. He placed a cookie sheet or pie pan under his chair. When he dozed off, he'd drop the key in the pan and the noise would awaken him.
My wife just bought some book he wrote in which he describes this rather odd technique.
Now you're doing it. "parsecmdlinE"? Don't be silly.
As for the other questions, yeah, it's fine by me. Because I'll go see what "parsecmdline" actually IS, rather than guessing based on how they typed it.
I am not in opposition to standards. I am opposed to the base language forcing case-based standards.
It isn't at all like driving. The rule you cite is a safety issue and is completely irrelevant. It's more like putting the steering wheel on the left or right side of the car. If production cost wasn't an issue, it would probably be an option.
I find it a bit ironic that you failed to capitalize the word "unparsable" in your sentence. A distinct violation of the well-established capitalization rules of the English language. Thankfully, I was still able to parse your meaning.
If you program for yourself and really want to use your own conventions then you are on your own, don't ask the entire world to forget their standards so you can write unparsable code.
That's a circular argument. If it wasn't case sensitive, it wouldn't be unparsable.
So which is better? Code that will compile fine because I accidentally typed For(i=0;i or the miraculous gift of consistency and readability that is for(i=0;i? (I can make ridiculous arguments, too.)
I really hate point-by-point arguments, but I guess I brought it upon myself.:) So, here we go...
1. History -- Argument: Lots of languages are case sensitive, and people seem to be capable of dealing with it, so this is a non-issue. Response: The problem is, of course, that this response completely avoids making a point relevant to the argument. Rebuttal: If people are really good at dealing with it, then that makes a pretty strong point that this is a non-issue. Why should we waste a lot of time and effort fixing a non-issue?
First of all, it wouldn't require a lot of time and effort to "fix" this. The question isn't whether anyone can deal with case-sensitivity, it's the fact that a lot of people simply don't like it.
2a. Readability -- Argument: Forcing people to type "if" instead of "IF", "If" or god forbid, "iF" will enhance readability. Response: I personally feel that all-lowercase individual words are a lot easier to read than leading capitals or all-uppercase, but this is only a solution for the predefined keywords of a language, and really fails to address the question of case *sensitivity* to case in programmer-defined names. Rebuttal: You admit that you feel all-lowercase keywords are easier to read. So do I. So does almost everybody else. Let's enforce 'em. What benefit is there to some people deciding to write "IF A=B THEN..." and other people deciding to write "if a=b then..." other than making everything difficult to read?
I have friends who prefer all caps. They find all lowercase difficult to read. Their preference is equally valid. I don't feel the need to impose my preference on anyone else, I prefer to let the user make a choice.
2b. Readability -- Argument: If I define myCleverMethod, I don't want to debug code littered with MYcleVERMetHOD. Response: Somebody inevitably posts some variation on this, and I can't imagine why they bother. What kind of idiot would bother with such screwy capitalization? Rebuttal: It's not just MYcleVERMetHOD we're worried about. We're also worried about myclevermethod and MYCLEVERMETHOD which, at first glance, do not even look remotely related to one another but are in fact the same thing in a case-insensitive language. And people will very much decide to type it in all-lowercase or all-uppercase, because if they intended to type it in the "correct" case, they wouldn't be arguing for case-insensitivity.
I understand the argument you're making. First of all, the reason I listed the poorly-mixed-case argument is because people DO make that specific argument, without any intention of referring to the more reasonable case you present. Speaking more specifically to your example, in just about every other area of programming, it is recognized as extremely bad form to use a single element for multiple things. I see this most commonly in databases (e.g. flag columns where the range of values span several unrelated sets of meaning). Differentiating an entire word or phrase only by case is just another example of this.
3. Flexibility -- Argument: Case sensitivity allows you to use the same multi-word phrase for two unrelated things when they both happen to require the same spelling. Response: I actually had somebody use the examples CarPass and CarpAss to illustrate the flexibility of case sensitivity (on the pre-release C# mailing list at Don Box's develop.com). To date I have not seen an example of this which is even remotely defensible. Elsewhere in this/. discussion someone posted SetsLow and SetSlow, which sounds slightly more realistic, but it's still reaching. Somebody show me one where the "obvious" names are significantly better than simply choosing an alternative. Rebuttal: Fine. User user = new User(); is better than User theUser = new User();
My response for the preceding item applies here, as well. Simply put, it isn't good practice to duplicate the class name in the instance variable. The entire concept behind defining a Class is that i
Having fought this war several times before (I agree that case sensitivity is an unnecessary pain in the ass), and I believe I can sum up most of the likely responses in one big post.
1. History -- Argument: Lots of languages are case sensitive, and people seem to be capable of dealing with it, so this is a non-issue. Response: The problem is, of course, that this response completely avoids making a point relevant to the argument.
2a. Readability -- Argument: Forcing people to type "if" instead of "IF", "If" or god forbid, "iF" will enhance readability. Response: I personally feel that all-lowercase individual words are a lot easier to read than leading capitals or all-uppercase, but this is only a solution for the predefined keywords of a language, and really fails to address the question of case *sensitivity* to case in programmer-defined names.
2b. Readability -- Argument: If I define myCleverMethod, I don't want to debug code littered with MYcleVERMetHOD. Response: Somebody inevitably posts some variation on this, and I can't imagine why they bother. What kind of idiot would bother with such screwy capitalization?
3. Flexibility -- Argument: Case sensitivity allows you to use the same multi-word phrase for two unrelated things when they both happen to require the same spelling. Response: I actually had somebody use the examples CarPass and CarpAss to illustrate the flexibility of case sensitivity (on the pre-release C# mailing list at Don Box's develop.com). To date I have not seen an example of this which is even remotely defensible. Elsewhere in this/. discussion someone posted SetsLow and SetSlow, which sounds slightly more realistic, but it's still reaching. Somebody show me one where the "obvious" names are significantly better than simply choosing an alternative.
4a. Parsing -- Argument: The main reason case sensitivity exists is because uppercase and lowercase letters really are different things to a computer. Response: This mattered a lot in the old days of computing (which also yielded the terseness we see in languages like C). The machine on my desktop has a 3GHz CPU and 1GB of RAM. It can compile tens of thousands of lines of code in a matter of seconds. Although it can probably be argued that non-ASCII platforms would have a harder time performing this conversion, I'd also point out that databases and other applications in those same environments perform case conversions quite easily on those same platforms. I do not consider this a valid argument.
4b. Parsing -- Response: The standard parsing argument could be extended in equally ridiculous directions. With the considerable power of modern desktop computers, we can do all sorts of things with text. Why not treat red, blue, and boldface text as separate characters, too?
5. Mathematics -- Argument: Mathematicians regularly represent different variables and other elements which are differentiated only by notational case. Response: Due to the incredibly tiny fraction of programmers who are also mathematicians writing mathematical code, I believe this argument is irrelevant. It's probably one of the more interesting arguments, but frankly it's always annoyed me in mathematics, too.:)
6. Constants and Classes -- Argument: Traditionally, many languages define constants using names which are all-uppercase, and more recently classes are often defined using names which are captialized. Response: This one always annoys me. Usually the same person is saying that the capitalization differences assist in the readability of the code moments after they've made the argument that capitalization should be inflexible for the sake of readability! There is nothing about case-insensitivity which would prevent this practice. I do it myself when I use case-insensitive languages. What it would prevent is using the same WORD to mean two different things. If that isn't just begging to introduce readability errors, I can't imagine what is. Nothing about case-insensitivity prevents peopl
That's because no game dev shop has ever been willing to produce a "game" which is so stupendously difficult to learn and play. If I wanted that level of realism, I would have joined the Air Force.
It isn't random at all. A friend of mine has a Q*Bert board (and a load of additional hardware, as Q*Bert had some ridiculously complicated electronics behind its sound system) rigged as his doorbell. The swearing is the same every time.
Maybe whatever they originally sampled (or however it was accomplished) was random, though.
Yup, that's what I did... but GTA isn't the kind of game that, in my mind, warrants such complicated flight controls. The worst kind of in-game challenge is one in which things are hard only because of control or interface problems.
I copied the text below directly from Markus Kuhn in the forum linked in the original article, yes, those same dots are now on US currency:
For those of you curious about how this algorithm detects a banknote, here is a slide of a short talk that I gave to our local research group soon after I discovered the "EURion Constellation" two years ago while experimenting with a new Xerox color photocopier and a 10 euro note:
http://www.cl.cam.ac.uk/~mgk25/eurion.pdf
The algorithm looks in the blue channel of a color image for little circles and most likely examines the distance distribution encountered. I have discovered a small constellation of just five circles (a bit like Orion with the belt starts merged) that will be rejected by a Xerox color photocopier installed next door from here as a banknote. Black on white circles do not work.
These little yellow, green or orange 1 mm large circles have been on European banknotes for many years. I found them on German marks, British pounds and the euro notes. In the US, they showed up only very recently on the new 20$ bill. On some notes like the euro, the circles are blatantly obvious, whereas on others the artists carefully integrated them into their design. On the 20 pound note, they appear as "notes" in an unlikely short music score, in the old German 50 mark note, they are neatly embedded into the background pattern, and in the new 20 dollar bill, they are used as the 0 of all the yellow 20 number printed across the note. The constellation are probably detected by the fact that the squares of the distances of the circles are integer multiples of the smallest one.
I have later been told that this scheme was invented by Omron and that the circle patter also encodes the issuing bank.
Slashdot Mirror
I have one of each.
They are both 488 cubic inch V10's. The truck engine is mostly a "Gen I" V10, which refers to the Viper Gen I engines (1992-1996), but with a very different (and inefficient) intake manifold. My Viper is a 2001, so it's a Gen II engine (1996-2002). The new Viper SRT-10 has the Gen III engine. The truck version is an iron block, whereas the car engines are aluminum blocks. The Gen I/II/III engines are all very similar to each other.
It is incorrect to state that the truck engine is tuned differently for torque. They are both very high torque, low RPM engines. My Viper currently makes about 525 HP / 550 TQ. It has open exhaust (it's mainly a track car) and a mixture controller. My truck makes about 410 HP / 450 TQ (stock except for the same mixture controller) -- very close to the power numbers for a Gen I Viper.
You will not be wearing out your car with the modifications these controllers allow. You are just adjusting variables that the OEMs already have there.
While it's true that you're just changing parameters (to me, this isn't hacking unless you also consider changing channels on your TV "hacking"), you can very easily damage or destroy your engine. For example, if you lean things out too much, you'll burn valves. I've seen it. You can also do things like run it so rich that you burn up O2 sensors or cats. While that isn't catastropic damage, you're still "wearing out" parts.
It's actually to prevent that KB article from being indexed under "SERVPACK". But thanks for trolling.
Is there any subject in existance where the Male Ego doesn't apply?
Most people are sheep.
Another insightful comment unfairly modded down by fanatics...
Yes. Arrange things so that you pass by your outdoor trash cans on the way back from the mailbox. :)
No, actually it doesn't. When I was a kid, I worked for a company which did direct-mail advertising. (I dislike it too, but I was 17 and hadn't really received junk mail in my name yet, and this was back when "online" meant a 300 baud connection to CompuServ and spam e-mail was just a glimmer in some evil asshole's eye.)
Anyway, we had people who hated direct mail, and they waste their time doing all sorts of "clever" things, and frankly, it was only noticed by the office staff when somebody did something exceedingly disgusting, strange, or illegal.
You'd waste more of their time by trying to come up with something *creative*. Shit, why not make it fun for the poor asshole opening your envelope? They're working for minimum wage hand-keying response cards; they sure as hell aren't making the big bucks off annual subscriptions or whatever.
In any case, when you send a million direct-mail pieces, you fully expect to get a bunch of junk back (the other stupid one is putting metal washers in the return mail... the postage is PRE-PAID, you won't cost them a single cent in extra charges), and you have hordes of low-paid drones to sort that stuff for you.
*shrug* What else can I say? I wish it worked, too.
My XBOX and many PC's are just fine, but many of those games are just as much fun as they were in the arcades. I'd kill for a real Joust machine. (Yes, I know I can run MAME in a cabinet, but screw that.)
So the answer to the slashdot article would appear to be, simply, "No." An illogical game would only be frustrating, but a logical game not based on reality can be fun (Qix is my favorite example). Probably, however, it would have to be fairly simple (again, like Qix) otherwise the player would probably lose interest before the non-reality-based rules were understood well enough to simply play for enjoyment.
I don't think he's saying you HAVE TO, I think his point was, that's generally how successful storytelling works -- and for a reason. Pare it down to the basic elements -- setup, execution, closure. This follows well if you see a game as basically an interactive kind of storytelling. That is probably generally true, even though it's easy to cite exceptions (the old arcade game Qix is a good example -- completely abstract).
Frankly I'm surprised anybody on /. would install software they know is written by the government.
The problem with that approach is that you're wasting a LOT -- probably MOST of your payload capacity on redundant systems. Each little bot is going to need it's own comm equipment, power supplies, drive system, and so on. I don't think we can build things small enough with a sufficiently reasonable expectation of survival to seriously consider that approach.
My wife just bought some book he wrote in which he describes this rather odd technique.
As for the other questions, yeah, it's fine by me. Because I'll go see what "parsecmdline" actually IS, rather than guessing based on how they typed it.
I am not in opposition to standards. I am opposed to the base language forcing case-based standards.
It isn't at all like driving. The rule you cite is a safety issue and is completely irrelevant. It's more like putting the steering wheel on the left or right side of the car. If production cost wasn't an issue, it would probably be an option.
You're missing the point. I was talking about the processing overhead related to dealing with case insensitivity.
I find it a bit ironic that you failed to capitalize the word "unparsable" in your sentence. A distinct violation of the well-established capitalization rules of the English language. Thankfully, I was still able to parse your meaning.
That's a circular argument. If it wasn't case sensitive, it wouldn't be unparsable.
So which is better? Code that will compile fine because I accidentally typed For(i=0;i or the miraculous gift of consistency and readability that is for(i=0;i? (I can make ridiculous arguments, too.)
1. History -- Argument: Lots of languages are case sensitive, and people seem to be capable of dealing with it, so this is a non-issue. Response: The problem is, of course, that this response completely avoids making a point relevant to the argument. Rebuttal: If people are really good at dealing with it, then that makes a pretty strong point that this is a non-issue. Why should we waste a lot of time and effort fixing a non-issue?
First of all, it wouldn't require a lot of time and effort to "fix" this. The question isn't whether anyone can deal with case-sensitivity, it's the fact that a lot of people simply don't like it.
2a. Readability -- Argument: Forcing people to type "if" instead of "IF", "If" or god forbid, "iF" will enhance readability. Response: I personally feel that all-lowercase individual words are a lot easier to read than leading capitals or all-uppercase, but this is only a solution for the predefined keywords of a language, and really fails to address the question of case *sensitivity* to case in programmer-defined names. Rebuttal: You admit that you feel all-lowercase keywords are easier to read. So do I. So does almost everybody else. Let's enforce 'em. What benefit is there to some people deciding to write "IF A=B THEN..." and other people deciding to write "if a=b then..." other than making everything difficult to read?
I have friends who prefer all caps. They find all lowercase difficult to read. Their preference is equally valid. I don't feel the need to impose my preference on anyone else, I prefer to let the user make a choice.
2b. Readability -- Argument: If I define myCleverMethod, I don't want to debug code littered with MYcleVERMetHOD. Response: Somebody inevitably posts some variation on this, and I can't imagine why they bother. What kind of idiot would bother with such screwy capitalization? Rebuttal: It's not just MYcleVERMetHOD we're worried about. We're also worried about myclevermethod and MYCLEVERMETHOD which, at first glance, do not even look remotely related to one another but are in fact the same thing in a case-insensitive language. And people will very much decide to type it in all-lowercase or all-uppercase, because if they intended to type it in the "correct" case, they wouldn't be arguing for case-insensitivity.
I understand the argument you're making. First of all, the reason I listed the poorly-mixed-case argument is because people DO make that specific argument, without any intention of referring to the more reasonable case you present. Speaking more specifically to your example, in just about every other area of programming, it is recognized as extremely bad form to use a single element for multiple things. I see this most commonly in databases (e.g. flag columns where the range of values span several unrelated sets of meaning). Differentiating an entire word or phrase only by case is just another example of this.
3. Flexibility -- Argument: Case sensitivity allows you to use the same multi-word phrase for two unrelated things when they both happen to require the same spelling. Response: I actually had somebody use the examples CarPass and CarpAss to illustrate the flexibility of case sensitivity (on the pre-release C# mailing list at Don Box's develop.com). To date I have not seen an example of this which is even remotely defensible. Elsewhere in this /. discussion someone posted SetsLow and SetSlow, which sounds slightly more realistic, but it's still reaching. Somebody show me one where the "obvious" names are significantly better than simply choosing an alternative. Rebuttal: Fine. User user = new User(); is better than User theUser = new User();
My response for the preceding item applies here, as well. Simply put, it isn't good practice to duplicate the class name in the instance variable. The entire concept behind defining a Class is that i
1. History -- Argument: Lots of languages are case sensitive, and people seem to be capable of dealing with it, so this is a non-issue. Response: The problem is, of course, that this response completely avoids making a point relevant to the argument.
2a. Readability -- Argument: Forcing people to type "if" instead of "IF", "If" or god forbid, "iF" will enhance readability. Response: I personally feel that all-lowercase individual words are a lot easier to read than leading capitals or all-uppercase, but this is only a solution for the predefined keywords of a language, and really fails to address the question of case *sensitivity* to case in programmer-defined names.
2b. Readability -- Argument: If I define myCleverMethod, I don't want to debug code littered with MYcleVERMetHOD. Response: Somebody inevitably posts some variation on this, and I can't imagine why they bother. What kind of idiot would bother with such screwy capitalization?
3. Flexibility -- Argument: Case sensitivity allows you to use the same multi-word phrase for two unrelated things when they both happen to require the same spelling. Response: I actually had somebody use the examples CarPass and CarpAss to illustrate the flexibility of case sensitivity (on the pre-release C# mailing list at Don Box's develop.com). To date I have not seen an example of this which is even remotely defensible. Elsewhere in this /. discussion someone posted SetsLow and SetSlow, which sounds slightly more realistic, but it's still reaching. Somebody show me one where the "obvious" names are significantly better than simply choosing an alternative.
4a. Parsing -- Argument: The main reason case sensitivity exists is because uppercase and lowercase letters really are different things to a computer. Response: This mattered a lot in the old days of computing (which also yielded the terseness we see in languages like C). The machine on my desktop has a 3GHz CPU and 1GB of RAM. It can compile tens of thousands of lines of code in a matter of seconds. Although it can probably be argued that non-ASCII platforms would have a harder time performing this conversion, I'd also point out that databases and other applications in those same environments perform case conversions quite easily on those same platforms. I do not consider this a valid argument.
4b. Parsing -- Response: The standard parsing argument could be extended in equally ridiculous directions. With the considerable power of modern desktop computers, we can do all sorts of things with text. Why not treat red, blue, and boldface text as separate characters, too?
5. Mathematics -- Argument: Mathematicians regularly represent different variables and other elements which are differentiated only by notational case. Response: Due to the incredibly tiny fraction of programmers who are also mathematicians writing mathematical code, I believe this argument is irrelevant. It's probably one of the more interesting arguments, but frankly it's always annoyed me in mathematics, too. :)
6. Constants and Classes -- Argument: Traditionally, many languages define constants using names which are all-uppercase, and more recently classes are often defined using names which are captialized. Response: This one always annoys me. Usually the same person is saying that the capitalization differences assist in the readability of the code moments after they've made the argument that capitalization should be inflexible for the sake of readability! There is nothing about case-insensitivity which would prevent this practice. I do it myself when I use case-insensitive languages. What it would prevent is using the same WORD to mean two different things. If that isn't just begging to introduce readability errors, I can't imagine what is. Nothing about case-insensitivity prevents peopl
That's because no game dev shop has ever been willing to produce a "game" which is so stupendously difficult to learn and play. If I wanted that level of realism, I would have joined the Air Force.
Maybe whatever they originally sampled (or however it was accomplished) was random, though.
Yup, that's what I did... but GTA isn't the kind of game that, in my mind, warrants such complicated flight controls. The worst kind of in-game challenge is one in which things are hard only because of control or interface problems.
Amen. GTA has to have the worst set of keyboard flying controls I've ever seen. Even after customizing the hell out of them, they were a pain to use.
Says here the MRO will have 20-30cm resolution...
For those of you curious about how this algorithm detects a banknote, here is a slide of a short talk that I gave to our local research group soon after I discovered the "EURion Constellation" two years ago while experimenting with a new Xerox color photocopier and a 10 euro note:
http://www.cl.cam.ac.uk/~mgk25/eurion.pdf
The algorithm looks in the blue channel of a color image for little circles and most likely examines the distance distribution encountered. I have discovered a small constellation of just five circles (a bit like Orion with the belt starts merged) that will be rejected by a Xerox color photocopier installed next door from here as a banknote. Black on white circles do not work.
These little yellow, green or orange 1 mm large circles have been on European banknotes for many years. I found them on German marks, British pounds and the euro notes. In the US, they showed up only very recently on the new 20$ bill. On some notes like the euro, the circles are blatantly obvious, whereas on others the artists carefully integrated them into their design. On the 20 pound note, they appear as "notes" in an unlikely short music score, in the old German 50 mark note, they are neatly embedded into the background pattern, and in the new 20 dollar bill, they are used as the 0 of all the yellow 20 number printed across the note. The constellation are probably detected by the fact that the squares of the distances of the circles are integer multiples of the smallest one.
I have later been told that this scheme was invented by Omron and that the circle patter also encodes the issuing bank.
So far, your post is the only thing insulting in this entire thread.