Ideally, we would like to minimize the lossiness of divuq to the lowest-precision bit. There are 3 broad strategies:

1. Full-precision multiplication + division with native ops when inputs are acceptably bounded inside uint256

• Implemented

2. Full-precision 336x256 division when inputs exceed uint256

• https://medium.com/wicketh/mathemagic-512-bit-division-in-solidity-afa55870a65
• https://github.com/gnosis/solidity-arithmetic

3. Long division

• https://blog.veitheller.de/Fixed_Point_Division.html

The proof for Babylonian square root algorithm in audit report is wrong
https://uniswap.org/audit.html

https://github.com/Uniswap/uniswap-lib/blob/2e31d2c594caf01f16041cd73d8701c43b87cc16/contracts/libraries/Babylonian.sol#L5

The fact that it uses the Babylonian method is an implementation detail. SquareRoot is what it does, and that is what should be expressed. You could call it, GasEfficientSquareRoot, at least that more clearly expresses what it does and why someone would want to use it.

After version 0.7.0,while regular string literals can only contain ASCII, Unicode literals – prefixed with the keyword unicode – can contain any valid UTF-8 sequence.

string memory a = unicode"Hello 😃";

So the pragma in PairName.sol should be solidity >=0.5.0 <0.7.0;

This function does not work correctly. If you call: fullDiv(
uint256 l,
uint256 h,
uint256 d
)

with l=238, d = 234, the return value is: 72246346276274207401031469278924933959732554534972317734020543868185115074491

if you call with l=2m d=234, the output is:
94019217756795201412301227143806420906501269600306440886739063938049122357213