In article <(E-Mail Removed)-berlin.de>,

http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de (Stefan Ram) wrote:

> | Supersedes: <(E-Mail Removed)-berlin.de>

>

> Calculating the remainder of a java.math.BigInteger object

> | seems to be slow. To test divisibility by 100, for a number

> | larger than 100, it would be sufficient and possibly faster to

> just extract the two least significant digits and compare them

> with »00«. But I can not directly access the internal

> representation of a java.math.BigInteger object. Does anyone

> see a possibility to accelerate such a divisibility test for a

> java.math.BigInteger object using the same tricks one uses

> when testing this by mental arithmetic?
If BigIntegers are stored in two's-complement form (they are only

required to behave that way) then getLowestSetBit() might be a faster

test for divisibility by powers of two.

Using toString(int radix), you can examine any glyph in a BigInteger's

representation in any base up to Character.MAX_RADIX. The conversion

will likely be slower than a remainder, but you only have to do it once

to check a number of divisibility shortcuts for small integers. Sadly,

the conversion itself is usually done with a series of divisions, so I

don't see a net gain.

Sorry, I lost track of the larger goal.

> (This is not premature optimization. I already have a program

> that is too slow, and a profiler showed that it spends a

> significant amount of time in java.math.BigInteger.remainder:

> [...]

> Because the profiler also includes program startup and other

> phases of the process, the percentage of the

> java.math.BigInteger.remainder operation is larger then shown

> above when put in relation to the actual calculation phase.)
Some Java profilers (NetBeans, Eclispe, others?) let you focus on

subsets of the code for a clearer picture.

--

John B. Matthews

trashgod at gmail dot com

home dot woh dot rr dot com slash jbmatthews