@zolern:
My point was exactly that the library function is NOT to be considered as bad
implemetned for not optimizing this case. Such optimizations come with cost
(additional runtime checks), yet at least they have a cost of implementing them
(their developers effort/time), so all possible optimizations cannot be done,
library/compiler developers should choose more probable and more sane cases
among all possible, to optimize them (say, -2 could also be optimized just to
instantly return 4, and -2.5 to instantly return -6.25, ..., but there's
infinity of numbers).
And this particular case (using POW for 1, -1, ...) is not of those worth both
runtime checks and library developers effort. If the programmer considers
efficiency (and readability too!) a little bit, why would he write it this way?
So what point in optimizing it? GCC does better in this case.
Yet for such special cases special (if the programmer just likes writing this
way) just-in-time optimizations can be made, like
proc pow(x: static[float], y: float): float = (when x == -1.0:
float([1,-1][y.int mod 2]) else: math.pow(x, y))
(yet faster with template), or with term rewriting, smth like
template optPowMinusOne{pow(-1.0, x)}(x: float): float = float([1,-1][y.int
mod 2])
(this didn't work for me though, may be someone can point what's wrong with it).
