About varocarbas.com


About me


Contact me


Visit customsolvers.com, another side of my work


Valid markup


Valid CSS


© 2015-2017 Alvaro Carballo Garcia


URL friendly


Optimised for 1920x1080 - Proudly mobile unfriendly

R&D projects RSS feed

All projects in full-screen mode


Project 10

Project 9

Project 8

FlexibleParser code analysis:




Chromatic encryption

(v. 1.3)

Pages in customsolvers.com:

Upcoming additions

Failed projects

Active crawling bots:

Ranking type 2


FlexibleParser raw data:

Unit conversion (UnitParser)

Compound types (UnitParser)

Timezones (DateParser)

Currently active or soon to be updated:

Domain ranking

FlexibleParser (DateParser)

Project 10 is expected to be the last formal project of varocarbas.com. I will continue using this site as my main self-promotional R&D-focused online resource, but by relying on other more adequate formats like domain ranking.
Note that the last versions of all the successfully completed projects (5 to 10) will always be available.
Completed (24 days)

Algorithm >

Fractional exponentiation

Completed (57 days)
Completed (26 days)
Completed (47 days)
Completed (19 days)
Completed (14 days)
Non-floating-point fractional exponentiation approach
Completed on 16-Nov-2016 (24 days)

Project 10 in full-screenProject 10 in PDF

The fractional exponentiation calculations are performed by PowFractionalPositive, which deals with all the exponentiation scenarios involving non-integer positive exponents. Its algorithm is a Number-based implementation of the expression x^m/n = root(x, n)^m and that's why is formed by three main parts:
  • Fraction determination. The exponents are always decimal variables which need to be converted to fractions via GetFraction.
    Note that the aforementioned method doesn't look for the most simplified alternative, but for a 10-based one (e.g., 0.4 outputting 4/10 rather than 2/5). The reason for relying on what seems a less efficient approach is explained in the next point.
    Additionally, this method avoids the denominator to grow beyond 1e25m, what implies that only the first 25 decimal digits of the exponent will be considered. As explained in the corresponding (code) comment, this limitation is meant to avoid numbers beyond the decimal precision in the subsequent Newton-Raphson calculations. As far as this issue shouldn't be seen as a problem (the 26th decimal position of the exponent being relevant?!), I have no plans to fix it.
  • Calculation of the n root. This is the most important part of the described implementation and of the current project. Here is where the non-floating-point high precision expectations become more problematic; the point where the generic implementations fail; what justifies the last part of this project.
    The next section, together with the aforementioned last part, explains all this code in detail. Nevertheless, its main ideas can already be summarised in the following points:
    • GetNRoot implements the Newton-Raphson method.
    • This method is highly dependent upon the initial guess (i.e., fx[1] right at the start).
    • The approach determining the initial guess works well with multiple-of-10 roots.
  • Raising the calculated root to m by calling PowIntegerPositive (already described in the previous section).