

The German Tank Problem - _pius
http://en.wikipedia.org/wiki/German_tank_problem

======
dimitar
I wonder how did the "conventional intelligence" so grossly overstate the
production of German tanks. If the conventional analysis were true there would
be ~350,000 tanks produced for two years of intensive warfare! Which is really
funny considering that Germany invaded the Soviet Union with something like
4000 tanks if I recall correctly. 246 a month is the statistically estimated
data, which is both close to the real number (245) and common sense - no
matter how much you militarize a country you still need raw materials and Nazi
Germany was no Soviet Union.

the source for this in wikipedia is the Guardian:

[http://www.guardian.co.uk/world/2006/jul/20/secondworldwar.t...](http://www.guardian.co.uk/world/2006/jul/20/secondworldwar.tvandradio)

addition: such a feat of production was possible, but in the Soviet Union and
at an extraordinary high cost of human lives and slave labor.

addition2: In fairness the Germans could produce more tanks if they wanted to.
But they built some pretty useless ships thought - Graf Zeppelin or Bismarck,
for example and oversize guns like the famous Dora. But still.. there is a
limit to the number of tanks realistically produced and Allied intelligence
must have been aware of the availability of raw materials in the Reich and the
construction of Bismark and Tirpitz and all the other huge ships (their
construction began before the war).

~~~
ErrantX
>how did the "conventional intelligence" so grossly overstate the production

Probably 1 word - fear.

Or more explicitly fear of underestimating the figures; that kind of thing can
be fatal! The human factor in this example is huge (nearly a factor of 8 I
think for some months) but you can see the same happening everywhere. No
matter how precise the statistical estimates are a human will always think
"yeh but they could......"

:)

------
jgrahamc
I assume this is getting mentioned because of this story I submitted to HN:
<http://news.ycombinator.com/item?id=670065>

~~~
_pius
Yeah, I hadn't seen this since college until reading your request, thanks. :)

------
harry
Tanks and math! Best way to start my morning. Thanks subby.

------
jjs
Heh, I was just thinking about this problem recently; it played a (small) part
in my decision to use random-ish strings as primary keys rather than
autoincrementing ints. :)

~~~
xal
hah, you better not be doing this on mysql/innodb

~~~
jjs
I am for the moment; if postgres is really that much better in this regard,
please let me know why you think so.

Incidentally, I'm using VARBINARY, not VARCHAR for the keys.

~~~
xal
Mysql/innodb lays out the data on disk in sort order of the primary key. If
you use GUIDs as primary key it will have to re-write the entire disk layout
every time you insert. Just use auto inc IDs, they are by far the best option
as long as you use a suffix of 10 or so to avoid ID collisions when you ever
have several masters to write to ( which you will never have ).

~~~
jjs
There are other reasons I want to use strings-as-keys. Are you familiar with
how, say, postgres handles this sort of thing, and is it any better in this
regard?

~~~
jjs
It occurs to me that I could still use integer primary keys internally and
have indexed strings as external lookup keys. I want the same key to be able
to show (a) which user, (b) which database, and (c) which row, so I can verify
ownership and route directly to the particular sub-db without having to do
several lookups first.

------
joshu
Same reason you shouldn't ever expose (or use) auto_increment numbers.

------
quizbiz
<http://search.twitter.com/search?q=i+got+new+iphone> will yield _slightly_
better results.

