Re: integer exponentiation with negative exponent

[Dirk Laurie <dirk.laurie@...>]

2014-04-29 12:19 GMT+02:00 Philipp Janda <siffiejoe@gmx.net>:

> There have been lots of arguments in this thread. The problem is that none
> of the proposals so far are best in all of consistency, usefulness, speed,
> expected behavior, _and_ backwards compatibility. So it's basically a
> judgment call about what you value most and how much the other categories
> suffer ...

That's a nice list of criteria.

1. Consistency. I can't improve on what Emerson said about it.
2. Usefulness. Throwing an error for 2^n when n is negative is useful,
so is returning 2.0^n. Silently returning 0, though consistent with
2^n == 1/2^n, is not useful.
3. Speed. It has to be quite a small exponent for repeated multiplication
to compete with built-in floating-point exponentiation instructions in
a modern CPU. The real case for such an algorithm is that there is no
loss of precision when the result is a 64-bit integer. Not applicable
to negative powers.
The other speed issue seems to be the overhead of a function call
versus a VM instruction for whatever feature ^ does not provide.
I can't believe there are many programs around with a CPU bottleneck
caused by zillions of exponentiations.
4. Expected behaviour. This seems to mean different things to
different people. It even means different things to the same person
at different points of the learning curve.
5. Backwards compatibility. This is IMHO of paramount importance
unless there is a substantial advantage in breaking it. E.g. Lua 5.1
programs that used `goto` as a name are now broken, but
the new keyword allows multilevel break, resume and continue.
That's substantial. Nothing like it here.