Of course it is not smart to do
reward=reward*x long before the result equals the input
You would rather implement it like
reward=50BTC*(pow(x,blockId))
This adds dramatic complexity to the Bitcoin client
Floating-point operations are inherently inexact, making the amount of bitcoins generated dependent on them is just asking for trouble. If anything it would be better to make integer multiplication/division once every several blocks.
Discontinuously diminishing block rewards is less mathematically elegant, but much simpler. The disruption it will cause is fairly minor.
You may also be interested in
http://bitcoin.stackexchange.com/questions/1526/what-are-the-advantages-disadvantages-of-a-continuously-decreasing-block-reward.
EDIT: To improve accuracy when doing decay for every block, work by BTC remaining, not by BTC for this block. That is, in the beginning there are 2,100,000,000,000,000 satoshis remaining. In every block, multiply the amount remaining by 1120732551094 and divide by 1120736250303. The block reward will be the difference between the current remaining amount and the previous remaining amount. This ensures that exactly 2,100,000,000,000,000 satoshis total will be paid. It also means, though, that decay will be faster than intended when the rounding starts being significant, but by then we may move to a finer division than satoshis.
To a mining operator whose margins are marginal (e.g., paying average or above-average electric rates and mining using GPUs) or even mining profitably at these levels, the block halving will be brutal to GPU mining. Like ... come block 210,000 it will be exit stage left, NAO!
Any GPU miner will pull out sooner or later, does it matter if they do it one by one or many of them at once? Besides, people (should) take into account the future halving in current hardware purchase decisions, and variations in electricity costs mean that the halving alone won't cause everyone to quit.