Should not integer exponentiation work when it works?
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Should not integer exponentiation work when it works?
- From: Dirk Laurie <dirk.laurie@...>
- Date: Thu, 9 Jun 2016 10:45:34 +0200
I know I am reopening an old can of worms.
I find that need to code something the following quite often.
n=327 -- some integer calculated earlier
u = 2*n+1
v = u*u
simply because
v=(2*n+1)^2
returns a float. It feels as if I am programming in some low-level
language where intermediates must be stored explicilty. I am doing
the work that the compiler should do.
More seriously, there may occur mathematically wrong results when
it is not necessary.
> 37^12%37
16.0
Some alternatives are:
1. v=math.floor((2*n+1)^2) -- no warning of precison loss
2. v=ipow(2*n+1,2) for some user-written ipow(n,p) that falls back to
floating n^p if
(a) n and p are not both integers
(b) p<0
(c) the exponentiation operation overflows the integers.
3. v=(2*n+1)[2] after doing debug.setmetatable(1,{__index=ipow})
The last is not always terribly readable, e,g,
> (37)[12]%37
0
Would it not be nice if 37^12 returned 6582952005840035281?
I'm not asking that an integer exponent always calls a different
algorithm, only that when integer^n with integer n>=0 can be
represented exactly, that exact result will be provided.
One difficulty is that ipow is not easy to write. We are multiplying
large numbers in the process, e.g
> 69343957*3512479453921
3761551257857134389
In base 10, you can see the result is wrong (the last digit should
be a 7) so there must have been an overflow, but is there a cheap,
elegant way to detect it?