The integer exponentiation method (i.e., the one being called when using
with an integer exponent) is
. It implements an exponentiation by squaring approach
and relies on the
type, either directly or indirectly through
. As indicated by its name and equivalently to what happens with the fractional exponentiation, this method only expects positive inputs.
In calculations involving non-integer exponents
is called at least twice: when determining the root of the exponent denominator and when raising that result to its numerator. In that first scenario, various calls are likely to occur because the root finding algorithm, despite converging quite quickly (custom-improved
Newton-Raphson), usually needs various iterations.
Contrarily to what happens in the fractional part, the current version of the integer exponentiation algorithm might even compete in speed with the native version (i.e.,
with integer exponents). In any case, the following two issues would need to be taken into account:
- Just the fact of being part of the .NET Framework itself (
Pow) or of a library created in a .NET language (
PowDecimal) represents an unmeasurable uncertainty which affects the reliability of the measurements. Note that the open-source essence isn't helpful here as far as the
Sqrt source codes haven't been made public. So in principle (i.e., without Microsoft's help), there is no way around this issue.
Number is the most efficient NumberX, but it performs notably worse than a native type like
decimal. For NumberParser,
Number is undoubtedly the best option; for performance-measuring purposes, it would be better to replace these variables with native ones.