Триумф Воли

Вчера посмотрели эту гадость. Поучительное кино, конечно. Немецкая армия, по нынешнему - так это сплошные гомики, только серьёзные. Спинки друг другу трут, борются полуголые, и очень этим горды.

Лидеры (фюреры) все довольно молодые, держатся просто. Называют друг друга "товарищ" - "а сейчас выступит товарищ Геббельс" - и товарищ Геббельс начинает впаривать, как немецкий народ должен восстановить свою былую гордость, как много делает партия, какое молодёжь ждёт светлое будущее.

Всякие шествия и митинги, как у комсомольских стройотрядов.

Все ужасно довольны собой, и рады, что всё скоро будет совершенно заебись. При этом военные парады вызывают просто смех - скачут на лошадях, каски трясутся; едут на каких-то фанерных броневичках.

Ведь ни одна эта сволочь не имела в виду какую-нибудь гадость учинить родине, все только добра и желали, и процветания - и народ отвечал любовью и старанием.

Ну и что вышло?

calculating percentage

How To Calculate Percentage

The problem looks stupid, right? You have two numbers, k and n, result is 100*k/n, right? Wrong.

Suppose, in real life, you have in a database n items belonging to your project, and k of them are finished. In your gxp you write something like that, 100*k/n.

First, for some reasons, for certain projects n = 0. You have an exception thrown. Oops.

So you add the check:

n == 0 ? 0 : 100 * k / n

This would work, if we did not have the harsh reality all around. You probably do not expect a negative value of n - still it can happen, if it was wrongly calculated somewhere. Check for it:

n <= 0 ? 0 : 100 * k / n

How about k, are you interested in checking k for negative values? Who knows what happens in those databases...

(n <= 0 || k <= 0) ? 0 : 100 * k / n

Now what if somehow, by the moment of this calculation, k is higher than n? For instance, you retrieve k first, and then, while you were rendering other things, someone has deleted half of the items, and n became lower. Or you took n first, and the next microsecond someone had doubled n and k. We know about transactions, but who would care about transactions while just counting 10 records? In principle, a benevolent user would not mind seeing values over 100%... but managers are not that kind of users. They'll remind you that 101% till the rest of your employment. And if it is 10000%, as happened once with my friend (he did just this, 100 * k / n, in his PL/SQL function), and the user is Dale Fuller, a CEO... bad, bad. So, let's limit the value:

(n <= 0 || k <= 0) ? 0 : Math.min(100, 100 * k / n)

Wait... suppose there are 10000 items in total; and 4999 are finished. Do you want to report 49%, while it is practically 50%? Of course we'd rather round the numbers, to be closer to reality:

(n <= 0 || k <= 0) ? 0 : Math.min(100, (100 * k + n/2) / n)

That would work great... except one special case. Suppose again that we have 10000 items in total, and 9951 are finished. The formula gives us 100%... bad answer again! Never report 100% if k is less than n! That's... what is it? Sarbanes-Oxley? Something like that.

Now here is the final formula that I believe might work in most of the circumstances:

(n <= 0 || k <= 0) ? 0 : Math.min(k < n ? 99 : 100, (100 * k + n/2) / n)

Love it?

(no subject)

Говнокрут Кралевски рулит!