## FlexibleParser code

Project 10
Completed (24 days)

## Project 9

Completed (57 days)

## Project 8

Completed (26 days)

## Project 7

Completed (47 days)

## Project 6

Completed (19 days)

## Project 5

Completed (14 days)

The integer exponentiation method (i.e., the one being called when using `Math2.PowDecimal` with an integer exponent) is `PowIntegerPositive`. It implements an exponentiation by squaring approach and relies on the `decimal` type, either directly or indirectly through `Number`. 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, `PowIntegerPositive` 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., `System.Math.Pow` 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 `Pow`/`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.