This scheme will work for one branch in Lesser Nowhere, Sechwan Province, with a finite and small set of pictures, and a small number of crooks. Once the number of faces increases, the probability of a false positive explodes, roughly as (N 2) (select every two out of N), where N is the size of the pools of pictures + the person being scanned.

The well-known example is the "birthday paradox", in which twenty-three people at a party increases the probability of two of them having the same birthday to fifty-fifty. That particular case was because the actual probability was multiplied by (25 2) = 25! / ((25-2)! * 2!) = 6900 comparisons being made, times 1/365 chances of a hit.

The German federal security service considered using one of my then employer's recognizers for airports to catch terrorists, but ended up facing the problem of accusing grandma of being part of the Bader-Meinhoff gang (;-)) No matter how accurate we were, a few more people in the pool would give us false positives. We'd need roughly an accuracy of 99.9 followed by roughly as many decimal places of 9s as there were powers of ten of people.

--dave

C is a good choice where performance is critical for small or large programs. C++ used like C is comparable.

Perl or Python are good choices for short programs where ease of development and programming practices resilient to buffer-overflow style bugs are more important than performance.

Java is a good choice for large, complex programs where safe and secure programming practices are more important than micro-optimized performance.

See what's missing from that picture? Any role where C++ used with the low-performance safe practices abstractions is a better choice than something else.

No, you lose efficient code. For a simple example, the string abstractions in C++ and Java are much, much less computationally efficient than manipulating a C character array.

Once you're willing to take that hit for the sake of the things the abstractions gain you, Java's bytecode machine is a tiny additional hit versus the far superior design of the language itself.

And anyway, in case you didn't know it there are tools (like gcj) for compiling java straight to native code if that's what you really want. Only that usually isn't what you want because object code portability is damn useful.

Except we're not talking about off-grid systems, we're talking about Tesla's grid-tie application where power is stored from both off-peak grid delivery and adjunct DC systems and then supplements household usage during grid peak pricing.

When living completely off grid, you move most of the high-wattage equipment to propane. No electric stove or hot water heater. And you use an ammonia-cycle refrigerator. But that always will be a niche market, even if Tesla's dream comes true.

That's what C is for -- situations where low overhead is important. You retain that feature when you use C++ as if it was C but lose it when you employ Java-like abstractions instead.

The common buck converter circuit that reduces 12VDC to 5 VDC is as inefficient if not more inefficient than the common transform/rectify/smooth wall wart that drops 120VAC to 5 VDC. That's another problem with running a low voltage DC circuit through the house: whatever voltage we standardized on, every dang thing you plugged in to it will still need buck/boost circuits that are no better than the AC to DC circuits we're using now.

And it probably would be 12 volts (actually, 13.6). There's too much obvious value in matching what car electronics run on.

Seems premature to me. An awful lot of things have to work out just right for whole-home battery systems to make much sense.

Even then low-voltage DC plants don't make much sense. Your microwave oven consumes 1100+ watts. Know what amperage that is at 5 volts DC? You'd barely be able to wrap your hand around the power cord.

Even at 48 volts DC, the power plant in a telephone company central office is really something to behold.

Also, AC/DC conversion isn't as dire as stated. Sloppy cheap converters do indeed operate at around 75% effeciency with the remaining 25% lost as heat. But look at the "80+" computer power supply standards. The "80+ platinum" standard requires 95% efficiency. Those power cost twice as much but "pure science" does not prevent their operation. They work as promised.

Russia would like for us to continue gifting them with cash for 40-year-old missle motors, it's our own government that doesn't want them any longer. For good reason. That did not cause SpaceX to enter the competitive process, they want the U.S. military as a customer. But it probably did make it go faster.

Also, ULA is flying 1960 technology, stuff that Mercury astronauts used, and only recently came up with concept drawings for something new due to competitive pressure from SpaceX. So, I am sure that folks within the Air Force wished for a better vendor but had no choice.

That's a bit of a problem, because when you program in C++ the same way you'd program in Java, you lose the efficiency and simplicity of C without gaining the clean design of Java. Java is superior to C++ in almost every reasonable use of C++ *except* the ones which call for programming in C but with, you know, a little bit plus.

I resemble that remark.

That's certainly better, but I'm looking for a version in some kind of vector format, not just a larger bitmap that will print out "less" pixelated.

This ends a situation in which two companies that would otherwise have been competitive bidders decided that it would cost them less to be a monopoly, and created their own cartel. Since they were a sole provider, they persuaded the government to pay them a Billion dollars a year simply so that they would retain the capability to manufacture rockets to government requirements.

Yes, there will be at least that Billion in savings and SpaceX so far seems more than competitive with the prices United Launch Alliance was charging. There will be other bidders eventually, as well.