The German Tank Problem | Hacker News Reader

The German Tank Problem

en.wikipedia.org

103 points_pius18 comments

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...

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).

>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......"

The same way that U boat captains overestimated the ships they sunk and pilots overestimated the planes they shot own - every plane they took a shot at was counted a hit.

It's the same way you estimate how long a bug fix will take, every line of code you touch is 'fixed'.

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

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

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

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. :)

Apparently it's also a good idea for tanks.

If you store tanks in a SQL database, it is.

If your tank is downloadable, you sholud also provide the hash signature :-)

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

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.

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 ).

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?

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.

Please elaborate?

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

http://search.twitter.com/search?q=i+got+new+iphone will yield slightly better results.

Reply on news.ycombinator.com