double precision vs. integers

[Andersen]

I want to take power of something, or the logarithm of something, with
different bases. the Math.* are only defined for doubles, how do I do
these operations if I am sure that everything is a perfect integer log
or a perfect power (integer).

 

[Andersen]

I want to take power of something, or the logarithm of something, with
different bases. the Math.* are only defined for doubles, how do I do
these operations if I am sure that everything is a perfect integer log
or a perfect power (integer).

I extend that question to ceiling and floor which return integers/longs.

 

[O.L.]

Andersen a écrit :

I want to take power of something, or the logarithm of something, with
different bases. the Math.* are only defined for doubles, how do I do these
operations if I am sure that everything is a perfect integer log or a perfect
power (integer).

int a = 5;
int b = 2;
int pow = (int) Math.pow(a, b);

?

 

[Andersen]

int a = 5;
int b = 2;
int pow = (int) Math.pow(a, b);

I want the results to be precise and not have any mishaps because of the
conversion.

 

[Mark Thornton]

I want the results to be precise and not have any mishaps because of the
conversion.

The specification of Math.pow() includes this

"If both arguments are integers, then the result is exactly equal to the
mathematical result of raising the first argument to the power of the
second argument if that result can in fact be represented exactly as a
double value"

Thus if the arguments are integers and the result is within the range of
int, then the expression given will be correct. This is one of the
advantages of Java's specification; it provides useful guarantees in
circumstances like this.

Mark Thornton

 

[Googmeister]

I want the results to be precise and not have any mishaps because of the
conversion.

Not a problem with Math.pow since all values of type int are exactly
representable using type double. According to the API

If both arguments are integers, then the result
is exactly equal to the mathematical result of
raising the first argument to the power of the
second argument if that result can in fact be
represented exactly as a double value.

 

[Roedy Green]

I want to take power of something, or the logarithm of something, with
different bases. the Math.* are only defined for doubles, how do I do
these operations if I am sure that everything is a perfect integer log
or a perfect power (integer).

You can take your answer then round it and see if it matches exactly.

see http://mindprod.com/jgloss/round.html

 

[Thomas Weidenfeller]

I want the results to be precise and not have any mishaps because of the
conversion.

Well, you might want your logarithms "to be precise" in integer
notation, but I am afraid, the odds are very much against you.

logarithms of negative numbers result in complex numbers, so lets forget
about negative numbers at all.

For positive integers, lets take a logarithm where there is some chance
of getting exact results: A logarithm for the base 2 [1]. Then for a 31
bit integer (32 bits minus the sign bit), there are only 32 out of
2147483647 possible integers (the 0 included) where the base 2 logarithm
fits exactly into an integer[1].

That is roughly a chance of one in 67 million to get an exact result for
a random non negative integer argument from a base 2 logarithm.

I think you should reconsider your requirements.

/Thomas

[1] Logarithm computating degenerates into bit counting in this case.

[2] All cases where there is only a single bit true within the 31 bits,
plus when all are false (the 0).

 

[Thomas Weidenfeller]

ITYM 31 cases, or else you've come up with a new way
of defining the logarithm of zero.

Ups

(Also, if "the 0 included"
then why only 2147483647 possible integers instead of ...8?)

Because, ahem, because, aehm, aehm, well

/Thomas

 

[Chris Uppal]

You could do an all-integer (or -long) version using
repeated multiplication: start with 1, multiply by k until
you get n, and return the count. You'd never need more
than 30 (62) iterations in the worst legitimate case.

Or a table lookup (probably with a binary chop or similar).

-- chris

 

[Thomas Weidenfeller]

Hope you had a little fun there.

Sure, nothing in the group's charter prohibits having a bit of fun.

And as a general hint, playing with then numbers and some formulas when
you have a math problem at hand doesn't hurt. It gives you some feel for
the problem.

I have an application where I know the
numbers are powers of some base k,

k being a positive integer? Why didn't you tell us this upfront? You
could e.g. handle that problem with a lookup table. E.g for a base 2 a
table of 31 integers if you really don't trust log():

final static int logs2[] = {
0x00000001, 0x00000002, 0x00000004, 0x00000008,
0x00000010, 0x00000020, 0x00000040, 0x00000080,
0x00000100, 0x00000200, 0x00000400, 0x00000800,
0x00001000, 0x00002000, 0x00004000, 0x00008000,
0x00010000, 0x00020000, 0x00040000, 0x00080000,
0x00100000, 0x00200000, 0x00400000, 0x00800000,
0x01000000, 0x02000000, 0x04000000, 0x08000000,
0x10000000, 0x20000000, 0x40000000
};

final static int logs3[] = {
1, 3, 9, 27,
...
};


private int binSearch(int values[], int e) throws ImpreciseException
{
int l = 0;
int r = values.length - 1;
int p;
while(l <= r) {
p = (l + r) / 2;
if(e == values[p]) return p;
if(e < values[p]) {
r = p - 1;
} else {
l = p + 1;
}
}
throw new ImpreciseException();
}

public int preciseLog2(int e) throws ImpreciseException
{
return binSearch(logs2, e);
}

public int preciseLog3(int e) throws ImpreciseException
{
return binSearch(logs3, e);
}


/Thomas

 

[Andersen]

k being a positive integer? Why didn't you tell us this upfront? You
could e.g. handle that problem with a lookup table. E.g for a base 2 a
table of 31 integers if you really don't trust log():

That is fine if you need 5 different k's, if you want something general
you need more tables. Given what I said earlier that I am not interested
in the trivial logarithm: log_k(k), that would mean we need
floor(sqrt(2^n)) tables for a n bit numbers. Only for 31 bits that would
be some 46340 tables or so. I suppose you could generate these in a list
of lists... The only limit would be the memory, it would take 100kb of
memory or so, not much for a PC, huge for a smaller device under MIDP.